Release 1.9 (Node.js 12) #10527

benjamn · 2019-04-12T22:13:54Z

Since Node.js 12 is scheduled to become the LTS version on October 1st, 2019, Meteor 1.9 will update the Node.js version used by Meteor from 8.16.1 (in Meteor 1.8.2) to 12.10.0 (the most recent current version).

If you would like to help test the latest prerelease version of Meteor 1.9, you can run the following command to create a fresh application:

meteor create --release 1.9-rc.1 new-19rc1-app

The first casualty of this upgrade is that 32-bit Linux can no longer be supported. In fact, 32-bit Linux support was dropped in Node 10, so this is not exactly breaking news: nodejs/build#885

Node 10 dropped support for 32-bit Linux: nodejs/build#885

https://circleci.com/gh/meteor/meteor/32476

https://circleci.com/gh/meteor/meteor/32465

KoenLav · 2019-04-13T18:28:22Z

Just updated one of our more complicated apps to Meteor 1.9; at first look everything seems to work just fine.

The only thing holding us back was fourseven:scss (which relies on an older version of node-sass, which doesn't support Node 11). Created this PR to update node-sass in meteor-scss: Meteor-Community-Packages/meteor-scss#290

For anyone wanting to try out Meteor 1.9 with fourseven:scss:
cd packages
git clone https://github.com/KoenLav/meteor-scss.git

KoenLav · 2019-04-13T18:41:00Z

tools/tests/apps/modules/.meteor/release

@@ -1 +1 @@
-METEOR@1.8
+METEOR@1.8.1


Shouldn't this be 1.9-alpha.0?

The modules test app runs from a checkout during Circle CI self-tests, so the .meteor/release file doesn't really matter (although we totally could update the version to METEOR@1.9-alpha.0). The reason it shows up in the changes for this PR is because I recently merged release-1.8.2 into release-1.9 (and both PRs are targeting master, which doesn't have the change).

SimonSimCity · 2019-04-23T08:21:54Z

Node.js 12 will be out by the time Meteor 1.9 is finalized [...]

According to nodejs/node#25082 the initial version of Node.js 12 will be released today but LTS will start somewhen in October, so I guess you mean the latter one.

benjamn · 2019-04-27T21:08:01Z

@SimonSimCity Right, I was mostly thinking about the LTS schedule. That said, we will update this branch to Node.js 12 as soon as this fibers/V8 issue has been addressed: laverdet/node-fibers#409

sebakerckhof · 2019-04-29T11:35:31Z

