Arch Linux User Repository

[Edit: +1]
@unphysicalix: hi,
I'm ok to flag the package out-of-date when a new version of Electron is out, no problem!
This time I was late because poor internet connection: the new PKGBUILD had already been ready for some time.
Thanks to a neighbor, I could push the commit today.

--> Finally I think I've found a way to use Arch Linux's electron13 instead of github's one.
But I can't make a new release just now and for a few days. :(

--> I also found a way to perhaps save some more bandwidth. As we don't use Eslint to build the app,
I think we can safely drop Eslint dependencies (in package.json). I've quickly tested a build without it and
it doesn't seem to be any differences in the output. And the node_modules size dir decreased significantly
(-40 in number of folders, -17% in size: -176 MB). Would you like to test such a version?

hi @etaboon,

They could have made it more flexible. For instance in using a config file which would store the path to the installed library (not so easy though when it needs adaptation to other platforms).

thanks for the elaborate answer. Using these arguments it fairly responsible to use your own electron. As soon as the upstream developer think of these issues, it might be time to reconsider using a system-wide installation.

anyway, is it ok to flag the package out-of-date in case like this today, that there was a new version of electron13 out? I'm not sure how to automatically do this, it just came to my mind when I saw the update...

Cheers, Tobias

@unphysicalix: hi,

original question: is it impossible to use the system-wide installed electron13 ?
or is it just "common behaviour" to package your own electron to make your piece of software more portable?

About 'common behavior', I don't know, I'm just not a developer. Here is however what I think of this:

It's entirely possible to use the system-wide installed electron13 in certain circumstances.
It will depend on the features of the app and how the dev will code them.

Besides the first packager of Scratch3 proposed to install Scratch3 in this way
and the app was running fine. However there was the issue of not being able to load other sprites,
load other backgrounds and load other sounds from the library. Why?

The app needs to know the location of the library. The devs choose an easy way to do so,
they just concatenate the application path with the string '/resources/static/assets/'.
Then, when you use the system-wide Electron app, the app will look into the folder
/usr/share/electron13/resources/static/assets/, which doesn't exist of course,
instead of the path of installed app: /opt/scratch3/resources/static/assets/.

They could have made it more flexible. For instance in using a config file which would store
the path to the installed library (not so easy though when it needs adaptation to other platforms).

The use of system-wide installed electron is moreover not necessarily desirable.
In packaging the app with one's chosen and tested version of Electron has one big advantage:
the warranty of delivering an app that won't be broken by a new Electron version (with possible regressions)
after a system update. Remember Scratch3 stopped loading when Electron version reached the 12 series?

Hope all this answers to your question. There are other aspects I could develop but it would make the answer very long.

Hi @etaboon,

sorry for the confusion: First of all: for a working installation on my system I can use scratch3-bin, thanks.

The other stuff: I was just trying to help and probably making it more confusing by using a docker-container. I am using a clean arch-linux docker installation exactly for the reason to have a clean environment - and since this docker-machine is simply more powerful to compile AUR-packages than my laptop. Inside the docker:

• the npm + npx versions are up-to-date 8.3.0
• kernel is up-to-date 5.4.0-91-generic
• I am using a non-root user doing only non-root stuff

Then I searched and found this (rather old problem): https://github.com/electron/electron/issues/17972#issuecomment-516957971 -> electron introduces sandboxing somewhere and neither Arch nor docker-container handle the workaround by default.

Anyway: lets put the docker aside, maybe there is a problem we don't need to look into.

I don't know why I was doubting it: scratch3 compiled + packaged correctly on my live laptop (5 min. or so) ... and it runs ok.

Back to my original question: is it impossible to use the system-wide installed electron13 ? or is it just "common behaviour" to package your own electron to make your piece of software more portable?

@unphysicalix: hi,
dockerized arch linux machine: this is what make the difference!
And I don't know how it works and what kind of installation it is
(strip down with 'git pull' or complete...?). In any case, you shouldn't
use root's right to build it.

Easy and fast solution would be to build the package on a standard installation
of Arch Linux and then copy et install it into your dockerized arch linux machine.

Second option: try with scratch3-bin just to see if it works there.
As no compilation is needed, installation should succeed and it can give some hints
if it fails to load (start it in a terminal to see what's happen).

Otherwise I'll need some more info about your installation. In a terminal (inside your dockerized arch linux machine of course)
as a non-root user, what are the (full) outputs of (consider using pastebin?):

$ uname -a
$ echo $PATH
$ which npm
$ npm --version
$ which npx
$ npx --version

Then cd into your build directory, delete all files but the one needed for build, only five files must remain (use
the last one posted yesterday):

PKGBUILD  scratch3.desktop  scratch3-icons.tar.gz  scratch3-patches.tar.gz  scratch3.xml

Before building, increase (eventually) the cache of your terminal in order to be able to copy all the output. Then:

$ makepkg

Same error will occur, but this will certainly give me some hints as why and how to fix the issue
(I hope so) in analyzing the differences when running the same on my system.

Hi @etaboon,

sorry, no, not cross compiling. Simple compile test on a dockerized arch linux machine. (archlinux/archlinux:latest)

the user "archie" has sudo-rights, since it is in the "wheel" group.

I just used "yay -S scratch3" which trys to compile + install your package.

using git clone https://aur.archlinux.org/scratch3.git; cd scratch3; makepkg results in the same error as pasted below: https://aur.archlinux.org/packages/scratch3/#comment-844450

and compiling it on my desktop also results in this failure...

what's wrong with me ? ;)

@gyurman: great!

Just posted new version that fix the issue (app icon not showing).

@etaboon: hello; Thanks; Working well. Founds the apps my language also. It was 23 minutes for wait compile on Raspberry Pi 4B 2000 Mhz Can you change the app icon? Only have X. Thanks

@unphysicalix: hi,
could you please tell me more about the context?
Which version of npm do you use? The system (wide) version or a local one?

$ pacman -Ss npm
community/npm 8.3.0-1 [installed]

$ npm --version
8.3.0

A local version (with its modules) may interfere with the app's modules.

$ which npm
/usr/bin/npm

If it's different, edit your .bashrc and revert the $PATH back
so as to not use local version. I've already seen such weird troubles.

Then in a folder save all the files needed: scratch3* > plain > save as...
And build the package:

$ makepkg

I've do it again just a minute ago and I didn't see any errors.