New package: deno-1.5.3

[shizonic]

No description provided.

[Chocimier]

Are problems from #22043 addressed in this release?

[shizonic]

No they aren't. I can't figure out where exactly the binaries are fetched.

[shizonic]

I really don't know why it always runs out of time. It builds successfully on my local machine. Any suggestions?

[Chocimier]

Disabling arm following upstream suggestion is acceptable, but limiting to single arch due to precompiled components is not.

I really don't know why it always runs out of time.

See linked PR.

[shizonic]

but limiting to single arch due to precompiled components is not.

It's not because of that, it's because x64_86 is currently the only supported arch. See: denoland/deno#7958 (comment)

But I appreciate any help!

[ericonr]

You might need to package GN in void, I think (ew). See here, I think the env var is just GN.

[shizonic]

@ericonr Thanks! What should the content of the env var GN be? The path to the gn binary?

[shizonic]

Waiting for merge of #25703

[q66]

it's come to my attention that gn is unstable, so it probably doesn't make sense to have a separate package of it; i'd just fetch it as a second distfile in the deno template and build it as a part of it

[smorimoto]

The CIs should complete successfully, but the GitHub Actions runner is somehow hung and needs to be triggered again.

[smorimoto]

Oh disregard. It looks like it's still running.

[shizonic]

Oh disregard. It looks like it's still running.

Yes, build process needs terribly long...

[shizonic]

builds now fine on x86_64. Other archs aren't supported yet...

[smorimoto]

Checks have passed.

[shizonic]

Checks have passed.

Not at all: travis-ci still failes even if I don't understand why these checks are still present.

[smorimoto]

Well, I think we can ignore the result of Travis.

[shizonic]

Well, I think we can ignore the result of Travis.

Agree but guess it still won't get merged because it's only for x86_64 arch... :(

[shizonic]

Is there a chance to get this merged?

[q66]

only if it can do musl and/or other archs imo

[smorimoto]

​I think there is no reason why we cannot support all of them. (​In fact, I built and used Deno on aarch64 machines.)

[q66]

definitely not all of them, i just ran a ppc64le build out of curiosity and it fails on ring which seems to be a hard dependency and practically restricts the whole thing to x86_64 and possibly aarch64

[shizonic]

Okay, to do so I need help. I only get it building on x86_64 and AFAIK officially it's only supported on this too.

[astralchan]

Even if it's not officially supported, it's probably worth trying to build it as a target. As for how to test against other archs locally, xbps-src has an -a flag. You can ./xbps-src -a x86_64-musl pkg deno if you wanted to test, for example.

I just read the conversation, and, uhh. I wonder why not just use build_style=cargo? Does it not work? Here's the PKGBUILD from Arch linux.

[Chocimier]

You can ./xbps-src -a x86_64-musl pkg deno if you wanted to test, for example.

That's not what builders do. -a is for other processor. For other libc separate masterdir is better, see readme.

I wonder why not just use build_style=cargo? Does it not work?

Try and tell us.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.