[Sugar-devel] [ANNOUNCE] sugar-toolkit has been branched
Hi, sugar-toolkit has now a sucrose-0.88 [1] branch for backporting fixes intended for future releases in the 0.88.x series. Unstable development leading to 0.90 will happen in master [2]. Regards, Simon [1] http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/logs/sucrose-0.88 [2] http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/logs/master ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Patches to mail list, or patches to trac?
On 07/05/2010 02:47 PM, Tomeu Vizoso wrote: On 07/01/2010 08:32 PM, Gary Martin wrote: Hi folks, Just wanted to ask the obvious question. Patches to mail list, or patches to trac? About acceptance, the current process is in place until its wiki page is changed: http://wiki.sugarlabs.org/go/Development_Team/Code_Review Now, that process already mentioned reviews on mailing lists in some cases and of course, doesn't forbid people from sending patches to the ml for non-acceptance reviews. Patches to mail-list seem great for quick random 'easy' feedback from and for any one who cares to give it, and I really like seeing little code snippets go past. However it seems vital that with the current process we at least make a final closing stage (currently tickets in trac) where the hard final call can be made and the loop closed. Yup, I guess this is the acceptance part of it which needs to be very clear to submitters and thus should be agreed by all maintainers of official modules. Personally I read mail in a bunch of different places/devices and there's no way I can currently (and sanely) keep track of all the list activity and know who suggested what, what was actually agreed, and what is still outstanding. I've had a few patches and reviews now from kind folk posting to the mail-list, but for me, I've ended up having to ask folks to create git clones so I can pull in patches in a maintainable work flow. I dread to think what it must be like trying to look after several large core modules! Last we discussed this, I understood that the conclusion is that the parties interested in a particular submission will keep pinging the maintainer in public (irc, ml) until it gets reviewed. I still think it would be much better to have a simpler queue such as http://bugs.sugarlabs.org/wiki/TomeuReviewQueue in which you know more clearly what is awaiting review and exactly which patches they are (well, when the submitter properly discards all patches and don't put several patches in the same ticket), but it was contended that the bureaucracy needed was too much and discouraged contributions. Regards, Tomeu The main problem I am seeing with having trac and the mailing list being used is that the two parts get out of sync. As a well-behaving maintainer, I have to follow both discussions in order to follow up. For example take http://bugs.sugarlabs.org/ticket/1926 There is a ticket and a mailing list discussion with patches, icons etc. Now, there is no link in the ticket to this discussion, and one needs to follow both tracks. Of course adding policies such as link the ml-discussion in the ticket can help here. Do people have a plan/policy for this? Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Write-70
On Tue, Jul 6, 2010 at 5:00 AM, Sugar Labs Activities activit...@sugarlabs.org wrote: Activity Homepage: http://activities.sugarlabs.org/addon/4201 Sugar Platform: 0.86 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26971/write-70.xo Release notes: Fix startup zoom level (sl#1121) Could the Write developer upload a tar file to http://download.sugarlabs.org/sources/sucrose/fructose/Write/ Cheers, Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity title update
On Mon, Jul 05, 2010 at 11:57:42AM -0400, Bernie Innocenti wrote: On Mon, 2010-07-05 at 16:37 +0200, Tomeu Vizoso wrote: But you can do the same with Gtk+, cannot you? This signal is emitted when the Return or Enter key is pressed or the line edit loses focus No, GTK does not seem to send a focus-out-event when the user clicks on the close button. Which is what makes my approach fail. In other applications, I've synthesised this event in the callback on the close button. One might also catch mouse motion and conclude editing has ended when the mouse is ordered away from the text entry widget. As for metadata taking ~1 sec to update ... wow, that's slow! -- 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] Activity title update
On Mon, Jul 5, 2010 at 17:57, Bernie Innocenti ber...@codewiz.org wrote:
On Mon, 2010-07-05 at 16:37 +0200, Tomeu Vizoso wrote:
But you can do the same with Gtk+, cannot you?
This signal is emitted when the Return or Enter key is pressed or the
line edit loses focus
No, GTK does not seem to send a focus-out-event when the user clicks
on the close button. Which is what makes my approach fail.
Ok, that's quite different from what I read initially.
Have made a little test that seems to show that when the user clicks
on a button and a text field had the focus, the focus is moved from
the field to the button and thus focus-out-event is emitted:
import gtk
def focus_out_event_cb(entry, event):
print 'focus-out-event'
def button_activate_cb(button):
gtk.main_quit()
w = gtk.Window()
w.show()
hbox = gtk.HBox()
w.add(hbox)
hbox.show()
e = gtk.Entry()
e.connect('focus-out-event', focus_out_event_cb)
hbox.add(e)
e.show()
b = gtk.Button('mec')
b.connect('clicked', button_activate_cb)
hbox.add(b)
b.show()
gtk.main()
Have printed the C traceback in focus_out_event_cb and it seems to be
emitted when the button gains focus.
Any idea why this is not working in the activity toolbar?
Regards,
Tomeu
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity title update
On Tue, Jul 06, 2010 at 11:05:34AM +0200, Tomeu Vizoso wrote:
On Mon, Jul 5, 2010 at 17:57, Bernie Innocenti ber...@codewiz.org wrote:
On Mon, 2010-07-05 at 16:37 +0200, Tomeu Vizoso wrote:
But you can do the same with Gtk+, cannot you?
This signal is emitted when the Return or Enter key is pressed or the
line edit loses focus
No, GTK does not seem to send a focus-out-event when the user clicks
on the close button. Which is what makes my approach fail.
Ok, that's quite different from what I read initially.
Have made a little test that seems to show that when the user clicks
on a button and a text field had the focus, the focus is moved from
the field to the button and thus focus-out-event is emitted:
I've tested this fragment on F11 for XO-1.5, and I agree, it does seem
to be working fine. I added a changed callback, and as far as I can
tell a metadata update could be deferred until changed plus a delta
time, or focus-out, whichever occurs first.
import gtk
def changed_cb(entry):
print 'changed-event'
def focus_in_event_cb(entry, event):
print 'focus-in-event'
def focus_out_event_cb(entry, event):
print 'focus-out-event'
def button_activate_cb(button):
gtk.main_quit()
w = gtk.Window()
w.show()
hbox = gtk.HBox()
w.add(hbox)
hbox.show()
e = gtk.Entry()
e.connect('focus-in-event', focus_in_event_cb)
e.connect('focus-out-event', focus_out_event_cb)
e.connect('changed', changed_cb)
hbox.add(e)
e.show()
b = gtk.Button('mec')
b.connect('clicked', button_activate_cb)
hbox.add(b)
b.show()
gtk.main()
--
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] Activity title update
On Tue, Jul 06, 2010 at 07:30:52PM +1000, James Cameron wrote:
[...] and as far as I can tell a metadata update could be deferred
until changed plus a delta time, or focus-out, whichever occurs first.
This is what I mean: untested. I also think the metadata update should
be avoided if there is no change to the value, which occurs if (a)
changes are made and then reverted before timeout, or (b) focus out. I
don't know that the way I've done it below will work.
diff --git a/src/sugar/activity/widgets.py b/src/sugar/activity/widgets.py
index 5b712f2..f2f4693 100644
--- a/src/sugar/activity/widgets.py
+++ b/src/sugar/activity/widgets.py
@@ -190,6 +190,7 @@ class TitleEntry(gtk.ToolItem):
self.entry = gtk.Entry(**kwargs)
self.entry.set_size_request(int(gtk.gdk.screen_width() / 3), -1)
self.entry.set_text(activity.metadata['title'])
+self.entry.connect('focus-out-event', self.__title_focus_out_cb,
activity)
self.entry.connect('changed', self.__title_changed_cb, activity)
self.entry.show()
self.add(self.entry)
@@ -203,6 +204,11 @@ class TitleEntry(gtk.ToolItem):
def __jobject_updated_cb(self, jobject):
self.entry.set_text(jobject['title'])
+def __title_focus_out_cb(self, entry, event, activity):
+if self._update_title_sid is not None:
+gobject.source_remove(self._update_title_sid)
+self.__update_title_cb(activity)
+
def __title_changed_cb(self, entry, activity):
if self._update_title_sid is not None:
gobject.source_remove(self._update_title_sid)
@@ -212,9 +218,10 @@ class TitleEntry(gtk.ToolItem):
def __update_title_cb(self, activity):
title = self.entry.get_text()
-activity.metadata['title'] = title
-activity.metadata['title_set_by_user'] = '1'
-activity.save()
+if activity.metadata['title'] != title:
+activity.metadata['title'] = title
+activity.metadata['title_set_by_user'] = '1'
+activity.save()
shared_activity = activity.get_shared_activity()
if shared_activity is not None:
--
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] Activity title update
And, for what it is worth, Sugar 0.84 only connects the focus-out-event, it doesn't connect changed. Also, it avoids a save if the name is unchanged. src/sugar/activity/activity.py ActivityToolbar -- 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] [PATCH 3/3] Add config.py.in and update AC_CONFIG_FILES.
On Mon, Jun 14, 2010 at 06:14, Andrés Ambrois andresambr...@gmail.com wrote: config.py is generated from config.py.in at configure time by autoconf, so it needs to be added to AC_CONFIG_FILES in configure.ac. Signed-off-by: Andrés Ambrois andresambr...@gmail.com create mode 100644 extensions/cpsection/modemconfiguration/config.py.in diff --git a/configure.ac b/configure.ac index 13a2f09..68a8bf3 100644 --- a/configure.ac +++ b/configure.ac @@ -56,6 +56,7 @@ extensions/cpsection/frame/Makefile extensions/cpsection/keyboard/Makefile extensions/cpsection/language/Makefile extensions/cpsection/modemconfiguration/Makefile +extensions/cpsection/modemconfiguration/config.py extensions/cpsection/Makefile extensions/cpsection/network/Makefile extensions/cpsection/power/Makefile diff --git a/extensions/cpsection/modemconfiguration/Makefile.am b/extensions/cpsection/modemconfiguration/Makefile.am index 3e2613e..525e02e 100644 --- a/extensions/cpsection/modemconfiguration/Makefile.am +++ b/extensions/cpsection/modemconfiguration/Makefile.am @@ -4,3 +4,5 @@ sugar_PYTHON = \ __init__.py \ model.py \ view.py + +nodist_sugar_PYTHON = config.py diff --git a/extensions/cpsection/modemconfiguration/config.py.in b/extensions/cpsection/modemconfiguration/config.py.in new file mode 100644 index 000..6fa688e --- /dev/null +++ b/extensions/cpsection/modemconfiguration/config.py.in @@ -0,0 +1,20 @@ +# -*- encoding: utf-8 -*- +# Copyright (C) 2010 Andrés Ambrois +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 US + +PROVIDERS_PATH = @prefix@/share/mobile-broadband-provider-info/serviceproviders.xml +PROVIDERS_FORMAT_SUPPORTED = 2.0 +COUNTRY_CODES_PATH = @prefix@/share/zoneinfo/iso3166.tab Hi, we should instead be looking for these files in the paths in $XDG_DATA_DIRS as per http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html Regards, Tomeu -- 1.6.3.3 ___ 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] [DESIGN] Using providers database for 3G modem configuration
Hi, anybody has input on this proposed feature? http://bugs.sugarlabs.org/ticket/1630 http://people.collabora.co.uk/~tomeu/providers_database.png Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 2/3] Show Country/Provider/Plan comboboxes if DB exists.
On Mon, Jun 14, 2010 at 06:14, Andrés Ambrois andresambr...@gmail.com wrote:
Display comboboxes for selecting a data plan for each country and
provider if the mobile-broadband-providers-info package is installed.
Populate the connection parameters with the info from the selected data
plan.
Signed-off-by: Andrés Ambrois andresambr...@gmail.com
diff --git a/extensions/cpsection/modemconfiguration/view.py
b/extensions/cpsection/modemconfiguration/view.py
index b236f3f..e2fdd53 100644
--- a/extensions/cpsection/modemconfiguration/view.py
+++ b/extensions/cpsection/modemconfiguration/view.py
@@ -160,61 +160,142 @@ class ModemConfiguration(SectionView):
self._model = model
self.restart_alerts = alerts
-self.set_border_width(style.DEFAULT_SPACING)
self.set_spacing(style.DEFAULT_SPACING)
-self._group = gtk.SizeGroup(gtk.SIZE_GROUP_HORIZONTAL)
+
+label_group = gtk.SizeGroup(gtk.SIZE_GROUP_HORIZONTAL)
+
+scrolled_win = gtk.ScrolledWindow()
Better try to avoid abbreviations.
+scrolled_win.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
+scrolled_win.show()
+self.add(scrolled_win)
+
+main_box = gtk.VBox(spacing=style.DEFAULT_SPACING)
+main_box.set_border_width(style.DEFAULT_SPACING)
+main_box.show()
+scrolled_win.add_with_viewport(main_box)
explanation = _(You will need to provide the following \
information to set up a mobile \
broadband connection to a cellular \
(3G) network.)
self._text = gtk.Label(explanation)
-self._text.set_width_chars(100)
self._text.set_line_wrap(True)
self._text.set_alignment(0, 0)
-self.pack_start(self._text, False)
+main_box.pack_start(self._text, False)
self._text.show()
+if model.has_providers_db():
Put this in a separate private method so __init__ doesn't grow so big?
Nothing else, please wait a bit before pushing this so people have
time to comment on the UX. Next time is better to start the design
discussion as soon as possible, even if there's no code or mockups
yet.
Also may be better to hold off the commits and do one more review
round if you aren't 100% confident about the XDG data dirs thing.
Thanks a lot for following the code style of the existing code, this
has made the review much faster.
Regards,
Tomeu
+self._upper_box = gtk.VBox(spacing=style.DEFAULT_SPACING)
+self._upper_box.set_border_width(style.DEFAULT_SPACING)
+main_box.pack_start(self._upper_box, expand=False)
+self._upper_box.show()
+
+combo_group = gtk.SizeGroup(gtk.SIZE_GROUP_HORIZONTAL)
+
+box = gtk.HBox(spacing=style.DEFAULT_SPACING)
+label = gtk.Label(_('Country:'))
+label_group.add_widget(label)
+box.pack_start(label, False)
+label.show()
+country_store = model.CountryListStore()
+country_combo = gtk.ComboBox(country_store)
+combo_group.add_widget(country_combo)
+cell = gtk.CellRendererText()
+cell.props.xalign = 0.5
+country_combo.pack_start(cell)
+country_combo.add_attribute(cell, 'text', 0)
+country_combo.connect('changed', self.__country_selected_cb)
+box.pack_start(country_combo, False)
+country_combo.show()
+self._upper_box.pack_start(box, False)
+box.show()
+
+box = gtk.HBox(spacing=style.DEFAULT_SPACING)
+label = gtk.Label(_('Provider:'))
+label_group.add_widget(label)
+box.pack_start(label, False)
+label.show()
+self._providers_combo = gtk.ComboBox()
+combo_group.add_widget(self._providers_combo)
+cell = gtk.CellRendererText()
+cell.props.xalign = 0.5
+self._providers_combo.pack_start(cell)
+self._providers_combo.add_attribute(cell, 'text', 0)
+self._providers_combo.connect('changed',
+ self.__provider_selected_cb)
+box.pack_start(self._providers_combo, False)
+self._providers_combo.show()
+self._upper_box.pack_start(box, False)
+box.show()
+
+box = gtk.HBox(spacing=style.DEFAULT_SPACING)
+label = gtk.Label(_('Plan:'))
+label_group.add_widget(label)
+box.pack_start(label, False)
+label.show()
+self._plan_combo = gtk.ComboBox()
+combo_group.add_widget(self._plan_combo)
+cell = gtk.CellRendererText()
+cell.props.xalign = 0.5
+self._plan_combo.pack_start(cell)
+self._plan_combo.add_attribute(cell, 'text', 0)
Re: [Sugar-devel] [DESIGN] Using providers database for 3G modem configuration
On Tue, Jul 6, 2010 at 13:29, pbrobin...@gmail.com pbrobin...@gmail.com wrote: On Tue, Jul 6, 2010 at 12:07 PM, Tomeu Vizoso to...@tomeuvizoso.net wrote: Hi, anybody has input on this proposed feature? http://bugs.sugarlabs.org/ticket/1630 http://people.collabora.co.uk/~tomeu/providers_database.png I presume that's the ModemManager provider DB? Yup. Regards, Tomeu Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Fwd: [Bugs] #1747 UNSP: Default sugar-emulator window size does not follow HIG
Hi, this ticket raises the question of how the layout section in the HIG should be interpreted/modified for screens with different proportions than that of the XO-1. Regards, Tomeu -- Forwarded message -- From: Sugar Labs Bugs bugtracker-nore...@sugarlabs.org Date: Tue, Feb 23, 2010 at 13:51 Subject: Re: [Bugs] #1747 UNSP: Default sugar-emulator window size does not follow HIG To: Cc: b...@lists.sugarlabs.org #1747: Default sugar-emulator window size does not follow HIG --+- Reporter: alsroot | Owner: tomeu Type: enhancement | Status: new Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team Component: sugar | Version: Git as of bugdate Severity: Unspecified | Keywords: r? Distribution: Unspecified | Status_field: Unconfirmed --+- Changes (by sascha_silbe): * cc: sascha_silbe (added) * keywords: = r? * version: Unspecified = Git as of bugdate Comment: I'm not convinced changing sugar-emulator to use some odd size (832x624 with the default scaling of 72 if I've got my math right) is a good idea. Sugar should scale well to real-world screen sizes. 800x600 was chosen because it's used in actual, current hardware. If we really want to raise the bar, we should go for 1024x600 (used by several netbooks, e.g. [http://en.wikipedia.org/wiki/EeePC#Specifications Asus Eee PC]). -- Ticket URL: http://bugs.sugarlabs.org/ticket/1747#comment:2 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Bugs mailing list b...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/bugs ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Patches to mail list, or patches to trac?
I was thinking that google groups deals great with two views on the same discussion (forum-like comments and ml). Could something like that be done for trac? Would it be a good idea? On 6 July 2010 09:07, Simon Schampijer si...@schampijer.de wrote: On 07/05/2010 02:47 PM, Tomeu Vizoso wrote: On 07/01/2010 08:32 PM, Gary Martin wrote: Hi folks, Just wanted to ask the obvious question. Patches to mail list, or patches to trac? About acceptance, the current process is in place until its wiki page is changed: http://wiki.sugarlabs.org/go/Development_Team/Code_Review Now, that process already mentioned reviews on mailing lists in some cases and of course, doesn't forbid people from sending patches to the ml for non-acceptance reviews. Patches to mail-list seem great for quick random 'easy' feedback from and for any one who cares to give it, and I really like seeing little code snippets go past. However it seems vital that with the current process we at least make a final closing stage (currently tickets in trac) where the hard final call can be made and the loop closed. Yup, I guess this is the acceptance part of it which needs to be very clear to submitters and thus should be agreed by all maintainers of official modules. Personally I read mail in a bunch of different places/devices and there's no way I can currently (and sanely) keep track of all the list activity and know who suggested what, what was actually agreed, and what is still outstanding. I've had a few patches and reviews now from kind folk posting to the mail-list, but for me, I've ended up having to ask folks to create git clones so I can pull in patches in a maintainable work flow. I dread to think what it must be like trying to look after several large core modules! Last we discussed this, I understood that the conclusion is that the parties interested in a particular submission will keep pinging the maintainer in public (irc, ml) until it gets reviewed. I still think it would be much better to have a simpler queue such as http://bugs.sugarlabs.org/wiki/TomeuReviewQueue in which you know more clearly what is awaiting review and exactly which patches they are (well, when the submitter properly discards all patches and don't put several patches in the same ticket), but it was contended that the bureaucracy needed was too much and discouraged contributions. Regards, Tomeu The main problem I am seeing with having trac and the mailing list being used is that the two parts get out of sync. As a well-behaving maintainer, I have to follow both discussions in order to follow up. For example take http://bugs.sugarlabs.org/ticket/1926 There is a ticket and a mailing list discussion with patches, icons etc. Now, there is no link in the ticket to this discussion, and one needs to follow both tracks. Of course adding policies such as link the ml-discussion in the ticket can help here. Do people have a plan/policy for this? Regards, Simon ___ 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] [DESIGN] Using providers database for 3G modem configuration
This is just a small aesthetic side-note, but it would look better if the country/provider/plan text was right-aligned like the labels below, and if the description above (You will need to provide ...) spanned the entire width of the window. Otherwise this looks great! Christian On Tue, Jul 6, 2010 at 7:07 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: Hi, anybody has input on this proposed feature? http://bugs.sugarlabs.org/ticket/1630 http://people.collabora.co.uk/~tomeu/providers_database.png Thanks, Tomeu -- anyth...@christianmarcschmidt.com 917/ 575 0013 http://www.christianmarcschmidt.com http://www.linkedin.com/in/christianmarcschmidt http://twitter.com/cms_ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Fwd: [Bugs] #1747 UNSP: Default sugar-emulator window size does not follow HIG
Why not use sugar-emulator -f option in terminal (full screen mode)? Tom Gilliard satellit Tomeu Vizoso wrote: Hi, this ticket raises the question of how the layout section in the HIG should be interpreted/modified for screens with different proportions than that of the XO-1. Regards, Tomeu -- Forwarded message -- From: Sugar Labs Bugs bugtracker-nore...@sugarlabs.org Date: Tue, Feb 23, 2010 at 13:51 Subject: Re: [Bugs] #1747 UNSP: Default sugar-emulator window size does not follow HIG To: Cc: b...@lists.sugarlabs.org #1747: Default sugar-emulator window size does not follow HIG --+- Reporter: alsroot| Owner: tomeu Type: enhancement| Status: new Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team Component: sugar |Version: Git as of bugdate Severity: Unspecified| Keywords: r? Distribution: Unspecified| Status_field: Unconfirmed --+- Changes (by sascha_silbe): * cc: sascha_silbe (added) * keywords: = r? * version: Unspecified = Git as of bugdate Comment: I'm not convinced changing sugar-emulator to use some odd size (832x624 with the default scaling of 72 if I've got my math right) is a good idea. Sugar should scale well to real-world screen sizes. 800x600 was chosen because it's used in actual, current hardware. If we really want to raise the bar, we should go for 1024x600 (used by several netbooks, e.g. [http://en.wikipedia.org/wiki/EeePC#Specifications Asus Eee PC]). -- Ticket URL: http://bugs.sugarlabs.org/ticket/1747#comment:2 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Bugs mailing list b...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/bugs ___ 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 1/3] Add models for detecting and parsing
from jarabe.model.network import GSM_USERNAME_PATH, GSM_PASSWORD_PATH, \
GSM_NUMBER_PATH, GSM_APN_PATH,
GSM_PIN_PATH, \
GSM_PUK_PATH
+from cpsection.modemconfiguration.config import PROVIDERS_PATH, \
+PROVIDERS_FORMAT_SUPPORTED, \
+COUNTRY_CODES_PATH
+
def get_username():
client =3D gconf.client_get_default()
return client.get_string(GSM_USERNAME_PATH) or ''
@@ -68,3 +77,103 @@ def set_puk(puk):
client =3D gconf.client_get_default()
client.set_string(GSM_PUK_PATH, puk)
+def has_providers_db():
+if not os.path.isfile(COUNTRY_CODES_PATH):
+return False
+try:
+tree = ElementTree(file=PROVIDERS_PATH)
+elem = tree.getroot()
+if elem is None or elem.get('format') != PROVIDERS_FORMAT_SUPPORTED:
+return False
+return True
+except IOError:
+return False
Consider checking for file existence and readability with
os.access().
As a general safety rule, it's better to open the file, catch any errors, and
do any further work via fstat(), openat(), and friends because doing so avoids
some annoying time-of-check-to-time-of-use (TOCTTOU) races without being any
more difficult. However, beware: when designing for a hostile environment, more
care is needed [1].
[1]: http://www.usenix.org/events/fast08/tech/tsafrir.html
+class CountryListStore(gtk.ListStore):
+COUNTRY_CODE =3D locale.getdefaultlocale()[0][3:5].lower()
+
+def __init__(self):
+gtk.ListStore.__init__(self, str, object)
+codes =3D {}
+with open(COUNTRY_CODES_PATH) as codes_file:
Using 'with' like that makes us depend on Python 2.6.
Fortunately, using 'with' with a
from __future__ import with_statement
import is Python-2.5 compatible.
Regards,
Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Activity packaging
On Mon, 2010-07-05 at 16:20 +0200, Tomeu Vizoso wrote: Sorry about the confusion, these questions were about the move from xo bundles to packages :( Ah! Communication FAIL! :) Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. To obtain (2) and (7), we might want to wrap the native packages with a distro-neutral meta-format, similar to the current activity.info files. I don't know the details yet, but I guess this is pretty much what Aleksey is doing with his 0sugar redesign. I think switching to a native package format is essential: currently, both the Fedora and Ubuntu teams are spending a lot of time to re-packaging just a few activities, resulting in duplicated effort and increased time-to-market for activities. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. --Ben P.S. This cross-posting is getting ridiculous. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
On Mon, 2010-07-05 at 08:22 -0600, Daniel Drake wrote: On 3 July 2010 16:52, Bernie Innocenti ber...@codewiz.org wrote: I checked: olpc-update-query only sets the clock if it's off by more than 24hours, so it cannot serve as a replacement for ntpdate. What's the requirement for super-accurate clocks on the XO? It doesn't have to be super-accurate, just good enough to show a clock with a meaningful time. Laptops with anti-theft enabled can get the time from the OATS server when it's off by more than 24 hours. Unlocked laptops don't have a way to synchronize the time at all. All we need to fix it is a trivial shell script. Why not do it? NOTE: whoever is interested in supporting configurations that take away root access from users will probably want to remove this functionality as well. Very sad :-( -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI experiments: pop-up menus and hot corners
Err, we've dropped sugar-devel off the cc list again :-) On Mon, 2010-07-05 at 10:37 -0400, Christian Marc Schmidt wrote: We are looking to schedule a design meeting next Saturday (July 10), at 10:30am EST (2:30 UTC/GMT). We'll be reviewing designs for the proposed Start new/Resume functionality in Home view. Please join! This Saturday I'll be in Belo Horizonte, probably without Internet connection. I'll try to join in if I can. Thanks, Christian On Sun, Jul 4, 2010 at 7:05 PM, Bernie Innocenti ber...@codewiz.org wrote: On Sun, 2010-07-04 at 23:42 +0100, Gary Martin wrote: P.S. We keep slipping on a date/time for the next irc #sugar-meeting design meeting, folks are most welcome, Christian has some nice mockups he's been polishing up for publication. We're trying again for tomorrow/Monday, but no time confirmed just yet. Tomorrow (monday) I'll be in Caacupé all day and I might be offline most of the time. Please, give me some advance notice if the meeting is happening tomorrow. p.s. The Journal user-interface was invented, with a filter capability. Now a full screen dialogue user-interface would be duplicating what the Journal can show. I myself am not comfortable with duplication. I agree with Mikus, but I'd like to see the mock-ups -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Schoolserver security
On Sat, Jul 3, 2010 at 8:09 AM, Bernie Innocenti ber...@codewiz.org wrote: El Thu, 01-07-2010 a las 20:55 -0600, Daniel Drake escribió: Child connects to a network, perhaps just to go online outside of school. The network has an XS. The laptop registers. The journal is backed up to the server. Ok, this is a serious security issue. Ho hum. Remove the serious and I'll agree. Low pri at the moment. How about asking the user to confirm registration to an unknown server, like ssh does? For slightly improved security, we could hash the ssh fingerprint to a color pair, so the teacher could say your schoolserver is blue and red, don't register to any other. Nope. It'd be easy to brute force (gentle force?) to get the appropriate colours. As you've already figured out, asking a 6-y-o to check an ssh fingerprint is not the fix either... A real fix is to upgrade the reg protocol to be signed -- we can copy the OAT protocol, and use/reuse the OAT keys. To be secure then, the XS needs to have a valid OAT delegation. plenty of scary webapps. *You* are a scary webapp ;-) In more serious terms, I hope you can tone down the level of scare about security. For starters: We don't handle bank acct or CC info. And we don't require users to login to their own user sessions. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - 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] Clocks on XOs
On 6 July 2010 10:10, Bernie Innocenti ber...@codewiz.org wrote: Laptops with anti-theft enabled can get the time from the OATS server when it's off by more than 24 hours. Unlocked laptops don't have a way to synchronize the time at all. All we need to fix it is a trivial shell script. Why not do it? I think it's fine that individual deployments can do it. But it shouldn't be done globally because it weakens the security system. A globally acceptable solution could be to decrease the safety guard on the olpc-update-query check so that it corrects the time if it is (e.g.) more than 1 hour out. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Tue, Jul 6, 2010 at 1:50 PM, John Gilmore g...@toad.com wrote: I think you are missing an important requirement: installation without elevated permissions. Enhancing deb or rpm to be able to do this would be a win all around. Yes, it's been in the To Do list for dpkg and rpm for as long as I've been using Linux -- I asked about this for rpms in '98. Sadly, the rate of development around rpm and dpkg is... well... slow... rpm has a leg up, anyway, in that it has (limited? buggy?) support for relocatable rpms. It would be amazing for the overall health of Linux distros if someone took this on and worked on it all the way to getting it done and merged. Packages (and maint scripts) would need to be updated/adapted to support this, and of course it's not appropriate for all packages. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - 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] [ASLO] Release StarChart-12
Activity Homepage: http://activities.sugarlabs.org/addon/4300 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26976/starchart-12.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] Activity packaging
On Tue, Jul 06, 2010 at 11:51:00AM -0400, Bernie Innocenti wrote: On Mon, 2010-07-05 at 16:20 +0200, Tomeu Vizoso wrote: Sorry about the confusion, these questions were about the move from xo bundles to packages :( Ah! Communication FAIL! :) Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. To obtain (2) and (7), we might want to wrap the native packages with a distro-neutral meta-format, similar to the current activity.info files. I don't know the details yet, but I guess this is pretty much what Aleksey is doing with his 0sugar redesign. Just to mention how it could look like on high level http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar#How_it_works_at_a_glance i.e. for activity developer, process should look like pretty straight forward, everything what he needs is a spec file. Spec file is not like regular activity.info (some kind of metadata file that is used in runtime) but a regular spec file like .spec in rpm. Some examples of real (but for now only built only for 0install) http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Python_library http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Vala_library and how it will look like for activities http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Python_activity The milestones I'm planing are: * Having just 0sugar.info spec file (and 0distro build time dependency on obs), build native packages on bunch of rpm and deb based distros on OBS. I'm planing to have rpm and deb packages for Sucrose, Polyol, GC, OOo4Kids built from only 0sugar.info spec files in two weeks * Having just 0sugar.info and 0sugar tool, distribute homemade blobs (already works) and blobs built on OBS via 0install * merge all things together and make it useful within sugar - move all packaging related stuff from current glucose to some kind of packaging core with using 0install as an unified packaging engine, such core could be e.g. a dbus service (but could be a library as well) e.g. for now, shell does things like: decides what activities to use, from /usr or from ~/Activities, plain versions vs. dotted versions (sounds a bit amusing). All these tasks will be handled within new packaging core - switch from bundle_id identification to http urls for activities, (at some point it sounds like urls for microformat updates) it could be really useful if user on any sugar box could run activity just by mentioning its url * new UI, how it could look like with new packaging infrastructure So, Zero Sugar will be useful already in two weeks e.g. it should be possible to attach Sugar:Platform:Factory repo from obs to have development sucrose on major rpm/deb distros (http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets) or install sugarized GC (in form of application or activity) from native packages. The rest of steps could be implemented in parallel manner. I think switching to a native package format is essential: currently, both the Fedora and Ubuntu teams are spending a lot of time to re-packaging just a few activities, resulting in duplicated effort and increased time-to-market for activities. just an OBS feature that could be used as is if most of activities will accessible from obs http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/Use_Cases#Per_user_Sugar_on_a_stick -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. XO and SoaS distributions are configured for sudo with no password. Rainbow has been bit-rotting for the past 2 years and nobody volunteered to work on it. The bottom line is that *nowadays*, any activity can escalate root privileges. Before someone screams in horror, consider this: the only valuable data on the laptop belongs to user olpc. A non-privileged account can already effectively do anything that a spammer would like to do. Even in a Rainbow-enabled environment, privileged vs unprivileged installation isn't by itself the source of security issues. Packages could easily be checked to ensure that all bundled files are within a specific path, like we currently do with the zip files. Post-install scriptlets can be disabled. Even with these limitations, a native packaging system is still years ahead of us in terms of robustness and feature-completeness. P.S. This cross-posting is getting ridiculous. Mikus keeps moving this thread to other lists because he won't subscribe to sugar-devel. (why?? ask him). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
On Tue, 2010-07-06 at 11:21 -0600, Daniel Drake wrote: I think it's fine that individual deployments can do it. But it shouldn't be done globally because it weakens the security system. Which security system, the theft deterrence? Well, granting root access from the console already weakens it to the point of being useless. Who would bother to setup a fake DHCP, DNS and NTP server when it takes 20 seconds to crack it from the console? :-) Where you thinking of a different scenario? A globally acceptable solution could be to decrease the safety guard on the olpc-update-query check so that it corrects the time if it is (e.g.) more than 1 hour out. This isn't globally acceptable: many (most?) laptops run without a OATS server, so their clock would remain wrong forever. PS: I just found yet another laptop which won't activate because the clock was set to 15 July 2000 (not 2010!). Do you see many of these? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
On Sat, Jul 3, 2010 at 9:54 AM, Bernie Innocenti ber...@codewiz.org wrote: Likely so, but the software should be able to compensate for it. After discussing it on IRC, it seems that olpc-update-query should automatically update the clock from the OATS server. Do _not_ rely on this for accurate clock setting. It only kicks in if - the clock is really off - the XS has delegated OATS keys NetworkManager used to call ntpdate when it setup a connection. Was that an OLPC addition? We figured out that the ntp package has never been present on the XO images. Um? I thought it was there -- perhaps in much older builds? ... There's no way to practical way to implement effective anti-theft without taking away root from the user. And once we take away root access, we've also taken away olpc's principle #1: child ownership. Not true on several levels. We can control the clock in OFW for the case where the time is reset to the past. Not implemented (yet) but planned. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - 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] Activity packaging
On Tue, 2010-07-06 at 19:56 +, Aleksey Lim wrote: Just to mention how it could look like on high level http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar#How_it_works_at_a_glance Will it also remove the need to ship fat bundles, as we do now? I mean, will it produce separate packages for each architecture/os or just one large package with many binaries in it? I tend to prefer the first way, like rpm and deb do. - move all packaging related stuff from current glucose to some kind of packaging core with using 0install as an unified packaging engine, such core could be e.g. a dbus service (but could be a library as well) e.g. for now, shell does things like: decides what activities to use, from /usr or from ~/Activities, plain versions vs. dotted versions (sounds a bit amusing). All these tasks will be handled within new packaging core Wouldn't PackageKit be a perfect match for this? So, Zero Sugar will be useful already in two weeks e.g. it should be possible to attach Sugar:Platform:Factory repo from obs to have development sucrose on major rpm/deb distros (http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets) or install sugarized GC (in form of application or activity) from native packages. It's an amazing piece of work, Aleksey!! Considering that you're tackling on the hardest problem in the Sugar universe, I'm very impressed by the progress you've made in such a short amount of time. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
On 6 July 2010 15:03, Bernie Innocenti ber...@codewiz.org wrote: Well, granting root access from the console already weakens it to the point of being useless. Who would bother to setup a fake DHCP, DNS and NTP server when it takes 20 seconds to crack it from the console? :-) Right. So with that logic, lets just throw out the whole security system. Ignoring the fact that some deployments ship without root access. And that there are efforts to solve that in the future. Having ntp sync like this weakens the security system because it means that when you fix one problem (of easy root access, for example), you still have other ones that make your system easily defeatable. Instead, if you choose not to add more holes, once you fix the existing ones then you have a fully secure system. This isn't globally acceptable: many (most?) laptops run without a OATS server, so their clock would remain wrong forever. This picture is rapidly changing. PS: I just found yet another laptop which won't activate because the clock was set to 15 July 2000 (not 2010!). Do you see many of these? This was probably a human error in the Fix_clock repair process that happened on that laptop. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
On Tue, 2010-07-06 at 16:36 -0600, Daniel Drake wrote: On 6 July 2010 15:03, Bernie Innocenti ber...@codewiz.org wrote: Well, granting root access from the console already weakens it to the point of being useless. Who would bother to setup a fake DHCP, DNS and NTP server when it takes 20 seconds to crack it from the console? :-) Right. So with that logic, lets just throw out the whole security system. Ignoring the fact that some deployments ship without root access. Is the practice of completely locking-down the laptops something we'd even want to encourage? Assuming we don't, why should we cripple time-syncing for everyone just to simplify an unsupported customization? And that there are efforts to solve that in the future. Oh, I was unaware of this. Who is working on it, and what's the exact plan? Having ntp sync like this weakens the security system because it means that when you fix one problem (of easy root access, for example), you still have other ones that make your system easily defeatable. Instead, if you choose not to add more holes, once you fix the existing ones then you have a fully secure system. Easy root access is not a security bug, it's a feature that OLPC deliberately chose to give to all users. I even submitted a mingetty patch adding --loginpause which we use to drop into the root console. Why? Because, without root access, children would own the XO the same way consumers own the iPhone and the TiVo. They could crash the physical thing on the floor and burn it, but not flip one bit without government's authorization. I may sound a bit melodramatic, but a project of this kind wouldn't have inspired me to volunteer even for one day. Moralities apart, I guess anyone would agree on the purely technical statement that we can't make OATS work effectively without also taking away root privileges (or the best parts of it). Any half-hearted compromise is likely to be as ineffective as it is annoying. This isn't globally acceptable: many (most?) laptops run without a OATS server, so their clock would remain wrong forever. This picture is rapidly changing. I thought the default was changed one year ago from locked to unlocked. I would be surprised if many deployments had the technical skills to deal comfortably with the complexity of the activation system, when it is very challenging even for us. We probably disagree here, but I think that in most cases OATS costs more to maintain than its actual economical benefit. Admittedly, it works very well at addressing a problem of fear that may play a big role in influencing decision makers. Come on, we all secretly know this and play dumb :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Tue, Jul 06, 2010 at 05:59:04PM -0400, Bernie Innocenti wrote: On Tue, 2010-07-06 at 19:56 +, Aleksey Lim wrote: Just to mention how it could look like on high level http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar#How_it_works_at_a_glance Will it also remove the need to ship fat bundles, as we do now? I mean, will it produce separate packages for each architecture/os or just one large package with many binaries in it? I tend to prefer the first way, like rpm and deb do. There is no any bundles in core design i.e. if you are talking about fat bundles we are talking about distribution method, in my mind such distribution methods could be: * via distro repos on obs(or other build farm), users attach these repos * via 0install, user just type sugar-activity/0lauch http-url to start activity or any software * for sneakernet, 0sugar tool could generate bundles like ./setup.py dist_xo does, imho there is not huge need in having smart/fat bundles like I tried to to with 0installed bundles; but anyway later practice will make it more clear - move all packaging related stuff from current glucose to some kind of packaging core with using 0install as an unified packaging engine, such core could be e.g. a dbus service (but could be a library as well) e.g. for now, shell does things like: decides what activities to use, from /usr or from ~/Activities, plain versions vs. dotted versions (sounds a bit amusing). All these tasks will be handled within new packaging core Wouldn't PackageKit be a perfect match for this? Firstly, 0install already can install native packages via PackageKit and secondly (keeping in mind your reply to Benjamin), talking about *only* native packages we loose one simple and core-for-sugar thing, any sugar user should be, at the end, a doer. For example, if we have TuxPaint activity and many doers are experimenting (change C code and compile) with it, what can do a person, who decides to try all these TuxPaint activities, having native packages as only distribution method? ask all doers use the same repo (sounds useless); attach repos per doer (conflicts); handle all issues by himself (not useful as well). With having 0install (which is already exists and works) as engine, we handle these issues automatically. Using 0install doesn't mean that everything is ok with 0install from sugar pov, e.g. one of core sugar workflows when user need only place activity to ~/Activities to make it useful is absent in 0install (it designed as regular packaging system e.g. there is no need in changing some software in /usr/lib). So, 0install is required later hacking but it effectively solve last of packaging issues - how to *launch*(not install) arbitrary activity in heterogeneous environment. So, Zero Sugar will be useful already in two weeks e.g. it should be possible to attach Sugar:Platform:Factory repo from obs to have development sucrose on major rpm/deb distros (http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets) or install sugarized GC (in form of application or activity) from native packages. It's an amazing piece of work, Aleksey!! Considering that you're tackling on the hardest problem in the Sugar universe, I'm very impressed by the progress you've made in such a short amount of time. Well, not so short amount of time, my first commit to jhconvert (my first experience in meta packaging) was Fri Dec 05 01:29:55 + 2008 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
Bernie wrote: On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. XO and SoaS distributions are configured for sudo with no password. Yes. However, Uruguay does not maintain this configuration choice. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. Rainbow, on the other hand, has seen a major new release, feature development that spurred new work in general Linux sandboxing, and is now available in more distributions than ever before thanks to dedicated support by folks like Luke, Sascha, and Jonas. Finally, if rainbow itself now receives little day-to-day attention, this is because it mostly does what its authors require and it does it well enough not to require their continued hand-holding. and nobody volunteered to work on it. If you check the dates carefully, you'll find that most of my recent work on rainbow and rainbow/sugar integration has occurred while I was on vacation from my real job. So please do count that as volunteer hours. The bottom line is that *nowadays*, any activity can escalate root privileges. Sure. And if, by some miracle, Sugar ever becomes *worth* attacking [1], then we will all rue the day when we had the opportunity to make it safe and chose not to. A non-privileged account can already effectively do anything that a spammer would like to do. And when will you be shipping my prctl(PR_DISABLENETWORK) kernel patch? (Or have you a better approach?) Even in a Rainbow-enabled environment, privileged vs unprivileged installation isn't by itself the source of security issues. Packages could easily be checked to ensure that all bundled files are within a specific path, like we currently do with the zip files. Post-install scriptlets can be disabled. I am still much more satisfied with the approach taken by 0install. [2] Regards, Michael [1]: Except by accident, like with GNOME and Sugar today. [2]: Thanks again, Aleksey, for pushing this work forward and for all the improvements you've already contributed back to 0install to make this work better for us! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Physics-5
Activity Homepage: http://activities.sugarlabs.org/addon/4193 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26977/physics-5.xo Release notes: - Added support for new toolbar design for Sugar 0.86 (old toolbars still work for Sugar 0.84 and back) - Objects can now be moved with the Grab tool while the simulation is paused! - Tool code cleanup and refactoring - Includes latest translations Many thanks go to Peter Froehlich, Akash Gangil, Craig Macomber, and the translation team. 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] Clocks on XOs
On Tue, Jul 06, 2010 at 05:03:02PM -0400, Bernie Innocenti wrote: PS: I just found yet another laptop which won't activate because the clock was set to 15 July 2000 (not 2010!). Do you see many of these? just a query as I dont know the details of activation: if the rtc is off by a year or more (10 year?) the laptop will not activte using the required activation lease key? so the rtc must be up-to-date to use an activation lease key? -- | .''`. == Debian GNU/Linux ==.| http://kevix.myopenid.com..| | : :' : The Universal OS| mysite.verizon.net/kevin.mark/.| | `. `' http://www.debian.org/.| http://counter.li.org [#238656]| |___`-Unless I ask to be CCd,.assume I am subscribed._| ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