The only thing holding us back was fourseven:scss (which relies on an older version of node-sass, which doesn't support Node 11). Created this PR to update node-sass in meteor-scss: Meteor-Community-Packages/meteor-scss#290

Thanks. Just released a new version

https://nodejs.org/en/blog/release/v12.0.0/ https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V12.md#12.0.0 https://nodejs.org/en/blog/release/v12.1.0/ https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V12.md#12.1.0

KoenLav · 2019-05-01T07:03:17Z

@benjamn are there any specific areas of interest you would like to have tested?

This way people will know what to look out for.

sakulstra · 2019-05-03T12:54:30Z

i'm not sure if this is worth mentioning, but we've been struggling with meteor build times for quite some time(20min+). Out of curiosity i updated to meteor update --release 1.9-alpha.0 to check if node 11/12 improves anything for us.

I'm not sure yet if anything is broken - dosn't seem like it -, but development cold start time was cut by min 5x(before i could go and make a coffee, now it was almost instant) - didn't benchmark it yet though.

Our build time without build-cache(which i think is the important one when using galaxy) dropped from 861s to 243s. Is there any explanation for this massive improvement?
I didn't change anything between the two runs except running meteor update --all-packages && meteor update --release 1.9-alpha.0 (which first bumped webapp one minor version before updating meteor)

// before
| other Target#minifyJs..................................465,274 ms (3)
| files.createTarball app.tar.gz...................169,961 ms (1)

// after
| other Target#minifyJs..................................162,104 ms (3)
| files.createTarball app.tar.gz....................43,075 ms (1)

Looking forward for this improvements in a stable release 🚀 💃

edit: for the people wondering how 861s relates to (20min+) -> when running the build via meteor deploy, and running it in our ci it's appearently a few minutes slower than when running meteor build locally.

benjamn · 2020-01-02T16:57:05Z

@gunn It sounds like you've been testing with the alphas/betas and maybe there's a cached file lying around somewhere? I wasn't able to reproduce this starting from a 1.9-alpha.7 application, for what it's worth. I suspect meteor reset would solve the problem (note: resetting will delete your development Mongo database, in case you care about that).

paulincai · 2020-01-04T08:38:21Z

@benjamn I confirm that CPU usage has been dramatically reduced with 1.9-rc.1. Well done!

The only question that remains is academic - does this actually fix the problem or merely treat the symptoms of a design flaw in the node.js v12 garbage collector?

@benjamn observations from the monitoring tools. I use a no-traffic project of a pretty large code bundle. On "standby" I want to highlight the move of memory and processor for 1.8.x to 1.9-rc.0, 1.9-rc.1 and 1.9-rc2:

1.8.x to 1.9-rc.0
Memory usage keeps growing.

Processor stable over many days.

1.9-rc.1
I think this is self explanatory. There are CPU spikes for every memory drop. I don't know how big the spike would go in a heavy traffic project. Maybe we can get some graphics from others.
You can clearly notice where I deployed the 1.9-rc.1 as the memory usage pattern changes and CPU drops.

1.9-rc.2 behaves exactly like 1.9-rc.1

sebakerckhof · 2020-01-04T11:42:13Z

@paulincai A couple of observations regarding those graphs:

A no-traffic project isn't a very good measure in this case. The changes are related to triggering v8 global garbage collection when a fiber starts/exits. Meteor handles each incoming request from each connection in a separate fiber. With no traffic not a lot of fibers start/exit and the changes between rc.0 and rc.2 shouldn't really make a difference
The time scale of your graphs (between the top and bottom) is very different, which can give a skewed view in kadira.
E.g. this is a graph over a week on one of my projects:

This is the same project from the last 8 hours of the above graph:

So the spikes are just not visible when you view a larger time range.

rj-david · 2020-01-04T23:37:58Z

@benjamn we are getting an issue with 1.9-rc.2. The build was not starting in production

upon starting meteor service, we get:

bundle/programs/server/node_modules/fibers/bin/linux-x64-72-glibc/fibers.node is missing.

upon checking, the one available is

bundle/programs/server/node_modules/fibers/bin/linux-x64-57-glibc/fibers.node

72 and 57 point to NODE_MODULE_VERSION.

We did not get this problem with 1.9-rc.1

benjamn · 2020-01-05T00:13:16Z

@rj-david What's your production environment? Galaxy, or something else? That problem can happen if you use a different version of Node to run the npm install command in bundle/programs/server (which is one of the necessary steps for running a bundled Meteor application in production) than the version of Node you use to run the main.js script. You should be using Node 12 (or 12.14.0 specifically) in both cases.

rj-david · 2020-01-05T04:20:31Z

And that was the case. We were running npm install before updating the node version in our deploy script. Thanks

P.S. 1.9-rc.2 was running without issues

paulincai · 2020-01-05T04:32:30Z

@sebakerckhof I do appreciate your explanation about the fibers, I followed your contributions in this areas but I am not sure I understand the rest. Let me please explain it for you again.
In the first image I need a long time range to show how the memory builds slowly. If you would like to see them side-by-side, you would compare the first image with the third and observe a change of pattern. Now, to 'zoom in' and see what is in the new pattern, you have the 4th image with some beautiful waves.
These are "observations" and are not subject to good or bad measure. It's more like : "Look, a change of pattern. Nice."

sebakerckhof · 2020-01-05T09:34:45Z

@paulincai What I meant to say is that you shouldn't see much of a difference between 1.9-rc.0 and rc.1/rc.2 on a deployment without traffic (although 1.8.x is possible since it's a way older node version). I also have a test deployment with no traffic and don't see the same things as you between rc.0 and rc.2. So I'm trying to find an explanation for why you do see a difference.

In understood you're saying you have CPU spikes in rc.1&2 you did not have in rc.0. But the rc.0 graphs show a 5 day time window, while the graph of rc.2 with the peaks is an 8-hour window. So I was pointing out that the spikes you see might have been there as well on rc.0 if you look in the same time range, since the graphs in kadira will not show the peaks over a large time range.

