Re: [Sugar-devel] [DESIGN] multi-selection in journal
On Tue, May 31, 2011 at 07:45:09PM +1000, James Cameron wrote: > On Tue, May 31, 2011 at 12:38:04AM -0400, Martin Abente wrote: > > Anyway, I would like to hear everyone's feedback on the current design! > > 3. http://www.sugarlabs.org/~tch/journal2.mpeg > > I like it. > It looked nice. I was thinking about a 'move' option? -- | .''`. == 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._| Meade's Maxim: Always remember that you are absolutely unique, just like everyone else. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sunjammer.sugarlabs.org: emergency maintenance downtime, Tue May 31 17:00 UTC
Sunjammer is back online. Apologies for the prolonged outage. This machine hadn't been rebooted in a very long time (over 500 days), therefore I took the opportunity to upgrade the kernel, and migrate the filesystems to ext4. As a result of these and other performance tweaks, all services should feel a little faster. If you notice anything odd, please report it to us sysadmins. -- 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] Non-maintainer uploads of activities
On Sun, May 29, 2011 at 6:53 PM, Gonzalo Odiard wrote:
> I am not so sure this is a solution.
> I think we need active maintainers, not only bugs fixes.
> IMHO we need a MIA ("missing in action") or "non responsive maintainer"
> policy.
> We have hundred of pending tickets, from months or years ago.
> And when we start to work in a abandoned activity, there are not a clear
> way to request
> access to git or aslo (aslo is easier than git)
> Debian have policies [1] point 7.4, and teams [2] to manage MIA,
> Fedora have a Non responsive maintainers policy [3].
> Probably, we can change the time lapses, but the general idea is the same.
>
> Gonzalo
>
>
> [1]
> http://docs.huihoo.com/debian/manuals/developers-reference/ch-beyond-pkging.en.html
> [2] http://wiki.debian.org/Teams/MIA
> [3]
> http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
>
>
> I tend to agree more with Gonzalo here,
although I think that we'll need both policies in the long run,
as we have been experiencing, the key to solve some activities problems (as
Gonzalo depicted) is a MIA policy. Debian overall process is very well
described, we can follow it but changing time frames.
On Sat, May 28, 2011 at 11:46 AM, Sascha Silbe <
> sascha-ml-reply-to-201...@silbe.org> wrote:
>
>> Hi!
>>
>> I would like to propose adopting the Debian Non-Maintainer-Upload (NMU)
>> process [1] for Fructose. Individual activity authors would also be
>> encouraged to allow their activities to be NMU'ed following this policy.
>> The sections I'd consider applicable to Sugar Labs are 5.11.1, 5.11.2
>> (read debian/changelog as Release Notes) and 5.11.4. Since the version
>> number rules are different in Sugar, the NMU should append ".1" instead
>> of "+nmu1" (e.g. "123.1" for an NMU based on the maintainer release
>> "123").
>>
>> A few key points:
>> - NMUs are only to be done for bug fixes
>> - all bugs that get fixed by the NMU must have been reported in the BTS
>> [2]
>> - the maintainer must have been given sufficient time to act (rule of
>> thumb: 2-10 days depending on the severity of the bug that gets fixed)
>>
>> The Infrastructure Team [3] would be authorised to manage permissions
>> on git.sl.o and a.sl.o as needed for the NMU to happen.
>>
>> Since Sugar Labs lacks an equivalent of the Debian New Maintainer
>> process [4], I would like to add a requirement that the uploader has
>> successfully gone through review for a Sucrose (Glucose + Fructose)
>> package at least once and their patch been included in mainline. Note:
>> Patch author and uploader can be different persons.
>>
>> Sascha
>>
>> [1] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
>> [2] https://bugs.sugarlabs.org/
>> [3] https://wiki.sugarlabs.org/go/Infrastructure_Team
>> [4] http://www.debian.org/devel/join/newmaint
>> --
>> http://sascha.silbe.org/
>> http://www.infra-silbe.de/
>>
>> ___
>> 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 mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] I reinstalled my system back to a previous image, but don't know where to put my public key for gitorious
G'day Laurent, There's not enough information in what you say to let me conclude what the cause is. I presume that you have created a new SSH key pair and uploaded the public one to gitorious. (I don't think you had a good reason to do this, but you did it anyway, and so I have to work from that.) Have you tested this key? For instance, here is how I test my key: ssh gitori...@git.sugarlabs.org true The expected and successful output is "Gitorious: Access denied or bad command". If you see this, then the key is properly installed on both your system and git.sugarlabs.org. If you see something else, then there may be another problem. Next, could you show me what git commit command you try, and what the result is? I'm really surprised you didn't already show us what the result was. There are so many possibilities. You can capture an error to a text file and include it in e-mail. Like this: host:~$ script error.txt Script started, file is error.txt host:~$ git commit host:~$ exit Script done, file is error.txt host:~$ -- 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] I reinstalled my system back to a previous image, but don't know where to put my public key for gitorious
On 05/31/2011 08:35 AM, laurent bernabe wrote: > I think i've done some things strange and unreversable > >- i deleted my public keys >- i tried with a new one >- but still unable to commit > > Should i delete my project from the gitorious and create a new one for it ? No, that wouldn't fix anything. Simply replace your key on gitorious. If this isn't working, a mistake is probably being made somewhere. Please describe how you're generating a new key, and replacing it gitorious, or where else the process is breaking down for you. -- Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs, Systems lfaraone on irc.[freenode,oftc].net -- http://luke.faraone.cc PGP fprint: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 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] Sugar Labs bug tracker used by the OLPCA team?
> -Original Message- > From: sugar-devel-boun...@lists.sugarlabs.org [mailto:sugar-devel- > boun...@lists.sugarlabs.org] On Behalf Of Simon Schampijer > Sent: Tuesday, May 31, 2011 10:05 AM > To: sugar-devel@lists.sugarlabs.org > Subject: Re: [Sugar-devel] Sugar Labs bug tracker used by the OLPCA team? > > On 05/31/2011 10:58 AM, Simon Schampijer wrote: > > On 05/31/2011 02:09 AM, Rafael Ortiz wrote: > >> On Mon, May 30, 2011 at 6:12 PM, James Cameron > wrote: > >> > >>> On Mon, May 30, 2011 at 04:52:51PM -0500, Rafael Ortiz wrote: > Although, I really like this QA workflow, I'm not sure if this will > prevent people from the community to follow the workflow, e.g an > ''outsider'' or an activity developer that wants to close a bug or > do follow-ups that require a change of state on the workflow. For > starters there should be a wiki page where to document this in > order to point people to the process. > > In my opinion this could be yet another wall to enter sugar > development. > >>> > >>> I agree. > >>> > >>> I also don't like the workflow. I think organisations should use > >>> their own trackers to represent work they plan to do for themselves, > >>> and use Sugar tracker as well for work that Sugar Labs may be involved in. > >>> > >>> Thus a ticket in the Sugar Labs tracker would be closed when the > >>> problem is fixed to the satisfaction of Sugar Labs. (e.g. fix committed to git). > >>> > >>> Thus a ticket in the downstream organisation tracker would be closed > >>> when the problem is fixed to the satisfaction of the downstream > >>> organisation. (e.g. tested on hardware). > >>> > >>> I don't think it is likely that these events will happen at the same > >>> time, or in the same sequence, and so I don't think it is right to > >>> delay closure. > >>> > >>> This plan may expose the Sugar Labs tracker to a lot more event data > >>> that doesn't really benefit the Sugar Labs community that much. > >>> > >>> If Sugar Labs is happy with it, go for it. I'll work within the > >>> restrictions. I don't have to like it though. > >>> > >>> > >> Fully agree with your comments. I'd prefer we don't use this > >> workflow, but that's my way of viewing it, so community will have to > >> decide. > > > > I understand your concerns. Ideally upstream (SL) would be independent > > from the downstream (OLPCA). And maybe this is a bit sneaky. > > > > So, the current situation in the SL tracker is that it is not taken > > care of much. For example, I have seen that since the review happens > > on the mailing list tickets does not get closed as much anymore. So > > the benefit for SL would be that people help to keep the bug database > > clean and getting free QA. > > > > For OLPCA it gets easier since I do not have to open duplicates to > > trigger the status (either using a one ticket at the OLPC-bug-tracker > > per ticket on the SL-bug-tracker procedure or a multi-SL tickets in > > one OLPCA ticket procedure). > > > > Regards, > > Simon > > Ok, I think I step back on my initial proposal and just go with tagging the tickets > (keywords) we are interested in with '11.2.0'. > > As we need to as well triage the 'priority' field for bugs based on our release > goals we need to rely on our bug tracker anyhow. For new tickets we will try and > file them at the sl tracker and duplicate the tickets important for us on the olpc > tracker. Let's see if that works out for us. I think this is the correct (first draft) approach. It enables OLPC-A to build on the infrastructure and other shared resources Sugar Labs makes available without adding (or even appearing to add) internal process overhead to the community. I suggest waiting a few months to see how things settle out and then revist the issue with a refined workflow in August if necessary. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs bug tracker used by the OLPCA team?
On Tue, May 31, 2011 at 9:05 AM, Simon Schampijer wrote: > On 05/31/2011 10:58 AM, Simon Schampijer wrote: > >> On 05/31/2011 02:09 AM, Rafael Ortiz wrote: >> >>> On Mon, May 30, 2011 at 6:12 PM, James Cameron wrote: >>> >>> On Mon, May 30, 2011 at 04:52:51PM -0500, Rafael Ortiz wrote: > Although, I really like this QA workflow, I'm not sure if this will > prevent people from the community to follow the workflow, e.g an > ''outsider'' or an activity developer that wants to close a bug or do > follow-ups that require a change of state on the workflow. For > starters there should be a wiki page where to document this in order > to point people to the process. > > In my opinion this could be yet another wall to enter sugar > development. > I agree. I also don't like the workflow. I think organisations should use their own trackers to represent work they plan to do for themselves, and use Sugar tracker as well for work that Sugar Labs may be involved in. Thus a ticket in the Sugar Labs tracker would be closed when the problem is fixed to the satisfaction of Sugar Labs. (e.g. fix committed to git). Thus a ticket in the downstream organisation tracker would be closed when the problem is fixed to the satisfaction of the downstream organisation. (e.g. tested on hardware). I don't think it is likely that these events will happen at the same time, or in the same sequence, and so I don't think it is right to delay closure. This plan may expose the Sugar Labs tracker to a lot more event data that doesn't really benefit the Sugar Labs community that much. If Sugar Labs is happy with it, go for it. I'll work within the restrictions. I don't have to like it though. Fully agree with your comments. I'd prefer we don't use this workflow, >>> but >>> that's my way of viewing it, so community will have to decide. >>> >> >> I understand your concerns. Ideally upstream (SL) would be independent >> from the downstream (OLPCA). And maybe this is a bit sneaky. >> >> So, the current situation in the SL tracker is that it is not taken care >> of much. For example, I have seen that since the review happens on the >> mailing list tickets does not get closed as much anymore. So the benefit >> for SL would be that people help to keep the bug database clean and >> getting free QA. >> >> For OLPCA it gets easier since I do not have to open duplicates to >> trigger the status (either using a one ticket at the OLPC-bug-tracker >> per ticket on the SL-bug-tracker procedure or a multi-SL tickets in one >> OLPCA ticket procedure). >> >> Regards, >> Simon >> > > Ok, I think I step back on my initial proposal and just go with tagging the > tickets (keywords) we are interested in with '11.2.0'. > > +1 that's what we have also for dextrose. > As we need to as well triage the 'priority' field for bugs based on our > release goals we need to rely on our bug tracker anyhow. For new tickets we > will try and file them at the sl tracker and duplicate the tickets important > for us on the olpc tracker. Let's see if that works out for us. > > sounds good. cheers > Regards, > Simon > > 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
[Sugar-devel] [PATCH sugar] Fix invitations from a non sugar client (empathy), part of OLPC #10814
This does bring back the 'invitation from a non-sugar client'
functionality based on the 0.84 code. I did remove the part
where we claim to handle as well video invitations for now,
as we can not handle them.
Signed-off-by: Simon Schampijer
---
src/jarabe/model/invites.py | 154 +++
src/jarabe/model/telepathyclient.py | 11 ++-
2 files changed, 111 insertions(+), 54 deletions(-)
diff --git a/src/jarabe/model/invites.py b/src/jarabe/model/invites.py
index d2a2e0c..100ec57 100644
--- a/src/jarabe/model/invites.py
+++ b/src/jarabe/model/invites.py
@@ -17,16 +17,15 @@
import logging
from functools import partial
+import simplejson
import gobject
import dbus
+import gconf
from telepathy.interfaces import CHANNEL, \
CHANNEL_DISPATCHER, \
CHANNEL_DISPATCH_OPERATION, \
CHANNEL_TYPE_CONTACT_LIST, \
- CHANNEL_TYPE_DBUS_TUBE, \
- CHANNEL_TYPE_STREAMED_MEDIA, \
- CHANNEL_TYPE_STREAM_TUBE, \
CHANNEL_TYPE_TEXT, \
CLIENT
from telepathy.constants import HANDLE_TYPE_ROOM
@@ -45,25 +44,51 @@ CONNECTION_INTERFACE_ACTIVITY_PROPERTIES = \
_instance = None
-class ActivityInvite(object):
-"""Invitation to a shared activity."""
-def __init__(self, dispatch_operation_path, handle, handler,
- activity_properties):
+class BaseInvite(object):
+"""Invitation to shared activity or private 1-1 Telepathy channel"""
+def __init__(self, dispatch_operation_path, handle, handler):
self.dispatch_operation_path = dispatch_operation_path
self._handle = handle
self._handler = handler
-if activity_properties is not None:
-self._activity_properties = activity_properties
-else:
-self._activity_properties = {}
-
def get_bundle_id(self):
if CLIENT in self._handler:
return self._handler[len(CLIENT + '.'):]
else:
return None
+def _call_handle_with(self):
+bus = dbus.Bus()
+obj = bus.get_object(CHANNEL_DISPATCHER, self.dispatch_operation_path)
+dispatch_operation = dbus.Interface(obj, CHANNEL_DISPATCH_OPERATION)
+dispatch_operation.HandleWith(self._handler,
+ reply_handler=self._handle_with_reply_cb,
+ error_handler=self._handle_with_reply_cb)
+
+def _handle_with_reply_cb(self, error=None):
+if error is not None:
+raise error
+else:
+logging.debug('_handle_with_reply_cb')
+
+def _name_owner_changed_cb(self, name, old_owner, new_owner):
+logging.debug('BaseInvite._name_owner_changed_cb %r %r %r', name,
+ new_owner, old_owner)
+if name == self._handler and new_owner and not old_owner:
+self._call_handle_with()
+
+
+class ActivityInvite(BaseInvite):
+"""Invitation to a shared activity."""
+def __init__(self, dispatch_operation_path, handle, handler,
+ activity_properties):
+BaseInvite.__init__(self, dispatch_operation_path, handle, handler)
+
+if activity_properties is not None:
+self._activity_properties = activity_properties
+else:
+self._activity_properties = {}
+
def get_color(self):
color = self._activity_properties.get('color', None)
return XoColor(color)
@@ -76,37 +101,47 @@ class ActivityInvite(object):
bundle = registry.get_bundle(bundle_id)
if bundle is None:
self._call_handle_with()
+return
+
+bus = dbus.SessionBus()
+bus.add_signal_receiver(self._name_owner_changed_cb,
+'NameOwnerChanged',
+'org.freedesktop.DBus',
+arg0=self._handler)
+
+model = neighborhood.get_model()
+activity_id = model.get_activity_by_room(self._handle).activity_id
+misc.launch(bundle, color=self.get_color(), invited=True,
+activity_id=activity_id)
+
+
+class PrivateInvite(BaseInvite):
+def __init__(self, dispatch_operation_path, handle, handler,
+ private_channel):
+BaseInvite.__init__(self, dispatch_operation_path, handle, handler)
+
+self._private_channel = private_channel
+
+def get_color(self):
+client = gconf.client_get_default()
+return XoColor(client.get_string('/desktop/sugar/user/color'))
+
+def join(self):
+logging.error('PrivateInvite.join handler %r', self._handler)
+
+registry = bundleregistry.get_registry()
+bundle_id = self.get_bundle_id()
+bundle = registry.get_bundle(bundle_id)
+if bundle is Non
Re: [Sugar-devel] [PATCH sugar] Register with schoolserver: adopt to changes in xmlrpclib for python 2.7 OLPC #10776
On 05/23/2011 10:01 AM, Simon Schampijer wrote: On 05/20/2011 10:15 PM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Thu May 19 16:08:36 +0200 2011: s/adopt/adapt/ (or adjust) Python 2.7 switched from using httplib.HTTP to using httplib.HTTPConnection, as the httplib.HTTPConnection includes a timeout by default we can use a xmlrpclib.Transport directly and do not need to subclass it. I guess we don't need to subclass Transport, but we probably need to call socket.setdefaulttimeout() during Sugar start-up: socket.setdefaulttimeout(timeout) Set the default timeout in floating seconds for new socket objects. A value of None indicates that new socket objects have no timeout. When the socket module is first imported, the default is None. Hmm, yes sounds about right. I don't think we have to do it during sugar startup (not sure about other side-effects), just after the 'else' is fine. In any case I guess the real solution is to make the registration asynchronous: http://bugs.sugarlabs.org/ticket/2289#comment:4 but I did not want to block on it. [src/jarabe/desktop/schoolserver.py] - server = xmlrpclib.ServerProxy(url, _TimeoutTransport()) + if sys.version_info[1]< 7: "if sys.hexversion< 0x0207:" has a higher chance of continuing to work after a transition to Py3K. The 2to3 tool already takes care of renaming xmlrpclib to xmlrpc.client [1]. I guess you mean: "sys.hexversion < 0x207". Is ok to me. + server = xmlrpclib.ServerProxy(url, _TimeoutTransport()) + else: + server = xmlrpclib.ServerProxy(url, xmlrpclib.Transport()) We can skip the transport altogether for 2.7+. That way we support https, too (SafeTransport instead of Transport). Sounds right: "The optional second argument is a transport factory instance; by default it is an internal SafeTransport instance for https: URLs and an internal HTTP Transport instance otherwise." I have attached a new patch with the changes noted here and tested with a school server. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH sugar] Register with schoolserver: adopt to changes in xmlrpclib for python 2.7 OLPC #10776
Python 2.7 switched from using httplib.HTTP to using httplib.HTTPConnection,
as the httplib.HTTPConnection includes a timeout by default we can use a
xmlrpclib.Transport directly and do not need to subclass it.
Signed-off-by: Simon Schampijer
---
src/jarabe/desktop/schoolserver.py |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/jarabe/desktop/schoolserver.py
b/src/jarabe/desktop/schoolserver.py
index aea2357..9491fdf 100644
--- a/src/jarabe/desktop/schoolserver.py
+++ b/src/jarabe/desktop/schoolserver.py
@@ -24,6 +24,7 @@ from string import ascii_uppercase
import random
import time
import uuid
+import sys
import gconf
@@ -123,7 +124,11 @@ def register_laptop(url=_REGISTER_URL):
nick = client.get_string('/desktop/sugar/user/nick')
-server = xmlrpclib.ServerProxy(url, _TimeoutTransport())
+if sys.hexversion < 0x207:
+server = xmlrpclib.ServerProxy(url, _TimeoutTransport())
+else:
+socket.setdefaulttimeout(_REGISTER_TIMEOUT)
+server = xmlrpclib.ServerProxy(url)
try:
data = server.register(sn, nick, uuid_, profile.pubkey)
except (xmlrpclib.Error, TypeError, socket.error):
--
1.7.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [DESIGN] multi-selection in journal
On Tue, 2011-05-31 at 17:06 +0200, Christoph Derndorfer wrote: > On Tue, May 31, 2011 at 11:45 AM, James Cameron > wrote: > On Tue, May 31, 2011 at 12:38:04AM -0400, Martin Abente wrote: > > Anyway, I would like to hear everyone's feedback on the > current design! > > > 3. http://www.sugarlabs.org/~tch/journal2.mpeg > > > I like it. > > > +1 A big +1 from me as well. We had this feature on the Dextrose wishlist for a long time. -- 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
[Sugar-devel] sunjammer.sugarlabs.org: emergency maintenance downtime, Tue May 31 17:00 UTC
Sorry for the short notice, at the FSF we have to reboot the XEN machine which hosts sunjammer for about 1 hour. The following public services will be temporarily unavailable: activities.sugarlabs.org activities-devel.sugarlabs.org activities-testing.sugarlabs.org activities-lb0.sugarlabs.org actividades.sugarlabs.org api.sugarlabs.org bugs.sugarlabs.org bugs-testing.sugarlabs.org bugs-devel.sugarlabs.org buildbot.sugarlabs.org cal.sugarlabs.org dev.sugarlabs.org download.sugarlabs.org download-testing.sugarlabs.org ftp.sugarlabs.org groups.sugarlabs.org ldap.sugarlabs.org id.sugarlabs.org imap.sugarlabs.org join.sugarlabs.org karma.sugarlabs.org karma-devel.sugarlabs.org karma-testing.sugarlabs.org logcollect.sugarlabs.org munin.sugarlabs.org mirrors.sugarlabs.org patchwork.sugarlabs.org people.sugarlabs.org pydocweb.sugarlabs.org planet.sugarlabs.org planet-testing.sugarlabs.org planet-devel.sugarlabs.org rsync.sugarlabs.org secure.sugarlabs.org services.sugarlabs.org static.sugarlabs.org shell.sugarlabs.org smtp.sugarlabs.org ssl-test.sugarlabs.org stats.sugarlabs.org trac.sugarlabs.org upload.sugarlabs.org vueltaciclista.sugarlabs.org webmail.sugarlabs.org wiki.sugarlabs.org wiki.ipv4.sugarlabs.org wiki.ipv6.sugarlabs.org wiki-devel.sugarlabs.org wiki-testing.sugarlabs.org www.sugarlabs.org www.ipv4.sugarlabs.org www.ipv6.sugarlabs.org www-testing.sugarlabs.org www-devel.sugarlabs.org cl.sugarlabs.org pe.sugarlabs.org planet.py.sugarlabs.org -- 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] SunMoonMusic Activity does not open in Mango Lassi
On Mon, May 30, 2011 at 9:19 PM, Art Hunkins wrote:
> James,
>
> Thanks both for your well-expressed advice, as well as your continued
> interest in my musical projects. I've recently had several "go's" at git -
> and thanks to your help, did not experience heart failure (it went quite
> well in fact).
>
> I've discovered what was wrong, and so file your suggestions for my next
> set of troubles.
>
> I've been using primarily 1GB USB sticks, which (with Mango especially)
> doesn't leave much extra room (I use the LiveUSB Creator, reserving the
> remainder of the stick's space). The hitch about Mango is that it doesn't
> allow you to delete any activities, *and* once you add some, you can't
> delete *them* either - even though there is an option to do so.
>
> I always load in my six activities, two of which (with sound files) are 7MB
> each. I've apparently always loaded in the big ones prior to SunMoonMusic.
> It seems the stick just runs out of space. If I load SunMoonMusic before the
> others, it opens and runs fine.
>
> I would hope that all distributions would allow for deleting activities,
> *especially* those added by the user. (This seems to be intended; is
> probably a bug in Mango Lassi.) Many previous distros allowed you to delete
> any activity you wanted.
>
The only activities where deleting is disabled are pre-installed ones. The
ones you install should be able to be deleted. If not, this is a bug.
Regarding the decision to make pre-installed activities permanent, it is
driven by Sugar deployments: teachers requested that certain activities
always be available. Which ones is a deployment x deployment decision. For
SoaS, we have a very limited set of pre-installed activities, but as the
Fedora image grows, the user-space shrinks.
FWIW, from the Terminal Activity, you can delete the pre-loaded activities
in /usr/share/sugar
regards.
-walter
>
> BTW, I enjoyed your tunes, especially the last few. The "fiddle tune" in
> triplets is particularly fetching.
>
> Thanks again -
>
> Art Hunkins
>
> - Original Message - From: "James Cameron"
> To: "Art Hunkins"
> Cc:
> Sent: Monday, May 30, 2011 7:54 PM
> Subject: Re: [Sugar-devel] SunMoonMusic Activity does not open in Mango
> Lassi
>
>
>
> I've no idea what might be special, the activity looks normal to me, but
>> if there is no error log left behind my next step in diagnosis is to
>> launch the activity from a Terminal prompt using sugar-launch, then if
>> still no output is visible launch it with strace and interpret the
>> output.
>>
>> To launch using sugar-launch, start Terminal, "cd" to the activity
>> directory, check the activity bundle id or service name from the
>> activity/activity.info file, and then use it like so:
>>
>> sugar-launch ${NAME}
>>
>> where ${NAME} os the bundle id or service name, in your case
>> org.laptop.SunMoonMusic.
>>
>> It is unfortunate that this is so complex, but an alternative is:
>>
>> cd ~/Activities/SunMoonMusic.activity && \
>> sugar-launch \
>> $(grep bundle_id activity/activity.info | cut -f3 -d' ')
>>
>> To capture further diagnostic data using strace, add the word strace
>> before the word sugar-launch. You can redirect the output to a file.
>>
>> cd ~/Activities/SunMoonMusic.activity && \
>> strace -o strace.log -f \
>> sugar-launch \
>> $(grep bundle_id activity/activity.info | cut -f3 -d' ')
>>
>> I offer to review the output if you still don't see what is causing
>> the problem.
>>
>> --
>> James Cameron
>> http://quozl.linux.org.au/
>>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [DESIGN] multi-selection in journal
On Tue, May 31, 2011 at 11:45 AM, James Cameron wrote: > On Tue, May 31, 2011 at 12:38:04AM -0400, Martin Abente wrote: > > Anyway, I would like to hear everyone's feedback on the current design! > > 3. http://www.sugarlabs.org/~tch/journal2.mpeg > > I like it. +1 Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [DESIGN] multi-selection in journal
Good work! Gonzalo On Tue, May 31, 2011 at 1:38 AM, Martin Abente < martin.abente.lah...@gmail.com> wrote: > Hello Amigos, > > Lately I have been working on the support for multi-selection in the > journal. This feature was originally part of Dextrose3's TODO [1], but > during EduJAM [2], many people were interested in having it on Sugar > mainstream, so I will give it a try ;) > > I already have a functional prototype running on sugar 0.9.x (check > video!) [3], its design was based on different ideas and proposals > [4,5]. My current patch does the minimum required to get this working, > avoiding any big code re-factoring or massive rewrites (for now). > > Anyway, I would like to hear everyone's feedback on the current design! > > Thanks in advance, > tch > > References: > 1. http://wiki.sugarlabs.org/go/Dextrose/3/Todo > 2. http://wiki.sugarlabs.org/go/EduJAM/2011/Brainstorm > 3. http://www.sugarlabs.org/~tch/journal2.mpeg > 4. http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#06 > 5. http://wiki.sugarlabs.org/go/Journal_NewUI > ___ > Dextrose mailing list > dextr...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/dextrose > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Raise alert when trying to send an entry without an associated file OLPC #10798
On 05/30/2011 03:00 PM, Simon Schampijer wrote: On 05/28/2011 08:09 PM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Wed May 25 18:30:45 +0200 2011: We raise the same error when we try to copy an entry without an associated file to an external device. Acked-By: Sascha Silbe Pushed as: http://git.sugarlabs.org/sugar/mainline/commit/bfc725ea04f482cc0aab8bf3c9206f07dd331427 http://git.sugarlabs.org/sugar/mainline/commit/9d0d3720c167e1897fe5b9d055d1763710c507b8 Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit] Only show joined buddies on sharer side, part of OLPC#10578
On 05/28/2011 08:18 PM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Mon May 23 17:43:45 +0200 2011: This is correct yes. Bad wording, better would be: "Show joined buddies on both sides, part of OLPC #10578". OK, with that change: Acked-By: Sascha Silbe Sascha Thanks for the review, pushed as: http://git.sugarlabs.org/sugar-toolkit/mainline/commit/67143d8042c32a0976b063c5af4089da7b325fcf http://git.sugarlabs.org/sugar-toolkit/mainline/commit/5a68809af2a6bf490f5a49c11db21a0c9b3a2ba7 Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Convert nick to a str, follow up on OLPC #10735
On 05/28/2011 07:52 PM, Sascha Silbe wrote:
Excerpts from Simon Schampijer's message of Wed May 25 17:41:13 +0200 2011:
[src/jarabe/frame/activitiestray.py]
@@ -545,7 +545,7 @@ class IncomingTransferPalette(BaseTransferPalette):
self.file_transfer.connect('notify::state', self.__notify_state_cb)
-nick = self.file_transfer.buddy.props.nick
+nick = str(self.file_transfer.buddy.props.nick)
self.props.secondary_text = _('Transfer from %s') % (nick,)
If we'd care about non-UTF-8 locales, this should read something like:
nick = unicode(self.file_transfer.buddy.props.nick, 'utf-8')
text = _('Transfer from %s') % (nick, )
self.props.secondary_text = text.encode('utf-8')
with gettext.ugettext as _.
However there's a lot more that will break in Sugar for non-UTF-8
locales, so for now:
Yes, better to do this in a coherent manner.
Acked-By: Sascha Silbe
Sascha
Pushed as:
http://git.sugarlabs.org/sugar/mainline/commit/5cfb315d89eaa2fb21372f4fb545315bb28fb1e0
http://git.sugarlabs.org/sugar/mainline/commit/dc782bda31b590f89bd097d50dd8e6feb5575adc
Thanks for the review,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Read-89
Activity Homepage: http://activities.sugarlabs.org/addon/4028 Sugar Platform: 0.90 - 0.92 Download Now: http://activities.sugarlabs.org/downloads/file/27394/read-89.xo Release notes: Fix OLPC #10806 - No scrolling in Read fix stop button accelerator, dev.laptop.org #10786 Get back functionalities in EPUB framework Support of text files Restore Topbar in full screen mode (Sascha Silbe) battery display (fullscreen mode): replace HAL with UPower (Sascha Silbe) 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] Sugar Labs bug tracker used by the OLPCA team?
On 05/31/2011 10:58 AM, Simon Schampijer wrote: On 05/31/2011 02:09 AM, Rafael Ortiz wrote: On Mon, May 30, 2011 at 6:12 PM, James Cameron wrote: On Mon, May 30, 2011 at 04:52:51PM -0500, Rafael Ortiz wrote: Although, I really like this QA workflow, I'm not sure if this will prevent people from the community to follow the workflow, e.g an ''outsider'' or an activity developer that wants to close a bug or do follow-ups that require a change of state on the workflow. For starters there should be a wiki page where to document this in order to point people to the process. In my opinion this could be yet another wall to enter sugar development. I agree. I also don't like the workflow. I think organisations should use their own trackers to represent work they plan to do for themselves, and use Sugar tracker as well for work that Sugar Labs may be involved in. Thus a ticket in the Sugar Labs tracker would be closed when the problem is fixed to the satisfaction of Sugar Labs. (e.g. fix committed to git). Thus a ticket in the downstream organisation tracker would be closed when the problem is fixed to the satisfaction of the downstream organisation. (e.g. tested on hardware). I don't think it is likely that these events will happen at the same time, or in the same sequence, and so I don't think it is right to delay closure. This plan may expose the Sugar Labs tracker to a lot more event data that doesn't really benefit the Sugar Labs community that much. If Sugar Labs is happy with it, go for it. I'll work within the restrictions. I don't have to like it though. Fully agree with your comments. I'd prefer we don't use this workflow, but that's my way of viewing it, so community will have to decide. I understand your concerns. Ideally upstream (SL) would be independent from the downstream (OLPCA). And maybe this is a bit sneaky. So, the current situation in the SL tracker is that it is not taken care of much. For example, I have seen that since the review happens on the mailing list tickets does not get closed as much anymore. So the benefit for SL would be that people help to keep the bug database clean and getting free QA. For OLPCA it gets easier since I do not have to open duplicates to trigger the status (either using a one ticket at the OLPC-bug-tracker per ticket on the SL-bug-tracker procedure or a multi-SL tickets in one OLPCA ticket procedure). Regards, Simon Ok, I think I step back on my initial proposal and just go with tagging the tickets (keywords) we are interested in with '11.2.0'. As we need to as well triage the 'priority' field for bugs based on our release goals we need to rely on our bug tracker anyhow. For new tickets we will try and file them at the sl tracker and duplicate the tickets important for us on the olpc tracker. Let's see if that works out for us. Regards, Simon Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] I reinstalled my system back to a previous image, but don't know where to put my public key for gitorious
I think i've done some things strange and unreversable - i deleted my public keys - i tried with a new one - but still unable to commit Should i delete my project from the gitorious and create a new one for it ? Regards 2011/5/31 laurent bernabe > Hello, > > after a serious crash on my system, i restored it from a previous state > thanks to Clonezilla > Unfortunately, in my last image, i did not save my git configuration. > > I kept the public and the private key for my project LearningWriting, but i > don't know where to put them, so that i can't commit yet on my project. > > Does someone know how i can manage ? > > Regards > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] I reinstalled my system back to a previous image, but don't know where to put my public key for gitorious
Hello, after a serious crash on my system, i restored it from a previous state thanks to Clonezilla Unfortunately, in my last image, i did not save my git configuration. I kept the public and the private key for my project LearningWriting, but i don't know where to put them, so that i can't commit yet on my project. Does someone know how i can manage ? Regards ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: Should or should not i use PyGTK >= 2.4 widget ?
-- Forwarded message -- From: laurent bernabe Date: 2011/5/31 Subject: Re: [Sugar-devel] Should or should not i use PyGTK >= 2.4 widget ? To: James Cameron Thank you :) I managed to drag files from/to the journal/usb key. Now i must try to register my application with the correct mime types 2011/5/31 James Cameron > On Tue, May 31, 2011 at 10:27:44AM +0200, laurent bernabe wrote: > > But is it possible to, from the journal interface, see the generated > > file for a particular instance, so that i can transfer it to a folder, > > a usb key (and so on ...) ? Because i would like children to be able > > to import easily "graphs" files or "graphs" zip archives. > > To transfer a journal entry to a USB drive, insert the USB drive, > display the journal, then drag the journal item to the icon for the USB > drive. > > To transfer a file from a USB drive to the journal, insert the USB > drive, display the journal, click on the icon for the USB drive, locate > the file, drag it to the icon for the journal. > > Then, to open the file in an activity, the activity must have registered > interest in the MIME type of the file, and so the open entry dialog will > contain the activity name as an option. > > Try it with a text file and you will see Write offered. > > -- > 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] [DESIGN] multi-selection in journal
On Tue, May 31, 2011 at 12:38:04AM -0400, Martin Abente wrote: > Anyway, I would like to hear everyone's feedback on the current design! > 3. http://www.sugarlabs.org/~tch/journal2.mpeg I like it. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Should or should not i use PyGTK >= 2.4 widget ?
On Tue, May 31, 2011 at 10:27:44AM +0200, laurent bernabe wrote: > But is it possible to, from the journal interface, see the generated > file for a particular instance, so that i can transfer it to a folder, > a usb key (and so on ...) ? Because i would like children to be able > to import easily "graphs" files or "graphs" zip archives. To transfer a journal entry to a USB drive, insert the USB drive, display the journal, then drag the journal item to the icon for the USB drive. To transfer a file from a USB drive to the journal, insert the USB drive, display the journal, click on the icon for the USB drive, locate the file, drag it to the icon for the journal. Then, to open the file in an activity, the activity must have registered interest in the MIME type of the file, and so the open entry dialog will contain the activity name as an option. Try it with a text file and you will see Write offered. -- 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] Sugar Labs bug tracker used by the OLPCA team?
On 05/31/2011 02:09 AM, Rafael Ortiz wrote: On Mon, May 30, 2011 at 6:12 PM, James Cameron wrote: On Mon, May 30, 2011 at 04:52:51PM -0500, Rafael Ortiz wrote: Although, I really like this QA workflow, I'm not sure if this will prevent people from the community to follow the workflow, e.g an ''outsider'' or an activity developer that wants to close a bug or do follow-ups that require a change of state on the workflow. For starters there should be a wiki page where to document this in order to point people to the process. In my opinion this could be yet another wall to enter sugar development. I agree. I also don't like the workflow. I think organisations should use their own trackers to represent work they plan to do for themselves, and use Sugar tracker as well for work that Sugar Labs may be involved in. Thus a ticket in the Sugar Labs tracker would be closed when the problem is fixed to the satisfaction of Sugar Labs. (e.g. fix committed to git). Thus a ticket in the downstream organisation tracker would be closed when the problem is fixed to the satisfaction of the downstream organisation. (e.g. tested on hardware). I don't think it is likely that these events will happen at the same time, or in the same sequence, and so I don't think it is right to delay closure. This plan may expose the Sugar Labs tracker to a lot more event data that doesn't really benefit the Sugar Labs community that much. If Sugar Labs is happy with it, go for it. I'll work within the restrictions. I don't have to like it though. Fully agree with your comments. I'd prefer we don't use this workflow, but that's my way of viewing it, so community will have to decide. I understand your concerns. Ideally upstream (SL) would be independent from the downstream (OLPCA). And maybe this is a bit sneaky. So, the current situation in the SL tracker is that it is not taken care of much. For example, I have seen that since the review happens on the mailing list tickets does not get closed as much anymore. So the benefit for SL would be that people help to keep the bug database clean and getting free QA. For OLPCA it gets easier since I do not have to open duplicates to trigger the status (either using a one ticket at the OLPC-bug-tracker per ticket on the SL-bug-tracker procedure or a multi-SL tickets in one OLPCA ticket procedure). Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Should or should not i use PyGTK >= 2.4 widget ?
Thank you very much :) This time severals instances of activities have their own drawings resumed. :) But is it possible to, from the journal interface, see the generated file for a particular instance, so that i can transfer it to a folder, a usb key (and so on ...) ? Because i would like children to be able to import easily "graphs" files or "graphs" zip archives. Regards 2011/5/31 Walter Bender > > > On Mon, May 30, 2011 at 12:33 PM, laurent bernabe < > laurent.bern...@gmail.com> wrote: > >> >> 2011/5/30 Walter Bender >> >>> >>> >>> On Mon, May 30, 2011 at 11:59 AM, laurent bernabe < >>> laurent.bern...@gmail.com> wrote: >>> Hello I come back to this discussion, because there is another obscure point in my mind => Is it possible to write a file to a usb key, though the tutorial says that there the activity can only acess its data/instance/temp folder ? Apologizes if my question is too evident and unusefull . But i don't feel yet ready for developping serailisation/sharing part of my app >>> >>> No apology necessary. >>> >>> >> Than you >> >> >>> The standard way to share to removable media in Sugar is to simply save >>> as usual to the Journal. From the Journal, there are mechanisms for copying >>> files to USB (and soon, $HOME/Documents and a remote server). >>> >>> >> Argh : perhaps i saved my file badly from the application to the journal >> because (though i surcharged the method write_file of activity.activity) >> >>- in the journal (in its lits form, not graphical one) i can't see any >>trace of saves in the dropdown menu, though i clicked on the activity keep >>button >>- maybe i did not use the journal in the good way, or it's because i >>did not coded the algorithm well >> >> All changes have been made in the learning writing gitorious. >> >>- Launcher is the class inherited from activity.activity >>- TheDrawingAreaEventBox is the class which define the canvas, and in >>which i defined the serialization to the Journal >> >> Could someone have a look at my code and say if i bad coded the >> serialization please ? Many thanks ( Hard beginnings for me ..., as i'm a >> quite modest programmer ) >> >> Regards >> >> >> >>> -walter >>> Regards 2011/5/29 laurent bernabe > ok, thank you. > i'll have a look at the examples and try to find an example close to my > needs. > > regards > > > 2011/5/28 Walter Bender > >> >> >> On Sat, May 28, 2011 at 5:04 AM, laurent bernabe < >> laurent.bern...@gmail.com> wrote: >> >>> Thank you for your answers. >>> But i am not sure i can do my task just with an ObjectChooser. And i >>> need your advices for the strategy i should adopt : >>> >>>- I want my application to "save a graph" by writing the >>>coordinates in a text file => i am conviced that for this tasks, i >>> should >>>use the folder data of the activity >>>- i want my application to "load a graph" from a previously >>>recorded graph >>>- but i also want the users to share other graphs each others : >>>more precisely, for users who don't have internet access (or for >>> later >>>systems restores, maybe after a crash, for example) to be able to >>> import >>>files from a usb key >>> >>> So, what is the best strategy in order to do these tasks and remain >>> conform to Sugar best practices ? >>> >> >> In general, using the Journal for these sorts of tasks is best >> practice in Sugar. You can set a file path with your data associated >> with >> your activity's datastore instance. That file can contain anything you >> want. >> It is typical to have a method that overrides the builtin write_file >> method >> -- called whenever the activity is either removed from the foreground or >> the >> activity exits -- from which you save data. >> >> def write_file(self, file_path): >> ''' Write the project to the Journal. ''' >>... >> >> You can also set the mime type for this file, so as giving a hint as >> to what activities can subsequently open it. >> >> Lots of examples of this out there. >> >> -walter >> >> >>> Regards >>> >>> >>> 2011/5/27 Bert Freudenberg >>> Step 1: search wiki for ObjectChooser. Step 2: find http://wiki.sugarlabs.org/go/Activity_Team/Object_Chooser Step 3: there is no step 3 - Bert - On 27.05.2011, at 17:49, laurent bernabe wrote: > Thank you. > > I've been on Sugar Almanach page in order to find ObjectChooser class, but i did not manage. > (i've been here : http://wiki.sugarlabs.org/go/Development_Team/Almanac ) > Where shoul
