also if I might ask, why does this even exist https://github.com/rvagg/rpi-newer-crosstools ?
Seems like the gcc-8 available from ubuntu apt repo should work just fine (like this PR uses) and doesn't have the limitation of not being compatible with buster/glibc 2.27

@richardlau let's get this merged. It is inline with all of the other recipes

I am trying to do this but the lack of inclusion makes it difficult:

These builds are made available for the convenience of their user community but those communities are expected to assist in their maintenance.

My primary objection here is that these names are the same as official release names - linux-arm64 and linux-armv7l are already a thing.

easy enough change.

You seem to be wanting something specific out of these, is it the particular glibc version you're interested in? Perhaps you should append glibc-227 to the end of the names.

I considered this though the armv6l variants didn't have that so I didn't put it here.

Even then it's very specific to a single distro - which is why we tend to reach back further to an EL version, like 2.17 which was with EL7, or 2.28 which was with EL8. Although I do recall the pain of being on 18.04 with everything coming out being built with 2.28 .. kind of an annoying version of Ubuntu. Perhaps you could see if it's possible to use 2.17 first, like the existing glibc-217 recipe; if that's at all possible then we'd have better cross-distro compatibility.

EL7 does not have gcc/g++ cross compilers for anything other than gcc 4.6. These armv7l and aarch64 builds would also be for lower libstdc++ requirements compared to the official builds, not just glibc. The jank custom armv7l cross compilers used by the official nodejs produce binaries not compatible with general distros that have a combination of glibc 2.28/libstdc 6.0.25 (like debian buster).

linux-armv7l | Cross-compiled on RHEL 8 x64 with custom GCC toolchain [7]
[7] Binaries produced on these systems are compatible with glibc >= 2.28 and libstdc++ >= 6.0.28 (GLIBCXX_3.4.28). These are available on distributions natively supporting GCC 9.3 or higher, such as Debian 11, Ubuntu 20.04. 

But one reason to just reject these entirely is that launchpad.net might be a better place to do these, then you'd be able to do the full ppa setup and we wouldn't be stuck trying to maintain these into the future.

To not be the unique one out of the bunch I think it should be here with all the other unofficial builds

But one reason to just reject these entirely is that launchpad.net might be a better place to do these, then you'd be able to do the full ppa setup and we wouldn't be stuck trying to maintain these into the future.

also another comment on this. in order for that to be viable this needs to be resolved: nodesource/distributions#1491
@riosje, your fellow nodejs developer @rvagg would also like that you open source the buildscripts

Heh, don't rope me back in to nodesource/distributions (note that I started that project; been there, done that.)

nodejs/unofficial-builds is "unofficial" because it's low-effort and low-input. There's basically me and a fraction of other people who pay attention here, and it's run off a single server. I'm not really interested in bloating the load, either people or compute wise. The fact that what you want can be easily achieved on launchpad is a good argument for doing it there. One of the primary reasons for the existence of Launchpad is to service the Ubuntu ecosystem. In fact, nodesource/distributions had its genesis in Chris Lea's original Node.js PPA, but we wanted to make it more generic for different distros but couldn't achieve that in Launchpad. nodejs/unofficial-builds is a place to house builds that can't be justified as official builds (e.g. armv6l and x86 both fell out of the official list, but landed here because there's still people interested in attempting to maintain them and consume them as long as that's possible); but if there's a better place to do it, then it should be done there.

How about you give a Launchpad build a go, then you might either find (a) unsurmountable problems (I doubt it) and (b) that you can do a lot more, and do it without being gated by others (like me).

The fact that what you want can be easily achieved on launchpad is a good argument for doing it there.

what I want is something that fixes nodjs on ubuntu bionic and debian buster and centOS 8 armhf and arm64 (each of them can't be used on official nodejs due to GLIBC and/or libstdc++ requirements already outligned above). those are already solved by this repository for x86_64 so I don't see why this shouldn't be merged here.

One of the primary reasons for the existence of Launchpad is to service the Ubuntu ecosystem. In fact, nodesource/distributions had its genesis in Chris Lea's original Node.js PPA, but we wanted to make it more generic for different distros but couldn't achieve that in Launchpad. nodejs/unofficial-builds is a place to house builds that can't be justified as official builds (e.g. armv6l and x86 both fell out of the official list, but landed here because there's still people interested in attempting to maintain them and consume them as long as that's possible); but if there's a better place to do it, then it should be done there.

see above, not here for just ubuntu

How about you give a Launchpad build a go, then you might either find (a) unsurmountable problems (I doubt it) and (b) that you can do a lot more, and do it without being gated by others (like me).

already axed due to this not being fullfilled nodesource/distributions#1491 . I am not interested reverse engineering the buildscript and packaging process to produce fully compatible nodesource debs. In addition, any ppa that I make would have multiple magnitudes of lower impact than it existing in this repository which is well known and already used by the community.

I again request that this be merged.
Please refer to your README:

This project is in need of a community of maintainers to keep it viable. If you would like to join, please submit pull requests to improve the work here.

These builds are made available for the convenience of their user community but those communities are expected to assist in their maintenance.

I am trying to do this but it seems to me that you actually want the opposite of what you ask for.

two more weeks have past
please merge

Any change we can get this merged?

Sorry, I'm -1 on this for the reasons discussed above, so unless someone else who helps manage unofficial-builds wants to accept the maintenance burden this isn't going anywhere. Launchpad is a great option for this.

If it helps, we could also update the README and the index.html to have a catalog of links to other "unofficial builds", such as someone's Launchpad site that does this.

I skimmed conversation history, but what exactly would have to be changed in this PR to get it accepted here? Seems pretty straightforward.

I'm still a -1, this is ~trivial to do on launchpad, it's what launchpad exists for in fact. Do it there and we can put a link to it on the README and on https://unofficial-builds.nodejs.org/; that might be a good precedent to set in fact, list alternative and "unofficial" builds from the ecosystem.

I'm still a -1, this is ~trivial to do on launchpad, it's what launchpad exists for in fact. Do it there and we can put a link to it on the README and on https://unofficial-builds.nodejs.org/; that might be a good precedent to set in fact, list alternative and "unofficial" builds from the ecosystem.

sigh... read again the last part here #91 (comment) . I won't state it again.