Re: [sugar] specifying what services Activities may use
Erik Garrison [EMAIL PROTECTED] writes: On Thu, Jul 31, 2008 at 12:40:39AM +0200, Bastien wrote: It's not that important anyway. It just occurred to me that the dependancies management challenge could be somehow dealt with by delivering a set of default activities. I'm not aware of any software distribution drawing such a strong line between the core system and the applications/activities. We have been managing the dependency issue by ensuring that the 'core' activities required for a given build all work on the system-level software packages we include. What is the set of core activities? how does this depend on a given build? Maybe what I'm suggesting boils down to integrate this core activities in the environment so that people installing Sugar won't have to install them separatly. Just the same way that installing a standard Fedora will install Gnome (will install evolution (etc...)). -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
On Fri, Aug 01, 2008 at 08:21:34PM +0200, Bastien wrote: Erik Garrison [EMAIL PROTECTED] writes: On Thu, Jul 31, 2008 at 12:40:39AM +0200, Bastien wrote: It's not that important anyway. It just occurred to me that the dependancies management challenge could be somehow dealt with by delivering a set of default activities. I'm not aware of any software distribution drawing such a strong line between the core system and the applications/activities. We have been managing the dependency issue by ensuring that the 'core' activities required for a given build all work on the system-level software packages we include. What is the set of core activities? how does this depend on a given build? e.g., (for an old build): http://wiki.laptop.org/go/Category:Core I mean 'core' in the sense that the core activities are those included on a specific os image by default. Users can install activities later. These are not 'core'. Maybe what I'm suggesting boils down to integrate this core activities in the environment so that people installing Sugar won't have to install them separatly. Just the same way that installing a standard Fedora will install Gnome (will install evolution (etc...)). What I'm suggesting is that this step requires global optimization wrt which activities are 'core'. This is difficult, as various deployments have different usage patterns and require different sets of software. I have often built debian systems using debootstrap to pull in the most minimal typically used system components. On top of such a system customization is easy. I am suggesting that we may wish to develop a similar system so that our downstream developers can have more flexibility in customizing their systems. Activites could be Sugar-core and not XO-system core. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
Erik Garrison [EMAIL PROTECTED] writes: Maybe what I'm suggesting boils down to integrate this core activities in the environment so that people installing Sugar won't have to install them separatly. Just the same way that installing a standard Fedora will install Gnome (will install evolution (etc...)). What I'm suggesting is that this step requires global optimization wrt which activities are 'core'. This is difficult, as various deployments have different usage patterns and require different sets of software. Yes, I understand this, but it's quite reasonable to assume that each deployment will like the list of activities that is listed in the Core category (cf. http://wiki.laptop.org/go/Category:Core) I have often built debian systems using debootstrap to pull in the most minimal typically used system components. On top of such a system customization is easy. I am suggesting that we may wish to develop a similar system so that our downstream developers can have more flexibility in customizing their systems. Activites could be Sugar-core and not XO-system core. Agreed. We could have something like: ~$ apt-get install sugar = Install Sugar with a default set of activities ~$ apt-get install sugar-extra-activities = Install a set of extra activities ~$ apt-get install sugar-nepal-activities = Install a specific bundle with extra activities If Sugar installation takes this route, then there is something else that has to be defined: the default favorite activities. Each deb package above should define the default set of favs. And maybe there could be a way of importing someone's favs easily, whatever the extra package people installed. My 2 cents... -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
On Mon, Jul 28, 2008 at 6:32 PM, Jerry Williams [EMAIL PROTECTED] wrote: Seems like this problem for linux was solved with RPM. I wouldn't go quite that far. The holes in RPM drove me to Debian. %-[ With rpm if something is missing for something you want to install, it complains and won't let you install it. Apt and yum also track dependencies, both better than RPM, and rather than refuse to install, they offer to get the dependent libraries for you. Why aren't we using this approach with xo-get? It seems like a lot of the python code I have looked at assumes you have stuff and just quietly dies and you have to look at the log and see, oh I am missing some module. Like the Terminal activity needs python-json. Pacman needs pygame. Jerry Williams -Original Message- From: [EMAIL PROTECTED] [mailto:sugar- [EMAIL PROTECTED] On Behalf Of Mikus Grinbergs Sent: Monday, July 28, 2008 6:19 PM To: devel@lists.laptop.org; [EMAIL PROTECTED] Subject: [sugar] specifying what services Activities may use There was an earlier discussion of how to provide the right build level for users out in the field, since now Builds can be installed separately from Activities -- leading to the possibility that for someone an Activity_version on his XO will find itself *mismatched* with the Build_version on his XO. The problem is bigger than that. Since Joyride 2210, I have seen three of the Activities I often show off get broken by the *removal* of services from the Joyride builds. If the current software distribution process has trouble matching existing Activities to the services_provided_by_a_Build -- how will NOT YET EXISTING Activities be accommodated by the software that Sugar is supposed to run on top of ??? I'm thinking of someone in a far-off land who has an idea for a killer Activity, to be run under Sugar. HOW does he learn which (library, or kernel, or whatever) services will be available *everywhere* Sugar can be installed, which services will be available only with *specific* builds/platforms, and which services would *never* be available for functions fitted into Sugar ? mikus ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar -- Silent Thunder [默雷/शब्दगर्ज] is my name, And Children are my nation. The whole world is my dwelling place, And Truth my destination. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
On Thu, Jul 31, 2008 at 12:40:39AM +0200, Bastien wrote: It's not that important anyway. It just occurred to me that the dependancies management challenge could be somehow dealt with by delivering a set of default activities. I'm not aware of any software distribution drawing such a strong line between the core system and the applications/activities. We have been managing the dependency issue by ensuring that the 'core' activities required for a given build all work on the system-level software packages we include. To my knowledge this verification has been done manually. We could better share our efforts by working to make sure that a given activity simply lists the correct set of dependencies, pushing this data to a package repository, and supporting deployments as they cherry-pick their requirements from it to construct new images and push their products back into it. The separation between system and application-level software is a core roadblock in our integration of more intelligent package management policies. How can an isolated user-level package management application be allowed to modify system-level, shared, code that will affect other applications from which it is supposed to be isolated? A unification of system and application-level software package management thus violates our security model. The user-level application isolation required by this security model serves to enable easier code sharing between children. It also makes it easier for sysadmins to accept the use of relatively untested software packages on the XO. We can probably all agree that the separation between system and application software is useful for security and the execution of untrusted code. Can we reasonably work around this distinction to allow the management of both sets of software as one whole? Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
On Tue, 2008-07-29 at 17:09 -0400, Mikus Grinbergs wrote: Please ensure that you have filed tickets for each and every one of them What good will that do? We track issues through trac. Doing it through email is harder when you have a lot of email and a lot of issues. Filing a ticket keyworded 8.2.0:? will put it on our radar. While it can be useful to raise issues through email first, it easy to forget about emails. Trac is our designated issue-tracking system. Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
Bobby Powers [EMAIL PROTECTED] writes: recent joyrides include an activity updater which should help with this. And you guys could get rid of the scary red warning on the wiki :) on which page? See the barking here: http://wiki.laptop.org/go/OLPC_Update.1_Software_Release_Notes Activities must be installed separately. And unless my memory is fooling me, I'm pretty sure the warning was red at some point on this page: http://wiki.laptop.org/go/Olpc-upgrade Note that in builds 700 and above, you must install activities separately It's not that important anyway. It just occurred to me that the dependancies management challenge could be somehow dealt with by delivering a set of default activities. I'm not aware of any software distribution drawing such a strong line between the core system and the applications/activities. -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: [sugar] specifying what services Activities may use
-Original Message- From: Benjamin M. Schwartz [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2008 7:40 PM To: Jerry Williams Cc: 'Mikus Grinbergs'; devel@lists.laptop.org; [EMAIL PROTECTED] Subject: Re: [sugar] specifying what services Activities may use -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry Williams wrote: | Seems like this problem for linux was solved with RPM. | With rpm if something is missing for something you want to install, it | complains and won't let you install it. That's not really the problem we're discussing. We're talking about the case in which you try to install an old bundle onto a new build, or vice versa. RPM solves this problem by just not letting you do that. You can't install a rh9 RPM on FC8. This isn't true, you can run fc9 rpms on fc8 and you can run fc8 rpms on fc9. I have done both, just as long as the dependencies are met. It seems to me that for starters the sugar rpm is broken. It doesn't require python-json which is imported by activity.py. And the terminal activity won't run without it. So if sugar isn't checking for what it needs, how is any activity going to? I don't think many people around here would be happy to require all new .xo bundles for every release. I don't have a solution to suggest, but I don't think classic dependency management is going to do the trick. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiOdOEACgkQUJT6e6HFtqTGkwCfc1+dfhpyyBOeunbv0IWUeaaa GccAnRZGstdun3UbDMJ9INwCtfXYUt8T =TrAc -END PGP SIGNATURE- From what I have seen there is very little if any dependency checking going on. Not to pick on anyone, but Pacman needs pygame, but doen't check for it. Maybe using something like pychecker as part of .xo install process could do some checking. $ pychecker *.py Processing activity... ImportError: No module named pygame Processing game... ImportError: No module named pygame So should the activity be checking for what it needs or should the .xo install be doing that or both? Right now things just fail and you have to know how to go look at the logs. Should those errors just be sent to the screen as well? Jerry Williams ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
On Tue, 2008-07-29 at 15:10 -0400, Mikus Grinbergs wrote: A DECISION NEEDS TO BE MADE !!! I've been randomly launching Activities on 2226. __Far too many__ of them fail -- because csound was changed, numeric was changed, mixer was changed, etc., etc., etc. Please ensure that you have filed tickets for each and every one of them, unless tickets already exist. Even if you cannot provide any technical diagnosis, let's get them on record. Keyword all the tickets 8.2.0:? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
Please ensure that you have filed tickets for each and every one of them What good will that do? At the beginning of this year, I wrote a ticket saying an Activity would not start. Without notifying me, someone re-assigned *me* as the owner of that ticket -- presumably making it my responsibility to fix that Activity so it would start. Fixing Activities is not what I am being paid to do. All I want to do here is to point out the bad publicity that regression (from what previously worked) might cause. Is that an opinion worth filing a ticket about? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
Hi Mikus, On 29 Jul 2008, at 22:09, Mikus Grinbergs wrote: Please ensure that you have filed tickets for each and every one of them What good will that do? At the beginning of this year, I wrote a ticket saying an Activity would not start. Without notifying me, someone re-assigned *me* as the owner of that ticket -- presumably making it my responsibility to fix that Activity so it would start. Just assign the damn things back if that happens and hope you get a better triage next time around. I've not had this happen to me yet, but as mstone enjoys saying, be bold... I must say there is quite some guilt filing bugs this close to a release knowing the lack of resources, but reporting is kind'a the whole point close to release I guess. Very satisfying when you can catch something reproducible and one of the team can get the bug squished. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry Williams wrote: | Seems like this problem for linux was solved with RPM. | With rpm if something is missing for something you want to install, it | complains and won't let you install it. That's not really the problem we're discussing. We're talking about the case in which you try to install an old bundle onto a new build, or vice versa. RPM solves this problem by just not letting you do that. You can't install a rh9 RPM on FC8. I don't think many people around here would be happy to require all new .xo bundles for every release. I don't have a solution to suggest, but I don't think classic dependency management is going to do the trick. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiOdOEACgkQUJT6e6HFtqTGkwCfc1+dfhpyyBOeunbv0IWUeaaa GccAnRZGstdun3UbDMJ9INwCtfXYUt8T =TrAc -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
Benjamin M. Schwartz [EMAIL PROTECTED] writes: Jerry Williams wrote: | Seems like this problem for linux was solved with RPM. | With rpm if something is missing for something you want to install, it | complains and won't let you install it. That's not really the problem we're discussing. We're talking about the case in which you try to install an old bundle onto a new build, or vice versa. Another reason why each build should come with a default bundle. If countries develop their bundles independantly from Sugar evolution, then the problem will just be more painful. If countries have a default bundle to refer to when developing their own, it could help solving dependancy issues indirectly. The default activities could be selected so that 90% of the dependancies for other (known) activities are satisfied. At least, a default bundle combined with a nice GUI for xo-get.py would discourage installation of old bundles on newer builds. And you guys could get rid of the scary red warning on the wiki :) -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
On Mon, Jul 28, 2008 at 10:03 PM, Bastien [EMAIL PROTECTED] wrote: Benjamin M. Schwartz [EMAIL PROTECTED] writes: Jerry Williams wrote: | Seems like this problem for linux was solved with RPM. | With rpm if something is missing for something you want to install, it | complains and won't let you install it. That's not really the problem we're discussing. We're talking about the case in which you try to install an old bundle onto a new build, or vice versa. Another reason why each build should come with a default bundle. If countries develop their bundles independantly from Sugar evolution, then the problem will just be more painful. If countries have a default bundle to refer to when developing their own, it could help solving dependancy issues indirectly. The default activities could be selected so that 90% of the dependancies for other (known) activities are satisfied. At least, a default bundle combined with a nice GUI for xo-get.py would discourage installation of old bundles on newer builds. recent joyrides include an activity updater which should help with this. And you guys could get rid of the scary red warning on the wiki :) on which page? bobby -- Bastien ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
On Tue, Jul 29, 2008 at 1:39 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Jerry Williams wrote: | Seems like this problem for linux was solved with RPM. | With rpm if something is missing for something you want to install, it | complains and won't let you install it. That's not really the problem we're discussing. We're talking about the case in which you try to install an old bundle onto a new build, or vice versa. RPM solves this problem by just not letting you do that. You can't install a rh9 RPM on FC8. Yes you can. It will be prevented only if specific versioned dependencies prevent it. I don't think many people around here would be happy to require all new .xo bundles for every release. I don't have a solution to suggest, but I don't think classic dependency management is going to do the trick. Yes, classic dependency management would help. Unfortunately, rpm and dpkg have several shortcomings of their own when you try to apply them to the XO case. It would be mighty interesting to see a 'userland' adaptation of rpm, supporting user-friendly features such as relocatable packages, while still taking advantage of the OS-wide rpm (for checking dependencies, for example). cheers. m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: [sugar] specifying what services Activities may use
Seems like this problem for linux was solved with RPM. With rpm if something is missing for something you want to install, it complains and won't let you install it. It seems like a lot of the python code I have looked at assumes you have stuff and just quietly dies and you have to look at the log and see, oh I am missing some module. Like the Terminal activity needs python-json. Pacman needs pygame. Jerry Williams -Original Message- From: [EMAIL PROTECTED] [mailto:sugar- [EMAIL PROTECTED] On Behalf Of Mikus Grinbergs Sent: Monday, July 28, 2008 6:19 PM To: devel@lists.laptop.org; [EMAIL PROTECTED] Subject: [sugar] specifying what services Activities may use There was an earlier discussion of how to provide the right build level for users out in the field, since now Builds can be installed separately from Activities -- leading to the possibility that for someone an Activity_version on his XO will find itself *mismatched* with the Build_version on his XO. The problem is bigger than that. Since Joyride 2210, I have seen three of the Activities I often show off get broken by the *removal* of services from the Joyride builds. If the current software distribution process has trouble matching existing Activities to the services_provided_by_a_Build -- how will NOT YET EXISTING Activities be accommodated by the software that Sugar is supposed to run on top of ??? I'm thinking of someone in a far-off land who has an idea for a killer Activity, to be run under Sugar. HOW does he learn which (library, or kernel, or whatever) services will be available *everywhere* Sugar can be installed, which services will be available only with *specific* builds/platforms, and which services would *never* be available for functions fitted into Sugar ? mikus ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
