FS#60132 - [code] App should start in background unless using the "-w" (wait) cli flag

Attached to Project: Community Packages
Opened by Massimiliano Torromeo (mtorromeo) - Thursday, 20 September 2018, 07:30 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 29 November 2018, 01:38 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Filipe Laíns (FFY00)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
As already mentioned in  FS#60039 's comments if you start code in a shell the app does not start in the background as it's supposed to.

Code should block until closed only if the dedicated flag is used (see --help "-w, --wait Wait for the files to be closed before returning.")

The AUR package was working as intended.

Also note that this behaviour is only apparent if there are no other Code instances already open, otherwise the file/directory is opened in the background as intended.


Steps to reproduce:
With no code instances open, run "code /some/path/or/file" in a shell. The CLI is supposed to immediatly return and open Code in background.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Thursday, 29 November 2018, 01:38 GMT
Reason for closing:  Fixed
Additional comments about closing:  code 1.29.1-1
Comment by Filipe Laíns (FFY00) - Thursday, 20 September 2018, 22:15 GMT
I have spent several hours trying to make this, and other things, work. I failed. This is something that really should be fixed in the upstream. Please open an issue there.
Comment by Jacob Henner (JacobHenner) - Thursday, 29 November 2018, 00:47 GMT
  • Field changed: Percent Complete (100% → 0%)
Solution is adding ELECTRON_RUN_AS_NODE=1 to the invocation:

-exec electron /usr/lib/code/out/cli.js /usr/lib/code/code.js "$@"
+ELECTRON_RUN_AS_NODE=1 exec electron /usr/lib/code/out/cli.js /usr/lib/code/code.js "$@"
Comment by Jacob Henner (JacobHenner) - Thursday, 29 November 2018, 01:07 GMT
To add, this runs using the nodejs instance contained within electron. Setting this environment variable doesn't create a dependency on the nodejs package.
Comment by Jacob Henner (JacobHenner) - Thursday, 29 November 2018, 01:07 GMT
Attached patch that handles both this and the 1.29.1 upgrade (could break up if requested, was originally focusing on the latter and decided to fix this at the same time).
   1.29.1.patch (4 KiB)
Comment by Eli Schwartz (eschwartz) - Thursday, 29 November 2018, 01:38 GMT
Thanks! And fixed in code 1.29.1-1

Since this package has been weirdly failing to build from source, it was difficult to do so... the final piece I was missing was:

internal/streams/legacy.js:59
throw er; // Unhandled stream error in pipe.
^

Error: getaddrinfo EAI_AGAIN marketplace.visualstudio.com:443
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:67:26)


Which somehow magically got fixed by running extra-x86_64-build, CTRL+C to kill the build, then manually arch-nspawn into the chroot and run /chrootbuild with the usual makechrootpkg logic.

I assume somehow, I don't know why, this persnickety thing has a **DNS** error??? when running from a non-interactive nspawn session? I don't comprehend this, but it "worked". I dread to think how this package will be reproducible, but it's nodejs, that may be a lost cause anyway...

EDIT: The RNG gods have blessed us today, pkgrel=2 in staging for the electron 3 rebuild has successfully built without this makechrootpkg hacking nonsense.

Loading...