This includes laverdet/node-fibers#429, fixing the CPU spikes reported and discussed here: #10527 (comment) Using an official fibers release rather than a GitHub URL is preferable because it doesn't require building fibers from source when deploying a Meteor app to production, and also doesn't rely on GitHub being operational, though of course it does rely on other networked services like npm.

[no ci]

vlasky · 2020-01-09T02:19:49Z

@benjamn I have just updated to release-1.9. I am getting similar issues concerning node-fibers when deploying under CentOS 7.

It seems to have been compiled with a more recent version of G++ with a more recent version of libstdc++.so.6 that is not supported under CentOS 7.

Jan 09 12:44:07 ns557985 node[5223]: ## There is an issue with `node-fibers` ##
Jan 09 12:44:07 ns557985 node[5223]: `/var/www/html/fleety/meteor/new_dispatchprod-20200109-124257/bundle/programs/server/node_modules/fibers/bin/linux-x64-72-glibc/fibers.node` is missing.
Jan 09 12:44:07 ns557985 node[5223]: Try running this to fix the issue: /usr/bin/node /var/www/html/fleety/meteor/new_dispatchprod-20200109-124257/bundle/programs/server/node_modules/fibers/
build
Jan 09 12:44:07 ns557985 node[5223]: Error: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /var/www/html/fleety/meteor/new_dispatchprod-20200109-124257/bundle/programs/
server/node_modules/fibers/bin/linux-x64-72-glibc/fibers.node)

@benjamn we are getting an issue with 1.9-rc.2. The build was not starting in production

upon starting meteor service, we get:

bundle/programs/server/node_modules/fibers/bin/linux-x64-72-glibc/fibers.node is missing.

upon checking, the one available is

bundle/programs/server/node_modules/fibers/bin/linux-x64-57-glibc/fibers.node

72 and 57 point to NODE_MODULE_VERSION.

We did not get this problem with 1.9-rc.1

xet7 · 2020-01-09T21:20:42Z

@vlasky

CentOS 7 and RHEL7 is also problematic for Meteor 1.8.2, Snap updates don't work properly:
wekan/wekan-snap#103 (comment)

I don't know is it just that Meteor does not work well on CentOS 7 and RHEL7.

vlasky · 2020-01-09T22:20:39Z

@xet7 no I've been happily using CentOS 7 for all Meteor development since I first began using Meteor in 2015.

This issue is simply because the binary was compiled with a too recent version of G++ that broke compatibility with older environments, e.g. the package maintainer may have accidentally built it under an up-to-date Linux distribution like Fedora or Ubuntu that has cutting edge versions of GNU tools.

CentOS 7 is using GNU GCC 4.8.5 which was released in 2015.

benjamn · 2020-01-10T00:21:06Z

@vlasky When you run npm install in bundle/programs/server, it's supposed to run node npm-rebuild.js, which passes the --update-binary flag to npm, which I thought should recompile the fibers binary if necessary… but maybe something's wrong with that.

In the meantime, this seems like something you could potentially work around in your deployment environment, perhaps by deleting bundle/programs/server/node_modules/fibers/bin and running npm rebuild as an extra step? This has not been a problem on Galaxy, to my knowledge.

xet7 · 2020-01-10T01:07:02Z

About building fibers:

At Ubuntu 16.04 it requires build-essential and libcurl3.
At Ubuntu 18.04 it requires build-essential and libcurl4

https://askubuntu.com/questions/1058517/mongod-error-while-loading-shared-libraries-libcurl-so-4-cannot-open-shared

I'm currently trying to figure out how to build Wekan Snap with correct dependencies to get Ubuntu 16.04-based Snap to have working MongoDB:
https://github.com/wekan/wekan/blob/master/snapcraft.yaml#L81-L101

Sure I have also many other wishes what to get working in Snap wekan/wekan-snap#103 (comment)

I don't know could libssl.so.1 conflict on CentOS wekan/wekan-snap#117

xet7 · 2020-01-10T01:07:30Z

So for CentOS 7, some equivalent of build-essential would need to be installed first.

xet7 · 2020-01-10T01:13:45Z

Before I added libcurl3, snap errors looked like this:

 sudo snap logs wekan.mongodb
