fcastilloec
commented
2 years ago As you have noticed, this is not an error with our module but rather with all the files/modules you're using and the new policy on Fedora. Some of the warnings could go away if you change some files permissions (i.e. README.md doesn't need to be an executable). For all the python ones (the errors), you'd have to talk to the creators of those packages or you can change the shebang of those files (as per your links). Here's the pathfix.py script mentioned in your links. You could run it before packaging the app, pointing to the files listed in the errors. I didn't look at the script itself, so I wouldn't be able to help you run it.
As per having an option on the spec file that disables the new shebang policy (similar to what atom is doing), we have discussed introducing a template for the spec file (see https://github.com/electron-userland/electron-installer-redhat/issues/190#issuecomment-817199074) but I don't think that'll happen quickly enough.
I think I'm going to mark this as a duplicate of #190 since fixing both needs a spec template.
What version of
electron-installer-redhatare you using?3.3.0
What version of
nodeandnpmare you using?7.20.5
What operating system are you using?
Fedora 33
Can you compile the example app successfully?
Yes.
What did you do? Please include the configuration you are using for
electron-installer-redhat.I'm trying to build an electron app on a Fedora 33 machine via
electron-forgeandweb-pack. Everything works fine onelectron-builder, however I decided to switch toelectron-forge. I got everything working for running the app viayarn start. Basically firing the app without building it. However, when building the app, I'm getting into problems I can't solve even with the help of researching on the web.The peculiar aspect is including
knexandsqlite3as externals onwebpackand having them bundled as Node.js bindings.To be honest, everything works perfectly and this is quite a specific issue, but I think, it is related to this package. Though I'm not sure I'm totally correct.
So, here is what I found out so far: Fedora has decided to force a restrictive Shebang line as described here since version 33: https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error
and this issue was also happening over at Atom editor, which is built on electron, and the choose for ignoring that policy altogether: https://github.com/atom/atom/pull/21964/files by disabling it.
and here is their discussion for why they did so: https://github.com/atom/atom/pull/21964
and the original bug: https://github.com/atom/atom/issues/21937
It could be a problem at Sqlite3's side, but I kind of not sure about that, since the command line screams about lacking shebang in tons of files, ranging from
LICENSEto*.jsfiles.After some googling I ended up using @timfish/forge-externals-plugin which did made everything work like the electron-build would, but when packaging it, it fails. That's the best state I could get my project to, so far.
Another possible cause could be that there are multiple versions of python on my system, but then again, it looks like Fedora had already moved to python 3 before I even configured this system [see here: https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Phase_4:_Retire_Python_2_for_other_packages.2C_but_keep_it_around_for_developers_and_users]. So, I imagine the version 2 is just there because some programming hobbies of mine required it or something. But the default is 3 and I don't think, that's the cause.
I also tried replacing
sqlite3withbetter-sqlite3butknexis still unrealased with support forbetter-sqlite3. My workaround was to download the knex and link it via yarn. Everything worked, but when building the application, againyarn makeresulted in the error that:Which when I checked there was a symlink there, but apparantly whatever underlying code is doing to call the respective repo, it is not doing a good job at working seamlessly regardless of whether a package is installed or it is sourced via linking.
I think these errors are reproducable, with other projects and libraries, in case they are bundled up externally. Of coruse, it is not a super common approach but maybe these hinderances are a contributive factor.
What did you expect to happen?
Everything to work somehwhat smoothly [maybe with a little hassle but not days after days hassle ;-)]. I mean, your package, this issue asdie, seems to work awesomely :+1: So, well done on that.
What actually happened?