How to get certain .pets to work in Easy OS?

[keniv]

I thought I would try Easy OS. I used the very excellent tutorial by forum member @williwaw here
http://forum.puppylinux.com/viewtopic.php?f=63&t=2535
I did this a while ago but I think the version I started with was Dunfell 2.7.2. I have updated this twice and am now on Dunfell 2.9. I have a copy both on a usb drive and an hdd (booting using grub4dos). All this went well but I have had trouble installing pets. The only pet I have attempted to install that worked is pwidgets-2.5.10-x86_64. I have tried to install youtube-get3-1.5.1_noarch which I thought should work as it was a noarch pet. It sort of works but the windows are not correct which looks to me (no expert) like a gtk problem looking at the attached image. I have also tried to install Uextract. I have tried the what I believe is the most up to date version 4.5. This give an error no matter what I try to extract. I have also tried to install version 4.0.3 from "petget". I get two choices here. Nluug.nl tells me the link is broken and ibiblio.org tells me that python is missing. I have managed to get the portable versions of Iron, Opera and Slimjet provided by forum member @mikewalsh to work without a hitch. So I've had a mixed experience. I would be obliged if anybody could advise me as to how to get these packages to work on EasyOS as other than these problems I quite like it.

Regards,

Ken.

[BarryK]

Hi,
If you get PETs from elsewhere, then no guarantee.

From the PETget package manager, some of them in the "noarch" repo are old, I haven't checked them for a long time.

Regarding Python, Easy Dunfell-series uses python3, it is possible that a PET wants python2.

There is a python2 PET available in the package manager. That works, I use it to compile seamonkey.

[BarryK]

Regarding downloading videos from youtube, I suppose that you know Easy already has youtube-dl, in the "Internet" menu. You may have to click the "update" button for it to work, as youtube keep moving the goal posts to try and prevent these downloaders from working, and the youtube-dl developers keep updating their script so that it works again.

[keniv]

@BarryK

Regarding Python, Easy Dunfell-series uses python3, it is possible that a PET wants python2.

There is a python2 PET available in the package manager.

I downloaded and installed python2 from petget. I reinstalled uextract v4.0.3 again from petget. This time no missing stuff was reported. However, if I try to extract anything I get the error window shown in the image below. This is the same error window I got when I installed and ran v4.5.

Regarding downloading videos from youtube, I suppose that you know Easy already has youtube-dl, in the "Internet" menu.

Youtube-get3-1.5.1_noarch works it's just the windows that are not quite right. It's a bit more versatile than youtube-dl and also has an update button. I thought if the window thing was an easy fix it was worth doing. Hope the attached image helps with the uextract problem.

Regards,

Ken.

[fredx181]

@keniv Looking at your screenshot in first post, I think the reason why it doesn't display correctly is that the installed yad is compiled with GTK3
You can see it by running yad --version
Installing yad gtk2 probably will fix it, then it will show similar as this (older version, which I have):

Code: Select all

~# yad --version
0.40.0 (GTK+ 2.24.32)

[keniv]

@fredx181
Hi Fred

You can see it by running yad --version

Here's the output from running the above.

Code: Select all

# yad --version
6.0 (GTK+ 3.24.14)
# 

so it looks as if the installed version is gtk3 as you said.

Installing yad gtk2 probably will fix it,

I've tried downloading the above from the Easy OS ppm but get "Sorry, no matching package name". Can you point me towards a yad gtk2 .pet? Based on the experience I've had so far in terms of running .pets that don't come from the Easy OS ppm I'm not hopeful that a yad gtk2 .pet from elsewhere will work but it's worth a try. Can I ask will the gtk2 pet overwrite the existing gtk3 or will both co-exist?

Regards,

Ken.

[fredx181]

.... Can you point me towards a yad gtk2 .pet? Based on the experience I've had so far in terms of running .pets that don't come from the Easy OS ppm I'm not hopeful that a yad gtk2 .pet from elsewhere will work but it's worth a try. Can I ask will the gtk2 pet overwrite the existing gtk3 or will both co-exist?

Yes, see here v0.40 attached: viewtopic.php?p=9063#p9063 but didn't test if suitable for EasyOs, probably it will overwrite existing (if it's in /usr/bin), you may want to backup the gtk3 version first.

[JakeSFR]

