Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: sm8ps on September 27, 2017, 07:36:45 AM
-
I cannot get my head around the following problem. Please help my poor soul!
I want to load the extension owncloud-client.list from the Ondemand menu. It dependes on X.list and wireless.list. The latter contains the packages network-manager and nm-applet which should not only be loaded but started so that I can run the Owncloud client right away.
For that matter I have created the following Ondemand entries; both executable files.
/tce/ondemand/Network-Manager:
#!/bin/sh
ondemand -e wireless.list
sudo /usr/local/postinst/libglib2.0-0 trigger && sudo gtk-update-icon-cache-3.0 -f /usr/share/icons/hicolor
sudo service network-manager start
sudo /usr/bin/nm-applet &
/tce/ondemand/OwnCloud
#!/bin/sh
/tce/ondemand/Network-Manager
ondemand -e owncloud-client.list
owncloud &
Calling Network-Manager from the Ondemand menu works well. However, calling OwnCloud does not work. It does execute Network-Manager and gives a functional NM-applet in LXPanel but the Owncloud client is not started. When executing from the terminal via ''sh -x /tce/ondemand/OwnCloud'' I see "/tce/ondemand/OwnCloud: line 1: owncloud: not found". Indeed, ''which owncloud'' produces an empty result. So it seems that the command ''ondemand -e owncloud-client.list'' does not do what it should, namely loading the extension.
Issueing all commands from the terminal however does work as expected. Can anybody explain the difference in behavior? I have tried replacing ''ondemand'' by ''sce-load'' and adding some 'sleep 1' commands to no avail.
-
Hi
Strange tce is in root
-
Strange tce is in root
It isn't actually; I just put a symlink there. AFAICT that does not influence the behavior. Thanks for closely double-checking anyways!
-
This is getting really weird! I have done some trouble shooting and find the following:
The extension "owncloud-client.list" is defined by the following list:
ca-certificates
owncloud-client
owncloud-client-l10n
The packages are taken from a repo listed in a file under '/opt/debextra/' containing
http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_16.04/ /
The extension has the following dependencies
X.list
wireless.list
defined as follows
/tce/sce/X.list.sce.lst:
pm-utils
graphics-4.2.9-tinycore
xorg-intel
arandr
openbox
lxpanel
/tce/sce/wireless.list.sce.lst:
wireless-4.2.9-tinycore
wireless
gnome-keyring
network-manager
network-manager-gnome
Running ''sce-load owncloud-client.list'' does not produce an executable ''owncloud'' as expected. There is, however, a file '/usr/bin/owncloud'! Following the symlinks by copying and pasting the filenames gives the following chain resulting in a dead-end:
sm@aa1:/tmp$ ls -l /usr/bin/owncloud
lrwxrwxrwx 1 root root 35 Sep 29 10:46 /usr/bin/owncloud -> /opt/ownCloud/ownCloud/bin/owncloud
sm@aa1:/tmp$ ls -l /opt/ownCloud/ownCloud/bin/owncloud
lrwxrwxrwx 1 root staff 66 Sep 25 21:55 /opt/ownCloud/ownCloud/bin/owncloud -> /tmp/tcloop/owncloud-client.lst/opt/ownCloud/ownCloud/bin/owncloud
sm@aa1:/tmp$ ls -l /tmp/tcloop/owncloud-client.lst/opt/ownCloud/ownCloud/bin/owncloud
ls: cannot access '/tmp/tcloop/owncloud-client.lst/opt/ownCloud/ownCloud/bin/owncloud': No such file or directory
Here comes the weird part:
ls -l /tmp/tcloop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud
-rwxr-xr-x 1 root root 2194976 Sep 5 20:50 /tmp/tcloop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud
Yes, this is verbatim the same filename as above, this time typed by hand (using tab-completion)! So dCore must somehow have produced a non-valid symlink. How can that be? Is there a way to check the symlinks?
For testing, I imported the extension owncloud-client as stand-alone, depending on the same extensions X.list and wireless.list. This time, the loaded extension does produce the executable 'owncloud' under '/usr/bin/' as expected. So the above behavior seems to be related to the presence of a list file. I checked the file for dangling spaces or empty lines at the end but there is no such thing.
-
Are these ondemand entries ones you created rather than creating with "sce-import -o"?
-
Yes they are. The automatically created entries won't work becuase of the list files difffering in name from the executables. furthermore, I want to include some start commands into the ondemand file.
The problem, however seems rooted somewhere entirely different. Indeed, when I call these commands from the command line, they do NOT produce a working executable, as described in my previous post. (This is contrary to my first post!) In fact, I wonder how this could be. I am setting up three computers anew in parallel so the installations are pretty clean.
I forgot to mention that this happens on the current stable release as well as on the latest release candidate.
-
For one thing, "list" files are named .lst and not .list. Perphaps I can add the ability for sce-deb2sce to include a PACKAGENAME.deb2sce startup script that is in the same directory as the .deb file being worked with. As ondemand entries are not made for that.
-
ondemand gets the name of the executable from the .desktop file belonging to the main package, not the name of the extension whether it has a .lst file or not. Or the full path to the executable if found by the 'which' command. If neither exist, then of course will not work.
First, re-import the SCEs that have list files with .list so the are X.lst, wireless.lst, etc. It may not fix things but it will rule out it being the error.
-
Okay, back at trouble shooting after some (totally sober!) days at the Munich Oktoberfest.
I am certain that this whole issue is unrelated to ondemand menu entries. Here is what I did: re-imported owncloud-client without any dependencies, producing 'owncloud-client.sce'. As before, ''sce-load owncloud-client'' does not provide an executable. The following links are present:
sm@aa1:~$ ll /usr/bin/owncloud
lrwxrwxrwx 1 root root 35 Okt 4 22:07 /usr/bin/owncloud -> /opt/ownCloud/ownCloud/bin/owncloud
sm@aa1:~$ ll /opt/ownCloud/ownCloud/bin/owncloud
lrwxrwxrwx 1 root staff 66 Sep 25 21:55 /opt/ownCloud/ownCloud/bin/owncloud -> /tmp/tcloop/owncloud-client.lst/opt/ownCloud/ownCloud/bin/owncloud
The reason why this is a dangling link is that under '/tmp/tcloop/' there is no 'owncloud-client.lst'' but only the following:
sm@aa1:~$ ll /tmp/tcloop/owncloud-client/opt/ownCloud/ownCloud/bin/owncloud
-rwxr-xr-x 1 root root 2194976 Sep 5 20:50 /tmp/tcloop/owncloud-client/opt/ownCloud/ownCloud/bin/owncloud*
The same was present in my posting of 2017-09-29, 10:12:43 but tab-completion made me overlook it.
This is all independent of how user-created list files are named because there is none involved. However, dCore seems to produce an invalid link somewhere in the process. The loading of the extension does run quite too fast considering the 147 packages included in the 112 MB SCE-file.
Will keep testing.
-
OK, got some more resuts in the mean time. After loading the extension from the command line without any other extensions loaded (boot-code "base"), I get an executable that is missing the following dependencies: libQt5DBus, libQt5WebKit5, libQt5xml5 and libowncloud.so.0.
Checking '/usr/local/sce/owncloud-client/owncloud-client.md5sum', I find all but the last mentioned libraries present but with "ocqt562-" prepending their names. This seems to indicate that the repo provides some specific versions of these libraries but that dCore does not know how to handle these.
May I ask for verification of this? Please import onwcloud-client using a repo file containing
http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_16.04/ /Load the extension and run ''owncloud --help''.
I have been wondering how I managed to get 5.5 GB of data synchronised to this machine but I suspect that I had originally imported the extension from the standard Ubuntu Xenial repo and not from the up to date repo mentioned above.
-
owncloud-client in dCore-xenial works fine for me, at least I can launch it as I don't use it. I have made an adjustment to the ondemand routine to make it more dCore friendly. Either there needs to be an executable with the same name as the package, or a .desktop file in either /usr/share/applications or /usr/local/share/applications. I made a startup script for owncloud-client that moves the owncloud.desktop file to owncloud-client.desktop file in /usr/share/applications. I am uploading the new release candidates now, startup script is already available.
I have no trouble with the missing libraries you mention, all works for me with just xorg-all and icewm installed and X running, see the attached screenshot.
Please use a latest dCore release candidate, re-import owncloud-client, and test. Thanks.
-
Many thanks for checking, Jason! I really appreciated knowing that it works in principle because here it did not work at all. So the reason must be a rather peculiar one. After too many hours of head scratching, I have made some progress, albeit in a rather unexpected direction.
All of the following is done on dCore-xenial:2017.10.04.13.57 but does not differ in behavior from what I remember from the previous RC as well as from the latest stable release. I have an X-extension loaded containing pm-utils, arandr, openbox and lxpanel but I do not think this matters (will test from the console later). Furthermore, I am having otter-browser loaded and running but the phenomena have been consistent.
It seems that ''sce-import''/''sce-load'' are sensitive to the name of list files defining extensions. Indeed, I have three files named 'owncloud-client.list', 'owncloud-client_list', 'owncloud-client' of identical content:
owncloud-client
owncloud-client-l10n
With each of these I import an extension defined by these list files, yielding the appropriate 12 files under 'tce/sce/'. sce-loading these extension gives a symbolic link from '/usr/bin/owncloud' to '/opt/ownCloud/ownCloud/bin/owncloud' which itself is a symbolik link into '/tmp/tcloop/'. Here is where the difference starts. There are three different orders to proceed.
(A)
1. ''sce-load'': all three extension listed
1.1. select "owncloud-client.list": link points to /tmp/tcloop/owncloud-client/opt/ownCloud/ownCloud/bin/owncloud (notice the missing ".list").
2. ''sce-load'' again: only "owncloud-client_list" is available but not "owncloud-client"
2.1 select it: link remains unchanged
OK, so dCore does not like the file extension ".list". I can half-way imagine how this could come about.
For the correct executalbe, ''ldd /tmp/tcloop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud'' spits out the following errors after step 1.1 and the analogous errors after 2.1 for the corresponding executable under '/tmp/tcloop/owncloud-client_list/':
/tmp/tcloop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud: /usr/lib/i386-linux-gnu/libQt5DBus.so.5: version `Qt_5' not found (required by /tmp/tcloop/owncl oud-client.list/opt/ownCloud/ownCloud/bin/owncloud)
/tmp/tcloop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud: /usr/lib/i386-linux-gnu/libQt5WebKitWidgets.so.5: version `Qt_5' not found (required by /tmp/tcl oop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud)
/tmp/tcloop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud: /usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5: version `Qt_5' not found (required by /tmp/tcloop/o wncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud)
/tmp/tcloop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud: /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5: version `Qt_5.6' not found (required by /tmp/tcloo p/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud)
/tmp/tcloop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud: /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5: version `Qt_5' not found (required by /tmp/tcloop/
owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud)
/tmp/tcloop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud: /usr/lib/i386-linux-gnu/libQt5Widgets.so.5: version `Qt_5' not found (required by /tmp/tcloop/ow
ncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud)
/tmp/tcloop/owncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud: /usr/lib/i386-linux-gnu/libQt5Network.so.5: version `Qt_5' not found (required by /tmp/tcloop/ow
ncloud-client.list/opt/ownCloud/ownCloud/bin/owncloud)
(B)
1. ''sce-load'': all three extension listed
1.1. select "owncloud-client_list": link points to /tmp/tcloop/owncloud-client/opt/ownCloud/ownCloud/bin/owncloud (notice the missing "_list").
2. ''sce-load'' again: only "owncloud-client.list" is available but not "owncloud-client"
2.1 select it: link remains unchanged
This all is rather unexpected for I would imagine that the name of the list file without extension can be just about any string.
''ldd'' gives the same results as above about missing Qt-libraries.
(C)
1. ''sce-load'': all three extension listed
1.1. select "owncloud-client": link points to /tmp/tcloop/owncloud-client/opt/ownCloud/ownCloud/bin/owncloud which is indeed correct.
2. ''sce-load'' again: "owncloud-client.list" as well as "owncloud-client.list" are available
2.1 select it: link remains unchanged
TO BE CONTINUED (HAVE TO REBOOT)
-
Sorry for the exuberant length but I do not see any better way to explaining this weirdness!
So we have a winner with (C), finally. -- Just why exactly does the name of the extension, stemming from the list file, matter at all? Should it not be only a "container" which is mounted under '/tmp/tcloop/' and whose name does not matter when linking its content into the root file system?
Neither the '_import_summary'- nor the '.md5sum'-files under '/usr/local/sce/' differ. So the failure must happen somewhere allong the linking of files.
And here comes the weirdest part: this behavior is not consitent across installations! Indeed, on a KVM it does not show. I cannot think of any substantial difference between these installations. Indeed, the dCore version coincide and the list and repo files were copied via SSH.
BTW, the rationale for using extension names differing from their content is to point out if an extension is defined by a list of several packages as opposed to one single package. I can certainly live without that but it seemed kind of reassuring and I have not seen a clear reason why it should not work.
To make it clear, I used a list file 'owncloud-client.list' resulting in 'owncloud-client.list.sce', 'owncloud-client.list.sce.lst' etc. ''sce-load'' would then allow me to choose between ''owncloud-client.list'' (including l10n) and ''owncloud-client'' (single package) for example.
I want to point out that I have started over from scratch for several times taking great care not to mess anything up along the way. Either I am completely out of my mind or there is some hidden trap that I do not know of. -- I do not often use emojis but this one is appropriate:
:o
-
Just another weird thing: when selecting "owncloud-client.list" from the dialogue provided by ''sce-remove'' does also make "owncloud-client_list" vanish.
The ".list" extensions seem to mess up the dialogue in the sense that also false entries get selected. When selecting "X.list", also "obconf" is selected from removal.
:-\
-
I have tried to reproduce what you are seeing, and I don't have the library issue with any naming of owncloud-client or a list file containing that package. But I do see why once one of the SCEs containing the owncloud-client package will make an SCE sharing it's name not show up in the sce-load select menu. sce-load checks if an SCE name is already in /tmp.debinstalled, which is where Debian/prebuilt package names are stored once they are loaded. But since we are dealing with SCE names and not package names, I now have loaded SCEs stored in /tmp/.sceinstalled. That makes more sense as we are dealing not with indivudual packages but SCE names. Packages that exist in different SCEs still get thier files copied to filesystem when they are duplicates, well the new links don't overwrite the old. The startup scripts of packages are only run on the first loading, and then the package name stored in /tmp/.installed so the startup script is not run again if the package is loaded from another SCE. This seems to be logical.
I have now moved sce-remove to an extension, it is no longer in base and I will work on what is causing what you are seeing. This is to make it easier for me to maintain and not upload hundreds of megabytes across the dCore ports each time I change a less than 4kb file, and users don't have to download a new dCore release candidate to get the update. I will do this as I can on utilities that can be easily moved to extension status. sce-ppa-add and sce-debpurge are other candidates I will get to.
Uploading new dCore x86 release candidates now, will announce when ready.
-
Sorry for abandoning this issue! I could not continue at the time but had to run after a stack of urgencies and left this thread on my "to do later" list with the following prepared answer that I had intended to elaborate at that certain "later" moment. Here it is:
====
Many thanks for your efforts! I understand the logic behind separating extensions from packages. This sounds like a valid enhancement to the functionality of sce-loading. Out-sourcing the program to its proper extension does make sense as well.
AFAICT, the issue about the dead links is unrelated to the above. As said, the problem is not consistent across installations; it does not show on a fresh installation. Yet I have consistently run into this very problem somewhere along the way on four separate fresh installations (clean home/, opt/ and everything). So something must be going wrong somewhere. If it is my specific way of handling dCore then I want to find out about it so that others do not fall into the same trap. If it is some bug somewhere in dCore it could be corrected.
The only thing I copied over to the fresh installations was the list files themselves. I have just checked them for trailing spaces etc. and indeed found one in the original wireless.list.sce.lst upon which owncloud-client.list originally depended. Though, the issue also appears when importing stand-alone. Furthermore, I am running a system with the new releases candidate (dCore-xenial:2017.10.07.21.07) where I do not use that wireless list anymore and the problem persists. So trailing spaces in list files can be ruled out as a cause.
====
Meanwhile (i.e. now "later") I have abandoned Network Manager in favor of Wicd which worked very well and I somehow managed to circumvent the strange troubles described. Owncloud worked consistently well and I could use dCore productively which was very, very helpful while being on the road.
At some point I found out that my trusty netbook was slowly fading and was producing very strange hardware errors so I am not sure if the issues might not have been due to these errors (maybe related to time-out or something). It will be a while before I can get my hands on a fresh installation but I am guaranteed to get back because I put dCore on every machine I can.
Cheers!
Stefan
-
I would like to ask that periods (aka dot, point, full stop) are not to be used in package names of extensions, whether being made from a list file or not. Periods are used as a delimiter that is used by the dCore routines, should not part of a package name. Dashes are welcome as part of a package name, as many as one would like. Trailing spaces should not matter in a list file, as a space is added anyway between that value and the next, and the delimiter between package names is a space in the dependency gathering routine.
If you would re-create your setup with using no periods in package names, and you still see issue, I will be happy to test your setup further with my various machines. As a period is used as a value in separating parts of a package name, I want to make sure that is not it.
-
Thanks for your considerations! When I shall eventually start from scratch, I will reproduce the set-up and compare. Also, I will put this information into the wiki at the same time. For the time being, I just switched harddrives and dCore continues to run perfectly well on a replacement laptop. Wonderful!