FS#50357 - [atom] Should be packaged with certain Electron version

Attached to Project: Community Packages
Opened by Alexander (xander) - Thursday, 11 August 2016, 17:29 GMT
Last edited by Balló György (City-busz) - Wednesday, 25 January 2017, 19:42 GMT
Task Type General Gripe
Category Packages
Status Closed
Assigned To Nicola Squartini (tensor5)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Atom MUST be packaged with certain Electron version (at now - 0.37.8), in other cases there will be plenty of errors, issues and bug reports.

For example, at now you can just click File -> New File, type some text and get this exception: https://github.com/atom/autocomplete-plus/issues/722. As mentioned in that issue, this happens only because of incompatible Electron version (1.3.3 now in community).

Similar task in Fedora's unofficial repo's tracker: https://github.com/FZUG/repo/issues/125

Task about updating Atom codebase to newer Electron versions: https://github.com/atom/atom/pull/12300

Atom 1.9.8.
This task depends upon

Closed by  Balló György (City-busz)
Wednesday, 25 January 2017, 19:42 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Ask upstream to change their design decisions.
Comment by Balló György (City-busz) - Thursday, 11 August 2016, 23:45 GMT
These are just minor problems, so I don't see any reason why should we use an old Electron. Old Electron comes with old Chromium, which contains many vulnerabilities, thus insecure to use:
http://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/Google-Chrome.html

I think that upstream developers should support the latest releases of electron. If you found any problems, then bother upstream to fix it.
Comment by Peter Petrov (onestone) - Friday, 12 August 2016, 00:08 GMT
These vulnerabilities are important for a browser. Not so much for a code editor.

I also think that the upstream supported Electron version should be used. There are too many incompatibilities between major releases of Electron (most of which due to V8), upgrades are not as simple as a version bump, and it's naive to think that everything will just work with a newer major release than the officially supported and tested one.

In my case Atom from this package does not even start, and I strongly suspect this to be the cause.
Comment by Levente Polyak (anthraxx) - Friday, 12 August 2016, 00:54 GMT
well security its not that simple. atom is meant to be extended where you pull in potentially untrusted javascript... plus you may also open untrusted files with a code editor. Of cause its less compared to browsing the webm but saying its not so important is simply wrong.

before blindly guessing into the wild, could you try to rebuild a older version of electron yourself and test if that works?
Electron itself should be kept up-to-date so if this gets decided, it would basically mean to maintain an additional legacy version -,-
Comment by Peter Petrov (onestone) - Friday, 12 August 2016, 01:06 GMT
> before blindly guessing into the wild, could you try to rebuild a older version of electron yourself and test if that works?

Not for a few days. But I get this in dmesg each time I try to start Atom:

> [ 2539.736730] traps: electron[4719] trap invalid opcode ip:18a4291 sp:7ffdf6f06850 error:0 in electron[400000+3b8b000]

> Electron itself should be kept up-to-date so if this gets decided, it would basically mean to maintain an additional legacy version -,-

Not necessarily as a separate package, could be part of this package's build. Just like e.g. nodejs builds its own V8.
Comment by Balló György (City-busz) - Friday, 12 August 2016, 01:13 GMT
Electron is an application framework, and there is a web browser which uses it:
https://aur.archlinux.org/packages/min

So I think we have the following options:
1. Fix the autocomplete-plus plugin ASAP.
2. Remove the autocomplete-plus plugin from the package until it gets fixed.
3. Drop Atom from the official repositories, because it's unsupported by upstream.

I don't like the idea to bundle an old Electron release with Atom. If you want this, then you can download the pre-built packages from https://atom.io/ .

@onestone: are you using a 32 bit system? Please open a new task for this issue.
Comment by Peter Petrov (onestone) - Friday, 12 August 2016, 01:16 GMT
> @onestone: are you using a 32 bit system? Please open a new task for this issue.

No, my arch is x86_64 (with Multilib enabled).
Comment by Peter Petrov (onestone) - Friday, 12 August 2016, 01:25 GMT
>So I think we have the following options:
>1. Fix the autocomplete-plus plugin ASAP.

I doubt this will be the only issue caused by using an incompatible Electron version.

> 2. Remove the autocomplete-plus plugin from the package until it gets fixed.

Unacceptable, autocomplete-plus is an essential plugin, nearly all supported languages use it. Atom would be crippled without it.

> I don't like the idea to bundle an old Electron release with Atom. If you want this, then you can download the pre-built packages from https://atom.io/ .

There are two good AUR packages which bundle a compatible Electron release - atom-editor and atom-editor-bin. I've had good experience with both of them.

Is there any specific reason to not like this idea btw? It's not a precedent. E.g. nodejs does the same (it also demands a specific V8 version).
Comment by Levente Polyak (anthraxx) - Friday, 12 August 2016, 01:31 GMT
as György already pointed out, security is a pretty good point and just because the pre-built or ancient bundled versions in AUR work, doesn't mean it makes sense.

