Hey everybody,

I got everything running now.  Again, I am running Debian Etch on x86.  Here's 
how:

I changed setup.sh so that line 107 reads

bundledir="$GNUSTEP_SYSTEM_ROOT/Library/Bundles"

instead of

bundledir="$GNUSTEP_LOCAL_ROOT/Library/Bundles"

This is so setup.sh performs the 'defaults write . . .' for the bundles 
correctly, as Camaelon.themeEngine, EtoileWildMenus.bundle, and 
EtoileBehavior.bundle are installed in $GNUSTEP_SYSTEM_ROOT and not 
$GNUSTEP_LOCAL_ROOT.  This corrects the problem named in the last section of my 
last emails, that etoile_system couldn't load "3 user defined AppKit Bundles."  
WildMenus and the Nesedah theme are functional even running GNUstep apps 
outside of the Etoile environment (which is as it should be once these bundles 
are defined).

I ran ./setup.sh and chose option 1, the sudo option, so that things would be 
set up system wide and the defaults written for user 'james' and not for 'root.'

Also, I ran 'sudo chmod 644 
/usr/GNUstep/System/Library/Etoile/SystemTaskList.plist' to make it so regular 
users can read that file and so root can still write it.  Earlier the 
permissions were to set to 600 (-rw-------), read and write for root only, 
making etoile_system fail, as it did not have a readable SystemTaskList.plist.

I did have to run 'make install' as root (see next paragraph), so that might 
explain the permissions problems.  I don't know what would happen if 'sudo make 
install' would run.

