couldn’t wait.
It works perfectly for me. 
fine.
1 Like
Did you get Wekan up and running on scaleway? Have tried it with the provided Meteor 1.2 (thx a lot for taking the effort), but failed due to dependencies not being available for ARM platform 
All is running and ready to go. I am currently working on a new README and additional infos / howtos.
Please stay patient for a few more hours - all will run smoothly - I promise 
2 Likes
New 1.2.0.2 is out now
Hi @cathiavila
I do not prefer to use debian packages for deploying on debian based servers.
The reason is, that you may want to serve more than one app on your server, maybe based on different meteor releases and packages. In that case you need to place meteor more than once to your system what is not possible through a deb package. Also a deb package has to run the app in the context of root because you need write access to the “global” meteor directory (see https://github.com/meteor/meteor/pull/4330)
So with that in mind you should install a system wide mongodb from standard debian package if available and higher 2.6.7. If you can’t get any mongodb you should use the mongodb and nodejs from within our dev_bundle.
Cheers
Tom
They’re being given away with the latest Magpi magazine (in the UK at least) - although all the local places seem to have run out!
@tomfreudenberg I just took your Meteor Universal fork for a test drive. Very cool, it opens the door to some very powerful apps/projects. The installation was surprisingly easy and quick. However, the performance is pretty slow. I’m running a Pi 2 model B with a clean install of Jessie (overclocked to 1000 MHz). The Meteor create command takes about 6 minutes to create a new project. Then running the project takes another 5 minutes.
Do you have any tips to speed up the performance?
Run meteor command took 5 minutes to start? It is too long. That is the startup performance. What is the performance in running? Although there are four cores in Pi 2, JavaScript performance is dependent on single core.
@charliecl I installed todos (meteor create --example todos) on the Pi. This took over an hour to complete (compared to about 20 seconds on my Windows desktop). The initial run was also very slow. Subsequent runs were faster at about 2.5 minutes. Making a simple change to a template took about 25 seconds to refresh the browser. The running performance in the Epiphany browser on the Pi is OK. There is some noticeable lag but I wouldn’t attribute that to Meteor. Web browsing on a Pi is normally slow. Good news – when I connected to the Todos app running on the PI from my Windows desktop the performance was excellent. The refresh was slightly faster too at just under 20 seconds.
It is very poor to use Pi 2 as a dev platform. 1 hour create is unacceptable.
Do you test meteor deploy xxx? It may be not too bad
When access meteor app on Pi 2, the result is positive. All or main JavaScript codes may run on client as PC or mobile phone.
Sorry for late reply, I was offsite for last days.
I can confirm, that the first time installation (meteor --version) as well as the first time build (meteor create --example todos) take long time on a PI. But this does NOT AFFECT the overall runtime performance.
Just to give you a note what happens on an ARM board when using meteor after fresh clone. You have to build ALL bundles and packages on the ARM device because they are not yet pre-build from MDG nor from me (See ticket https://github.com/meteor/meteor/issues/5307 I am still working on). The thing is, that ARM is a new architecture which is not supported directly by MDG with pre-build binary codes. So in that case it takes so much longer for the first time instead of a x86 system. If you would use a clean checkout on a x86 and build the packages yourself, the first time build will raise time too (but not so much in case of the more performant board).
However, you NEED at least to create your runtime build on an ARM board, otherwise the binaries will not be useable. Depending on used packages, you can’t run a meteor deploy --directory myapp on a x86 and run that on your PI. You still need to do this once on the PI or an ARM architecture.
Our working process is as follows: Develop main software on our developers systems like MacBook etc. which is independently from the ARM board or device controlling. If we just want to build for the ARM devices, we have an account on Scaleway which gives us cheap access to fast ARM boards. We make our builds on that devices and then just deploy the content of tar/directory. That will just be started by node main.js and is up in seconds.
Sometimes we need to accept the pain when developing hardware depended stuff on the boards. In case that we are mostly using UDOO and ODROID boards there are not too slow and from my personal opinion, to have the ability to run your meteor processes on a PI, it is acceptable too.
Hope that gives you some better understanding.
We are running several apps now on ARM boards and haven’t any issues when running the production apps. Our customers are still happy and fine.
Cheers
Tom
P.S: I suggest to run the bundle node and mongodb from within the dev_bundle. You do not need to install some other system packages for that.
Just use /your-checkout-path/dev_bundle/mongodb/bin/mongod for the mongo daemon and /your-checkout-path/dev_bundle/bin/node to run your app.
So you also use compatible versions of the tools.
1 Like
Be aware that also meteor 1.2.1 is already out, see: Meteor Universal fork 1.2.1 on ARM (UDOO, Raspberry, ODroid, others)
meteor create … needs binary compile? I think most packages are pure JavaScript.
Most ARM apps are developed on X86 system like Mac which has a cross compiler and acts as a Host. Connected ARM board to Mac then dump ARM binary on board. I am not sure Raspberry. Most Android ARM tablets can work in this way.
@charliecl e.g. npm-bcrypt - if you install that, it will create some binaries on your arch. So you can#T yet cross-compile using meteor, because meteor does not official support arm architecture. I haven’t tried yet to use our fork on X86 and try to prepare a cross-compiled package. My feeling is that this won’t work.
Cheers
Tom
P.S.: If you use a package that isn’t installable via meteor add in case that it not support ARM yet (e.g. meteor-scss), you just need to clone the source inside your packages folder and it will get compiled on your ARM board. That worked for us all the time.
Hi all,
I love your porting for ARM.
Is there any timeline for an eventual Meteor 1.3 porting for ARM Architecture?
Is there any way, as far as you know, to install angular-meteor in meteor 1.2?
From the Angular-Meteor website I read that I need the meteor npm command, available only for Meteor 1.3.
Thank you in advance and sorry for my English.
Marco.
Hey Marco ( @marcodistrutti )
perfect timing for your question 
Today I launched the 1.3.3.1 release. Its not currently the default but you may install that
Have a look at https://github.com/4commerce-technologies-AG/meteor/issues/38#issuecomment-227120669
Cheers
Tom
1 Like
Great,
I have no word in order to thank you.
I found the way to develop an angular-meteor application in old school style, compatible with your porting for Meteor 1.2
But I have to congratulate your work, we have the right time for use your last porting.
Maybe is not much for you, but for us is a great step Thank you.
Marco
1 Like
Thanks Marco,
I will do a post about that new release soon. So if you find out any issue with the new release, please post an issue on our github repo.
Cheers
Tom