Arch Linux User Repository

@Zyper

Still same error: request to https://registry.npmjs.org/codemirror failed, reason: connect EHOSTUNREACH 2606:4700::6810:1423:443

I have no more ideas of what to do. I searched for this error but I didn't find the solution

Hey @willianholtz I checked a few days ago on two machines and had no problems with building. There was a problem with running though (which could be resolved by running ldtk as ldtk --in-process-gpu), which now seems to be fixed in v.1.0.0 and is working without problems.

First, thanks for the quick update!

Looking forward to getting home and installing this new update. I've been following for a while and I'm expecting a lot of improvements that deepnight was making.

By the way, were you able to fix the packaging errors that were happening in the previous build?

@justanotheruser2: The same thing happens to me when compiling from upstream (GitHub repo). I'm not an expert in Node.js either, but I'll try to investigate why that happens.

Edit: This is this issue: https://github.com/electron-userland/electron-builder/issues/5978 For now it can be resolved by hand when building from repo.

Edit2: There's also a problem with "GPU process isn't usable" error. Try running ldtk like this: ldtk --in-process-gpu

Not sure if this is just me not understanding something basic (not used to javascript), but when running ldtk on fresh build I get:

(node:189057) UnhandledPromiseRejectionWarning: Error: Cannot find module 'fs/promises' Require stack: - /usr/share/ldtk/resources/app.asar/node_modules/electron-updater/out/AppUpdater.js - /usr/share/ldtk/resources/app.asar/node_modules/electron-updater/out/main.js - /usr/share/ldtk/resources/app.asar/assets/main.js - at Module._resolveFilename (internal/modules/cjs/loader.js:961:15) at Function.o._resolveFilename (electron/js2c/browser_init.js:257:921) at Module._load (internal/modules/cjs/loader.js:844:27) at Function.Module._load (electron/js2c/asar.js:779:28) at Module.require (internal/modules/cjs/loader.js:1023:19) at require (internal/modules/cjs/helpers.js:77:18) at Object.<anonymous> (/usr/share/ldtk/resources/app.asar/node_modules/electron-updater/out/AppUpdater.js:8:20) at Module._compile (internal/modules/cjs/loader.js:1145:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:1166:10) at Module.load (internal/modules/cjs/loader.js:981:32) (node:189057) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1) (node:189057) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. [189057:0215/033410.673717:FATAL:gpu_data_manager_impl_private.cc(442)] GPU process isn't usable. Goodbye. zsh: trace trap (core dumped) ldtk

errr.. new error. [code] npm WARN using --force Recommended protections disabled. npm ERR! code EHOSTUNREACH npm ERR! syscall connect npm ERR! errno EHOSTUNREACH npm ERR! request to https://registry.npmjs.org/codemirror failed, reason: connect EHOSTUNREACH 2606:4700::6810:1123:443

npm ERR! A complete log of this run can be found in: npm ERR! /tmp/yaourt-tmp-willian/aur-ldtk/src/npm-cache/_logs/2021-12-16T00_32_44_486Z-debug.log ==> ERRO: Uma falha ocorreu em build(). Abortando... ==> ERRO: Makepkg não conseguiu compilar ldtk. ==> Reiniciar a compilação de ldtk ? [s/N] ==> -------------------------------------- [/code]

@ColonelThirtyTwo: Done

Any chance you can add some desktop files? This doesn't show up in the Gnome apps list. Other than that, works well.

@Zyper thanx!! :)

Works now, thanks for the timely fix Zyper.

I think this is not handled well by upstream. Would probably make sense for upstream releases to use tagged versions or something of the dependencies, otherwise issues like these are inevitable. As it stands every build will be different. Unless you specify some specific commit, like you have done here, but it will most likely still be different from the upstream 0.9.3 build.