[Glass] Cannot load Metacello nor Glass in Glass itself (spot bug)

Fri Jan 17 05:57:49 PST 2014

Hi guys,

Dale, I think I have the exact same problem as Johan. I am checking the .cs
attached to the issue tracker and I see some differences to what I have
loaded in my current glass.

First, in #extractRepositoryFrom: zipFile to: directory      I notice some
difference and after checking, it seems I am
using Metacello-Platform.gemstone-dkh.29 .. and that was committed
in Metacello-Platform.gemstone-dkh.32.  but the comment in the issue
tracker says the issue was integrated in  Metacello-Preview
1.0.0-beta.32.8. As far as I know, I am using last stable glass....

Same for #downloadFile: url to: outputFileName

#projectDirectoryFrom: projectPath version: versionStrin I see a completly
different version I have in my glass and I don't see Johan changes
committed. Moreover, there are new versions committed for that package that
still change this method but I am not sure if it includes Johan changes. I
think these may have been lost.

#downloadErrorFileNameFor: zipFileName I don't even see it nor in my
current version nor in the latest committed version...

So...all in all, those 2 last methods may have been lost.

Cheers,

On Fri, Jan 17, 2014 at 3:42 AM, Johan Brichau <johan at yesplan.be> wrote:

> Btw, the things to try below are for *after* the download failed and you
> end up with a 'broken' GitHub repo in your image. I typically also get that
> when restoring a backup locally. At that point the github repo has lost its
> link to the github-cache directory (because it's no longer there at the
> place I restore the backup). Doing a metacello load then fails because the
> repository is empty but a new download is not triggered. So I remove all
> and clear the cache to trigger a download.
> I also noticed you end up in the same situation if the download failed.
>
> Johan
>
> On 17 Jan 2014, at 02:38, Dale Henrichs <dale.henrichs at gemtalksystems.com>
> wrote:
>
> Johan,
>
> I fixed the error handling, but in Mariano's case he has multiple linux
> users (with incompatible file permissions) trying to overwrite the same
> file and the permissions will just not allow that ...
>
>
> On Thu, Jan 16, 2014 at 2:38 PM, Johan Brichau <johan at yesplan.be> wrote:
>
>> Mariano,
>>
>> Here are a couple of things I know to work when I hit this kind of issues:
>>
>> Is the github repository present in your list when you open metacello?
>> Remove it.
>> Is it present in the github-cache on disk? Remove it.
>> Clear the Monticello cache (from Monticello tool).
>>
>> Often, I find this helps. Hope it helps for you.
>>
>> Johan
>>
>> On 16 Jan 2014, at 22:43, Mariano Martinez Peck <marianopeck at gmail.com>
>> wrote:
>>
>>
>>
>>
>> On Thu, Jan 16, 2014 at 5:53 PM, Dale Henrichs <
>> dale.henrichs at gemtalksystems.com> wrote:
>>
>>> Mariano,
>>>
>>> The github downloads aren't very good at providing good error messages
>>> ... I have recently (in last month) improved some of the error handling for
>>> github, but those improvements are only in the github repo and if you can't
>>> download from github then you probably aren't using them...
>>>
>>>
>> Indeed. But something is weird: I could successfully bootstrap GLASS,
>> using the installGLASS you provided me...doesn't this script use any github
>> repo????
>>
>>
>>> But your use case of running multiple glass users (at the linux level)
>>> is probably not accounted for  in the github implementation so additional
>>> work needs to be done there to accomodate multiple users on the same
>>> machine using Metacello ...
>>>
>>>
>> ouch.....
>>
>>
>>> I've submitted a metacello bug[1] to track the issue ...
>>>
>>> Until I can fix the bug, you the code  there are a number of methods
>>> that make the assumption that /tmp can be used as a temporary dumping
>>> ground for files:
>>>
>>>   MCGitHubRepository class>>projectDirectoryFrom:version:
>>>   MetacelloGemStonePlatform>>downloadFile:to:
>>>   MetacelloGemStonePlatform>>extractRepositoryFrom:to:
>>>
>>> Presumably these methods could be hacked to replace the use of '/tmp'
>>> with a suitable image-specific replacement ... where you can set the root
>>> temp directory to something that works for you ... this is probably the
>>> route I will take for the final solution ...
>>>
>>
>> Thanks. I indeed found other files in /tmp which were owned by a
>> different system user... I have removed them like "sudo rm github*" and
>> "sudo rm curl*".
>>
>> Still...same problem. I then tried stopping and starting stone again.
>> Still, same problem. Finally I drop the extent and I bootstrapped
>> everything from scratch again...why? because I thought some class var or
>> something could have been persisted with wrong stuff or garbage. So I
>> started again with that just bootstrapped glass and an empty /tmp and that
>> worked!!!
>>
>> So I should wait for your fix to have multiple system users sharing the
>> same /tmp, right?
>>
>> Let me know if I can be of help.
>>
>> Thanks,
>>
>>
>>> Dale
>>>
>>> [1] https://github.com/dalehenrich/metacello-work/issues/232
>>>
>>>
>>> On Thu, Jan 16, 2014 at 11:51 AM, Mariano Martinez Peck <
>>> marianopeck at gmail.com> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I have managed to install Glass into a base extent using the
>>>> installGlass script provided by Dale. I am running this with a special
>>>> user, not DataCurator, but with similar privileges. I can install Glass,
>>>> but then as soon as I try to download something with Metacello...I get a
>>>> spec resolution error....
>>>> It is important to note that all gems/netldi/stone are also running
>>>> with its own system user.
>>>>
>>>> I am trying to download this for example:
>>>>
>>>>   Metacello new
>>>>  baseline:  'Metacello';
>>>> repository: 'github://dalehenrich/metacello-work:master/repository';
>>>>  get.
>>>>
>>>> First, I found a bug in #extractRepositoryFrom: zipFile to: directory
>>>> I was getting a simple GoferRepositoryError with no clear message.
>>>> AFter debugging a bit, I found that such a method was end up doing
>>>> something like:
>>>>
>>>> /usr/bin/unzip -u /tmp/github.zip -d
>>>> /home/Testing/github-cache/dalehenrich/metacello-work/master 2> /tmp/zip.err
>>>>
>>>> Problem was that I ALREADY had a /tmp/zip.err but that was written with
>>>> another SO user... and defined unix file permission, didn't allow to write
>>>> it with a different user..hence I was getting a permission denied which
>>>> ended in sending #contentsOfEntireFile to nil...
>>>> So would it be possible to write zip.err with a more specific name?
>>>> like per stone or something...or give write access to other ...
>>>>
>>>> Anyway....I remove the file with sudo and then it continue...but still
>>>> getting a spec resolution error...but what is funny here is that I don't
>>>> get ANY error nor repository error.. the line " self
>>>> resolvePackageSpecReferences: packageSpec gofer: gofer  " simply returns an
>>>> empty array....
>>>>
>>>> Any idea what could be?  any bell? remember, custom system operating
>>>> user (not sudoer), custom gemstone user, custom glass install, ... so yeah,
>>>> kind of sounds like I should get problems hahahah
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> --
>>>> Mariano
>>>> http://marianopeck.wordpress.com
>>>>
>>>> _______________________________________________
>>>> Glass mailing list
>>>> Glass at lists.gemtalksystems.com
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>
>>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140117/9ecd9fe9/attachment-0001.html>