[IAEP] Core Sugar framework now in Debian Testing!

Fri May 23 17:29:35 CEST 2008

The "tyranny of open" and of the self-appointed gate keepers.

Cheers,

Alan

----- Original Message ----
From: Bert Freudenberg <bert at freudenbergs.de>
To: Morgan Collett <morgan.collett at gmail.com>
Cc: Education <its.an.education.project at tema.lo-res.org>; José L. Redrejo Rodríguez <jredrejo at edu.juntaextremadura.net>; sugar List <sugar at lists.laptop..org>
Sent: Friday, May 23, 2008 7:50:20 AM
Subject: Re: [IAEP] Core Sugar framework now in Debian Testing!

On 23.05.2008, at 14:01, Morgan Collett wrote:

> On Fri, May 23, 2008 at 12:32 PM, Jonas Smedegaard <dr at jones.dk>  
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Thu, May 22, 2008 at 04:39:19PM -0600, Debian testing watch wrote:
>>> FYI: The status of the sugar source package
>>> in Debian's testing distribution has changed.
>>>
>>> Previous version: (not in testing)
>>> Current version:  0.79.4-2
>>
>> All core Sugar packages are now in Debian Testing!
>>
>> With "core" I mean all Sugar software except activities themselves.
>>
>> (upstream have no clear definition of "core" - it seems they agree  
>> that
>> Sugar should always include some activities, but does not agree on  
>> some
>> common default "core" set of activities...)
>
> You must have missed the recent activity on the sugar list... Sugar as
> an upstream project now has designated "demo" activities which distros
> can choose to bundle.
>
> http://wiki.sugarlabs.org/go/Taxonomy gives names to different
> components in the stack which as been known in whole or part as
> "Sugar". Fructose now refers to the activities bundled with Sugar.
>
> http://wiki.sugarlabs..org/go/Modules lists Sugar components,
> dependencies and these activities.
>
> http://wiki.sugarlabs.org/go/Release shows how releases are done of
> the Sugar (I mean, Glucose) modules and Fructose activities.
>
> http://wiki.sugarlabs.org/go/Roadmap shows the planned release
> strategy for the next few months.
>
>> We need more activities packaged! Please speak up if you are  
>> interested
>> in helping out.
>
> I haven't done packaging before - it's always been on my TODO list to
> learn. I run Ubuntu, but I'm interested in getting involved (with the
> view to making sure Ubuntu releases with the appropriate versions of
> the various components). Please remind me where your documentation is,
> and what list to join. I think we should have a page on the sugarlabs
> wiki tracking each distro's packaging.
>
> I helped test Jani's Ubuntu packages before the hardy release.
> Unfortunately I only realised days before the release that the sugar
> versions included were not the most appropriate versions: taken from a
> different branch to the stable release. While it looks the same as the
> stable release (0.75.x in build 703) there are differences, which may
> mean bugs in the Ubuntu version (0.79.0) which were fixed in the
> 0.75.x series after that release. So I really want to see distro
> releases (especially Ubuntu) having the most appropriate versions of
> the Sugar stack.
>
> We are not OpenSSL, but... I do think it is important that we maintain
> good communication with distro packagers to assist in this.

Etoys is missing, and is about to be rejected by Debian's ftp masters.  
This time not because of the license (which finally was solved) but  
because of Squeak's use of object memory snapshots (a.k.a. images).  
See below.

- Bert -

Begin forwarded message:

> From: Bert Freudenberg <bert at freudenbergs.de>
> Date: 23. Mai 2008 11:56:38 MESZ
> To: ftpmaster at debian.org
> Cc: "José L. Redrejo Rodríguez" <jredrejo at edu.juntaextremadura.net>, holger at layer-acht.org
> Subject: Re: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED
>
> On 21.05.2008, at 23:06, Thomas Viehmann wrote:
>> Hi José, Bert, Holger,
>>
>> this is, unfortunately, the REJECT of etoys.
>> First of all, thanks Bert, Holger, José for the discussion of some of
>> the concepts. However, I am afraid that there are some fundamental
>> concerns that have not been eliminated (yet). As such I would like to
>> invite you to start a discussion on the packaging of squeak session
>> images on debian-devel at lists.debian.org. Feel free to forward this
>> mail if you consider it useful as a starting point.
>>
>> It seems to me that the method of distributing VM sessions in .image
>> files as the preferred form of modification does not match too well
>> with Debian practices of compiling packages from source and having
>> easy access to the differences between various versions of a package.
>>
>> So as far as I understand it it seems like a typical squeak image
>> cannot be bootstrapped[1] from (textual) source and that the typical
>> mode of operation is to modify some known image and distribute the
>> result. As such, the preferred form of modification is indeed the
>> image file.
>>
>> This, in my opinion, raises at least the following questions that  
>> seem
>> fundamental to me:
>>
>> - How easy should it be to figure out what is in an image?
>> While the source code to any class seems to be available, the
>> image is more than that. Does that matter? Should source of Debian
>> packages be auditable and is etoys currently auditable easily
>> enough?
>>
>> - Does Debian (including the various teams that might have to take
>> a look at your packages) want to have easy access to the
>> differences between upstream version, one Debian revision and
>> another? Do squeak session images provide this in a way that
>> is acceptable to Debian?
>>
>> From the squeak wiki pages and your explanations it seems that what I
>> would consider at least partial solutions exist, but it seems that
>> either I am still lacking understanding of important concepts or
>> that the etoys packaging (Debian and maybe also upstream) could
>> possibly be made a bit more transparent.
>> Of course, we might find out that my difficulties with the
>> perspective of squeak images in Debian originate in misconceptions of
>> Debian packaging and maintenance that I may have. Either way, I would
>> appreciate if we could discuss this with the Debian development  
>> public
>> at large and draw on their additional expertise.
>>
>> Kind regards
>>
>> Thomas
>>
>> 1. http://wiki.squeak.org/squeak/769
>> -- Thomas Viehmann, http://thomas.viehmann.net/
>
>
>
> Yes, please discuss this. It would be sad if Squeak would not be  
> allowed into Debian just because it uses a different development  
> philosophy. It finally complies with the DFSG after the huge  
> relicensing effort. Communities like LinEx (which is Debian-based)  
> had included it even before that, but now finally they have the  
> chance to included it properly. There is active upstream  
> development. José is a maintainer who does understand Smalltalk  
> well. Squeak comes with all the tools to examine the image (they are  
> in the image). It certainly is not perfect, but that requirement  
> would be a high bar indeed.
>
> One very concrete urge to get it included is the Sugar environment.  
> It was initiated by OLPC first, but is now breaking free from it.  
> Etoys is one of the basic components of Sugar, used by kids and  
> teachers worldwide. There will certainly be many users who prefer to  
> run Sugar on Debian. Again, it would be sad if they were deprived of  
> parts of Sugar, just because of the fear of the unkown.
>
> So long,
>
> - Bert -
>

_______________________________________________
Its.an.education.project mailing list
Its.an.education.project at lists.sugarlabs.org
http://lists.lo-res.org/mailman/listinfo/its.an.education.project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lo-res.org/pipermail/its.an.education.project/attachments/20080523/84e164dc/attachment.htm>