Package Details: meteor 1.8.1-3

Git Clone URL: https://aur.archlinux.org/meteor.git (read-only, click to copy)
Package Base: meteor
Description: Full-stack JavaScript platform for developing modern web and mobile applications
Upstream URL: https://www.meteor.com
Licenses: MIT
Submitter: flacks
Maintainer: flacks
Last Packager: flacks
Votes: 19
Popularity: 0.000035
First Submitted: 2018-06-16 21:47
Last Updated: 2019-07-11 06:44

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

sibnull commented on 2016-04-10 20:31

This line doesn't work for me:

chown -R $USER:$USER "$pkgdir$HOME/.meteor/"

I don't have a group that is named the same as the user. I do belong to a "users" group, though. I'm coming from Manjaro KDE.

paulequilibrio commented on 2016-04-09 04:18

Fixed.
Installing in your $HOME directory now, just like the official Meteor installer.
But still taking a lot of time to install the resulting package, like @darkbasic said.

darkbasic commented on 2016-04-08 20:28

$ meteor create test

/opt/meteor-js/.meteor/packages/meteor-tool/.1.3.1.6yhl3g++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:116
throw error;
^
Error: Can't get default release version for track undefined
at RemoteCatalog.getDefaultReleaseVersion (/tools/packaging/catalog/catalog-remote.js:835:13)
at Object.release.latestKnown (/tools/packaging/release.js:201:41)
at /tools/cli/main.js:868:29

darkbasic commented on 2016-04-08 17:43

Is it just me or it really takes a lot of time to install the resulting package? Specifically for the "loading package" phase.

paulequilibrio commented on 2016-04-01 15:42

Updated to 1.3

paulequilibrio commented on 2016-03-30 02:27

ottod, this is a wrong behavior that I had not realized until now.
I'm working on a solution based on the suggestions made by cameel.

cameel commented on 2016-03-14 19:17

PKGBUILD installs the wrapper script that downloads the framework in /usr/bin/meteor. There's no point in that because the package already provides all the necessary files. /usr/bin/meteor should instead link directly to /opt/meteor/meteor. That's actually what a comment in the install script suggests:

# This is the script that we install somewhere in your $PATH (as "meteor")
# when you run
# $ curl https://install.meteor.com/ | sh
# It's the only file that we install globally on your system; each user of

# All this script does is exec ~/.meteor/meteor. But what if you don't have it
# yet? In that case, it downloads a "bootstrap tarball", which contains the
# latest version of the Meteor tools, and plops it down at ~/.meteor. In fact,
# once you've run this once, you don't even really need this script: you can put
# ~/.meteor/ into your PATH, or a symlink to ~/.meteor/meteor into some other
# PATH directory. No special permissions needed!

Since the PKGBUILD puts the files in /opt/meteor instead of ~/.meteor, we need to set METEOR_WAREHOUSE_DIR variable to point at the right directory.

There's one big problem though - meteor expects write access to /opt/meteor/package-metadata/v2.0.1 where its package database (packages.data.db) is stored and will crash without it.

Here are my modifications but because of this problem it's not a complete solution.

PKGBUILD: http://pastebin.com/BuNJ36Gc
meteor.sh: http://pastebin.com/fPFyX8UN

ottod commented on 2016-02-26 18:43

I installed this for the first time. When I called the meteor command without arguments just to test, the command did not find ~/.meteor so it downloaded meteor again on its own. Am I missing something?

paulequilibrio commented on 2015-11-04 15:36

Updated to 1.2.1

kenny_r commented on 2015-10-29 12:50

The install file just curls the tar.gz, links for 1.2.1 (currently the latest release) are:

https://d3sqy0vbqsdhku.cloudfront.net/packages-bootstrap/1.2.1/meteor-bootstrap-os.linux.x86_32.tar.gz
https://d3sqy0vbqsdhku.cloudfront.net/packages-bootstrap/1.2.1/meteor-bootstrap-os.linux.x86_64.tar.gz