2020-01-10T00:39:03Z wekan.mongodb[32472]: ATTACHMENTS_STORE_PATH= (default value)
2020-01-10T00:39:03Z wekan.mongodb[32472]: mongodb bind options:  --bind_ip 127.0.0.1 --port 27019
2020-01-10T00:39:03Z wekan.mongodb[33222]: mongod: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory
2020-01-10T00:39:03Z systemd[1]: snap.wekan.mongodb.service: Main process exited, code=exited, status=127/n/a
2020-01-10T00:39:03Z systemd[1]: snap.wekan.mongodb.service: Failed with result 'exit-code'.
2020-01-10T00:39:03Z systemd[1]: snap.wekan.mongodb.service: Scheduled restart job, restart counter is at 5.
2020-01-10T00:39:03Z systemd[1]: Stopped Service for snap application wekan.mongodb.
2020-01-10T00:39:03Z systemd[1]: snap.wekan.mongodb.service: Start request repeated too quickly.
2020-01-10T00:39:03Z systemd[1]: snap.wekan.mongodb.service: Failed with result 'exit-code'.
2020-01-10T00:39:03Z systemd[1]: Failed to start Service for snap application wekan.mongodb.

And at syslog:

Jan 10 02:39:08 x wekan.wekan[34749]: LOGOUT_ON_MINUTES= (default value)
Jan 10 02:39:08 x wekan.wekan[34749]: DEFAULT_AUTHENTICATION_METHOD= (default value)
Jan 10 02:39:08 x wekan.wekan[34749]: ATTACHMENTS_STORE_PATH= (default value)
Jan 10 02:39:08 x wekan.wekan[34749]: MONGO_URL=mongodb://127.0.0.1:27019/wekan
Jan 10 02:39:08 x wekan.wekan[35480]: /snap/wekan/717/programs/server/node_modules/fibers/future.js:313
Jan 10 02:39:08 x wekan.wekan[35480]: #011#011#011#011#011#011throw(ex);
Jan 10 02:39:08 x wekan.wekan[35480]: #011#011#011#011#011#011^
Jan 10 02:39:08 x wekan.wekan[35480]: MongoNetworkError: failed to connect to server [127.0.0.1:27019] on first connect [Error: connect ECONNREFUSED 127.0.0.1:27019
Jan 10 02:39:08 x wekan.wekan[35480]:     at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1134:16) {
Jan 10 02:39:08 x wekan.wekan[35480]:   name: 'MongoNetworkError',
Jan 10 02:39:08 x wekan.wekan[35480]:   errorLabels: [Array],
Jan 10 02:39:08 x wekan.wekan[35480]:   [Symbol(mongoErrorContextSymbol)]: {}
Jan 10 02:39:08 x wekan.wekan[35480]: }]
Jan 10 02:39:08 x wekan.wekan[35480]:     at Pool.<anonymous> (/snap/wekan/717/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/topologies/server.js:431:11)
Jan 10 02:39:08 x wekan.wekan[35480]:     at Pool.emit (events.js:223:5)
Jan 10 02:39:08 x wekan.wekan[35480]:     at /snap/wekan/717/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/connection/pool.js:557:14
Jan 10 02:39:08 x wekan.wekan[35480]:     at /snap/wekan/717/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/connection/connect.js:39:11
Jan 10 02:39:08 x wekan.wekan[35480]:     at callback (/snap/wekan/717/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/connection/connect.js:261:5)
Jan 10 02:39:08 x wekan.wekan[35480]:     at Socket.<anonymous> (/snap/wekan/717/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/connection/connect.js:286:7)
Jan 10 02:39:08 x wekan.wekan[35480]:     at Object.onceWrapper (events.js:313:26)
Jan 10 02:39:08 x wekan.wekan[35480]:     at Socket.emit (events.js:223:5)
Jan 10 02:39:08 x wekan.wekan[35480]:     at emitErrorNT (internal/streams/destroy.js:92:8)
Jan 10 02:39:08 x wekan.wekan[35480]:     at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
Jan 10 02:39:08 x wekan.wekan[35480]:     at processTicksAndRejections (internal/process/task_queues.js:81:21) {
Jan 10 02:39:08 x wekan.wekan[35480]:   name: 'MongoNetworkError',
Jan 10 02:39:08 x wekan.wekan[35480]:   errorLabels: [ 'TransientTransactionError' ],
Jan 10 02:39:08 x wekan.wekan[35480]:   [Symbol(mongoErrorContextSymbol)]: {}
Jan 10 02:39:08 x wekan.wekan[35480]: }
Jan 10 02:39:08 x systemd[1]: snap.wekan.wekan.service: Main process exited, code=exited, status=1/FAILURE
Jan 10 02:39:08 x systemd[1]: snap.wekan.wekan.service: Failed with result 'exit-code'.
Jan 10 02:39:09 x systemd[1]: snap.wekan.wekan.service: Scheduled restart job, restart counter is at 5.
Jan 10 02:39:09 x systemd[1]: Stopped Service for snap application wekan.wekan.
Jan 10 02:39:09 x systemd[1]: snap.wekan.wekan.service: Start request repeated too quickly.
Jan 10 02:39:09 x systemd[1]: snap.wekan.wekan.service: Failed with result 'exit-code'.
Jan 10 02:39:09 x systemd[1]: Failed to start Service for snap application wekan.wekan.

