Looking for a Maintainer for Ruby 2.2 and 2.3 releases

[Azolo]

From #344 (comment):

Unfortunately, I don't have the luxury of using RubyInstaller day-to-day anymore. So when there is a new release I have to make time to actually sit down and build it.

I've tried to pawn off the build process to VMs but there seems to be a problem where hypervisor environments don't get the same results as a regular Windows environment. I spent time on that rabbit hole until it exhausted me.

So at the moment, it takes about 1.5 hours to build, test, and package a version of Ruby. Then adding the quirks like making sure we have the correct version of Innoinstaller, getting HTMLHelp for the CHM, and the rdoc_chm workaround for building docs for Ruby 2.3. Most of my times is spent away from my PC these days and when something goes wrong the process just gets that much longer.

So while I sincerely enjoy doing this, but I'm unable to commit the time I used to or the time I want to make the project better because I don't use the project consistently anymore. There are tons of things that anyone can do to make the process better, but not without taking a deep dive into the project to understand the problems.

I'm getting the releases out when I can, but it's a time consuming process that I have to actually make time for these days.

Expanding on that, I feel like I'm doing an injustice to @luislavena and the rest of the community. But these releases are time consuming and taxing. Most of the time that I'm not building new releases is spent trying to automate this process or make this process easier on myself usually to no avail.

Until this need is met, I'll continue doing what I've been doing but as a result the releases will be on a delayed schedule. Especially the likely Christmas release of 2.4.0.

[sol-vin]

Hi,
Do you have a step by step guide or checklist on what you need to do to make a working version of Ruby for Windows? If you have some guidelines to follow I might be able to help you maintain.

[luislavena]

Hello @redcodefinal, thank you for your interest.

I don't believe there is an official guide for this, but will try to cover here the requisites and the steps involved in doing a release for each version of Ruby.

Bear with me on the length and also might not get all the details straight since been 2 years since last time I did one of these releases.

Requisites

In order to build the installers, you will require the following elements be installed on a clean (hopefully virus free) Windows 7+ computer:

• A working Ruby installation (guess will recommend use latest so dogfooding applies)
• Latest InnoSetup (one with unicode support version)
• HTMLHelp tool in order to produce the CHM files
• rdoc_chm gem installed and the matching rdoc version.
• Git without bash tools in the PATH (so cmd directory instead of bin one)
• curl binary be available to upload the resulting binaries to BinTray

Note: perhaps some of the points about the rdoc and rdoc_chm gem can be automated (by using Bundler and a Gemfile, just a thought)

Building an installer

In order to build a installer for an specific version, Ruby and it's dependencies must be fetched, compiled and linked.

Since RubyInstaller targets both 32bits (x86) and 64bits (x64) versions, different compilers needs to be used.

These version of the compilers are indicated in the DevKit version, and those needs to be used when building each version of Ruby.

Say you want to build the theoretical version of Ruby 2.3.9 in both 32 and 64 bits.

First, you will require to update the configuration files that define the version and update the URLs where it will grab the related package:

• https://github.com/oneclick/rubyinstaller/blob/master/config/ruby_installer.rb#L183
• https://github.com/oneclick/rubyinstaller/blob/master/config/ruby_installer.rb#L200

With all the requisites in place and the changes, you will now require to build Ruby for one of the compilers (say the 32bits one).

Since Ruby 2.3 uses GCC from mingw64 project, you will need to indicate this version when building:

> rake ruby23 DKVER=mingw64-32-4.7.2

This will fetch all the required source files, binaries and dependencies to setup the compiler (DevKit) and build that version of Ruby.

Next, is a good practice to confirm that the obtained build works and most of the tests pass, so you will invoke the check command (this runs the make check for that version of Ruby)

> rake ruby23:check

On each upgrade/release, you will notice that links to the results in the commits, like this one:

5e4b7a3

Now that you checked that it work, you will be building the installer package for that version:

> rake ruby23:package

Documentation using HTMLHelp and rdoc_chm will be generated and InnoSetup will be invoked to package the installer, which will be placed in the pkg folder.

Testing the installer

Is a good practice now that the installer was generated, do a clean installation to test that it works, that gems can be installed and that it doesn't blow up on first run 😄

Doing a release

Now is time to upload the binary packages (.7z and .exe files) to BinTray, which provides the binary downloads for RubyInstaller.

For this, the release:upload task is available, which requires the version to be released:

> rake release:upload[2.3.9]

Important: this requires both BINTRAY_USERNAME and BINTRAY_API_KEY environment variables be present. You can keep those in a local .bat file and run them when necessary, just avoid committing that file into the repository.

You can now build the same version using a different compiler, which will require you change the DevKit version. A good practice I had was trash the sandbox directory on every build.

Update the website and perform the announcement

With binaries in place, it is now time for you to update the website. As mentioned in other issues like #346, current website is an application (not an static website) so it involves manual updating.

---

My first recommendation will be clone the repository and take a look to the README file, which covers most of these points and provides some indication about code organization, tasks, etc.

Using above and the README, try to produce a local installer and test it out.

I guess that a good thing will be add this to the documentation and perhaps automate the other aspects mentioned above too, but getting your feet wet is a good start.

Let us know if you have questions.

Cheers.

[Azolo]

Here's where the fun part starts.

A working Ruby installation (guess will recommend use latest so dogfooding applies)

I think there's still a problem with Program Files redirection or something using 64-bit versions of Ruby. I remember fixing some things to only have other things pop up during the packaging task. So to be safe and so that I don't waste time, I just use a 32-bit Ruby version.

Latest InnoSetup (one with unicode support version)

The latest InnoSetup doesn't like the format of the internationalization files we have.
I'm using InnoSetup 5.4.2.

rdoc_chm gem installed and the matching rdoc version.

rdoc_chm depends on ~> 3.12 which comes out version 3.12.2. Version 3.12.2 has a problem parsing Ruby 2.3, so at the moment I'm building a patched rdoc based on @windwiny's patched rdoc branch.

[luislavena]

Thank you @Azolo for the updates! Indeed lot of fun! 😁

Based on the points you mention:

• Use Ruby 2.1.x as base for the installation
• Use InnoSetup 5.4.x for the installers
• Lock down specific version of RDoc (perhaps by using Gemfile and Bundler).

[zzak]

Hello,

Thank you for all of your hard work @Azolo and respect your decision and efforts to find sustainability.

I just wanted to add a thing about rdoc, and I'm happy to help find a way to fix rdoc_chm so it works on modern versions of Ruby with the latest rdoc (5.0.0 as of now).

[Azolo]

@zzak Thanks for the offer again! I'm going to shift the conversation over to vertiginous/rdoc_chm#7, where I added some more context.

[snarfmason]

Hey, I got here from a tweet of Luis' https://twitter.com/luislavena/status/806555329018339328

I have a fair bit of interest in Ruby for Windows and Open source on Windows. It's not my primary dev environment anymore, but I still care about it, and I'd like to help.

I've got no particular experience with building the ruby installer itself, but it's a thing I've used for actual production software, and I'd like to try to contribute back if it needs help.

[luislavena]

Thank you @snarfmason for showing interest. I believe the next step will be for you to confirm that details covered in this comment works on your end.

[snarfmason]

I'll find some time over the holidays to try a build, and post back.

[jonforums]

I suggest taking a hard look at the current build process for opportunities to simplify. I don't contribute to rubyinstaller anymore and only use ruby for (a) non-production uses, and (b) maintaining a cross-platform ruby env mgr (https://bitbucket.org/jonforums/uru). But I do think refining the current build recipes would ease maintainer load and enable more timely releases. For example, 1) I rewrote much of the Inno installer and find the Pascal syntax tiresome to support. Consider retiring the installer in favor of .7z archives and ruby-based installation scripts. This has serious downstream automation and end-user implications. 2) Scrap CHM and rdoc_chm. These aren't necessary as there are good online ruby doc sites. 3) Invest time in providing end-user documentation on how to build .7z archives. People can then easily build the ruby patch releases as they become available from core. While the current build recipes could use some work, they are really powerful. They'll download toolchains and dependencies. I added override (e.g. - *.rb files under override/ for many uses including using newer deps) and devkit selection (e.g. - dkver=mingw64-32-6.2.0) capabilities. Dependencies can be built with external knapsack recipes, artifacts on bintray, etc, etc... For example, using overrides I build patch releases similar to the following and never have to wait for a new rubyinstaller to be released. C:\Users\Jon\Documents\RubyDev\ri-git $ rake rubyXY make_opt=-j8 local=C:\Users\Jon\Documents\RubyDev\ruby-git openssl=1.1.0c libffi=3.2.1 libyaml=0.1.7 notk=1 rbreadline=0.5.3 dkver=mingw64-32-6.2.0 If rubyinstaller becomes overly complex, taking too much time for any maintainer to support, the project is going to stagnate and may lose relevance. Simplify, simplify, simplify. Jon

