[Sugar-devel] Activity Packaging Wish List
Hi, I updated the Fedora Sugar Activities page [1] so that the users can add their favourite/useful activities to be packaged. This will help the packagers so that they don't have to pick activities randomly to package. If you as a packager is working on a packaging a activity in the wish list please state that in the assigned to column to avoid any confusion. I hope this initiative will result for the betterment of both sugar and fedora. Comments are highly welcome. [1] https://fedoraproject.org/wiki/Sugar_Activities -- Best Regards, Kalpa Pathum Welivitigoda http://about.me/callkalpa ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Packaging Wish List
On Fri, Mar 23, 2012 at 8:51 AM, Kalpa Welivitigoda callka...@gmail.com wrote: Hi, I updated the Fedora Sugar Activities page [1] so that the users can add their favourite/useful activities to be packaged. This will help the packagers so that they don't have to pick activities randomly to package. If you as a packager is working on a packaging a activity in the wish list please state that in the assigned to column to avoid any confusion. Hey. How do we get some more recent versions packaged. Turtle Art is very very very old, for example. -walter I hope this initiative will result for the betterment of both sugar and fedora. Comments are highly welcome. [1] https://fedoraproject.org/wiki/Sugar_Activities -- Best Regards, Kalpa Pathum Welivitigoda http://about.me/callkalpa ___ 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] Activity Packaging Wish List
We should do a bit of merging - I created https://fedoraproject.org/wiki/QA:Testcase_sugar_activity_list since the Fedora 13 column made me think the list was unmaintained. (Misspellings in that list are from actual package descriptions - I did not correct most of them.) Keeping the version numbers in the Wiki though is a bit deceptive unless we can verify that packagers update the Wiki every time they update bodhi. There also a list at https://fedoraproject.org/wiki/Test_Day:2012-03-22_Sugar_Desktop which is based on my list while following a priority ranking a few developers came up with for OLPC work. But this one does not need to be updated as it is for an event in one point in time. On Fri, Mar 23, 2012 at 8:51 AM, Kalpa Welivitigoda callka...@gmail.comwrote: Hi, I updated the Fedora Sugar Activities page [1] so that the users can add their favourite/useful activities to be packaged. This will help the packagers so that they don't have to pick activities randomly to package. If you as a packager is working on a packaging a activity in the wish list please state that in the assigned to column to avoid any confusion. I hope this initiative will result for the betterment of both sugar and fedora. Comments are highly welcome. [1] https://fedoraproject.org/wiki/Sugar_Activities -- Best Regards, Kalpa Pathum Welivitigoda http://about.me/callkalpa ___ 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] Activity Packaging Wish List
On 03/23/2012 05:51 AM, Kalpa Welivitigoda wrote: Hi, I updated the Fedora Sugar Activities page [1] so that the users can add their favourite/useful activities to be packaged. This will help the packagers so that they don't have to pick activities randomly to package. If you as a packager is working on a packaging a activity in the wish list please state that in the assigned to column to avoid any confusion. I hope this initiative will result for the betterment of both sugar and fedora. The table needs updating. follow the first link for browse we are up to browse 132 (133 is ready) in f17 Beta TC2 Comments are highly welcome. [1] https://fedoraproject.org/wiki/Sugar_Activities ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Packaging Wish List
On Fri, Mar 23, 2012 at 6:45 PM, Walter Bender walter.ben...@gmail.com wrote: On Fri, Mar 23, 2012 at 8:51 AM, Kalpa Welivitigoda callka...@gmail.com wrote: Hi, I updated the Fedora Sugar Activities page [1] so that the users can add their favourite/useful activities to be packaged. This will help the packagers so that they don't have to pick activities randomly to package. If you as a packager is working on a packaging a activity in the wish list please state that in the assigned to column to avoid any confusion. Hey. How do we get some more recent versions packaged. Turtle Art is very very very old, for example. well if the maintainers are around we can ask them to update or else if they are willing to I would like to co-maintain. In the case of Turtle Art [1], the entry for sugar-turtleart in fedora package database [2] has a mismatching version number. I have informed Simon also who is a co-maintainer for sugar-turtleart. I thing there's some misunderstanding here. [1] http://activities.sugarlabs.org/en-US/sugar/addon/4298 [2] https://admin.fedoraproject.org/updates/sugar-turtleart?_csrf_token=4d36507c587016676973703d12cbe8b50ee4eae7 -walter I hope this initiative will result for the betterment of both sugar and fedora. Comments are highly welcome. [1] https://fedoraproject.org/wiki/Sugar_Activities -- Best Regards, Kalpa Pathum Welivitigoda http://about.me/callkalpa ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Best Regards, Kalpa Pathum Welivitigoda http://about.me/callkalpa ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Packaging Wish List
On Fri, Mar 23, 2012 at 6:52 PM, Samuel Greenfeld greenf...@laptop.org wrote: We should do a bit of merging - I created https://fedoraproject.org/wiki/QA:Testcase_sugar_activity_list since the Fedora 13 column made me think the list was unmaintained. (Misspellings in that list are from actual package descriptions - I did not correct most of them.) This is simple and serve the purpose. I generally update Fedora sugar activities [1] as soon as I do a packaging. And the Fructose Activities and Honey Activities section was there when I packaged the first activity. They should have been for some reason, may be. So better wait for others to comment. Personally I love a simpler page as yours. Keeping the version numbers in the Wiki though is a bit deceptive unless we can verify that packagers update the Wiki every time they update bodhi. Agreed, package name itself will do. If someone wants to see the version he/she can click on the package go to updates and see it. There also a list at https://fedoraproject.org/wiki/Test_Day:2012-03-22_Sugar_Desktop which is based on my list while following a priority ranking a few developers came up with for OLPC work. But this one does not need to be updated as it is for an event in one point in time. Understood [1] https://fedoraproject.org/wiki/Sugar_Activities On Fri, Mar 23, 2012 at 8:51 AM, Kalpa Welivitigoda callka...@gmail.com wrote: Hi, I updated the Fedora Sugar Activities page [1] so that the users can add their favourite/useful activities to be packaged. This will help the packagers so that they don't have to pick activities randomly to package. If you as a packager is working on a packaging a activity in the wish list please state that in the assigned to column to avoid any confusion. I hope this initiative will result for the betterment of both sugar and fedora. Comments are highly welcome. [1] https://fedoraproject.org/wiki/Sugar_Activities -- Best Regards, Kalpa Pathum Welivitigoda http://about.me/callkalpa ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Best Regards, Kalpa Pathum Welivitigoda http://about.me/callkalpa ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Wed, 04 Aug 2010 20:05:06 +0100, pbrobin...@gmail.com wrote: On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: 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. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. I think that's a little different. Fedora allowed an unprivileged user to install a package, but giving the package full privileges. For 0sugar, I assume, the user is fully privileged (it's their machine); it's the package that should be restricted, not the user. This distinction has caused a lot of confusion in the past, and I've now added a section to http://0install.net/injector-security.html to try and clarify it. I've also added a demonstration of using 0install for sandboxing, showing how sandboxed processes can still share libraries (which doesn't happen if you just create lots of separate RPM databases): http://0install.net/ebox.html Hope that helps, -- Dr Thomas Leonard http://0install.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Wed, Aug 04, 2010 at 08:05:06PM +0100, pbrobin...@gmail.com wrote: On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: 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. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. Thats right, and all PackageKit benefits will be reused within 0sugar/0install (but mostly for non-sugar dependencies, it will be possible to reuse native packages for sugar application as well but see below). But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Sun, Aug 08, 2010 at 07:18:51AM -0700, Jon Nettleton wrote: But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). This doesn't sound like a package management system scenario. Really this sounds like a revision control system is needed. Wouldn't it make the most sense to integrate bzr or git into sugar to handle code sharing like this? Then you could continue to have all the Activities in a single directory with multiple branches to can be switched between on the fly through a sugar interface. Well, I thought also about vcs but came to decision that it sounds like misusing of vcs: * vcs is all about sources (storing binaries is possible but is misusing), * all sugar related code will be shared only in sources, which is not bad in general (especially as an option) but sounds overkill for binary-based activities * all dependencies should be stored in vcs and deployed via vcs as well (otherwise system should be not pure vcs and will look pretty ugly) Also there is no need in storing results of experiments in vcs at all, e.g., doer just tweaks his local code and let 0sugar share it w/o commiting to vcs server(which should be used to fetch sources on client side), supporting per doer vcs servers would sound pretty overkill. Some kind of binding vcs repos with packaging/distribution stuff is possible and afaik many GNU/Linux distribution do packaging from, e.g., git repos (we can do similar things on our OBS), but they don't mix vcs and distribution. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On 8 Aug 2010, at 15:18, Jon Nettleton jon.nettle...@gmail.com wrote: But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). This doesn't sound like a package management system scenario. Really this sounds like a revision control system is needed. Wouldn't it make the most sense to integrate bzr or git into sugar to handle code sharing like this? Then you could continue to have all the Activities in a single directory with multiple branches to can be switched between on the fly through a sugar interface. FWIW this is certainly the way I've worked on activities in Sugar for some time now, my ~/Activities is mainly git clones. --Gary -Jon ___ olpc mailing list o...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/olpc ___ 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 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: 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. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: 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. 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. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software - compile on demand is a regular workflow within 0install (existed sugar doesn't not let such possibility:), rainbow should be more then essential requirement. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
Aleksey wrote: On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: 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. 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. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software... rainbow should be more then essential requirement. Let's be clear: the actual requirement is for something more like safety or isolation. Rainbow is merely one of several reasonable approaches -- and competition and interoperability would be no bad thing here. Michael P.S. - Several other isolation shells that might be worth thinking about, if only to better understand the tradeoffs that rainbow makes, are briefly described at http://sandboxing.org P.P.S. - Also, either way, thanks for your encouragement. :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Wed, Jul 7, 2010 at 2:16 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: 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. 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. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software - compile on demand is a regular workflow within 0install (existed sugar doesn't not let such possibility:), rainbow should be more then essential requirement. I took some time to read up on 0install -- very impressive technology, good work. I agree with Michael that this (userland installs) is the direction Sugar should be pursuing. With rainbow (or other sandbox) integration, this would accomplish all of the original goals with a much more robust packaging and dependency system than the .xo bundle. --scott -- ( http://cscott.net/ ) ___ 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] 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
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] 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] 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] Activity packaging problems
Hello, I listed all the problems I'm aware of, which are currently blocking activities packaging: http://sugarlabs.org/go/DevelopmentTeam/Activities_packaging If you are packaging activities and you run into any (non distribution specific) issue, please add to the list. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Sat, Dec 20, 2008 at 01:30:30PM +0100, Marco Pesenti Gritti wrote: I listed all the problems I'm aware of, which are currently blocking activities packaging: http://sugarlabs.org/go/DevelopmentTeam/Activities_packaging If you are packaging activities and you run into any (non distribution specific) issue, please add to the list. A common issue (so not sure how to best apply it) is copyright and licensing info for translations. Some translations lack such info completely. Some translations have boilerplate info like this: # SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR em...@address, YEAR. Technically distributors must then in principle respect that the file is owned by YEAR THE PACKAGE'S COPYRIGHT HOLDER who have licensed the file similar to PACKAGE which does not exist so the file is not FLOSS. The package maintainer should edit the .pot file to replace these: SOME DESCRIPTIVE TITLE THE PACKAGE'S COPYRIGHT HOLDER PACKAGE When that is done, they should get in contact with each translator to make them adopt that improved boilerplate and themselves replace these: FIRST AUTHOR em...@address YEAR When doing above, it makes good sense to also tidy the gettext hints to have proper info too, but that is just nice-to-have for semi-automated processing, not crucial as the licensing problem. I am aware that pootle is used for most translation, and that it does not currently handle above properly. Using a machine to help collect translations unfortunately cannot excuse licensing issues, so until pootle can automate it, I believe it is needed to fix the boilerplate by hand. I am also aware that this whole issue might seem too anal to some. Indeed, not all distributors are equally anal/relaxed about licensing. And Debian (where I work) is probably at the hysterical end of that scale. You may decide to simply ignore this as too much work for too little gain, but please beware that then the translation efforts will not reach all users of your software, as anal distributors will have to strip wrongly licensed translations from their systems. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklM9KEACgkQn7DbMsAkQLiGHwCff4lEje0BUTYFA/MdrmPpabpu +VoAn1fGPTTYW7M0WfWSEYIKZDZOh3WH =jjLm -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging problems
On Sat, Dec 20, 2008 at 2:35 PM, Jonas Smedegaard d...@jones.dk wrote: A common issue (so not sure how to best apply it) is copyright and licensing info for translations. Added a note about it. Thanks! Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging problems
On Sun, Dec 21, 2008 at 1:07 PM, Jonas Smedegaard d...@jones.dk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Dec 20, 2008 at 06:40:42PM +0100, Marco Pesenti Gritti wrote: On Sat, Dec 20, 2008 at 6:17 PM, Jonas Smedegaard d...@jones.dk wrote: Please consider republishing latest 0.82.x tarballs at sugarlabs.org, so that distributors can refer to a single upstream location for both stable and development sources. Good point, done. Please do not generate new tarballs from Git, but copy the already generated tarballs from laptop.org, to not break md5sums verifications used by some distros. We are leaving the old one on laptop.org for now. Ahem, either you misunderstood or somehow misunderstand your response: I do not suggest to change anything at laptop.org, but to _duplicate_ the most recent 0.82.x tarballs currently only officially available below http://dev.laptop.org/pub/ to _also_ be available below http://download.sugarlabs.org/sources/ 0.82.x packages will be included with next stable release of Debian, which means that (most likely) for the next couple of years Debian will promote laptop.org as the source of Sugar software rather than sugarlabs.org. Which is plain wrong IMO, but really needs above action to sanely be possible to attempt fixing now. You write that it is done but looking at e.g. http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/ shows only a single tarball for the 0.83.3 release. With my suggestion effectuated I would expect at that same URL to also see a tarball for the 0.82.11 release of sugar-toolkit. Kind regards, - Jonas Jonas, Please keep these points coming. Last release, Sugar's only active downstream was OLPC. This release we will be acting as upstreams, directly or indirectly, for OLPC, Fedora, Debian, Ubuntu, Mandriva, and a few others. There are fundamental differences between the work flow and priorities of upstream developers who are on six month release cycles and downstream distributors who support production systems for at least two years. Sometimes as upstreams we forget to look at things from downstreams point of view. So, Jonas and others representing downstreams, keep them coming and try to keep them constructive. Hopefully a large part of our focus over the next several months will be on finding the balance between keeping upstream development moving forward while supporting downstream distributions. thanks david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Dec 21, 2008 at 01:43:09PM +1800, David Farning wrote: Sometimes as upstreams we forget to look at things from downstreams point of view. So, Jonas and others representing downstreams, keep them coming and try to keep them constructive. ^^^ He he, I like your way of expression ;-) I shall do my best! - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklNWNoACgkQn7DbMsAkQLiJ2gCgo7cAqcXK1mUUg7Pq7dyxWhv4 Oy4AnA+qP+he/3uBm1DdJ8I0Yuasnrt2 =Ux0L -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging problems
On Sat, Dec 20, 2008 at 8:07 PM, Jonas Smedegaard d...@jones.dk wrote: Ahem, either you misunderstood or somehow misunderstand your response: My fault. I thought you was talking about my changes in the wiki, which also needed to be fixed anyway. I do not suggest to change anything at laptop.org, but to _duplicate_ the most recent 0.82.x tarballs currently only officially available below http://dev.laptop.org/pub/ to _also_ be available below http://download.sugarlabs.org/sources/ 0.82.x packages will be included with next stable release of Debian, which means that (most likely) for the next couple of years Debian will promote laptop.org as the source of Sugar software rather than sugarlabs.org. Which is plain wrong IMO, but really needs above action to sanely be possible to attempt fixing now. Makes totally sense. I'm ccing Simon and Bernie who took care of downloads.sugarlabs.org setup. I agree that we should fix that up. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging problems
On Sat, Dec 20, 2008 at 8:43 PM, David Farning dfarn...@sugarlabs.org wrote: Please keep these points coming. Last release, Sugar's only active downstream was OLPC. This release we will be acting as upstreams, directly or indirectly, for OLPC, Fedora, Debian, Ubuntu, Mandriva, and a few others. Absolutely, it's very helpful!!! Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