I reinstalled uextract v4.0.3 again from petget. This time no missing stuff was reported. However, if I try to extract anything I get the error window shown in the image below. This is the same error window I got when I installed and ran v4.5.

I checked that and after the installation, all UExtract symlinks in /etc/xdg/rox.sourceforge.net/OpenWith/.something_something directories point to:

Code: Select all

//usr/local/apps/UExtract/UExtract.desktop

instead of:

Code: Select all

/usr/local/apps/UExtract

The double / at the beginning doesn't make any difference, the problem is the UExtract.desktop part.

Long story short, when pinstall.sh from UExtract PET is finished, something else, beyond my control, is changing those symlinks, making them unusable.
And that "something else" turned out to be: /usr/sbin/build-rox-sendto.
I'm not sure what it does exactly and why, though...

You can still use UExtract via 'OpenWith -> UExtract' right-click option.
Or you can fix the symlinks with this:

Code: Select all

find /etc/xdg/rox.sourceforge.net/OpenWith -type l -name "UExtract" -exec ln -sf /usr/local/apps/UExtract {} \;

Greetings!

[keniv]

@JakeSFR

You can still use UExtract via 'OpenWith -> UExtract' right-click option.

The above is how I've been using UExtract but using it this way does not work for me. I get the the window with "Failed to execute child process..............." shown in my earlier post.

Or you can fix the symlinks with this:

CODE: SELECT ALL

find /etc/xdg/rox.sourceforge.net/OpenWith -type l -name "UExtract" -exec ln -sf /usr/local/apps/UExtract {} \;

This did work and UExtract v4.0.3 is working though I haven't done much testing so thanks for that. I might try uninstalling v4.0.3 and try v4.5 with your fix and see if that works.

@fredx181

Yes, see here v0.40 attached

Thanks for that Fred.

