Linux Appimage 64 Bit (x86-64)

[Dardo Hameed]

Iam trying to change to linux.

I have put a copy of linux on a new partition on my computer and can load and run it

uname-a returns

Linus bob-desktop 5-15-0-60 generic #66-ubuntu SMP Fri Jan 20 14:29:49 UTC 2023 x86_64 x86_64 xs86_64 GNU/Linux

I have downloaded AppImage 64 bits (X86-64) from the Arduino Software page. made it executable and run it.

All I get is a white box with the arduino logo in the middle moving in and out of the page (getting larger and smaller).

Thinking I had done something wrong I downloaded the linux zip file, extracted it and ran the appimage file from within it to get the same blank page with the arduino symbol on it.

Thinking it just took a while I left it all night, in the morning I still just had the arduino logo on the white page.

I can't see any other file to load, can anyone see what I am doing wrong?

Hi semperidem, yes you did. It had so many faults I asked the staff to delete it.

I have found how to get the directories and files in terminal and done as you ask ptillisch, It ran as you say and then produced the box as above it is on the linux partition of another machine so I can't just paste it here.

The machine it is on is only wifi connected and much slower than this machine. I will try to send it to my e-mail address and pick it up here please bear with me.

Right! I did as you asked and it gave me the box above for a short period and then loaded the IDE.

I have managed to produce a short cut on my desktop for it that works.

I tried to select a board and gave me the board manager and then started to download something else to do with board manager?

It is so long since I first loaded the IDE onto a computer, is this normal?

It looks as if it is loading board packages and port details.

I tried to select a board and gave me the board manager and then started to download something else to do with board manager?

It is so long since I first loaded the IDE onto a computer, is this normal?

It looks as if it is loading board packages and port details.

Yes, that is normal. The Arduino IDE 1.x installation includes the "Arduino AVR Boards" platform of the Uno, Leonardo, Mega, etc. boards. Arduino IDE 2.x works similarly, but a little differently in that the installation doesn't contain the "Arduino AVR Boards" platform, but it automatically installs the latest version on the first run after a fresh installation (unless you already have the "Arduino AVR Boards" platform installed on your computer).

If you are using one of the boards of that platform (e.g., Uno, Leonardo, Mega), you don't need to make any other installations after that, but if you have a different board then you also need to use Boards Manager to install the platform that adds support to Arduino IDE for the board.

However, I came across this QEMU Appimage at _Appimage.

There are two variants available, and without exhaustive testing, they both seem to work in BookwormPup64, as well as Fossapup64, Debian Dog and Quickpup64.

It does not run without error in S15pup for some reason, thus far.

To use the Appimge, download and change the permissions to executable. Lets say its called QEMU-x86_64.AppImage. For convenience, place in a new directory (say, QEMU). Open a terminal in that directory.

Once running use Geany in the virtual OS to add a partition table to the VirtualHDD and then format it to say, vfat32. Then install the OS as required on the HDD. The installed image can then be booted by changing the script from -boot d to -boot a.

AND, instead of having to look up the correct mod-probe to use on your PC, no matter if Intel or if AMD, use this Puppy Linux exclusive for QEMU users to do that for you by @norgo . This tiny utility SHOULD be included in all QEMU packages provided for forum distros for its automation of testing and turning the KVM ability 'on' within the running system.

to be faster for you unpack the appimage with ./my_appimage --appimage-extract and modify the AppRun file adding the option -f in the proot line after the proot option in $HERE/junest/bin/junest proot -f -n -b it should look like this, if you are in a hurry otherwise wait for my change in the github, I belive this is the fix for this problem.

friends I'm trying to fix that problem you have informed, but no success. I have other builds of qemu but it's old builds that I have built using old linux distros for better compatibilty in newer systems, it was build using pkg2appimage if you have interest on it just tell me I can upload for you.

dear friends I've tried everything but no success. I guess for now we may stick with ordinary builds made by pkg2appimage using old linux distros. Junest is not a bad idea but needs to maturate a bit. I've find out that junest is not good enough to run on systems that uses root directly like puppy linux does, I've installed fossa puppy in my machine for testing this appimages built on top of junest.