Your issue why its not starting is because electron was built with native mtune and uses AVX instruction sets while your CPU does not seem to support such. Thats a bug in electron and a ticket should be opened accordingly that it respects mtune=generic from /etc/makepkg.conf CFLAGS/LDFLAGS and does not override it:
> objdump -d ./usr/lib/electron/electron|grep -i vbro
70d020: c4 e2 7d 1a 25 f7 56 vbroadcastf128 0x3ce56f7(%rip),%ymm4 # 43f2720 <_ZN20TtsPlatformImplLinux21current_notification_E@@Ba
...
70e922: c4 e2 7d 18 ed vbroadcastss %xmm5,%ymm5
...
Comment by Peter Petrov (onestone) - Friday, 12 August 2016, 01:54 GMT
> as György already pointed out, security is a pretty good point

Extensions already have the power to break anything in $HOME. Regarding opening untrusted files, the danger is pretty small, as these files are only parsed, not executed. I'm not saying security is not important, but it's less important in a code editor than in a web browser. Correctness can (and IMHO should) be prioritized here.

> just because the pre-built or ancient bundled versions in AUR work, doesn't mean it makes sense

This is misrepresenting the issue. Let me try to summarize it again:

- Major Electron releases are not completely backwards compatible. This is often caused not only by Electron itself, but also by its own dependencies - V8 and Node.js. V8 in particular introduces breaking API changes quite often.

- Upgrading to a newer Electron major release is not trivial. It's not enough to just bump the version, it also takes extensive testing and fixing what has been broken. Atom periodically upgrades its Electron dependency, but not with every release, as it is a time-consuming task. Please see this comment from an Atom developer: https://github.com/atom/atom/issues/11967#issuecomment-225974781 (relevant quote: "So we will move to new versions of Electron as we can, when it makes sense, when we can guarantee a certain level of stability for all users of Atom, when we can work with our package authors (who we feel are a significant part of Atom's success) to ensure that their hard work isn't broken or at least they have fair warning, and when the benefits outweigh the downsides. We won't commit to a timeline because every new version of Electron brings with it new challenges. Some take longer and some are easier.").

P.S. Thank you for diagnosing my issue. Strange, my CPU is Sandy Bridge and it supports AVX.
Comment by Alexander (xander) - Friday, 12 August 2016, 07:30 GMT
There are only 2 right ways to fix it:

1) Bundle 'atom' package with an appropriate Electron version, just like 'atom-editor' from AUR does (and just like Node.js is shipped with appropriate V8 version).
2) Create a separate package, electron0.37.8, and change Atom's dep accordingly – but I found that way a lot less nice, especially because Atom's Electron version changes often.