I am still mystified as to the behavior of sudo.  I have to run 'make install' 
logged in as root, otherwise this happens:
[EMAIL PROTECTED]:~/Etoile-0.2$ sudo make install
GNUmakefile:1: /common.make: No such file or directory
GNUmakefile:82: /aggregate.make: No such file or directory
make: *** No rule to make target `/aggregate.make'.  Stop.

This tells me that the environment variables which are set by sourcing 
GNUstep.sh are being forgotten somehow by sudo.

Alright, that's all I've got right now.  Thanks for your time in helping me out 
and in writing this software.  I hope I can be of some help by reporting my 
troubles and problems with it.

James

On 2007-08-02 22:52:35 -0500 "Yen-Ju Chen" <[EMAIL PROTECTED]> wrote:

> I quickly write a troubleshoot post on Étoilé blog.
> If you can try it, let me know which step you have problem.
> I check the permission of my system and they are all property set.
> Some are under my username and some are root.
> But the permissions are all correct.
> The way I did is that I compile everything under my account
> and only 'sudo' for installation.
> 'setup.sh' is supposedly to run with regular user account, not root.
> But I believe it is only tested with Ubuntu.
> Maybe you can take a look at the script and set up your system manually.
> Most of the stuff is mentioned in the post already
> 
> Yen-Ju
> 
> On 8/2/07, James Mahoney <[EMAIL PROTECTED]> wrote:
>> Hey again,
>> 
>> I'm going to think out loud, and explain what I think might be going on 
>> with some of these phenomena.  That way you won't have to explain 
>> everything to me, or you can correct my misunderstandings.
>> 
>> On 2007-08-02 19:35:51 -0500 James Mahoney <[EMAIL PROTECTED]> wrote:
>> [snip]
>>> On 2007-08-01 04:50:20 -0500 Quentin Mathé <[EMAIL PROTECTED]> wrote:
>>> [snip]
>>>> You shouldn't run ./setup.sh as root, it isn't ready to be used this 
>>>> way..
>>>> When you run setup.sh as root some environment variables like
>>>> $GNUSTEP_SYSTEM_ROOT might be lost and also $GNUSTEP_USER_ROOT would 
>>>> point
>>>> to /root, the outcome is that some elements aren't set up for  your daily
>>>> user account (the one you use to log in from GDM).
>>> 
>>> What if I source GNUstep.sh in root's bashrc/profile as well?  (Which I 
>>> do.)
>>> 
>> 
>> The $GNUSTEP_SYSTEM_ROOT will be fine, but the preferences won't be set 
>> right for 'james.'  The preferences will be set right for 'root' however. 
>> I don't know what other consequences there might be.
>> 
>> [snip]
>> 
>>> Also, I (as root) ran 'make uninstall' and ran 'setdown.sh' both as 'root'
>>> and as 'james' with the sudo option (option number 1).  I then deleted the
>>> Etoile-0.2 folder, and untarred the etoile-0.2.tar.gz again, ran 'make' as
>>> 'james,' ran 'make install' as root, and then ran setup.sh as 'james' and
>>> chose the sudo option.  Choosing etoile.desktop still doesn't work, I have
>>> the same problem as before: nothing starts (well, once in a while I see a 
>>> few
>>> of those rapidly flashing small sqaure windows which always seem to 
>>> accompany
>>> the start of the first GNUstep app in a session of X: I get them starting
>>> GNUMail, for example, and remember them when running svn checkouts of the
>>> stable branch not too long ago) and I am left with the same color 
>>> background
>>> as I had in GDM.  This time however, the .xsession-errors is a little
>>> different:
>>> 
>>> /etc/gdm/PreSession/Default: Registering your session with wtmp and utmp
>>> /etc/gdm/PreSession/Default: running: /usr/bin/sessreg -a -w /var/log/wtmp 
>>> -u
>>> /var/run/utmp -x "/var/
>>> lib/gdm/:0.Xservers" -h "" -l ":0" "james"
>>> /etc/gdm/Xsession: Beginning session setup...
>>> 2007-08-02 19:12:21.047 etoile_system[25966] Setting up SCSystem server
>>> instance
>>> 2007-08-02 19:12:21.398 etoile_system[25966] Loading 3 user defined AppKit
>>> bundles
>>> 2007-08-02 19:12:21.398 etoile_system[25966] * Unable to load
>>> '/usr/GNUstep/Local/Library/Bundles/Cam
>>> aelon.themeEngine'
>>> 2007-08-02 19:12:21.398 etoile_system[25966] * Unable to load
>>> '/usr/GNUstep/Local/Library/Bundles/Eto
>>> ileMenus.bundle'
>>> 2007-08-02 19:12:21.399 etoile_system[25966] * Unable to load
>>> '/usr/GNUstep/Local/Library/Bundles/Eto
>>> ileBehavior.bundle'
>>> 2007-08-02 19:12:21.417 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 1
>>> 2007-08-02 19:12:21.418 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 2
>>> 2007-08-02 19:12:21.418 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 3
>>> 2007-08-02 19:12:21.419 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 4
>>> 2007-08-02 19:12:21.419 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 5
>>> 2007-08-02 19:12:21.420 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 6
>>> 2007-08-02 19:12:21.420 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 7
>>> 2007-08-02 19:12:21.421 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 8
>>> 2007-08-02 19:12:21.421 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 9
>>> 2007-08-02 19:12:21.422 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 10
>>> 2007-08-02 19:12:21.422 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 11
>>> 2007-08-02 19:12:21.423 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 12
>>> 2007-08-02 19:12:21.423 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 13
>>> 2007-08-02 19:12:21.424 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 14
>>> 2007-08-02 19:12:21.424 etoile_system[25966] Failed to determine offsets 
>>> for
>>> style 15
>>> 2007-08-02 19:12:21.499 etoile_system[25966] WARNING: no usable workspace
>>> process set file found. I'm
>>> not going to do workspace process management.
>>> 2007-08-02 19:12:21.499 etoile_system[25966] Launch queue is empty now
>>> X connection to :0.0 broken (explicit kill or server shutdown).
>>> 
>>> Before I reinstalled Etoile, the .xsession-errors didn't mention "Loading 3
>>> user defined AppKit bundles" and thus I didn't get the "Unable to load...."
>>> errors.  Those three missing bundles are in /usr/GNUstep/System instead of
>>> Local/.  I am not sure why.  Also, after the Etoile reinstall,
>>> SystemTaskList.plist is present but still has the root-only permissions
>>> (-rw-------).
>> 
>> Some program is now trying to load the 3 user defined AppKit Bundles 
>> because the preferences of 'james' got changed when you ran ./setup.sh as 
>> 'james' (instead of as 'root').  When you ran setup.sh logged in as root, 
>> root's preferences got changed, but not james's.  (see my answer to the 
>> first question about sourcing GNUstep.sh as root).
>> 
>> Ok, those are my thoughts.  I still need help with everything else from my 
>> previous email.  Thanks!
>> 
>> James
>> 
>> 
>> 
>> _______________________________________________
>> Etoile-discuss mailing list
>> [email protected]
>> https://mail.gna.org/listinfo/etoile-discuss
>> 
> 
> _______________________________________________
> Etoile-discuss mailing list
> [email protected]
> https://mail.gna.org/listinfo/etoile-discuss
> 
> 


_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss

Répondre à