probably it will overwrite existing (if it's in /usr/bin), you may want to backup the gtk3 version first.

I've looked in /usr/bin and have also used pfind to look for gtk3 files. There are many of these and I do not know which to backup. As the windows are only slightly affected and Youtube-get3-1.5.1 still works I am tempted to leave it as is rather than break Easy OS. Oddly enough I know how to backup save files/folders in pups but I don't know how to do this in Easy OS. I better have a look at this.

Regards,

Ken.

[fredx181]

I've looked in /usr/bin and have also used pfind to look for gtk3 files.

Sorry if I wasn't clear, I didn't mean gtk3 files in /usr/bin, I just meant the existing "yad" binary (probably /usr/bin/yad). If you back that one up first (copy to some other location), then install the yad 0.40 gtk2 pet, I expect it will work fine, but in case not, you can always restore from the back-up yad binary.

[keniv]

@fredx181

I didn't mean gtk3 files in /usr/bin, I just meant the existing "yad" binary (probably /usr/bin/yad)

Well I can no longer get into /usr/bin. The attached image shows whats in /usr. I cannot open bin and it's icon has change. I don't know what has caused this unless it was something to do with what I have tried to get these pets to work. I do not understand this. I will try removing the pets I have installed that have given problems to see if this helps.

Regards,

Ken.

Edit I decide to remove the pets one at a time. I removed UExtract first and /usr/bin is back looking normal and can be opened. I have copied /usr/bin/yad. I have left the other pets as is.

[williams2]

There is an executable file named AppRun in /usr/bin.
It should not be there.
It may be a file or a symlink.

You can fix it by right clicking /usr/bin, select App dir 'bin' -> look inside
then rename or delete the file AppRun in /usr/bin.

All you need to do to fix the problem is delete that file.

[keniv]

@fredx181
Hi Fred,
I've installed the yad pet. Below is the output from running yad --version.

Code: Select all

# yad --version
0.40.0 (GTK+ 2.24.32)
# 

I looked in /usr/bin and there's only one yad so I guess this plus the above means the original was overwritten. The good news is the windows in youtube-get3 now render properly.

Regards,

Ken

[keniv]

@williams2

You can fix it by right clicking /usr/bin, select App dir 'bin' -> look inside
then rename or delete the file AppRun in /usr/bin.

Now my /usr/bin seems to be operating normally when I look inside I cannot find a file name AppRun. I do have three files called appstream......etc. Could this AppRun file have anything to do with my abortive attempts to get Uextract working? Would it be removed when I uninstalled UExtract? I am a bit resistant about trying to reinstall UExtract again as it seems to cause problems for me at least, in Easy OS.

Regards,

Ken.

[JakeSFR]

@williams2

You can fix it by right clicking /usr/bin, select App dir 'bin' -> look inside
then rename or delete the file AppRun in /usr/bin.

Now my /usr/bin seems to be operating normally when I look inside I cannot find a file name AppRun. I do have three files called appstream......etc. Could this AppRun file have anything to do with my abortive attempts to get Uextract working? Would it be removed when I uninstalled UExtract? I am a bit resistant about trying to reinstall UExtract again as it seems to cause problems for me at least, in Easy OS.

Regards,

Ken.

This "/usr/bin" defect is, in turn, caused by this line (843) in /usr/local/petget/installpkg.sh:

Code: Select all

echo -e "#!/bin/sh/\nexec ${EXESPEC}" > /usr/bin/${EXENAME}

It creates /usr/bin/AppRun file, what turns the entire /usr/bin dir into a false ROX-App.

Petget in EasyOS apparently doesn't like *.desktop files containing Exec lines like this one:

Code: Select all

Exec=/usr/local/apps/UExtract/AppRun

and converts them to:

Code: Select all

Exec=AppRun

I think the bottom line is that EasyOS's Petget differs too much from Woof-CE's one, so installing foreign PETs is not a good idea, unless you know all the quirks and how to rectify them.

Greetings!

[mikewalsh]

@JakeSFR :-

From what I can understand, BK's built his Dunfell series so they just don't work quite the same in many small ways, compared to anything he's built before. Which was part of the reason why, when I tried EasyOS a few weeks ago, I went with the last of the Buster-series, just before the "Dunfells" started rolling off the production line.

I wanted to be able to use my own stuff with it. Despite what most folks are conditioned to believe, newer ain't always better!

Mike.

[keniv]

@JakeSFR
Thanks for that information.

EasyOS's Petget differs too much from Woof-CE's one, so installing foreign PETs is not a good idea

Given that uextract v4.0.3 is in petget I re-downloaded and installed this version. However, even this version needs Python2 and your code

Code: Select all

find /etc/xdg/rox.sourceforge.net/OpenWith -type l -name "UExtract" -exec ln -sf /usr/local/apps/UExtract {} \;

to get it to work. I checked /usr/bin which appeared normal. It did not contain an AppRun file. The drawback to this is that it does not allow me to run v4.5.
@mikewalsh

Despite what most folks are conditioned to believe, newer ain't always better!

Yep I chose the Dunfell version because I thought as it was newer it would be better. However, I've just installed the Buster 2.6.2 version to a 4GB USB drive (might be a bit small but I don't currently have anything bigger that I'm not using). I'm posting from it now. Youtube-get3-1.5.1 worked rendering the windows properly. I haven't tried Uextract v4.5 yet but I'll give it a go this evening. You portable Iron and Opera are also both working. One thing that I wonder about with this version is will there be further updates.

Regards,

Ken.

[BarryK]

I have scanned through this thread. A few issues, but about yad...

For the Dunfell series, all the packages are compiled in OpenEmbedded, including yad. The OE developers would have used a recent version of yad, that requires gtk3.

Is this bad? has yad deteriorated after moving to gtk3? Like, apparently, gtkdialog has lost some features.

I am staying with the gtk2 version of gtkdialog. If required, I can also wind back to the last version of yad that supports gtk2, and modify the build recipe in OpenEmbedded to link with gtk2.

[fredx181]

I have scanned through this thread. A few issues, but about yad...

For the Dunfell series, all the packages are compiled in OpenEmbedded, including yad. The OE developers would have used a recent version of yad, that requires gtk3.

Is this bad? has yad deteriorated after moving to gtk3?

Just small differences between yad gtk2 and gtk3, for example --button="gtk-cancel:1" shows "Cancel" button fine with gtk2 version but with gtk3 version it shows as "gtk-cancel" (as on screenshot in first post).
Maybe there are some other small differences, not sure.
EDIT: with gtk3 yad, I think to make the 'Cancel' button display correct: --button="Cancel!gtk-cancel:1" (this, btw, works ok with gtk2 version too for me, so in fact older scripts using yad (expecting "gtk2 yad") should be modified to use this, then works well with both gtk2 and gtk3).

[keniv]

so in fact older scripts using yad (expecting "gtk2 yad") should be modified to use this, then works well with both gtk2 and gtk3).

