First io.js release build plan / discussion

[rvagg]

Things we need to make a first official io.js release in mid January (this is top of my head, please contribute if you see something that I don't have).

Target

At a minimum we need to release a solid source tarball that's tested, tagged and good to compile and use as a fully compatible version of joyent/node, v0.12-worthy. Version will be 1.0.0, perhaps with an -alpha.x suffix, that'll be up to the TC.

Binaries would be good but may be practical only for Linux at this stage in lieu of signing keys.

Need

• OSX 10.10 and 10.9 hooked up to CI (Voxer has machines ready for us to hook up, we just need to do some VM work) - @ryanstevens is responsible for this, @rvagg to work with him to make this happen
• CentOS5 hooked up to CI to ensure RHEL5-level compatibility (yak shaving abounds here) - @rvagg responsible for this, I believe I have a good strategy after shaving the RHEL6 yak with C++11

Nice but not essential

• OSX 10.8 hooked up to CI
• At least one version of FreeBSD hooked up to CI (Voxer has the hardware on offer for this)
• A Solaris-ish machine hooked up to CI, what are the chances of Joyent offering a box?
• Signing keys for io.js org so we can release proper Mac and Windows binaries
• Linux releases via deb.nodesource.com and rpm.nodesource.com (or similar hosts if not the same hosts) - @rvagg to work with @chrislea to make this happen

Decisions

• Do we mark Linux packages as "conflicting" with "nodejs" or set up an "alternatives" style system? (I know it's doable on Debian-based systems but am vague on RHEL/Fedora-based systems here)
• Exact version, up to TC, not an urgent decision
• How are tarballs named and hosted, straight from GitHub?

[yorkie]

How about after someone had ran make test, the test runtime will send back the result and testing machine information to our build system, it will help us collect more unexpected failure cases as possible, I'm unsure this is the right place to post this, just figure this out after reading @rvagg's article, thanks.

[rvagg]

@yorkie, check out https://jenkins-node-forward.nodesource.com and drill down in to "Console Output", it's all there. We still have a failure on ARM and intermittent failures on others, those need to be cleaned up so feel free to dig around in https://jenkins-node-forward.nodesource.com/job/iojs+v0.12+multi/ if you want to contribute to making the test suite more solid.

[yorkie]

Okay, thanks for the detailed guidance for me, i'm busy recently but i'm always interested in the build project for node(or iojs, haha), i will do check given links by you and wanna contribute to this upcoming project once i'm free, 🍒

[bnoordhuis]

Do we mark Linux packages as "conflicting" with "nodejs" or set up an "alternatives" style system? (I know it's doable on Debian-based systems but am vague on RHEL/Fedora-based systems here)

You can put a Conflicts: nodejs header in the .spec file. There's an additional safeguard in that rpm/yum won't let you install a package that overwrites files from an installed package (unless you force it to, of course.)

[bnoordhuis]

How are tarballs named and hosted, straight from GitHub?

Good question. I would suggest mirroring what nodejs.org currently does and host them at a stable and predictable URL, like http://iojs.org/dist/v1.2.3/iojs-v1.2.3.tar.gz, but that would require checking in the tarballs because iojs.org is currently a GH pages website.

[davidbanham]

dist.iojs.org/etc then?

It would make sense to keep big binary assets like that separate from the
website content.
On 5 Dec 2014 08:22, "Ben Noordhuis" [email protected] wrote:

How are tarballs named and hosted, straight from GitHub?

Good question. I would suggest mirroring what nodejs.org currently does
and host them at a stable and predictable URL, like
http://iojs.org/dist/v1.2.3/iojs-v1.2.3.tar.gz, but that would require
checking in the tarballs because iojs.org is currently a GH pages website.

—
Reply to this email directly or view it on GitHub
#18 (comment).

[indexzero]

👍 to dist.iojs.org as a separate repo backed by Github pages

[davidbanham]

Agree. Back it with github early on and we've always got the flexibility to
switch it out to S3+CloudFlare or similar later on.
On 5 Dec 2014 08:45, "Charlie Robbins" [email protected] wrote:

[image: 👍] to dist.iojs.org as a separate repo backed by Github pages

—
Reply to this email directly or view it on GitHub
#18 (comment).

[ghostbar]

@rvagg @chrislea I can help on the Debian releases, making up a reprepro on deb and helping on the infrastructure for it. Plus, I could be pushing the debian packages to the debian archive (I'm a debian developer)

[chrislea]

@ghostbar Thanks for the offer! We already have a build box with reprepro set up that we're using. And I don't think we're allowed to push the packages as they are into the real Debian archive because we statically link in basically everything (v8, cares, etc), which as I understand it is against the Debian packaging guidelines. But, if I'm wrong then I'm sure @rvagg and others would be interested in talking about official Debian support. So if that's the case please let us know.

[ghostbar]

@chrislea Ok yes, that's against the rules for getting into the archive and I understand the reasoning behind this as in: just download one .deb, install it and you're done.

Anyway, if it's going into a reprepro anyway, I don't see why we couldn't even make the separate v8 packages without adding too much issues into it. We could use the base as of how it's handled currently the v8 and nodejs packages on debian.

Let me know and I could work on it next weekend.

[stryju]

Hey guys!

Any progress re: Debian packages?

[chrislea]

We are working on them. Support for the current Debian stable (wheezy) is a godawful PITA because the compiler it ships with is too old to build iojs. And backporting a newer compiler brings its own headaches. So once we have that planned / sorted out we'll get packages built.

[stryju]

sweet! thanks for taking the time to reply :-)

[ianare]

Hi all, any plans for a CentOS 7 packages?

I would think this would be easier than 5/6 due to the newer compiler and systemd...
There are node packages also which could be used for inspiration.

In any case, excited about all the hard work done on this project, keep it up!

[Fishrock123]

@rvagg looks like some of this is done? :)

[stryju]

can we get a small update on what was achieved from the list?

[rvagg]

Sorry! I've ticked some things off, but here's things that weren't achieved:

• OS X CI machines are only 10.10. I have a 10.9 image I might ship over to the CI machines but I have no way of getting hold of a 10.8. If anyone has ideas on how to get installation media for a virtual machine for 10.9 or 10.8 that would be greatly appreciated. Apple make this way too hard (and I don't understand why nerds embrace them so much!)
• Linux releases are not being made available as .deb or .rpm yet. @chrislea is working on this but it's a non-trivial task. Expect news on this very soon though.
• Solaris-variant is not being tested in any way and this doesn't appear to be missed. From memory there has only been one Solaris-related issue on the io.js issue tracker and that was simply about DTrace on an Illumos variant, by @No9.

[stryju]

thanks for taking the time to reply, @rvagg! 🍻

---

would be great to have it as a summary @ top - WDYT?

[No9]

@rvagg Initial thread was DTrace compiling on FreeBSD

Problem I have is that my running illumOS instances are all 4.6.4 GCC and so iojs wouldn't build.

I can take the razor to that hirsuit mammal if there is we want to provide a SmartOS build but I don't know how much bandwidth I would need to give to integrate with CI

[rvagg]

@No9 it's not really a technical problem but a resourcing one, we don't have the ability to provision solaris-variant machines at the moment, none of the providers we're working with have that capability and nobody has expressed an interest in providing it. I'm not too fussed at this point, I don't think it's in our target audience at this stage.

[No9]

@rvagg ok ill leave this for now then.
If someone shows up with the need and we need to dig in you know where I am.

[jgrund]

Hi, Is there still an io.js rpm in the works?

[rvagg]

@jgrund yes, over @ https://github.com/nodesource/distributions

we're having some complications in getting everything up and working properly across all our supported platforms given the new complexity in the versions we're supporting but we're now in the process of throwing more people at this.

[stryju]

thanks for the update @rvagg

[StefanoBalocco]

Any news about a (maybe official) debian (jessie) package?

[ripper2hl]

iojs.rpm ? D: