Small problem with gtk2.tcz

[maro]

On a "plain" TC system (e.g. "base norestore") there is no '/usr/local/etc' directory. If one loads onto such a system the gtk2.tcz extension the usr/local/tce.installed/gtk2 script attempts to create /usr/local/etc/gtk-2.0 directory. This will fail because of the missing parent directory. I discovered this when I tried to load PCMANFM onto such a system and saw an error and all icons were missing.

The solution is simple: use mkdir -p /usr/local/tce.installed/gtk2 instead, since this will create missing parent directories. The "-p" option for mkdir would actually not require the "[ -d ... ]" test, but that is not too critical.

[Jason W]

Is gtk2 extension failing to create that directory when using the appbrowser on a "base norestore" boot?  I had tested it on a clean boot.  Pango is a dep of gtk2, and /usr/local/etc/ is a directory in the pango extension so the directory should already be there since pango would be loaded first, whether during boot or appbrowser load. 

You are correct in that the gtk2 extension will not create that directory if no other dependency extensions have been loaded, though that should not happen.  I normally use the "mkdir -p" option as a matter of practice, though I didn't with gtk2.  I will add it in the script, though under normal circumstances the directory should be created as the deps should create /usr/local/etc.

Using the test condition simply prevents harmless error messages that would be seen when tce-load is used in the termimal, or during boot with the "showapps" boot code.  Another way of course is using "> /dev/null 2>&1", but I prefer in principle not to try to create a directory if it already exists.  Reducing even harmless error messages keeps the screen cleaner and saves time for folks who see the message and troubleshoot the cause to make sure it is not a bug.

[maro]

I appreciate the aim to avoid harmless error messages, and I share the same goal. In this case "mkdir -p ..." is actually helping us: If you'd do for example mkdir -p /tmp/bogus/dir twice you will find that the second time does not throw up an error message (in contrast to what you'd get without the "-p").

WRT pango being a dependency that should have created the /usr/local/etc, I have to confess that I did not try to load gtk2.tcz on it's own onto a plain system. As I mentioned, I ran into the issue with pcmanfm.tcz and that triggered me to create this message here.

I guess it highlights our little weakness that we don't do recursive dependency checking. I wonder why we don't do that instead. Was that tried and found out to be too difficult? I guess the vast majority of other distributions are following a recursive approach.

I'm not saying that it is a "must have", but it ever so often creates little problems when the sequence of dependencies becomes a critical point. I'd love to find the time to do a dependecy validation script that would try to find those (potential) problems, but have not got around to it (yet).

[Jason W]

If -p does not cause an error message, then the test would not be necessary.  Either way I will add the -p since it is always good business as I didn't intentionally count on pango to create the parent directory, it just was overlooked though it worked with the appbrowser.

Robert explained at one time the reason we don't do recursive dep processing.  It is not that it would be difficult to do but we instead opted for simplicity of straight dep processing instead of recursing into layers of dep files with the potential of getting hung as well as increased load time. 

[teastopple]

I've been fiddling with TCL for some weeks now and I found, that it is an amazing basis to set up a diskless mp3 jukebox. So far ...

Since yesterday evening booting into a pristine TCL I'm encountering a strange (IMHO) GTK issue - both GTK1 and GTK2. Related apps won't start anymore.

Eg: After booting into TCL and downloading XMMS (GTK1 deps are solved automagically) the XMMS icon in wbar is dead. So I try it to start from a console window and I'm getting the following error message:

xmms-bin: error while loading shared libraries libgtk-1.2.so.0:
cannot open shared object file: No such file or directory

However: sudo find / -name libgtk-1.2.so.0 gives me:

/tmp/tcloop/gtk1/usr/local/lib/libgtk-1.2.so.0
/usr/local/lib/libgtk-1.2.so.0

The directory /usr/local/etc as mentioned above does exists.

Same issue with the GTK2 stuff (and thus gtkmixer, emelfm2 etc).

I'm a little bit confused as things went straight until yesterday. Can anyone point me to a solution of this strange behavior?

TIA

[Jason W]

Are you running a current version of TC? 

If not, you will see the problems you mentioned.

[roberts]

It would be helpful to state which version of Tiny Core you are using.
Use the command version to display your version.
There have been some dramatic changes recently with more to come.

Libraries not loading would seem to indicate that perhaps you are using v2.6.1 or earlier, in which case you need to have tce-notify.tcz loaded. tce-notify.tcz is now required for v2.0 through v2.6.1

[teastopple]

OMG, shit happens ... 

 I've had paused some time playing with TCL. Yesterday I downloaded the 2.7 ISO and did a harddisk install on the DOC module of the mp3 machine by booting from my 2.6.1 CD an copying over the 2.7 stuff from the loop mounted ISO file.

Then I booted the 2.6.1 CD on another machine and plugged in an USB stick to have an environment for testing purpose. On the mp3 machine I left over the vanilla TCL stuff, then loading XMMS and some other stuff on the testing machine.

As I now see that couldn't work due to the dramatic changes in the current release.
The workaround for older releases given by Robert works too.

Thank you very much for your immediate response.

PS: Is there a special board to post suggestions on TCE extensions?

[curaga]

PS: Is there a special board to post suggestions on TCE extensions?

TCE talk, or if it's specific to the extension, the extension's release thread.