xet7 · 2020-01-10T01:14:45Z

I don't know is it possible to go directly from MongoDB 3.2.22 to 4.2.2 or would database need some conversion steps.

filipenevola · 2020-01-13T19:44:24Z

Meteor 1.9 is now recommended 🎉 🎉 🎉

vlasky · 2020-01-16T13:38:26Z

@benjamn I rebooted the server, did a clean install of meteor and then it started working normally.

@vlasky When you run npm install in bundle/programs/server, it's supposed to run node npm-rebuild.js, which passes the --update-binary flag to npm, which I thought should recompile the fibers binary if necessary… but maybe something's wrong with that.

In the meantime, this seems like something you could potentially work around in your deployment environment, perhaps by deleting bundle/programs/server/node_modules/fibers/bin and running npm rebuild as an extra step? This has not been a problem on Galaxy, to my knowledge.

Ben Newman added 6 commits April 12, 2019 17:41

Update Node.js to version 11.14.0.

11b0783

Update sqlite3 to version 4.0.6.

c19bfe0

Bump $BUNDLE_VERSION to 11.14.0.0 before rebuilding dev bundle.

b5dc62b

Merge branch 'release-1.8.2' into release-1.9

b144634

Bump $BUNDLE_VERSION to 11.14.0.1 before rebuilding dev bundle.

c72f240

Remove support for 32-bit Linux builds.

db4c94c

Node 10 dropped support for 32-bit Linux: nodejs/build#885

benjamn added the in-development We are already working on it label Apr 12, 2019

benjamn added this to the Release 1.9.0 milestone Apr 12, 2019

benjamn self-assigned this Apr 12, 2019

Ben Newman added 2 commits April 12, 2019 18:43

Remove long-deprecated idle-gc dependency from modules test app.

9171b56

https://circleci.com/gh/meteor/meteor/32476

Use Buffer.alloc instead of the Buffer constructor.

ae8f217

https://circleci.com/gh/meteor/meteor/32465

benjamn changed the title ~~Release 1.9~~ [WIP] Release 1.9 Apr 12, 2019

benjamn changed the base branch from devel to master April 12, 2019 22:47

Ben Newman added 2 commits April 12, 2019 19:25

Merge branch 'release-1.8.2' into release-1.9

da8796d

Bump package versions for 1.9-alpha.0 release.

3614e22

benjamn changed the title ~~[WIP] Release 1.9~~ [WIP] Release 1.9 (Node.js 11-going-on-12) Apr 13, 2019

KoenLav reviewed Apr 13, 2019

View reviewed changes

This was referenced Apr 13, 2019

Major performance degradation when upgrading from meteor 1.6.0.1 to meteor 1.7 or 1.8 #10515

Closed

Update Meteor to Node.js 10 meteor/meteor-feature-requests#342

Closed

angelocordon mentioned this pull request Apr 16, 2019

Increment node version to >= 10.0.0 codebuddies/cb-connect#61

Closed

Ben Newman added 2 commits April 29, 2019 10:41

Merge branch 'release-1.8.2' into release-1.9

f888e6f

Update Node.js to version 12.1.0.

4cd76ad

https://nodejs.org/en/blog/release/v12.0.0/ https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V12.md#12.0.0 https://nodejs.org/en/blog/release/v12.1.0/ https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V12.md#12.1.0

benjamn mentioned this pull request Apr 30, 2019

Support node 12 atom/watcher#224

Closed

Bump fibers version to 4.0.1 for Node.js 12 compatibility.

