Would’ve been nice if there were (at least a couple) basic libs with long time support. Security fixes, maybe some added functionality now and then, but no breaking changes…
The actual risk of almost all vulnerabilities is quite low indeed because of the way our systems are setup. It’s just the earie feeling of seeing all these critical issues while installing my modules that doesn’t feel right.
Hi everyone,
As a developer/maintainer of a couple of MM modules I’m really wondering how everyone is keeping their modules’ dependencies up to date.
An easy thing to do would be to run npm audit fix on my repos and/or merge all PRs from dependabot, but I’m too worried about breaking changes in dependencies. I wouldn’t know how to find the time to extensively test and fix all functionality in the modules. Especially if it would break functionality that someone else is using, that I’m not myself.
How do other developer handle this?
Chris
Hi @3squaremirror,
At the time it’s not configurable.
If you’re able to work out a fix and create a pull request, I’d be happy to include it in my version.
If you’re using my fork, there’s a detailed description of the some what complex setup. Did you follow those steps?
@bhepler Thanks! Switching away from the fake driver seems to fix it.
Hi all,
Finally got to building my own MagicMirror and am quite pleased with the result. I am however running into an issue I can’t get fixed on my own. I’m hoping someone out here might have a good suggestion that will fix the issue.
When my mirror’s been on for a couple of minutes the screen starts flashing and shows green lines about every other line on the display.
I have been searching for solutions and tried some stuff to fix it, including:
The weird this is, if I disable MagicMirror (pm2 stop mm) before it starts flashing, it won’t flash even after an hour. If it has started flashing nothing seems to help, except turning off and on power or a full reboot of the pi.
I’m using a Raspberry pi 3B+
Edit: here’s a short video of what I see:
https://youtu.be/_qaLOZ1Pj7E
@roramirez
Except for one of the errors I think all can still be explained by my last post.
@roramirez sorry, haven’t had much time to spend on MagicMirror lately.
My guess is that some of the tests take too long. Especially the ones actually starting MM and not just load a module.
I imagine Travis runs the tests in some sort of container with multiple containers running on the same system. If there is some heavy load at the same time as the MM test is run this might slow down our test with a certain factor. Seeing the difference in the usual runtime between tests (couple of ms vs multiple seconds) makes me think some of our tests are on the heavier end. Having a multiple second test delayed by a factor, say, 2 makes it easily run 5 seconds. Hitting the 5 sec maximum (see log).
Two possibilities I see to fix this:
Hopefully this helps.
Best regards and thanks for keeping this thread alive!
@roramirez my tests ran on Ubuntu.
The failed build you’re linking has timeouts. That’s the issue I added to the Trello board. We could increase the timeout a bit and see if it happens again in the next days.
Ask Mich to re-run the failed build, he should be able to click that option in Travis, being the owner of the project. See if that fails again. That resolved it for me before.