…

On 12/19/16, Jonathan Mason ***@***.***> wrote: I'll find some time over the holidays to try a build, and post back. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #348 (comment)

[MSP-Greg]

My compiling experience is limited to working with C#, and hence, not really applicable.

I've tried to update rubyinstaller to use the 6.2.0 compiler and the msys2 packages.

It does compile 2.33 and 2.40, both allow me build several gems (thin, eventmachine, nokogiri). But --

• Can't build curses or libxml-ruby
• Fails a few of the spec tests
• It doesn't generate a libmsvcrt-ruby###-static.a file

Never bothered with the installer or the chm (see https://msp-greg.github.io/)

1. I'd be happy to help, but I'm not sure what I could do.

2. It would be helpful if someone (@jonforums maybe?) could get a current version anywhere, as the current repo seems to have a mix of branches with msys, msys2, old knapsack site, etc.

$ rake rubyXY make_opt=-j8 local=C:\Users\Jon\Documents\RubyDev\ruby-git openssl=1.1.0c libffi=3.2.1 libyaml=0.1.7 notk=1 rbreadline=0.5.3 dkver=mingw64-32-6.2.0

3. Where can one get the openssl=1.1.0c package?

4. One issue that I've come across is doing an in-place upgrade of Ruby. IOW, I updated from 2.3.2 to 2.33. I wrote a bat file for that, but I could convert it to rake or whatever. Ever had a request for that?

[daniel-rikowski]

1. I rewrote much of the Inno installer and find the Pascal syntax tiresome to support. Consider retiring the installer in favor of .7z archives and ruby-based installation scripts. This has serious downstream automation and end-user implications.

I use InnoSetup and Pascal/Delphi on a regular basis, so if there's something to do in that specific area I would gladly help.
Perhaps that is better than recreating one of the essential parts of RubyInstaller.

Are there any pressing issues to solve? (After I quick glance the only installer related issue is #136 (MSI), but perhaps I overlooked something)

2. Scrap CHM and rdoc_chm.

I couldn't agree more. It is nice for offline use, but there are other ways for that specific use case.
Perhaps a separate Github project can be created, with a seperate maintainer (or none if that's the case)

3. Invest time in providing end-user documentation

I believe this is the most important step. Right now all that knowledge is scattered across the wiki, several issues and some Google groups discussions.
If it were clear what actually has to be done for a new release it might attract more helping hands. Perhaps the whole process can even be split in separate steps which can be performed by multiple individuals.

It would also help setting up a CI solution (#321) since the one setting it up needs to know what has to be done anyway.

[vais]

@daniel-rikowski

Scrap CHM and rdoc_chm.

I couldn't agree more.

I proposed the same thing a while back, and though I agree with you that dispensing with InnoSetup is going a bit too far, I think RubyInstaller is suffering from a bit of a scope creep problem.

Just think of all the things it's trying to do, from providing a full stack required to build Unix software on Windows, to educating the next generation of Rubyists on how to program, with books and offline documentation to boot.

Let me put it this way: there is no other solution out there on any other platform that attempts to do for Ruby what RubyInstaller is attempting to do for it on Windows. Yet if you ask in any public forum whether one should use Windows to program in Ruby, what will you hear? It's a shame, really...

[vais]

Anyway, I volunteer @avdi to be the maintainer of Ruby on Windows since I read his https://www.rubytapas.com/2016/12/14/ruby-code-on-windows/ article 😜 At least in my imaginary universe 🦄 🌈 🦋

[avdi]

You don't want that. I'm the worst maintainer ever, that's why I give away all my OSS projects to people who actually keep up with their email.

[snarfmason]

I haven't forgotten about you guys. I forgot that my house is house sitting some 4 month old kittens over Christmas and I've been distracted. I'm planning try a build on this on Friday. It's on my shortlist todo for early January.

[jonforums]

@MSP-Greg you'll likely need to build your own openssl 1.1.0c using something similar to https://github.com/jonforums/buildlets/blob/master/build_openssl.ps1#L35-L74 or the knapsack build recipe. That said, I'm running into an issue that 2.4.0 doesn't build ruby's openssl ext https://bugs.ruby-lang.org/issues/13080

@daniel-rikowski I'm not aware of anything currently broken with the Inno installer. A lot of hard work was put into it before me and by be, and the installer appears to be stable enough. That said, it's yet one more thing for a maintainer to have to install/learn/manage.

@vais while I think a .7z + ruby-based install script + doco would be fine even for noobs, scrapping the installer may be too much. There is nice branding, all-in-one-place ease-of-use, downstream use, etc that shouldn't be thrown away especially since there hasn't been any changes needed for awhile. It's my personal rant against the overuse of installers bleeding through.

@vais if by "full stack..to build Unix software" you're including the integrated build devkit, I disagree. One of the strengths of the current recipes is that someone can quickly download all the pieces needed to build ruby on windows and just do it. No need to first figure out how to install msys2+mingw64, then the library deps, etc. I've not looked into it in awhile, but I recall StrawberryPerl taking a stronger position on their devkit equivalent.

I'm making the survival argument. Make the hard call to pare down to the essentials so that it is much easier to maintain this project. Maintainer != prison time. When new maintainers can easily onboard, the probability dramatically increases for the sustainable delivery of timely, usable ruby-on-windows solutions. Solutions that ruby-core has failed to deliver for a number of years.

[vais]

@MSP-Greg don't get me wrong, I think the "full stack..to build Unix software" is absolutely the essential core of what RubyInstaller does. I.e. if all else had to go, this is the piece that would be left.

[vais]

@MSP-Greg just to be clear, what I think RubyInstaller should not try to do is popularize Ruby (for lack of a better word). That means the book, online help, related website content, etc, should probably be made available elsewhere and by someone else who is interested in working specifically on that. If someone wants the .chm file, there could be a project for that. This alone would take a painful step out of maintaining RubyInstaller if I understood @Azolo correctly. I think moving .chm help out to an independent project where it can be maintained at its own pace is a reasonable compromise.

[vais]

The other big problem is having to use a physical machine for builds. Quoting @Azolo:

I've tried to pawn off the build process to VMs but there seems to be a problem where hypervisor environments don't get the same results as a regular Windows environment. I spent time on that rabbit hole until it exhausted me.

Does anyone know what the problem is? Because I could see some kind benefactor (like AppVeyor, hint, hint) providing a VM for automated builds, but this apparently not even being possible for hard technical reasons is a big show stopper.

Needless to say that using known 3rd party servers to make builds is very important from a trust perspective. So this issue of not being able to use VMs for builds looks like an elephant in the room.

[MSP-Greg]

@vais

I'm sorry if I inferred that RubyInstaller should popularize Ruby, but I think that better support of the Windows OS could be a goal.

After all, the point has been made to give consideration to the needs of first time programmers (starting with Ruby), possibly without a 24/7 internet connection.

Regardless, I think RubyInstaller's purpose should be narrowed to only creating the installer, with hopefully an option for in place upgrades.

Your point about VM's or 'cloud based' automated builds is a very good one. The doc site I've started essentially requires one click to check all the repos for new commits, then updates all the doc files.

If a cloud based system could do automated builds of Ruby 'trunk' and 'stable', I think the Ruby team (and gem teams/authors) could give a lot more support to Windows...

[Azolo]

The test results between my local build system and a hypervised system seem to been different.

I get a lot of additional errors on a VM than on my local machine.

[jonforums]

As you guys are considering test results and potential CI opportunities, entice @luislavena to weigh in.

As I recall, Luis spent effort, time, and $$ to build a Jenkins-based solution. While this was generally good, it also highlighted a key project maintenance issue. From my pov, it appeared very difficult to get ruby-core to pay much attention to the test results and resolving some of the more tricky make test-all failures. Unless this has changed, solving these could take non-trivial amounts of rubyinstaller mainainter + contributor effort.

Consider declaring build and CI "success" as simply passing make test. Not perfect but may be pragmatically enough.

I think build automation could be a maintainer time saver. But since this project is a bolt-on that solves a deficiency in the current ruby-core project, what does automated testing really mean and how much value does it add? Are you trying to test the build recipes (low value), or are you attempting to take on testing responsibility for ruby-on-windows source plus all needed deps?

@luislavena's experiences rather than my memories should take precedence as Luis was the primary gauntlet runner on this one.

[snarfmason]

Okay, first attempt:

> rake ruby23 DKVER=mingw64-32-4.7.2

That seems to have worked, but for some reason I don't have a ruby23:check task.

PS D:\ruby\rubyinstaller> rake -T
rake book                      # Download and extract The Book of Ruby
rake clean                     # Remove any temporary products
rake clobber                   # Remove any generated file
rake default                   # Build Ruby 2.3
rake devkit                    # Build DevKit installer and/or archives
rake devkit:ls                 # List available DevKit flavors
rake release:digests[version]  # Get the md5 and sha256 digests and print t...
rake release:upload[version]   # Upload release files
rake ruby18                    # Compile Ruby 1.8.7-p374
rake ruby19                    # Compile Ruby 1.9.3-p551
rake ruby20                    # Compile Ruby 2.0.0-p648
rake ruby21                    # Compile Ruby 2.1.9
rake ruby22                    # Compile Ruby 2.2.6
rake ruby23                    # Compile Ruby 2.3.3
rake ruby23:docs               # build docs for ruby23
rake ruby23:install            # install rubyinstaller-2.3.3.exe
rake ruby23:package            # generate packages for ruby 2.3.3
rake ruby23:package:archive    # generate ruby-2.3.3-i386-mingw32.7z
rake ruby23:package:docs       # generate ruby-2.3.3-doc-chm.7z
rake ruby23:package:installer  # generate rubyinstaller-2.3.3.exe
rake ruby23:redocs             # rebuild docs for ruby23
rake ruby23:repackage          # rebuild rubyinstaller-2.3.3.exe
PS D:\ruby\rubyinstaller>

Any thoughts on why that task might not exist?

[snarfmason]

Moving on, ruby23:package does exist. So lets run it. Build seemed to work.

I get:

PS D:\ruby\rubyinstaller> rake ruby23:package
cd sandbox/ruby_2_3
Parsing sources...
100% [89/89]  vsnprintf.c
rake aborted!
NoMethodError: undefined method `<<' for nil:NilClass
D:/ruby/rubyinstaller/recipes/tools/docs.rake:64:in `block (4 levels) in <top (required)>'
D:/ruby/rubyinstaller/recipes/tools/docs.rake:52:in `block (3 levels) in <top (required)>'
Tasks: TOP => ruby23:package => ruby23:package:installer => pkg/rubyinstaller-2.3.3.exe => ruby23:docs => sandbox/doc/ru
by23/ruby23.chm => D:/ruby/rubyinstaller/sandbox/doc/ruby23/ruby23-core.chm
(See full trace by running task with --trace)

Looking over @Azolo's notes here, I just realized that I have InnoSetup 5.5.9, not 5.4.2 installed. Does that error seem consistent there?

I did do this part:

rdoc_chm depends on ~> 3.12 which comes out version 3.12.2. Version 3.12.2 has a problem parsing Ruby 2.3, so at the moment I'm building a patched rdoc based on @windwiny's patched rdoc branch.

[snarfmason]

I'll try again with 5.4.2, but I have a family thing I have to go deal with now.

[luislavena]

Hello folks,

I've read the conversation but would like to take a proper time to respond to most of the points in detail.

Please bear with me a few days as I'm travelling right now.

Thank you.

[MSP-Greg]

I've heard mention that test-all can yield 'odd' or bad results, but I haven't seen mention of what the results were.

I hacked together a version from a few branches, with 6.2.0 compiler. Using Ruby trunk, the tests from appveyor.yml pass (excepting KNOWNBUGS.rb), along with a regular make test:

make -l "TESTOPTS=-v -q" btest
make -l "TESTOPTS=-v -q" test-basic
make test

Running --

make -l "TESTOPTS=-v -q" test-all > "\test-all_25.txt"

Produced --

16981 tests, 4987884 assertions, 15 failures, 2 errors, 149 skips
ruby -v: ruby 2.5.0dev (2017-01-06 trunk 57274) [i386-mingw32]

For test-all, I needed to comment out the highlighted lines in test/ruby/test_enum.rb, otherwise I got a segmentation fault. Two tests, both involve callcc.

Also, looking at the error messages, some could be caused by my security settings or the fact that all my git repos (and the build) are on D:, but my system files (and TEMP/TMP folder) are on C:.

Shortened version of results are at GitHub Gist

Anyway, are the quantities listed (15 failures, 2 errors) a reasonable amount of failures (three failures are bugs - 1, 6, 15), or is the threshold 0 and 0?

Reminder, I don't write c or c++. I do have three things re RubyInstaller:

1. Ruby downloads from ruby-lang.org include 'bundled gems'. If you're using a local repo, they need to be added after the build. I haven't checked to see if I added them to the 'sandbox', would they be added to a package and/or installer...

2. This GitHub account has knap-build, and @jonforums has some dependency recipes. Wouldn't it be possible to build them into (or in) RubyInstaller using a Ruby/rake solution and remove the need for packages at bintray.com or whatever? I tried using sourceforge packages, but first attempt failed...

3. This is general, but (for instance), does the DevKit include all packages needed to install the current version of Rails? I got nokogiri to install, but I needed to configure some path information for it to build. I don't know enough about building 'extension' gems to know if that can be simplified...

Really, I'll wait until all of you that are familiar with compiling (and c) weigh in...

[jonforums]

1. I clone the ruby GH mirror https://github.com/ruby/ruby (creating local tracking branches for ruby_2_3, ruby_2_4, etc) rather than downloading archives from ruby-lang.org. I do nothing special to get 'bundled gems'. My only complaint is that creation of new branches (e.g. - ruby_2_4) on the GH mirror often lags the SVN branch. Trivial.

2. I consider the current dependency setup of knapsack-recipes and bintray distribution of pre-compiled binary deps to be far superior to having to re-compile every dep every time you build ruby from source. Do not switch over to using my buildlets recipes for some of the deps. Untimely support awaits down that path. Note that the binary deps are downloaded just once and cached in downloads/. A minor irritation with the current recipes is that downloading the SF-based packages sometimes gives 0-byte files that must be deleted and retried. Perhaps a recipe update to use SHA1 verification for the downloads?

3. DevKit is a minimally complete build toolchain with the main goals of (a) building ruby from source, and (b) building native gems from source. DevKit is automatically deployed to sandbox/devkit when building ruby. One can also build a standalone version (e.g. - rake devkit sfx=1 dkver=...), install it locally (e.g. - extract to C:\DevKit-x32-6.2.0 or another non-spacey dir), and install it into your rubies (e.g. - cd C:\DevKit & ruby dk.rb init & vim config.yml & ruby dk.rb review & ruby dk.rb install). Once installed, you can build most native gems as long as the gem maintainer has added support or hasn't borked things. Some of the better maintained native gems are oj, nokogiri, mysql2, psych, redcarpet, and sqlite3. You may have to use a few tweaks similar to gem i nokogiri --platform=ruby or gem i mysql2 -- --with-mysql-dir=C:/devlibs/mysql-c/x86/6.1.6 or gem i sqlite3 -- --with-sqlite3-dir=C:/devlibs/sqlite3/x86/3.16.2 to get the native gems to build. I don't use rails so I can't comment on any windows install issues beyond the deps I've mentioned.

[MSP-Greg]

@jonforums

I do nothing special to get 'bundled gems'

So just to be clear, in your 'sandbox', when building 'local', the gems listed in bundled_gems are installed? I must have missed some code...

Re the Git ruby clone, the v2_4_0 tag existed several days before the 'stable' Ruby_2_4 branch.

knapsack-recipes and bintray distribution

I don't know how many people are using RubyInstaller vs making use of the downloads at rubyinstaller.org. I thought if the dependency generation code was in RubyInstaller, and it also cached the results, it would possibly result in less work for maintainers. I don't know how often the recipes change from version to version, as opposed to just the vers, url, and hash.

I don't use rails

At present, neither do I. It was just an example, and I recall that it has a lot of dependencies. I installed it to double check the documentation of it. I've been mostly working on ruby builds, I'll try the DevKit again with some of my 'extension' gems. I never did get libxml-ruby to install...

Lastly, thanks for the response, and is the failure / error counts I'm getting in the ballpark? I thought it odd that the AppVeyer script that the Ruby team uses does not do a test-all check...

[jonforums]

@MSP-Greg oh I have been away from ruby for awhile...I thought you meant io-console, psych, etc as the bundled gems. I also don't get the listed gems when building from source.

re: deps, builds are faster when using cached binary ruby dep (e.g. - libyaml) downloads rather than building all from source everytime. Having the dep build infrastructure separate doesn't really put extra work on a maintainer as the updates are often easy. Luis did a nice job making usable dep build recipes.

Your test-all error counts seem in the ballpark. Although, the last time I ran it, my win8.1 x64 system segfaulted. I've lost interest and treat test-all like being north of the wall with ruby-core dropping failing untested-on-windows zombie code commits...or gremlins with my system.

[larskanis]

Hi all,

I'm using RubyInstaller since 13 years now, so that I want to say a big thank you to Luis and all others!

However the current RubyInstaller is based on the outdated MSYS1, so that it needs to switch to a newer toolchain. Also the DevKit is too limited, since it doesn't provide any libraries to link to.

Therefore and because of this "looking for a maintainer" call, if started a new version of RubyInstaller based on MSYS2. I would be happy for some feedback!

https://github.com/larskanis/rubyinstaller2

[snarfmason]

Hi guys,

Sorry I haven't written in a while. I'm still very interested in helping with this project, but I feel I'm a little out of my depth at the moment.

I've done Java, C#, and Ruby development - mainly using this Ruby Installer - on Windows. But my experience with the Unix-like toolsets in Windows is minimal. I've installed cygwin a time or two, but never really used it. I've always been a multi-platform guy, and I just do Unix-type things on Ubuntu or MacOS (I have machines running all 3 at the moment). I don't even really know what MSYS2 is.

I'm going to spend some time getting up to speed on the tools here, and I still hope to contribute to Ruby Installer in the future, but right now I don't think I'd be good at taking on partial maintainer duties to get releases out more quickly.

cheers,
Jon

[snarfmason]

@luislavena (and @Azolo) do you guys agree that a new MSYS2 based branch would be the way forward for this? Or should I focus learning on the existing MSYS1 codebase?

[sroller]

@snarfmason You should definitively go with MSYS2! It's working great for me. It's very close to the Linux experience. It's also way less intrusive than Cygwin (IMHO). Give it a try. @larskanis wrote a very good introduction in the README.md for the Rubyinstaller2 project. (https://github.com/larskanis/rubyinstaller2)

[luislavena]

@snarfmason I haven't looked entirely the work done by Lars, but knowing his past contributions to RubyInstaller and many other projects, I wouldn't be surprised if is a great alternative to the current build process and potentially a longer term solution than current RubyInstaller+DevKit.

However, said that, there is nothing bad on reading and understanding current process, specially since new one also involves InnoSetup, MSYS (new version, but still have sh and other stuff)

Last but not least, I believe there is value releasing at least the new patchlevels with current setup before switching to MSYS2: no test for x86 done yet, installers and installations might require more testing and documentation might be needed.

Then focus the new installer only on a single version of Ruby (say 2.4.0) and continue from there.

Of course, just my comments without having looked at the code or tried anything in detail (still travelling and with lot of work).

Cheers.

[vnluc]

Hi, is there any of you sucessfully build ruby 2.4.1? the rubyinstaller release now still at 2.3 and I want to try new version. I download 2.4.1 and try to compile and after steps:

make -> ok
make test -> ok
make install : Some error happen, extensions gdb, gdbm, zlib are done able to install.

Is there anyone can help or interested in discussion to form a group that will build ruby?

[luislavena]

Please see https://github.com/oneclick/rubyinstaller2/ Sorry for top posting. Sent from mobile.

…

On Apr 10, 2017 23:18, "Luc Vu" ***@***.***> wrote: Hi, is there any of you sucessfully build ruby 2.4.1? the rubyinstaller release now still at 2.3 and I want to try new version. I download 2.4.1 and try to compile and after steps: make -> ok make test -> ok make install : Some error happen, extensions gdb, gdbm, zlib are done able to install. Is there anyone can help or interested in discussion to form a group that will build ruby? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#348 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQVmoIbwzxNNQCAs4jBqNvoX1Jcvdnks5ruuLWgaJpZM4LGFlU> .

[vnluc]

Thank you, that is what I am looking. Hope we can have some post to rubyinstaller so other can know where to download? Is the source code attached must be modified to build or just from ruby-lang page?

[luislavena]

Please see this thread and specially the latest comments: #352 (comment) Sorry for top posting. Sent from mobile.

…

On Apr 11, 2017 01:47, "Luc Vu" ***@***.***> wrote: Thank you, that is what I am looking. Hope we can have some post to rubyinstaller so other can know where to download? Is the source code attached must be modified to build or just from ruby-lang page? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#348 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQVgVXBpb6x1jBTABXIwbsxbj9O3HRks5ruwXZgaJpZM4LGFlU> .

[vnluc]

Thank you, I will try to build again.