Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: enoch on October 06, 2009, 07:04:21 AM
-
Soo many questions thanks everyone for your help.
Now after downloading abiword tcz ,installed, click the wbar icon and nothing?
-
What happens if you try to launch from a terminal (type "abiword")?
-
When I checked few month ago ABIWORD I have seen it overwrote DBUS system config and caused incompatibility issues. Sorry I forgot to report it, I was busy with many other stuff.
I guess it is a DBUS related issue due to DBUS locations changed.
-
It's true that /etc/dbus-1 moved to /usr/local/etc/dbus-1, but it should write it's own dbus config file rather than overwriting the dbus config, no?
-
It's true that /etc/dbus-1 moved to /usr/local/etc/dbus-1, but it should write it's own dbus config file rather than overwriting the dbus config, no?
Yes, placed into the system.d directory same way as HAL.
-
Abiword is compiled without dbus. So unless it's doing something weird without libdbus..
-
Abiword is now missing libgsf. When I try to install it separately, some key files are still missing.
-
Ah - I split the old librsvg.tczl extension into it's component parts - libcroco, libgsf, librsvg - maybe this could be the problem?
-
Things change fast 'round here :P Added libgsf and libcroco to .dep. Abiword starts on a base norestore 2.4rc4.
-
..my fault, I should have caught that. I'll double-check for similar cases.
-
Maybe we should start acting like the big software vendors. No big changes without an advance notice of a month, then provide backwards compatibility for 5 years. And since we have access to all software in our repo, automated reports about what needs changing, when and how. And maybe testing, QA and QC.
;)
ie. These things happen.
-
typing abiword in a terminal yields error while loading shared libraries: libgsf-1.so.114
-
Please retry with the updated abiword.tcz:
rm /usr/local/tce.installed/abiword
tce-load -w -i abiword.tcz
-
I'm seeing the same thing as enoch using "base norestore". Is the libgsf package corrupted?
-
Sorry, I'm stupid. Talking without checking first what I'm saying :-\
It is not ABIWORD, it is GNUMERIC with DBUS setup.
-
I repackaged libgsf.tczl and installed it locally. Abiword now works for me.
-
Is there a problem with the libgsf extension? It works for me with other apps.
-
I tried once again to confirm this.
Booted 2.4rc4 with base norestore
Installed Abiword
The files libgsf-1.so.114.x are missing.
Installed my repackaged libgsf.tczl.
Abiword works.
-
Can't reproduce, everything works for me since the dep update. Are you using a mirror?
(http://i37.tinypic.com/219rrrt.png)
-
Are you using a mirror?
No, and I'm still getting the same negative result on several machines. I guess someone else will have to weigh in with a test run.
-
the libgsf.tczl md5sum checks out OK in the repository
-
the libgsf.tczl md5sum checks out OK in the repository
Here's what I get:
"abiword: error while loading shared libraries: libgsf-1.so.114: cannot open shared object file: No such file or directory"
-
Are you installing to ram? Maybe that is a factor, I used the conventional tcz way, mounting..
Edit: Well, how nice. GNU cpio as in 2.4rc4 segfaults when loading libgsf to ram.
(http://i38.tinypic.com/b5i0pt.png)
GNU cpio is no longer used, but it should be checked with busybox cpio. And also if it's because of cpio, or the script.
edit 2. Busybox cpio is more verbose about it: short read, I/O error. The libgsf extension is corrupted, and the corruption is in the dev headers, that's why abiword runs when mounted.
-
Are you installing to ram?
Yes. I thought that was now the conventional way to load tcz's in 2.4.
All I did to fix libgsf was un-squash it (there were some errors) and re-squash it.
-
Yes. I thought that was now the conventional way to load tcz's in 2.4.
It's still a choice - of load time, ram use, speed after load, plain preference for either. This choice isn't going away anytime soon.
All I did to fix libgsf was un-squash it (there were some errors) and re-squash it.
That would leave the affected files corrupted. If the tcel is still fine, then it can be used, if not, it would need a rebuild.
-
It's still a choice
Fair enough. But it's important that both methods are tried during the testing of a new package.
That would leave the affected files corrupted
Actually, I believe the corrupted files got dropped during the un-squash phase. So my re-squashed version was clean (but incomplete).
-
Thanks everyone its fixed!