I'm not sure I'm really qualified to comment on this but I think I can provide a non-expert point of view and that is anything that could be done that would allow more "commonly used pets" to work, out of the box, would be a good thing. I realised that my "commonly used pets" might not be the same as somebody else's. Also It would help if pets in petget worked out of the box. I presume that there are probably only a small number that don't work out of the box. I would hope it this would not involve a huge amount of work to fix this but I don't have the knowledge to know if this is the case. If this would be a huge amount of work then I apologise for making the suggestion.

Regards,

Ken.

[keniv]

I haven't tried Uextract v4.5 yet but I'll give it a go this evening.

Have just tried the above. Uextract v4.5 does work on EasyOS 2.6.2 but still needs @JakeSFR's code.

Regards,

Ken.

[BarryK]

@williams2

You can fix it by right clicking /usr/bin, select App dir 'bin' -> look inside
then rename or delete the file AppRun in /usr/bin.

Now my /usr/bin seems to be operating normally when I look inside I cannot find a file name AppRun. I do have three files called appstream......etc. Could this AppRun file have anything to do with my abortive attempts to get Uextract working? Would it be removed when I uninstalled UExtract? I am a bit resistant about trying to reinstall UExtract again as it seems to cause problems for me at least, in Easy OS.

Regards,

Ken.

This "/usr/bin" defect is, in turn, caused by this line (843) in /usr/local/petget/installpkg.sh:

Code: Select all

echo -e "#!/bin/sh/\nexec ${EXESPEC}" > /usr/bin/${EXENAME}

It creates /usr/bin/AppRun file, what turns the entire /usr/bin dir into a false ROX-App.

Petget in EasyOS apparently doesn't like *.desktop files containing Exec lines like this one:

Code: Select all

Exec=/usr/local/apps/UExtract/AppRun

and converts them to:

Code: Select all

Exec=AppRun

Yeah, that is bad news. installpkg.sh is not much different from the early pup days, circa 2013. looking at the changelog, mostly small changes.

The code that has caused the problem with uextract, is supposed to fix the Exec= line in the .desktop file, so that it doesn't have a path, just name of an executable. There are various reasons for doing this.

I have put in a fix, well it looks like a fix, not yet tested, at line 843:

Code: Select all

  if [ ! "$xEXEPATH" ];then
   if [ "$EXENAME" == "AppRun" ];then #20210915 disaster. ref: http://forum.puppylinux.com/viewtopic.php?p=36693#p36693
    #change $EXENAME to something sane... ex: extract "abiword" out of /usr/share/applications/abiword.desktop
    EXENAME="$(echo -n "${ONEDESKTOP}" | rev | cut -f 1 -d '/' | cut -f 2- -d '.' | rev)"
   fi
   echo -e "#!/bin/sh\nexec ${EXESPEC}" > /usr/bin/${EXENAME}
   chmod 755 /usr/bin/${EXENAME}

Thanks for finding the cause of the problem with uextract.

[BarryK]

I have scanned through this thread. A few issues, but about yad...

For the Dunfell series, all the packages are compiled in OpenEmbedded, including yad. The OE developers would have used a recent version of yad, that requires gtk3.

Is this bad? has yad deteriorated after moving to gtk3?

Just small differences between yad gtk2 and gtk3, for example --button="gtk-cancel:1" shows "Cancel" button fine with gtk2 version but with gtk3 version it shows as "gtk-cancel" (as on screenshot in first post).
Maybe there are some other small differences, not sure.
EDIT: with gtk3 yad, I think to make the 'Cancel' button display correct: --button="Cancel!gtk-cancel:1" (this, btw, works ok with gtk2 version too for me, so in fact older scripts using yad (expecting "gtk2 yad") should be modified to use this, then works well with both gtk2 and gtk3).

In EasyOS I am hanging onto gtk2 apps whenever possible. It was a pleasant discovery that the gtk2 version of yad is still being maintained:

https://bkhome.org/news/202109/rolled-b ... f-yad.html

[fredx181]

...
In EasyOS I am hanging onto gtk2 apps whenever possible. It was a pleasant discovery that the gtk2 version of yad is still being maintained:

https://bkhome.org/news/202109/rolled-b ... f-yad.html

Yes, me too, I'd like to stay with gtk2, pleasant surprise indeed that yad-gtk2 is still maintained.

The maintainer is "step-", don't know who that is.

Must be forum member @step from FatDog.

[step]

Confirmed