I think this should be a separate gem, but we can agree on the design/implementation here.

Since there are some dependencies (fpm, rpmbuild) they would also have to be added to the stack image.

I'm not sure a separate gem is worth the effort tbh. There aren't great ways in the MRI Rakefile to detect if a mrbgem is installed and then to pull it in. We could hack stuff and then require stuff in there, but that seems SUPER hacky.

Let's see if it's possible to build the packaging service we need before worry about doing any hacks.

This seems like we can do rpm and deb, what about the other packages: dmg and windows?

I think it should be all or nothing.

Sorry for the delay (holidays :p)

Since there are some dependencies (fpm, rpmbuild) they would also have to be added to the stack image.

done there toch/mruby-cli-docker@8d2d65d but as you refer into the Dockerfile to a public image (hone/mruby-cli), toch/mruby-cli-docker should be merged into it, right?

(zzak) I think this should be a separate gem, but we can agree on the design/implementation here.
(hone) I'm not sure a separate gem is worth the effort tbh. There aren't great ways in the MRI Rakefile to detect if a mrbgem is installed and then to pull it in. We could hack stuff and then require stuff in there, but that seems SUPER hacky.

I've just pushed my solution:

• https://github.com/toch/mruby-cli-distpackage
• toch@e94ec03

What do you think?

This seems like we can do rpm and deb, what about the other packages: dmg and windows?
I think it should be all or nothing.

fpm can also generate osx package, I'll git it a try.
for msi, I'll try https://wiki.gnome.org/msitools

Sounds good to me, let's try to get osx and msi working before we ship this.

A quick update about my investigation.

• msitools do the job, but there are no package for 14.04, I'm struggling with compilation of the package,
• fpm won't work to build a osx package as it requires pkgbuild tool which is a osx tool.

For osx, I have two options, build a simple dmg package, or a brew package. It seems that dmg is more ubiquitous, but brew easier. what is your preference?

Perhaps pkgbuild is something we can get out of osxcross?

Myself, I'd prefer to build a package for OSX as that is more easily distributable (I don't also need homebrew installed). Although, I don't see why we can't offer both as ultimately all of this should be configurable [which] packages we actually output.

Where are you stuck on msitools? I found a package for Wily Werewolf (whatever that is), so maybe we can just backport that? https://launchpad.net/ubuntu/+source/msitools

Perhaps pkgbuild is something we can get out of osxcross?

I do not know, I have to check.
I found that discussion about building .dmg on the osxcross. It refers two other tools (https://pypi.python.org/pypi/dmgbuild and https://github.com/LinusU/node-appdmg)

Myself, I'd prefer to build a package for OSX as that is more easily distributable (I don't also need homebrew installed). Although, I don't see why we can't offer both as ultimately all of this should be configurable [which] packages we actually output.

👍 let's start first with dmg which is the most ubiquitous.

Where are you stuck on msitools? I found a package for Wily Werewolf (whatever that is), so maybe we can just backport that? https://launchpad.net/ubuntu/+source/msitools

With the upstream, configure failed even if all the dependencies were provided.
With the ubuntu package 15.10, I can go farther but compilation fails with VALAC with the following error:

error: Package `config' not found in specified Vala API directories or GObject-Introspection GIR directories

I'll try first with the one you provided me before digging more the Vala error.

Thanks a lot for your pointers.

I found that discussion about building .dmg on the osxcross. It refers two other tools (https://pypi.python.org/pypi/dmgbuild and https://github.com/LinusU/node-appdmg)

I guess it doesn't really matter which tools we use, so long as it works.

With the ubuntu package 15.10, I can go farther but compilation fails with VALAC with the following error:

It looks like that msitools is just a meta package, maybe try finding the equivalent in the 14.04 repos, otherwise installing the newer packages manually until we find which one breaks.

quick update. I've managed to install msitools into our docker and started to build msi package.

@zzak
I've updated the gems mruby-cli-distpackage. I can now generate msi package that embeds the exe file mruby-cli.exe. \o/

I still need to try it on a real windows machine. Then, I'll work on dmg package.

I just tried the x86_64 msi package on a windows 8. It works! (I can install and uninstall it, and I can run mruby-cli)

I cannot easily access a win 32 install. Would you have one?

Woot!

I cannot easily access a win 32 install. Would you have one?

I don't but would compatibility mode work?

I don't but would compatibility mode work?

I've tried to install the 32 msi package on the windows 8 machine and got a cryptic message informing me I can only this for package already installed ?!

@toch Can you try installing the 32bit version of Windows 10?
https://www.microsoft.com/en-us/software-download/windows10ISO

This link is also valid for 24 hours.

Just downloaded it, I'll try it now.

I've just pushed the dmg packaging. My OSX VM crashes I do not know why. Could you try the dmg packages?

Sure! I will try out the OSX packages <3

On Monday, August 24, 2015, Christophe Philemotte notifications@github.com
wrote:

Just downloaded it, I'll try it now.

I've just pushed the dmg packaging
https://github.com/toch/mruby-cli-distpackage/blob/master/tasks/package.rake#L141.
My OSX VM crashes I do not know why. Could you try the dmg packages?

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

It would be great if we can automatically test the packages on respective platforms. Even after some google-fu, I do not find any hosted CI service for win32, win64 (maybe AppVeyor), OSx32, or OSx64. Do you know one or another doing that?

Found the problem for the i686 msi package, fixed. it works now.

If the container will run on Windows we can use that to test the compiled
binary.

For OS X we should be able to use Travis still, I think.

On Monday, August 24, 2015, Christophe Philemotte notifications@github.com
wrote:

Found the problem for the i686 msi package, fixed. it works now.

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

I've fixed my VirtualBox setup, OSX VM works again. I've tried the dmg packages. It nearly works:

• dmg is correctly mounted OK
• the bundle .app is recognized and can be moved to the Applications folder OK
• the execution permissions are not kept, I had to set it again on the binary KO

For both dmg and msi packages, the binary is not available in the PATH. Should it be?

It would be nice to get CI hooked up for this, but I realize that's probably a little out of scope for this feature.

the execution permissions are not kept, I had to set it again on the binary KO

Perhaps this is a bug with the packager?

How did you transfer the binary? (I know google drive will remove the executable bit)

For both dmg and msi packages, the binary is not available in the PATH. Should it be?

For most installers, don't you have to put the thing someplace that already exists in your path?
Like the users Application directory, or Program Files on windows?

@zzak here an update:

• for dmg,
  • permission problem is fixed
  • for the path, after having tried several options, I've added a simple setup bash script that the user can run to add mruby-cli to his environment PATH.
• for msi, msitools doesn't support the Environment property, I've ended to find a way which consists in using BATCH command called by a CustomAction ... when it's called, I can't make it work. I'll try to find someone who can help.

The last changes are available in https://github.com/toch/mruby-cli-distpackage/blob/master/tasks/package.rake

@toch Does dmg work then?

I can help test osx and 64bit windows, but I'd have to reinstall for 32bit (I think).

@zzak yes, dmg works.

msi works also. I'm just looking for a way to set the environment path. It's a nice to have to help the user to set it. A simpler way to do that is to provide the instruction to set the env path.

@zzak I've rebased the PR onto #13.

Quick recap, in order to testdocker-compose run package you need the following:

• https://github.com/toch/mruby-cli-docker
• https://github.com/toch/mruby-cli-distpackage

Also found this blog post, that might be interesting:
http://blog.codeship.com/using-docker-build-debian-packages/

So here's the output I see:

Writing releases/v0.0.2/mruby-cli-0.0.2-x86_64-pc-linux-gnu.tgz
Writing releases/v0.0.2/mruby-cli-0.0.2-i686-pc-linux-gnu.tgz
Writing releases/v0.0.2/mruby-cli-0.0.2-x86_64-apple-darwin14.tgz
Writing releases/v0.0.2/mruby-cli-0.0.2-i386-apple-darwin14.tgz
Writing releases/v0.0.2/mruby-cli-0.0.2-x86_64-w64-mingw32.tgz
Writing releases/v0.0.2/mruby-cli-0.0.2-i686-w64-mingw32.tgz
Writing releases/v0.0.2/mruby-cli-0.0.2.tgz
Packaging deb for x86_64 into packages/v0.0.2
Packaging deb for i686 into packages/v0.0.2
Packaging rpm for x86_64 into packages/v0.0.2
Packaging rpm for i686 into packages/v0.0.2
Packaging msi for x86_64 into packages/v0.0.2

(wixl:1742): wixl-CRITICAL **: wixl_msi_table_custom_action_add: assertion 'Source != NULL' failed

(wixl:1742): wixl-CRITICAL **: wixl_msi_summary_info_set_author: assertion 'value != NULL' failed

(wixl:1742): wixl-CRITICAL **: wixl_msi_table_property_add: assertion 'value != NULL' failed

** (wixl:1742): CRITICAL **: wixl_add_braces: assertion 'str != NULL' failed

(wixl:1742): wixl-CRITICAL **: wixl_msi_table_property_add: assertion 'value != NULL' failed
Packaging msi for i686 into packages/v0.0.2

(wixl:1748): wixl-CRITICAL **: wixl_msi_table_custom_action_add: assertion 'Source != NULL' failed

(wixl:1748): wixl-CRITICAL **: wixl_msi_summary_info_set_author: assertion 'value != NULL' failed

(wixl:1748): wixl-CRITICAL **: wixl_msi_table_property_add: assertion 'value != NULL' failed

** (wixl:1748): CRITICAL **: wixl_add_braces: assertion 'str != NULL' failed

(wixl:1748): wixl-CRITICAL **: wixl_msi_table_property_add: assertion 'value != NULL' failed
Packaging msi for x86_64 into packages/v0.0.2
genisoimage: Warning: no Apple/Unix files will be decoded/mapped
Total translation table size: 0
Total rockridge attributes bytes: 1117
Total directory bytes: 6144
Path table size(bytes): 60
Max brk space used 22000
245 extents written (0 MB)
Packaging msi for i386 into packages/v0.0.2
genisoimage: Warning: no Apple/Unix files will be decoded/mapped

@toch It'd be nice to fix these warnings.

Also, I think we should use the same output format as release so instead of:

Packaging deb for x86_64 into packages/v0.0.2

We'd have:

Writing packages/v0.0.2/mruby-cli-0.0.2-ARCH.deb

It also seems like the ARCH is missing from the output, so I'd like to fix that as well.

@zzak

Also found this blog post, that might be interesting:
http://blog.codeship.com/using-docker-build-debian-packages/

I'll read the blog post.

It'd be nice to fix these warnings.

do you mean to no show them?

for genisoimage, this is just information.
for msitools, the software is not yet very mature, it seems that those warnings could happen and still you have a msi generated (as in our case).

Also, I think we should use the same output format as release

I'll fix that.

@zzak update: better output is available toch/mruby-cli-distpackage@b99cd46

@zzak I've rebased onto subdirs and I've fixed the warning cf toch/mruby-cli-distpackage@b0801be

Do you see anything else to do?

@hone @zzak

I've rebased onto the PR #13 and squashed the commits. Before merging it, that PR hone/mruby-cli-docker#1 should be merged first into hone/mruby-cli-docker

Two questions:

1/ should I put the code of toch/mruby-cli-distpackage here?

2/ According to mrblib/mruby-cli/setup.rb, the task release is not yet available when you setup your project with mruby-cli. Without that, I can't right now make the package task available neither. I suggest to implement that separately. What do you think?

the task release is not yet available when you setup your project with mruby-cli

Right, we can keep this task private as well, until we're happy with it.

We can make packaging available to users of mruby-cli vs devs a separate PR for sure.

following a call I had with @zzak, here a summary of the things to decide and some other informations

current situation:

• deb and rpm work
• dmg works but a script should be run via shell to add the binary to the PATH
• msi works but nothing to set up the PATH

dmg

I do not know how to include a install action into the bundle such as linking the binary into /usr/local/bin what we would like to do.

some apps do that when you run it the first time (e.g. atom), we should find someone who knows it

msi

with the current msitools, the directive Environment is not recognized. It's then impossible to set it up during the installation.

I've contacted the maintainer to understand how to support it

end goal:

the user shouldn't do something more than just install the package

Tasks to do

1. merge https://github.com/toch/mruby-cli-docker/blob/master/Dockerfile into upstream and build the stack image
2. bring back the code of https://github.com/toch/mruby-cli-distpackage

To decide

we should decide if:

1. we already merge it as it is and agree to postpone the automated installation of the binary in the path environment for osx and windows, or
2. we wait for having fix it the

talked with @toch. I'm fine merging as is for mruby-cli itself. Let's make sure to make issues for fixing the MSI/DMG path stuff so it's tracked. We should probably wait on making all of this generally available (at least MSI/DMG) downstream of mruby-cli.

Ok, let's clean this up and get it merged/shipped so we can start working on the next steps.

done

rebased onto master to resolve conflict

merged here c2ef3f2