c0bf4b2

filipenevola and others added 5 commits January 7, 2020 10:52

Merge branch 'devel' into release-1.9

8bf018f

Bump $BUNDLE_VERSION to 12.14.0.4 before rebuilding dev bundle.

fbf69e3

Bump package versions for 1.9-rc.3 release.

80b4e4d

Adds Galaxy hosting URL when creating new Meteor apps

f6b4b09

benjamn force-pushed the release-1.9 branch from ffa929a to f6b4b09 Compare January 8, 2020 22:29

Ben Newman and others added 2 commits January 8, 2020 17:36

Bump Circle CI cache keys to fix spurious Babel error.

863c5fa

Bump package versions for the official 1.9 release. 🎉

39cc074

filipenevola force-pushed the release-1.9 branch from 912b26c to 39cc074 Compare January 8, 2020 23:39

Update the release date for Meteor 1.9 in History.md.

2257bdc

[no ci]

benjamn merged commit 2809237 into master Jan 9, 2020

akalittle mentioned this pull request Jan 13, 2020

fibers cant match RocketChat/Rocket.Chat#16224

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release 1.9 (Node.js 12) #10527

Release 1.9 (Node.js 12) #10527

benjamn commented Apr 12, 2019 •

edited

Loading

KoenLav commented Apr 13, 2019

KoenLav Apr 13, 2019

benjamn Apr 14, 2019 •

edited

Loading

SimonSimCity commented Apr 23, 2019

benjamn commented Apr 27, 2019

sebakerckhof commented Apr 29, 2019

KoenLav commented May 1, 2019

sakulstra commented May 3, 2019 •

edited

Loading

benjamn commented Jan 2, 2020 •

edited

Loading

paulincai commented Jan 4, 2020

sebakerckhof commented Jan 4, 2020

rj-david commented Jan 4, 2020

benjamn commented Jan 5, 2020

rj-david commented Jan 5, 2020 •

edited

Loading

paulincai commented Jan 5, 2020

sebakerckhof commented Jan 5, 2020

vlasky commented Jan 9, 2020

xet7 commented Jan 9, 2020

vlasky commented Jan 9, 2020

benjamn commented Jan 10, 2020 •

edited

Loading

xet7 commented Jan 10, 2020

xet7 commented Jan 10, 2020

xet7 commented Jan 10, 2020

xet7 commented Jan 10, 2020

filipenevola commented Jan 13, 2020

vlasky commented Jan 16, 2020

		@@ -1 +1 @@
		METEOR@1.8
		METEOR@1.8.1

Release 1.9 (Node.js 12) #10527

Release 1.9 (Node.js 12) #10527

Conversation

benjamn commented Apr 12, 2019 • edited Loading

KoenLav commented Apr 13, 2019

KoenLav Apr 13, 2019

Choose a reason for hiding this comment

benjamn Apr 14, 2019 • edited Loading

Choose a reason for hiding this comment

SimonSimCity commented Apr 23, 2019

benjamn commented Apr 27, 2019

sebakerckhof commented Apr 29, 2019

KoenLav commented May 1, 2019

sakulstra commented May 3, 2019 • edited Loading

benjamn commented Jan 2, 2020 • edited Loading

paulincai commented Jan 4, 2020

sebakerckhof commented Jan 4, 2020

rj-david commented Jan 4, 2020

benjamn commented Jan 5, 2020

rj-david commented Jan 5, 2020 • edited Loading

paulincai commented Jan 5, 2020

sebakerckhof commented Jan 5, 2020

vlasky commented Jan 9, 2020

xet7 commented Jan 9, 2020

vlasky commented Jan 9, 2020

benjamn commented Jan 10, 2020 • edited Loading

xet7 commented Jan 10, 2020

xet7 commented Jan 10, 2020

xet7 commented Jan 10, 2020

xet7 commented Jan 10, 2020

filipenevola commented Jan 13, 2020

vlasky commented Jan 16, 2020

benjamn commented Apr 12, 2019 •

edited

Loading

benjamn Apr 14, 2019 •

edited

Loading

sakulstra commented May 3, 2019 •

edited

Loading

benjamn commented Jan 2, 2020 •

edited

Loading

rj-david commented Jan 5, 2020 •

edited

Loading

benjamn commented Jan 10, 2020 •

edited

Loading