I have been building Joplin on Fedora Linux for some time now – https://github.com/taw00/joplin-rpm – and it looks like Joplin is relying on Python 2.6.0 in some places. Fedora 31 is in beta (release in November I think? and will supply Python 3.8) and it will mark moving beyond mere deprecation to wholesale cleansing of Python 2.6.0. Or at least all the related packages: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal
Now, I don’t know if I grasp the reported errors at this point, but it looks like however sqllite3 is being compiled/installed seems to be a problem? Because it is calling for python 2.6.0 stuff?
I will keep investigating, but I wanted Laurent and the other folks working on Joplin to be aware that Linux distros will be moving away from this older variety of Python very soon now and there will likely be implications.
Joplin uses something that uses python. And python is used for Joplin’s build scripts. And then there is NPM which is a morass of almost unfathomable dependencies. I haven’t dug too deeply into it yet. Regardless, this is a word of warning about the impending complications that may be forthcoming for many many projects out there.
Joplin doesn’t directly use Python. Maybe some libs are built using Python but in that case they are the ones who will fix this kind of issue. On our side there’s no much we can do.
Based on the log it’s sqlite3 which uses Python but this is a widely used package, so for sure they’ll update it if Python 2 becomes discontinued.
Yes. I finally got it to build for Fedora 31. Here were the issues:
Python2 is still required by some of the cascading build scripts (not a Joplin issue, … well, until it is)
sqlite3 is built and the OS’es deployment is ignored. I am not sure why it behaves this way, but it does.
the sqlite3 version indicated in the two package.json files didn’t allow newer linuxes, like Fedora 31, to complete a compile.
What I did to get it to build on Fedora 31:
Forced a python2 install and ensured it was available in the path
Bumped the acceptable version of sqlite3 in the two package.json files (risky, but so far, so good) to match what the OS expects.
Note: I am not a javascript expert, trying to parse the tracebacks and find a root cause has been … challenging.
If you are a Fedora 31 user, please help me test the Joplin RPM builds. I am very confident they are fine, but I don’t currently have a desktop version of Fedora 31 available. Again, you can enable the Joplin repo via the instructions found here: https://github.com/taw00/joplin-rpm
Seems to be working just fine right now. I haven’t found any issues on F31. Yay! Is it only the build that has the dependency on Python2, rather than the RPM?
If you are after any logs or other info, please let me know and I will do my best to assist. I am all in with Joplin now!
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.263N5O
+ umask 022
+ cd /builddir/build/BUILD
+ cd joplin-1.0
+ cd joplin-1.0.174
+ cd Tools
+ npm install
npm ERR! cb() never called!
npm ERR! This is an error with npm itself. Please report this error at:
npm ERR! <https://npm.community>
I build rpms the official way using the mock building system. This implies that every build takes place in a freshly installed, clean environment, using only the packages specified in the spec file. For all packages the most recent officially released versions are used. That’s npm 6.9.0 and nodejs 10.16.3.
I just duplicated your error.
You have to give build access to the internet. With these insane Javascript based builds there is no real way around it and hence, Red Hat for example, will probably never let these kinds of applications ship with the product (in particular electron based applications, but I digress). A truly proper build should never need access to the internet to complete. A source package should be self-contained. With NPM… this makes for super ugly source RPMs.
You have to edit your ~/.config/mock.cfg file and set this variable to True:
config_opts['rpmbuild_networking'] = True
Then it should build for you just fine.
-todd
Side note: I need to clean up that contrib tarball. The only thing it uses is the joplin.appdata.xml file. I really should contribute that to the joplin project directly, to be frank. Haven’t gotten around to it.