dCore Import Debian Packages to Mountable SCE extensions > dCore X86
Cannot start application from Ondemand entry
Jason W:
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.
sm8ps:
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:
--- Code: ---owncloud-client
owncloud-client-l10n
--- End code ---
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/':
--- Code: ---/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)
--- End code ---
(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)
sm8ps:
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
sm8ps:
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.
:-\
Jason W:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version