We can't just fix 'autocomplete-plus' plugin and believe that no more bugs will appear – as Peter said, newer Electron versions breaks and deprecates a lot of API, and upgrading Atom to it is a non-trivial task (I mentioned a link to related issue in head post).
Comment by Nicola Squartini (tensor5) - Friday, 12 August 2016, 08:26 GMT
Peter, you mentioned an error in dmesg. By chance are you using linux-lts? Another user had a problem with it (https://github.com/tensor5/arch-atom/issues/34).
Comment by Nicola Squartini (tensor5) - Friday, 12 August 2016, 08:52 GMT
The incompatibilities between atom and the latest version of electron have a trivial fix the vast majority of the times, and if they are not fixable right away I delay upgrading electron. The issue with autocomplete-plus also have a trivial fix, thanks for reporting it.
Comment by Peter Petrov (onestone) - Friday, 12 August 2016, 12:26 GMT
> Peter, you mentioned an error in dmesg. By chance are you using linux-lts? Another user had a problem with it (https://github.com/tensor5/arch-atom/issues/34).

Yes. I also responded on the GitHub issue you linked, let's continue the discussion about this there.
Comment by Nicola Squartini (tensor5) - Friday, 12 August 2016, 15:10 GMT
I just uploaded a new release that fixes the autocomplete-plus issue.
Comment by Vasyl Demin (zersaa) - Wednesday, 17 August 2016, 16:19 GMT
I get "Error: Path must be a string. Received null" when try to open any js-file in atom with installed 'linter-eslint' package. Have no errors with bundled electron.
Comment by Nicola Squartini (tensor5) - Friday, 19 August 2016, 12:42 GMT
Vasyl, I opened a PR just now https://github.com/AtomLinter/linter-eslint/pull/673. Meantime you can fix it manually by applying the changes in the PR to your ~/.atom/packages/linter-eslint.
Comment by NicoHood (NicoHood) - Monday, 29 August 2016, 16:48 GMT
This also causes this bug:
https://github.com/atom/atom/issues/12534
Comment by Nicola Squartini (tensor5) - Wednesday, 31 August 2016, 13:43 GMT
NicoHood, I fixed it in 1.9.9-3. Please try it and let me not if there is any side-effect to my patch.
Comment by NicoHood (NicoHood) - Wednesday, 31 August 2016, 14:29 GMT
Thanks a lot! That seems to work :)
Comment by geoffrey bonneville (G-Ray) - Thursday, 01 September 2016, 13:36 GMT
Fresh install on a new arch system: The editor window is entirely black, there is no welcome screen, no tree view, etc...
Comment by Nicola Squartini (tensor5) - Friday, 02 September 2016, 00:56 GMT
Hi Geoffrey,
I tried to reproduce your problem by removing .atom and .config/Atom. It starts regularly with welcome page and welcome guide.
Can you try and launch electron alone, and electron --app=/usr/lib/atom, and see if you get some some error message on the terminal.
Comment by geoffrey bonneville (G-Ray) - Friday, 02 September 2016, 07:40 GMT
After deleting ~/.atom/ and ~/.config/Atom (I think I forgot to try this one yesterday), it works well. That's strange because I"m sure it didn't work at the very first start. Thanks
Comment by Vasyl Demin (zersaa) - Thursday, 08 September 2016, 07:54 GMT
> Vasyl, I opened a PR just now https://github.com/AtomLinter/linter-eslint/pull/673.
Thanks, it works after release 7.3.0.
Comment by Vasyl Demin (zersaa) - Friday, 09 September 2016, 10:30 GMT
I have another one "Path must be a string" error when trying to open new file (Ctrl+N). The cause is the 'react' package:
https://github.com/orktes/atom-react/blob/master/lib/atom-react.coffee#L126
Comment by Nicola Squartini (tensor5) - Saturday, 10 September 2016, 08:06 GMT Comment by CB (cle1109) - Wednesday, 02 November 2016, 13:17 GMT
Since the latest update of Node.js to 7.0.0, apm has stopped to work completely. I reported this upstream (https://github.com/atom/apm/issues/635), but the devs say that Atom must be bundled with the appropriate version of Electron.
Comment by Laury Bueno (laurybueno) - Wednesday, 02 November 2016, 17:03 GMT
Now, I can only use apm if I downgrade Node :(
Comment by Nicola Squartini (tensor5) - Wednesday, 02 November 2016, 19:27 GMT
@cle1109 and @laurybueno, apm 1.14.0-2.
Comment by Laury Bueno (laurybueno) - Wednesday, 02 November 2016, 22:50 GMT
@tensor5 thank you so much for the great work!
Comment by Clemens Brunner (cbrnr) - Thursday, 03 November 2016, 07:29 GMT
@tensor5 thanks a lot, great work!
Comment by NicoHood (NicoHood) - Saturday, 05 November 2016, 10:22 GMT
I currently have 2 problems with atom:
Sometimes the scrol bar is not shown when the windows is in full screen. This also sometimes happens with splitted view where one of both views does not work.

I always get the welcome message when I open atom. Annoying but acceptable for now.
Comment by Philip Abernethy (Chais) - Sunday, 06 November 2016, 16:06 GMT
Another reason to package the official release is documented here: https://github.com/atom/tabs/issues/395
Comment by Nicola Squartini (tensor5) - Monday, 07 November 2016, 09:15 GMT
Thanks for reporting.

@NicoHood, I noticed the scrollbar issue and I'll look into it. I don't have the welcome message problem.

@Chais, that's another "path must be a string" type of problem, I'll fix it soon.

Fortunately starting from v1.12 Atom will use a much more updated version of Electron (1.3), so I expect that the rate of this kind of bugs will decrease dramatically.
Comment by Nicola Squartini (tensor5) - Monday, 14 November 2016, 09:27 GMT
@Chais, the Ctrl-N thing should be fixed in atom-1.12.
Comment by Vasyl Demin (zersaa) - Monday, 14 November 2016, 20:05 GMT
> https://github.com/orktes/atom-react/pull/196
@Nicola Ctrl-N works without this fix in atom-1.12. Thank you anyway for your time.
Comment by Oli (dotb52) - Saturday, 26 November 2016, 15:15 GMT
I'm highly in favour of bundling the specific Electron version, as this introduces subtle bugs and general annoyances. It's not worth to save a few megs but introducing potential problems. For example, in my cases I have issues with mit HiDPI setup due to a too new version of Electron. An Atom dev explicitly said to bundle the specific Electron version.

https://github.com/atom/atom/issues/13331#issuecomment-263067273
Comment by Balló György (City-busz) - Sunday, 22 January 2017, 20:10 GMT
I think this discussion goes nowhere. Upstream developers have wrong design decisions. Someone should fill an issue or send a pull request to change their minds:
https://github.com/atom/design-decisions/blob/master/unofficial-atom-distributions.md

I think it's reasonable to package the latest electron, and use it with all electron applications. So I'm closing this task soon.
Comment by Nicola Squartini (tensor5) - Monday, 23 January 2017, 09:47 GMT
I agree. Moreover Atom is fully functional with the latest version of Electron, and there are no bugs that are related to this.

Loading...