dukto64 AppImage

[mikeslr]

@mikewalsh's recent mention of dukto reminded me that I had it stored somewhere. Found it in my Bionicppup64 storage folder. I think it was version 4.9 and wasn't sure it was for 64bit systems. So I tracked down the latest 64bit for Linux (packaged as an rpm) and repacked it as an AppImage. (Thanks, fredx181 for that application). Runs under Fossapup64 and Bionicpup64. Fails under Bookworm and Jammy64. See my next post.

Mikewalsh's original explanatory post, https://oldforum.puppylinux.com/viewtopic.php?t=113738

Remove the false '.gz' Place anywhere. Check that it's executable. Left-Click to run.

dukto64.AppImage.gz

(403.98 KiB) Downloaded 10 times

The Windows version program can be obtained here, https://sourceforge.net/projects/dukto/

@mikewalsh, I've never actually used this app. When it opens it presents the display you showed at the above link. It automatically finds the address of the operating system from which it's being run. At the bottom of its GUI is a Button named Addresses. Is establishing a connection as simple as having dukto running under the operating system you desire to send-to and selecting its address from a list that will appear when the Addresses button is clicked? Or something else?

[mikewalsh]

@mikeslr :-

Where it says "addresses", Mike, that simply shows your Puppy's IP address. To connect, you use the 'IP connection' button; all you do is enter the 'local' IP of the machine you're sending it to. (In other words, "192.168.1.x".....which always denotes a 'local' connection. It's only ever the final digit(s) that change on a LAN.

Dukto is supposed to be able to 'auto-discover' other devices on the LAN, but it doesn't work that way for me. I always enter the other device's IP addy manually, since my Pups all run with 'static' IPs for various reasons. And THEN you just drag'n'drop files/folders onto the GUI.

(I have made one discovery. If you send any 'executables' over the network, Linux removes exec permissions by default. If you need to retain those permissions - especially where a package has several executables within it - then 'zip' it first.)

Hope that 'clarifies' things a wee bit...

~~~~~~~~~~~~~~~~~~~~~~~~~

The 'portables' I've built of Dukto, I've turned the executable and Qt4 libs into an AppImage with Fred's scripts. I've built 2 versions of it, in both 32-bit and 64-bit; one of each using Qt4.8.6, and one of each using Qt4.8.7. There's method in this seeming 'madness'; I mainly use PhilB's 'buntu-based LTS Puppies, and frequently Phil produced them with Qt4 built-in. Any app with Qt libs already in it - 4, 5 OR 6 - will detect if there's any other versions on the system.....and if there is, it will simply refuse to run. So you need to make sure that the Qt libs in your app match whatever's already there...

T'other Mike.

[mikeslr]

Attempting to run the AppImage under Bookworm and Jammy fail with a notice (IIRC) 'Can not find executable'. Mikewalsh's pet was also unsuccessful. The structure is 'user-merge' compliant; so I didn't think that was the problem and looked for a solution. Instead I discovered that Devs at Ubuntu have recently ported to Qt5 (and Qt6*), https://ubuntuhandbook.org/index.php/20 ... buntu-ppa/ unfortunately most easily available as a snap. https://snapcraft.io/install/dukto/ubuntu.

https://ubuntuhandbook.org/index.php/20 ... buntu-ppa/ provides instructions for installing it under Ubuntu 20.04 (Fossa) and 22.04 (Jammy) without snaps. But last night applying that to Puppy appeared to be 'above my paygrade'.

-=-=--
The post refers to both. But I think only Qt5 libs are made available.

[mikewalsh]

@mikeslr :-

Ah, right. So, the old Qt4 port is no longer supported, because Canonical have dropped support for Qt4? I can't say I'm surprised; I was expecting this sooner or later, since the previous general release to the current one appears to be supported for around 5 years or so. This being the case, I'm expecting Qt7 to arrive around 2026/7, along with the end of Qt5 support around 12 months later.

It's "progress", y'know?

Mike.

[mikewalsh]

Okey-dokey, guys.

In response to Mike's first post about the newer port of Dukto, I've tracked down the Launchpad repo of the Qt5 developer, and downloaded the Ubuntu 20.04 build. This is 64-bit ONLY; the new developer hasn't provided any 32-bit Linux builds, I'm afraid.

This being the Fossapup64 9.5 base, I've also used ldd to track down the relevant Qt5 libs, bundled them together with the upgraded Dukto binary and used Fred's scripts to create an AppImage. I've then built my 'standard format' portable around it, and with the addition of an 'AppRun' sym-link turned the whole thing into a ROX-app. Just download it, unzip it, and click on the directory to fire it up.

(There should be NO 'usrmerge' conflict, since the contents of the AppImage all sit under /usr anyway.)

Obviously, it runs fine in Fossapup64 itself. I shall be testing in other Pups over the coming days to see whether this will "play nice", Qt5 being somewhat less forgiving than Qt4 was, and will report back. Watch this space...

~~~~~~~~~~~~~~~~~~~~~~~~~

If anybody wants to take this for a spin, y'all can find the new Qt5 build of Dukto-portable here at MediaFire :-

https://www.mediafire.com/folder/4w5m2k ... portable64

Feedback would be appreciated, especially for newer Pups (Jammy, BWP, etc.)

Enjoy..!

Mike.

[mikeslr]

Thanks, Mike. I'll test it under Bookworm and Jammy tomorrow. In case I forget, you should add it to your list here, https://www.forum.puppylinux.com/viewtopic.php?t=5104. But maybe wait for the results of that test.

[mikewalsh]

@mikeslr / everybody :-

I'm withdrawing this particular portable. I completely forgot to test it against a 'vanilla' install.....and discovered it needed at least another 300MB-worth of libs to get it working. That's the size of a complete Puppy! The 'dukto' binary itself is tiny, yet wants a ton of other stuff simply to function...

This is ridiculous, considering the older Qt4 build is only around 10 MB in size. It's now humungous for a 'basic' app.....considering there ARE far smaller alternatives readily available. If you simply install the .deb package, the package manager will want to drag in nearly 700MB-worth of other dependency suites for this to work. Mind you, that's probably 'par for the course', since many devs are now building everything with heavy dependency on Qt5/Qt6, and it's expected that the majority will have the full Qt suite installed for this very reason.

A Qt4 package used to be a reasonable size. It ballooned to ridiculous with the advent of Qt5. With Qt6, it's become insane....but, it's the old, old story. No matter how easy the hardware manufacturers make it for you to increase memory/storage, most developers seem determined to use as much of it as possible with their creations. With no incentive to keep things tight'n'tidy any more, it encourages lazy coding.......and a whole generation of would-be coders no longer even bother to learn languages any more, instead relying on coding web-sites and "AI" to do it all for them. And of course, AI has no conception of hardware limitations, does it?

</...rant over...!!>

Personally, the sheer amount of stuff needed doesn't bother me, but packages offered to the community need to be useful for as many people as possible, don't they? I'll need to have a re-think on this one, I reckon.

I know most of us are now running more powerful hardware, with a lot more RAM and storage, but even so, there ARE limits.

Sorry 'bout that.

T'other Mike.

[mikeslr]

And there's another problem, Qt5 versions aren't interchangeable. As promised, tested under Bookworm and Jammy64, albeit neither were OOTB.

Starting via terminal under MY Bookworm64 report:

dukto: error while loading shared libraries: libicui18n.so.66: cannot open shared object file: No such file or directory
Checking dukto for missing libraries...
/initrd/mnt/tmpfs/tmp/.mount_Dukto6wg5wGl/usr/bin/dukto: /initrd/mnt/tmpfs/tmp/.mount_Dukto6wg5wGl/usr/lib/libQt5Core.so.5: version `Qt_5.15' not found (required by /lib/x86_64-linux-gnu/libQt5Quick.so.5)
/initrd/mnt/tmpfs/tmp/.mount_Dukto6wg5wGl/usr/bin/dukto: /initrd/mnt/tmpfs/tmp/.mount_Dukto6wg5wGl/usr/lib/libQt5Core.so.5: version `Qt_5.15' not found (required by /lib/x86_64-linux-gnu/libQt5QmlModels.so.5)
libicui18n.so.66 => not found
libicuuc.so.66 => not found
Adding these depencencies will probably fix if the program doesn't run.
Script completed, press RETURN to close window.

Terminal under MY Jammy64 crashes when I try to copy its output. But here's a screenshot.

scr2(1).png (51.08 KiB) Viewed 176 times

Might work if it was built like firefox-portable with a fleshed-out extra-libs folder and a command in the LAUNCH script to use it.

[rcrsn51]

If you are transferring files between Puppies, all you need is gnetcat. Remove the fake .gz extension.

The only dependency is lzop which is already in some Puppies.

[mikewalsh]

@rcrsn51 :-

Thanks, Bill. Small and simple.....and does what's needed.

@mikeslr :-

Might work if it was built like firefox-portable with a fleshed-out extra-libs folder and a command in the LAUNCH script to use it.

I doubt it, Mike. AFAIK, Qt is a bit of a special 'use-case'; even if you compartmentalise it, and point the app at a specific folder for its libs, Qt will STILL detect any other versions 'on the system'. I did read somewhere a while back that the only way to run multiple versions of the SAME generation - Qt4, Qt5, Qt6, etc - is to edit /etc/profile, and 'point' specific apps at specific versions in specific locations. In other words, it doesn't work with the 'portable' format (even this has limitations).....the app EXPECTS to be 'fully installed' on your system.

Perhaps somebody else could figure out another way round that, but it's above MY present 'pay-grade'.

Mike.