We have release process but it's a little complicated.
http://etoys.squeak.org/svn/trunk/Documentation/Release-HowTo.txt

Karl


On Mon, Jan 20, 2014 at 5:34 PM, Gustavo Duarte <gduarte at activitycentral.com
> wrote:

> Bert,
>
> I saw the commit to fix the sugar interaction was done.
>
> To generate the deb package of Etoys with the last changes, without wait
> for the upsream release: It is right the following procedure ?:
>
> 1) Run Etoys, and from unnamed project, update from server code.
> 2) Save the changes
> 3) Copy etoys.image and etoys.changes to my source code tree
> 4) Generate the deb package.
>
>
> My doubt, is meanly if only etoys.image and etoys.changes are needed to
> copy ?
>
>
> Thanks.
> Gustavo.
>
>
>
>
> On Fri, Jan 17, 2014 at 5:52 PM, Gustavo Duarte <
> gduarte at activitycentral.com> wrote:
>
>> Bert, thank a ton for the fix.
>>
>> I added the bug to the tracker and upload the fix.
>>
>> http://tracker.squeakland.org/browse/SQ-1200
>>
>> I gonna wait, to be included on upstream.
>>
>> I hope procedure followed was be right.
>>
>> Thanks.
>> Gustavo
>>
>>
>> On Fri, Jan 17, 2014 at 9:51 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:
>>
>>> Hi Gustavo,
>>>
>>> the problem is not in the XMLDomParser, but how it it used. Apparently
>>> the way gconf stores its values changed. Previously both numeric and string
>>> values had a separate entity inside, like you discovered. Now it appears
>>> int values are stored in a more compact way.
>>>
>>> The problem is in the SugarLauncher>>gconfPropertiesAt: method. It
>>> treats strings and int properties the same way.
>>>
>>> Instead of "entry elements first contentString" it might use "entry
>>> attributeAt: 'value' ifAbsent: [entry elements first contentString]". This
>>> should work with both the old and the new format. Here's the full method,
>>> patched (but untested):
>>>
>>> gconfPropertiesAt: aString
>>> | dir |
>>> "search up tree to guess home dir"
>>>  dir := Project squeakletDirectory.
>>> [dir pathName = '/'] whileFalse: [
>>> dir := dir containingDirectory.
>>>  [FileStream
>>> readOnlyFileNamed: dir pathName, '/.gconf', aString, '/%gconf.xml'
>>> do: [:f |
>>>  | props |
>>> props := Dictionary new.
>>> (XMLDOMParser parseDocumentFrom: f)
>>>  tagsNamed: #entry do: [:entry |
>>> props at: (entry attributeAt: 'name')
>>>  put: (entry attributeAt: 'value'
>>> ifAbsent: [entry elements first contentString])].
>>>  ^props].
>>> ] on: FileDoesNotExistException do: [:ignore | ].
>>> ].
>>>  ^self error: 'cannot find gconf path ', aString
>>>
>>> This document describes how to publish a fix for Etoys:
>>>
>>> http://etoys.squeak.org/svn/trunk/Documentation/Developer-HowTo.txt
>>>
>>> If you just want to fix it in the distro rather than waiting for an
>>> upstream release, you should be able to change the method, enter the hidden
>>> unnamed top-level project, and save the image from that project (it is
>>> important to be in that project when saving the image).
>>>
>>> - Bert -
>>>
>>> On 16.01.2014, at 15:54, Gustavo Duarte <gduarte at activitycentral.com>
>>> wrote:
>>>
>>> Hi Georg,
>>>
>>> The xml file content is:
>>>
>>> <?xml version="1.0"?>
>>> <gconf>
>>>         <entry name="color" mtime="1389708067" type="string">
>>>                 <stringvalue>#9A5200,#FF2B34</stringvalue>
>>>         </entry>
>>>
>>>         <entry name="birth_timestamp" mtime="1389708044" type="int"
>>> value="-849347955"/>
>>>
>>>         <entry name="ip" mtime="1389708044" type="string">
>>>                 <stringvalue>1.2.3.4</stringvalue>
>>>         </entry>
>>>
>>>         <entry name="SugarBuddyOwner" mtime="1389708044" type="string">
>>>                 <stringvalue>1234</stringvalue>
>>>         </entry>
>>>
>>>         <entry name="nick" mtime="1389708044" type="string">
>>>                 <stringvalue>estudiante</stringvalue>
>>>         </entry>
>>> </gconf>
>>>
>>> I don't know much about xml format, but seemingly it hasn't XML schema
>>> specification, right ?
>>>
>>>
>>> On Thu, Jan 16, 2014 at 11:11 AM, Georg Gollmann <
>>> gollmann at zid.tuwien.ac.at> wrote:
>>>
>>>>
>>>> Am 16.01.2014 um 13:10 schrieb Gustavo Duarte <
>>>> gduarte at activitycentral.com>:
>>>>
>>>>  I guess that XMLDOMParser doesn't support the xml line format:
>>>> <entry name="birth_timestamp" mtime="1389708044" type="int"
>>>> value="-849347955"/>.
>>>>
>>>> I don't know much about xml format, but i think that is valid format
>>>> entry, so XMLDOMParser has bug.
>>>>
>>>>
>>>> Whether the bug is in the parser or the file depends on the XML schema
>>>> specified in the file.
>>>>
>>>>  Kind regards
>>>> Georg
>>>>
>>>>
>>>
>>>
>>>  - Bert -
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140121/bc9dd2ea/attachment.htm