Bug#563436: sugar-0.88: sugar depends on python-numpy and python-pygames
dfarning
Version: lastest
Severity: important
Is serious the correct category for this type of bug?
Sugar activitity developers now depend on the availability of
python-numpy
python-pygames
Several activities such as maze and memorize will not run without these dependancies
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonas Smedegaard
>Is serious the correct category for this type of bug?
Nope. More info here: http://www.debian.org/Bugs/Developer#severities
Also, please simply skip version number rather than providing a bogus
one like "lastest".
But thanks for trying, and asking - and for reporting! :-)
>Sugar activitity developers now depend on the availability of
>python-numpy
>python-pygames
>
>Several activities such as maze and memorize will not run without these
>dependancies
Please file RFP (reguest for packaging) or ITP (intend to package) for
each of those relevant-even-if-not-core activities.
sucrose-NN is intended to depend on all of core Sugar from Sugarlabs,
recommend non-core parts shipped with Debian and suggest oddly packaged
Sugar software (e.g. non-free packages).
It does not make sense to me to add non-package dependencies to
sucrose-NN. It might make sense to maintain such in a separate
metapackage, e.g. honey-NN.
Also, I feel that handling such dependencies are less urgent than
packaging and dependening on actual core Sugar parts - some of which are
still missing.
Let's keep this bugreport open until decided if it belongs here or
should be solved with a separate honey-NN package.
Regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
David Farning
On Sat, Jan 2, 2010 at 5:28 PM, Jonas Smedegaard <d...@jones.dk> wrote:
> On Sat, Jan 02, 2010 at 04:26:55PM -0600, dfarning wrote:
>>
>> Is serious the correct category for this type of bug?
>
> Nope. More info here: http://www.debian.org/Bugs/Developer#severities
> Also, please simply skip version number rather than providing a bogus one
> like "lastest".
Open a debian VM with quem (when testing which debian version should I use?)
Update to latest packages.
Run tests
Report via reportbug.
> But thanks for trying, and asking - and for reporting! :-)
>
>
>
>> Sugar activitity developers now depend on the availability of
>> python-numpy
>> python-pygames
>>
>> Several activities such as maze and memorize will not run without these
>> dependancies
>
> Please file RFP (reguest for packaging) or ITP (intend to package) for each
> of those relevant-even-if-not-core activities.
> sucrose-NN is intended to depend on all of core Sugar from Sugarlabs,
> recommend non-core parts shipped with Debian and suggest oddly packaged
> Sugar software (e.g. non-free packages).
> It does not make sense to me to add non-package dependencies to sucrose-NN.
> It might make sense to maintain such in a separate metapackage, e.g.
> honey-NN.
>
> Also, I feel that handling such dependencies are less urgent than packaging
> and dependening on actual core Sugar parts - some of which are still
> missing.
> Let's keep this bugreport open until decided if it belongs here or should be
> solved with a separate honey-NN package.
>
Creating a separate honey package which contains these expected dependencies makes sense... with the caveat that I _hate_ the terms; glucose, sucrose, fructose, and honey. I can never keep them straight.
> Regards,
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136 Website: http://dr.jones.dk/
>
> [x] quote me freely [ ] ask before reusing [ ] keep private
>
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLP9auAAoJECx8MUbBoAEha+4P/0XhyGD2wv9mbkzm2bOZYvZi
> +K5ebeYaCXXxBwh5QnqwFKgIW+7uiP5Uelk6SjJXmKCFNE8ZrZP0mNu1pPAu09gF
> fu8HYUY+X1ha825pQr/qeRi5i7Hybz/O31iDqDYG8gvB0SELc6sTt6UPd0Wve6e1
> zoZsDT/LyqANhnPrAKnSns1V5Dx/cvzIrUwEstYk1G1Jxxel4clwvmEGVJSDKC+V
> 90JRXpHOTYnkWKBJ1kTKNxxnirYM76KYPz4PeOSEuNtpkoiw0DDt5QAHS9HtxbcG
> DD7Mu6P9e1LBjdaTtUqtd874p0J1kuC9A9x/cN1ffwgx1u4sgNBczSf5OGmv/3S0
> ZplznR29Zt+Kc4N4y76YoYkFMrSnJoQBnQGLTPj/wmflBqWK9VVECYw8yq8Luw/u
> OsOkpuGC7yjeAyG0Wwek8T0wURQwdutzMGj1E7tzwVgpKbPygybU8SkTKNbXuxs9
> LO81hLnuUgxSpAt/0SV36XJumM4dGKj0pvT3SOYlc8iNEerSaSrA1MB2hcVxdww4
> dVa46hMjA6mgnNKwa9PwBktldxcR+6qMnHVLeqP4v59ZfmH2EKwMjhFTDmHsZOH8
> sX8QKGal8bhITzTfxPAK9P7g5ZZLLqv/dVTv35qjzs+xx8EIJLzMu5M+X3EIqxD7
> u6WcasiIsdRA/frfH6BT
> =4HRJ
> -----END PGP SIGNATURE-----
>
>
Sascha Silbe
> The problem is that because activity bundles (.xo) do not have the
> ability to declare dependencies, activity developers must be able to
> depend on a specific set package being available. I don't belive that
> this list of packages has been set in stone;
Actually it has been. [1,2]
I don't think these should be added to sucrose-0.8x, but rather to a new
meta package, e.g. sugar-platform-0.8x. Not the core itself (which is
what sucrose-0.8x represents) depends on the packages in the list, but
rather individual activities.
[1] http://wiki.sugarlabs.org/go/0.84/Platform_Components
[2] http://wiki.sugarlabs.org/go/0.86/Platform_Components
CU Sascha
Tomeu Vizoso
<sascha-debia...@silbe.org> wrote:
> On Sat, Jan 02, 2010 at 09:04:09PM -0600, David Farning wrote:
>
>> The problem is that because activity bundles (.xo) do not have the ability
>> to declare dependencies, activity developers must be able to depend on a
>> specific set package being available. I don't belive that this list of
>> packages has been set in stone;
>
> Actually it has been. [1,2]
> I don't think these should be added to sucrose-0.8x, but rather to a new
> meta package, e.g. sugar-platform-0.8x. Not the core itself (which is what
> sucrose-0.8x represents) depends on the packages in the list, but rather
> individual activities.
My understanding was that Jonas believes that software should be
deployed by the distro and not by developers (by using mechanisms such
as .xo bundles). From that POV sugar-platform is not needed.
Regards,
Tomeu
>
> [1] http://wiki.sugarlabs.org/go/0.84/Platform_Components
> [2] http://wiki.sugarlabs.org/go/0.86/Platform_Components
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJLQIEgAAoJELpz82VMF3Da4GoH/AwjjaUzBJl6f/3jcK9ikNdd
> GfYVvfMNMHiZocF9Y/sxxhssZICLzB0L9tBXh4/I5UzeP109dTlwyGhsoK/aKixo
> uqtN5L+M/ymcXvN2JyRxoU9YQo+OZXcr8rGUX2nAmaYZKiJtXgd6cafMRSVXSDHk
> KEVfzlbuFm3l5KqrXDI9U6vz+mXrbO/tW6+viONTs7idnXzgw0I6aRjrWTN4TvYt
> i6DlgJccrbTi9CnY3seG/b4hH80F4iA6qVMC0I7R+Glv3973baMpFvt0KLCKTwi5
> wq1zMrOSTW5kkKvQLRrbeHqgh4EJlYbxPFJGqHu2XMfnmMmmb+CfnGqkR9zijiE=
> =A8nx
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Debian-olpc-devel mailing list
> Debian-o...@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/debian-olpc-devel
>
>
--
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
Sascha Silbe
> My understanding was that Jonas believes that software should be
> deployed by the distro and not by developers (by using mechanisms such
> as .xo bundles). From that POV sugar-platform is not needed.
I don't think it should be an either-or decision. In fact it cannot be;
there's no way Debian could ship _every_ activity.
Sugar Platform is intended as a base line for _all_ activities, esp. all
the random "small" ones.
I guess Jonas was talking about Fructose activities, but will let him
speak for himself. :)
Jonas Smedegaard
>
>
>>On Sat, Jan 02, 2010 at 04:26:55PM -0600, dfarning wrote:
>Ok, still learning the bug reporting system. It seems pretty handy to:
>Open a debian VM with quem (when testing which debian version should
>I use?) Update to latest packages.
>Run tests
>Report via reportbug.
I guess you mean qemu (not quem).
Develop packages using unstable. Test using either unstable or testing
(depending on what you want to test).
>>Please file RFP (reguest for packaging) or ITP (intend to package) for
>>each of those relevant-even-if-not-core activities.
>
>Distros don't need to worry about packaging the non-core activities.
Yeah, there's many ways to get Free Software, only one of them being
through Debian packages.
It makes sense to support those wanting to use .xo bundles (honey-NN?)
or build from source (sugar-dev-NN?), but only i not getting in the way
of those wanting/expecting the main logic of Debian: Being fully
installable while offline!
>>sucrose-NN is intended to depend on all of core Sugar from Sugarlabs,
>>recommend non-core parts shipped with Debian and suggest oddly packaged
>>Sugar software (e.g. non-free packages).
>
>The problem is that because activity bundles (.xo) do not have the
>ability to declare dependencies, activity developers must be able to
>depend on a specific set package being available. I don't belive that
>this list of packages has been set in stone; Rather is is more of a
>convention that activity developers can depend on python-numpy and
>python-pygames being available.
Yes, .xo bundles have their own pile of challenges. Those challenges are
relevant only for those who want to mix Debian with that other oddity,
so should be possible to avoid, and irrelevant to discuss in detail here
IMO.
>Creating a separate honey package which contains these expected
>dependencies makes sense... with the caveat that I _hate_ the terms;
>glucose, sucrose, fructose, and honey. I can never keep them
>straight.
:-)
Jonas Smedegaard
>On Sun, Jan 03, 2010 at 12:58:34PM +0100, Tomeu Vizoso wrote:
>
>>My understanding was that Jonas believes that software should be
>>deployed by the distro and not by developers (by using mechanisms such
>>as .xo bundles). From that POV sugar-platform is not needed.
>I don't think it should be an either-or decision. In fact it cannot
>be; there's no way Debian could ship _every_ activity.
>Sugar Platform is intended as a base line for _all_ activities, esp.
>all the random "small" ones.
>I guess Jonas was talking about Fructose activities, but will let him
>speak for himself. :)
User A installs the upcoming Debian Squeeze from a DVD onto his laptop
deep in the jungle with only expensive satellite link to the outside
world, so will only install "main" packages, not "contrib" ones that
depends on software not released with Debian (packages in "non-free" are
hosted using Debian infrastructure but not included with the final
distribution releases). User A will install sucrose-0.88 but not
honey-0.88.
User B installs a future Skolelinux consisting on Debian packages but
unlike Debian also including a few "non-free" packages - notably Etoys.
User B will install debian-edu-sugar which pulls in both sucrose-0.88
and honey-0.88, and perhaps also pulls a few popular .xo bundles if
reachable at install time.
User C installs some future Ubuntu which includes Sugar packaged as in
Debian except for a few tweaks: a splash screen is hacked in at startup
time, and sucrose-0.88 is made to depend on honey-0.88 as the many names
are considered user-unfriendly by Ubuntu Sugar developers. ;-)
User D wants to develop Sugar activities for Latin America, so installs
Debian unstable and the sugar-dev package.
Does that make sense?
Did I miss some obvious use case?
Holger Levsen
On Sonntag, 3. Januar 2010, Jonas Smedegaard wrote:
> It does not make sense to me to add non-package dependencies to
> sucrose-NN. It might make sense to maintain such in a separate
> metapackage, e.g. honey-NN.
/me suggest to build honey-NN from the sugar source package :)
regards,
Holger
David Farning
> On Sat, Jan 02, 2010 at 09:04:09PM -0600, David Farning wrote:
>>
>>
>> On Sat, Jan 2, 2010 at 5:28 PM, Jonas Smedegaard <d...@jones.dk> wrote:
>>>
>>> On Sat, Jan 02, 2010 at 04:26:55PM -0600, dfarning wrote:
>
>> Ok, still learning the bug reporting system. It seems pretty handy to:
>> Open a debian VM with quem (when testing which debian version should I
>> use?) Update to latest packages.
>> Run tests
>> Report via reportbug.
>
> I guess you mean qemu (not quem).
My spell is horiable:)
> Develop packages using unstable. Test using either unstable or testing
> (depending on what you want to test).
>
>
>>> Please file RFP (reguest for packaging) or ITP (intend to package) for
>>> each of those relevant-even-if-not-core activities.
>>
>> Distros don't need to worry about packaging the non-core activities.
>
> Yeah, there's many ways to get Free Software, only one of them being through
> Debian packages.
>
> It makes sense to support those wanting to use .xo bundles (honey-NN?) or
> build from source (sugar-dev-NN?), but only i not getting in the way of
> those wanting/expecting the main logic of Debian: Being fully installable
> while offline!
>
>
>>> sucrose-NN is intended to depend on all of core Sugar from Sugarlabs,
>>> recommend non-core parts shipped with Debian and suggest oddly packaged
>>> Sugar software (e.g. non-free packages).
>>
>> The problem is that because activity bundles (.xo) do not have the ability
>> to declare dependencies, activity developers must be able to depend on a
>> specific set package being available. I don't belive that this list of
>> packages has been set in stone; Rather is is more of a convention that
>> activity developers can depend on python-numpy and python-pygames being
>> available.
>
> Yes, .xo bundles have their own pile of challenges. Those challenges are
> relevant only for those who want to mix Debian with that other oddity, so
> should be possible to avoid, and irrelevant to discuss in detail here IMO.
That sounds reasonable. Wanting to install .XO bundles via
install_activity_bundle goes against the theory and practice of Debian
packaging.
One way we can get new packagers involved in Packaging Sugar on Debian
is to help package activities. I'll try to file ITPs and start making
packages for the simple activities for Debain. If someone downstream
wants to do something odd... It is on them.
>> Creating a separate honey package which contains these expected
>> dependencies makes sense... with the caveat that I _hate_ the terms;
>> glucose, sucrose, fructose, and honey. I can never keep them straight.
>
> :-)
>
>
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & 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.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLQPKyAAoJECx8MUbBoAEhRocP/1s6u3Lr3EzHfoRlSuUABzwJ
> m6YMcIzJpjxGkF5hXfYzBOsVkBXXiLpfgiHMsxnBkeWMBnV+eB+u31NcEJTH9Ynb
> qPLjsVqJeVct4V7jSHMQPCZQS7qqWTZdDrNbNHsOYfscyOU+XOkAeyVvD4jLDZf8
> pX5Npbqm6s++xJXrk8fFQsfqq61esnWTkMI35TpEDBWCOcKSx11fDp7o5ApL+DK0
> SZ43L+erNNTUTGrO3+Afcck17bc4xZ2w+k+BB5Fcg5FL+yzu6vS6N7O1UpwjwQGp
> qY+ZKeCtJBC4vQwZTx+U7/4qjPCRD5TzkCLejSKPdCJPHEjp7YnZ3dL+WTb2lhtO
> 4iT0ZY04Q8SvkSZkV9TOgF6HGnLvDxeo7Gy3MAqfd/bgrOcUqbzdy4KwM36I/lq2
> /Ql+4404TrLXZLIPkSVjiCG6pisZudx8yZTgYpIA3IxaaLrfeWY8xy/zdh1i8lsl
> 0EFldYwdd4tzzOiush9snowdqx2AQgo4gqKQkXIkayfWkkqWDkBbqpImfMxmnFuZ
> KRexbKslkc/deJLgbN6wUGoL+7EDi28YcBHj4SJw4H7XqbIgzc9GcYqHDYpoGCcB
> u3TfmrCUpDICkGf8ay+lGbNL0t30NydEWcWPx28NBHnR2/yIK+aX6dCPZRcFhQsu
> 6aCb7b4fn2S8Tb3oVbE6
> =O9Ed
> -----END PGP SIGNATURE-----
David Farning
Two missing use cases are:
School A installs a base Sugar on 100,00 machines and would like
teachers and students to be able to install locally written activities
bundles. I believe skolelinux has 10s of millions of users around the
world.
Company A wants to sell machines preloaded with a base Sugar and
expects users and schools to be able to install additional activities.
david
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & 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.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLQPtsAAoJECx8MUbBoAEh+9UQAKmwz9/gPfkG0/SueEnVkB7K
> xwCCxl6ZjMItpCDETDR+g6N3jb4cfwspSxUwcW20SI9QArNTIu24rG/A9M6Bc+fq
> JSz7vaM0Ti0ljwP1N2TXxMMBHaqWYXQlhAwMqlhRQF4iQCOUMVyGEDuhvVod86/0
> xX3vAoL3NbuKhx+HxM8mZ7vba2TYfQzI1QovLCfPsIXTqewvys3cHTakkDJH4bOD
> CS+KfiTe/8uxkh6/QCwnEz9CIEz8WtWYPdSm8lrx44yJD0go7oZK7EP8cpEDWDIE
> FOtEV0pFf912LK7CPXV+XVBO3tgtr2ujLPcB0t/agVVTZ7knQI65wxbx6yU6PniS
> vlx4z32kKEOzzny7FQh/FPnqUSqhjFiQGOOSKAdk/zWG8+HeJqX+J8426fPx+bov
> AW3AktDDihNhtC9lsHDJp1yLC7UgbMWq8WaLiTO9uXo5PAsq0adFGsq1anC0Fs54
> S3tYe1r528unrqiFkRojuNLGtaFYNb39iSn4DIujO+8Acd6N7HKquzIXl64qlTFc
> rTcoZpZvCrokWY0D2nzt28oxTT8i0ktKFj2ifvfpoFHY8NvJfgBmO1c14vYzJFbt
> m4loevjI5wjhzjHgExr2NR7VzntZE8pnDhb25LjD5qed3/ItiG/bnstHmuAzh7ru
> hGEG1yvoa6ULu0dMvuVo
> =xdVi
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Debian-olpc-devel mailing list
> Debian-o...@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/debian-olpc-devel
>
>
--
David Farning
install_activity_bundle. From a technical POV the issue seems similar
to how how Debian handles mozilla add ons. There are instances where
users will want the ability to use and install addons, without being
limited by their underlying distribution choice.
The solution seem to be to create a meta package which (1) pulls in
the dependencies sacha mentioned and (2) recommends a collection of
activities. If a user/deployer prefers to install activities via
install_activity_bundle they can install the meta package containing
the dependencies without the activities themselves. Then they can
install things via ASLO.
Either way, while this may be a huge philosophical difference,
technically it should be straight forward. Go a head and package
according to debian standards and expectations. We can add a couple
of changes downstream for handling ALSO installs. If and when those
changes prove useful, we can talk about pushing them into Debian.
david
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLQViLAAoJECx8MUbBoAEhz4UQAI+HH/KRgbBtSL0K4mYNruU9
> 1Qd+ga6a0z3Ij1tFhD2AyF4EGCcQU+oIC7nxDrz9/j+1dT+Vo97K6nZ+s55LgpSI
> NDqEa4biLRf+epjb9TDEFWB4BgE/GMgMU2mRlSc3acfiqe3sNPe13PyPNncG+EV4
> 556GxfAacSrpJLos394INbIrRwwso9p5YEEKFuA2mfKSolJxEhB9ccCF88qH+dfy
> fb4jJRhV6deKJDs7pDQzt/Z7zv73KqF50QVjCb4U2O3ZqbLUgW/9uTxM92cpoGgT
> t48oz64Fq7favuVVvCMkwprYp0qPe480Z1ULEebZmxBjboONe0MYpKepOJ+dJLlX
> PfQqPNTthd5ZroAceJ1oM+IrGstEnivbVRqdtHMRC3DWi1ZY7zpU4QTOaCQe45Ob
> hb4qbrVfWosGjB0HU+npOQ/KRg3t+PcVCrC5WBD/tQ6/vvdB8AlJYQ3c96nMCTaP
> +y++Fm8n3rQ9RueDhnH5JK+PuE8qkmDJ31ZdECiWpkeqSLFja0Q3hONihgexa1oF
> g3fNCk6FnSiMZOtLAYiAGsmXp6OxfbhkdnP40V8VkxGwKZvMtPtgqjFi+avJKfwl
> HNXXz5hG8Qp3AxzMMyEM3bFYqADVuUm48EYyhjCKSQBkCKfrfnOAiP75Duci9Kf/
> e3a+RxIRoW1+ci8J7jp6
> =pnUO
> -----END PGP SIGNATURE-----
Jonas Smedegaard
>The difference is that they expect to be able to install bundles via
>install_activity_bundle. From a technical POV the issue seems similar
>to how how Debian handles mozilla add ons. There are instances where
>users will want the ability to use and install addons, without being
>limited by their underlying distribution choice.
Seems equal to my "User B" (even emphasized by installing parts of the
Sugar environment through .xo bundles).
If not, please elaborate.
>The solution seem to be to create a meta package which (1) pulls in
>the dependencies sacha mentioned and (2) recommends a collection of
>activities. If a user/deployer prefers to install activities via
>install_activity_bundle they can install the meta package containing
>the dependencies without the activities themselves. Then they can
>install things via ASLO.
Do you mean some other package than my proposed honey-NN?
>Either way, while this may be a huge philosophical difference,
>technically it should be straight forward. Go a head and package
>according to debian standards and expectations. We can add a couple
>of changes downstream for handling ALSO installs. If and when those
>changes prove useful, we can talk about pushing them into Debian.
What downstream hacks do you have in mind? Is it not currently working
to install .xo bundles in Debian, or am I missing the point?
Kind regards,
David Farning
> On Sun, Jan 03, 2010 at 10:34:12PM -0600, David Farning wrote:
>>
>> The difference is that they expect to be able to install bundles via
>> install_activity_bundle. From a technical POV the issue seems similar to
>> how how Debian handles mozilla add ons. There are instances where users
>> will want the ability to use and install addons, without being limited by
>> their underlying distribution choice.
>
> Seems equal to my "User B" (even emphasized by installing parts of the Sugar
> environment through .xo bundles).
>
> If not, please elaborate.
>
>
>> The solution seem to be to create a meta package which (1) pulls in
>> the dependencies sacha mentioned and (2) recommends a collection of
>> activities. If a user/deployer prefers to install activities via
>> install_activity_bundle they can install the meta package containing
>> the dependencies without the activities themselves. Then they can
>> install things via ASLO.
>
> Do you mean some other package than my proposed honey-NN?
No, I have come full circle to agree with the proposed honey-NN
>> Either way, while this may be a huge philosophical difference,
>> technically it should be straight forward. Go a head and package
>> according to debian standards and expectations. We can add a couple
>> of changes downstream for handling ALSO installs. If and when those
>> changes prove useful, we can talk about pushing them into Debian.
>
> What downstream hacks do you have in mind? Is it not currently working to
> install .xo bundles in Debian, or am I missing the point?
Below is a snippet of the script to used to preinstall .xo when
constructing the Ubuntu-Sugar-Remix. I think that SoaS does something
similar.
<snip>
## Install activities bundles ##
BUNDLE_LIST="org.laptop.community.TypingTurtle \
org.laptop.WebActivity \
org.laptop.Log \
org.sugarlabs.IRC \
com.garycmartin.Moon \
org.laptop.sugar.ReadEtextsActivity \
com.ywwg.CartoonBuilderActivity \
vu.lux.olpc.Speak \
org.laptop.ViewSlidesActivity \
org.sugarlabs.InfoSlicer \
org.worldwideworkshop.olpc.FlipSticks \
org.worldwideworkshop.olpc.JigsawPuzzle \
org.worldwideworkshop.olpc.SliderPuzzle \
org.laptop.community.Colors \
org.squeak.FreeCell \
org.laptop.Analyze \
org.laptop.Develop \
org.laptop.TamTamEdit \
org.laptop.TamTamJam \
org.laptop.TamTamMini \
org.laptop.TamTamSynthLab \
org.laptop.Memorize \
org.worldwideworkshop.JokeMachineActivity \
vu.lux.olpc.Maze \
org.worldwideworkshop.olpc.storybuilder \
org.worldwideworkshop.PollBuilder \
org.gnome.Labyrinth \
org.laptop.RecordActivity \
org.laptop.Oficina \
tv.alterna.Clock \
org.laptop.physics \
org.laptop.sugar.GetIABooksActivity \
org.laptop.Arithmetic"
BUNDLE_CACHE_DIR=${REMASTER_HOME}/bundle_cache
ASLO_SP='0.86'
ASLO_URL='http://activities.sugarlabs.org/services/update-aslo.php'
ASLO_LINK='.//{http://www.mozilla.org/2004/em-rdf#}updateLink'
function install_activity_bundles()
{
mkdir -p $BUNDLE_CACHE_DIR
echo "Preparing directory for activities"
if [ -e ${REMASTER_DIR}/usr/share/sugar/activitie ]; then
remove_directory ${REMASTER_DIR}/usr/share/sugar/activities ||
failure "Failed to remove directory
${REMASTER_DIR}/usr/share/sugar/activities"
fi
mkdir -p ${REMASTER_DIR}/usr/share/sugar/activities
for bundle_id in ${BUNDLE_LIST} ; do
curl -4 -s -L "$ASLO_URL?id=$bundle_id&appVersion=$ASLO_SP" >
$BUNDLE_CACHE_DIR/metadata
url=$(python -c "from xml.etree.ElementTree import parse;
url=parse('$BUNDLE_CACHE_DIR/metadata').find('$ASLO_LINK'); print url
is not None and url.text or ''")
if [ -z "$url" ]; then
echo "Can not find url for $bundle_id" >&2
continue
fi
remote_file=$(basename $(curl -4 -s -L -w %{url_effective} -I $url | tail -1))
bundle=$BUNDLE_CACHE_DIR/$remote_file
if [ ! -f $bundle ] ; then
curl -4 -L $url > $bundle
fi
cp -p $bundle ${REMASTER_DIR}/usr/share/sugar/activities
done
pushd ${REMASTER_DIR}/usr/share/sugar/activities
unp *.xo
popd
}
install_activity_bundles
<snip>
david
> Kind regards,
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & 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.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLQckuAAoJECx8MUbBoAEhhCUP/jz39DL3bj6YdwpFGKZkLRY4
> zoF7//+lsaTHanSJzvuqPJXUU5yWr72IUWHr0SPNYtjmhOgeAjP+IzAKTBmsCgHV
> Rp9WfZg/XKiy2TWAvDMxQGOZlHb7fqeZRV5FLJXJKteRRtd229R71rpnf0Pw/xdl
> YUeLtTh0585y6nWLUO53yGTD2J6WoszO6vo9WfS+r+VmOGK10Ampii5yqp4SGyVJ
> EX7MX17h9ahT4qcAf6N/JSd3tcd4EIvOit/xf7sjC6DqYCnIuPC+95380RKeB5w6
> 8GCPWoh8jG7kAdq0l9Up3yG6ZjP3ZwQHIfHHdJuHYonVNwzH46G4d5daMGwVcS+Y
> WBAj2SlrFLnbQSoxbkwQqQslEuyeZnBmKVlx1SnFoT3bam7EeJnqmt2prEEvxu4B
> KWEa9EJT48YCJk1U//vPC3VdzWctj1rZgtXJUXrA7hjHKid0w6joxPpst2ER2Ajn
> CvAFmZnbqsTfbem3vIfzK/ZiB42SeZtFxIqHMqAZD+RHJ7r+kMqZdsiL9oLpwZ7j
> bSn2D9Fk/R3c1eWSbVONl0t6hN8ns0BAZVcAaHLnqRGxS5vEZGKWpGdHec8upI4q
> tt/vbW1UMnkQbtiyAfZYy29lZCceF5lEYJcWSeghvxVoebIqJ72r5id/m+lvVoQ+
> oqH9RRCldmWv5yAJSvEF
> =fxjW
Jonas Smedegaard
>On Mon, Jan 4, 2010 at 4:55 AM, Jonas Smedegaard <d...@jones.dk> wrote:
>> Do you mean some other package than my proposed honey-NN?
>
>No, I have come full circle to agree with the proposed honey-NN
Ok.
>>> Either way, while this may be a huge philosophical difference,
>>> technically it should be straight forward. Go a head and package
>>> according to debian standards and expectations. We can add a couple
>>> of changes downstream for handling ALSO installs. If and when those
>>> changes prove useful, we can talk about pushing them into Debian.
>>
>> What downstream hacks do you have in mind? Is it not currently
>> working to install .xo bundles in Debian, or am I missing the point?
>
>Below is a snippet of the script to used to preinstall .xo when
>constructing the Ubuntu-Sugar-Remix. I think that SoaS does something
>similar.
Sorry if my question(s) were ambiguous: My interest (here and now) is
not in actual code, but in understanding if there is something broken in
the way the current Debian packages do things, or you are talking about
extensions/hacks that should perhaps be adopted upstream instead - and
if not, I want to understand *why* it makes sense to maintain something
downstream (either Debian+Ubuntu or only Ubuntu).
Regards,
David Farning
> On Mon, Jan 04, 2010 at 01:18:50PM -0600, David Farning wrote:
>>
>> On Mon, Jan 4, 2010 at 4:55 AM, Jonas Smedegaard <d...@jones.dk> wrote:
>>>
>>> Do you mean some other package than my proposed honey-NN?
>>
>> No, I have come full circle to agree with the proposed honey-NN
>
> Ok.
>
>
>>>> Either way, while this may be a huge philosophical difference,
>>>> technically it should be straight forward. Go a head and package according
>>>> to debian standards and expectations. We can add a couple of changes
>>>> downstream for handling ALSO installs. If and when those changes prove
>>>> useful, we can talk about pushing them into Debian.
>>>
>>> What downstream hacks do you have in mind? Is it not currently working to
>>> install .xo bundles in Debian, or am I missing the point?
>>
>> Below is a snippet of the script to used to preinstall .xo when
>> constructing the Ubuntu-Sugar-Remix. I think that SoaS does something
>> similar.
>
> Sorry if my question(s) were ambiguous: My interest (here and now) is not in
> actual code, but in understanding if there is something broken in the way
> the current Debian packages do things, or you are talking about
> extensions/hacks that should perhaps be adopted upstream instead - and if
> not, I want to understand *why* it makes sense to maintain something
> downstream (either Debian+Ubuntu or only Ubuntu).
The only reason for maintaining it down stream would be if it is
useful to a set of end users yet violates Debian policy or
conventions. If this fall into that case then it seems reasonable to
do so.
I would not consider it broken.... but it would be convenient if the
set of packages sacha mentioned could be installed as part of a
'default' sugar installation with out the activities themselves being
installed.
Activity developer expect the APIs from that set of packages to be
available to them. Yet, if an end user attempts to install a bundle
that depends on those API they will get an expected error unless it
has been installed.
david
>
> Regards,
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & 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.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLQkltAAoJECx8MUbBoAEhLioP/2X/EGbEYyBCsLDdv3LViGVE
> 6GnSexgSg5XsvEfD23YtUGTB1g3XNNSfozODidqHUwJ43+V/+O6QHxocKMIKqDEb
> 2DzlyZFhrFjK8YflnLR1BbGaBU0dtI+W+Pga3T5I+xp6YVtWvBaQE6rZ/A/pBaOg
> tKOMnT9KIkLygDq22RCFEddbitRCyzH6E1Dua3UYmOJK29h7pEPsYBaqtMGqdC0j
> CR6cP33NArD0No5onEFHs75ChHCOBGc0aF9U6iGuQc1TKn7OvGwbGHqVzVNYUHVv
> LM1RE9ANe8PG79g+fvUMI7VO1RL/DnflGTZqeTYOVwcZAfHwwytTcpZHpnR+NQ5K
> fsn5zzblB8RYKFJY55R3keq898MshP+8WhaQ26qcxAStENII64iGnf5Xg+gxmc8I
> Wz9cV0Oh4Cg2NLaqPRtKqigP7CSFkTvnR8OhHCXfKiT8ka36lwBFLCRUW1AB9oDO
> cZwLN4uWxC5PLxTv57wev8zFbduys5DWXSNfbNB+VavdUWM2gKsAIOg/u++6dw+9
> T99muY2oV5/YVEzLXlHOM3mmu4/RZOn+oh2KSzZUD4CAwe0O+lTAwbxDrbdQOifT
> wXW1PvQXpW7nAkp/qzhyEtqVt4lcOr/0DjdW5hF9ycNsw3iw1lWS28yHGrFeDCEP
> YJdKY6V9P1enkbC3FOe9
> =b7aB
Jonas Smedegaard
I suspect that there is no problem at all here: users wanting to install
.xo bindles need no hacks or custom scripts, but just need to install
whatever libraries the .xo files depend on - which may be covered by a
honey-libs-NN package or not, depending on the actual .xo's.
(please note that i've changed my mind regarding naming of that package:
honey-NN is bad as it does _not_ provide honey, only the supporting
libraries for (well-behaving) honey activities).
David Farning
david