I am able to accept ideas if anyone find out a solution contact me.

I'll be uploading other builds of qemu I've made before to github.

thanks for your patience.

hello friends I've made a new appimage using the git version of qemu it's the latest version from the source code built against ubuntu 20.04, still having some things to be done but the network is working.

I need ideas of how to enable audio on the host os. please if you download it read it the readme file for new instructions.

hope you enjoy!

AppImage has a number of significant issues building images for GUI apps. It isincompatible with the use of binary wheels, and the use of an older Linux base imagefor compatibility purposes is incompatible with using modern GUI frameworks. Evenwhen a GUI toolkit can be installed, the AppImage packaging process frequentlyintroduces bugs related to DBus integration or libraries like WebKit2 that usesubprocesses.

Briefcase provides an AppImage backend for historical reasons, but we stronglydiscourage the use of AppImages for distribution. We maintain unit test coverage forthe AppImage backend, but we do not build AppImages as part of our release process.We will accept bug reports related to AppImage support, and we will merge PRs thataddress AppImage support, but the core team does not consider addressing AppImagebugs a priority.

Packaging binaries for Linux is complicated, because of the inconsistentlibrary versions present on each distribution. An AppImage can be executed onany Linux distribution with a version of libc greater than or equal theversion of the distribution where the AppImage was created.

Briefcase makes a best-effort attempt to use the AppImage tools to builda binary, but sometimes, the problem lies with AppImage itself. If youhave problems with AppImage binaries, you should first check whether theproblem is a limitation with AppImage.

A configuration argument to be passed to the Docker build command for the appimage. For example, to provide an additional build argument to the Dockerfile,specify --Xdocker-build=--build-arg=ARG=value. See the Docker builddocumentationfor details on the full list of options that can be provided.

A list of operating system packages that must be installed for the AppImagebuild to succeed. If a Docker build is requested, this list will be passed tothe Docker context when building the container for the app build. By default,entries should be Ubuntu 18.04 apt package requirements. For example:

but the app works under briefcase dev, the problem may be an incompletesystem_requires definition. The briefcase build process generatesa new environment that is completely isolated from your developmentenvironment, so if your app has any operating system dependencies, theymust be listed in your system_requires definition.

A list of linuxdeploy pluginsthat you wish to be included when building the AppImage. This is needed forapplications that depend on libraries that have dependencies that cannot beautomatically discovered by Linuxdeploy. GTK and Qt both have complexruntime resource requirements that can be difficult for Linuxdeploy toidentify automatically.

If your plugin requires an environment variable for configuration, thatenvironment variable can be provided as a prefix to the plugin declaration,similar to how environment variables can be defined for a shell command.

Any additional Docker instructions that are required to configure the containerused to build your Python app. For example, any dependencies that cannot beconfigured with apt-get could be installed. dockerfile_extra_content isstring literal that will be added verbatim to the end of the project Dockerfile.

Briefcase will unpack the new support package without cleaning up existingsupport package content. This should work; however, ensure a reproduciblerelease artefacts, it is advisable to perform a clean app build before release.

In addition, many of the commonly used manylinux base images predate the release ofWebKit2. As a result, system packages providing WebKit2 are not available on these baseimages. manylinux_2_28 is the earliest supported manylinux image that providesWebKit2 support.

it is likely that one or more of the libraries you are using in your apprequires a Linuxdeploy plugin. GUI libraries, or libraries that do dynamicmodule loading are particularly prone to this problem.

Briefcase uses a tool named Linuxdeploy to build AppImages. Linuxdeployprocesses all the libraries used by an app so that they can be relocated intothe final packaged binary. Building a manylinux binary wheel involves a toolnamed auditwheel that performs a very similar process. Unfortunately,processing a binary with Linuxdeploy after it has been processed byauditwheel can result in a binary library that cannot be loaded at runtime.

3a8082e126