DietPi-Software | Non-APT software versions

Created on 27 Dec 2017 · 35Comments · Source: MichaIng/DietPi

DietPi-Software current and upstream versions

_Last update: 2018-06-23_
🈴 update available
🈺 reasonable beta or unsure
🈯️ up-to-date

Enhancement

Source

MichaIng

👍2 ❤1

Most helpful comment

Extended and moved table to Wiki: https://github.com/Fourdee/DietPi/wiki/DietPi-Software-list

MichaIng on 12 Jan 2019

❤1 👍1

All 35 comments

@MichaIng

Great stuff 👍

Although, I hate these new git emotes, looks like a child made them, for other children.

Fourdee on 27 Dec 2017

@MichaIng

Legend 👍

Merged: https://github.com/Fourdee/DietPi/pull/1339#issuecomment-354128584

Testing required (quick installs) to verify functional.

Fourdee on 27 Dec 2017

Everything tested on VM Jessie+Stretch:

All installations work fine, software does it's job/opens as far as I could test fast, but:
Koel installation fails at least on only-local VMs: https://github.com/Fourdee/DietPi/issues/1343
General issue with MariaDB: https://github.com/Fourdee/DietPi/issues/1344
If we have some time, we can discuss how to handle the list above.

@Fourdee

Although, I hate these new git emotes, looks like a child made them, for other children.

Which new emotes you mean? 😆

MichaIng on 27 Dec 2017

@MichaIng

lol

Koel, install is fine, but new issue with automation (cant see a solution, looks limited to Koel's source?): https://github.com/Fourdee/DietPi/issues/1343#issuecomment-354434655
MariaDB looks like a big one, i'll take a look when I can.

Fourdee on 29 Dec 2017

@Fourdee
Huh, these icons are new for you? I have them as long as I can remember using github. Now I am interested how the old ones looked like 😆.

Koel seems to be related to my VM network setup, see the separete topic: https://github.com/Fourdee/DietPi/issues/1343
Yes, further discussion in separate topic also: https://github.com/Fourdee/DietPi/issues/1344

Lets concentrate here on the update method/installation source of software list above, as we find time. But as long as there are no actual issues with our current versions/sources, there is no need to hurry. Will mark this as low topic for that reason.

MichaIng on 29 Dec 2017

👍1

@Fourdee
To come back to this topic:

NoMachine: version 6 available, as well as RPi3/ARMv8 version: https://www.nomachine.com/de/download/linux&id=29&s=Raspberry
- Tested successfully on VM with: http://download.nomachine.com/download/6.0/Linux/nomachine_6.0.78_1_amd64.deb

MichaIng on 13 Mar 2018

👍1

@MichaIng

NoMachine: version 6 available, as well as RPi3/ARMv8 version:

Thanks.

Binaries updated https://github.com/Fourdee/DietPi/commit/30e8eb58bdc5f36d52d1455fafc5ae9454bc4fe1, tested RPi 3 with 6.0.78:

🈯️

Fourdee on 14 Mar 2018

👍1

@Fourdee
I finished the list above with all our software where the newest version is not installed automatically.
By this we can easily check for new versions regularly and update our links or upload/build new binaries.
As you can see, there is already much to do 😅.

I am thinking about updating all links and binaries that do not need to be build manually, as I am not too experienced with this and do not have all required machines anyway.
But theoretically we need to retest the installation/configuration process for all affected software on all devices, which is even more work.

Maybe with above link and binary updates, we can offer a "software update" branch with just those updates based on v6.8 release and invite users to help testing their new software versions via dietpi-software reinstall?

€: PR up: https://github.com/Fourdee/DietPi/pull/1774

MichaIng on 13 May 2018

❤1 👍1

@MichaIng

Great work, yep, its a long task this one 👍

But theoretically we need to retest the installation/configuration process for all affected software on all devices, which is even more work.

Yep, I can test ARMv6/7/8.
Not only do we need to verify install succeeds, but also its functional via basic use testing (eg: check interface works).

Maybe with above link and binary updates, we can offer a "software update" branch with just those updates based on v6.8 release and invite users to help testing their new software versions via dietpi-software reinstall?

Like the idea 👍 However, I believe we can request them to use the testing branch. I personally feel making multiple branches will cause havoc and confusion for us (well me at least 🤣).
They could basically do a fresh install of master, run a backup, then G_DEV_1, then test.

Fourdee on 14 May 2018

Install tests:

@MichaIng: Test on VirtualBox VM Jessie + Stretch

ID | Title | ARMv6 | ARMv7 | ARMv8 | x86_64
-- | ----- | -- | -- | -- | --
30 | NoMachine | 🈯️ | 🈯️ | 🈯️ | 🈯️ @MichaIng
111 | UrBackup | N/A | 🈯️ | 🈯️ | 🈯️ @MichaIng
59 | RPi Cam Control (https://github.com/Fourdee/DietPi/issues/1747) | 🈯️ | 🈯️ | N/A | N/A
68 | Weaved | 🈯️ | 🈯️ | 🈯️ | N/A
131 | Blynk | 🈯️ | 🈯️ | 🈯️ | 🈯️ @MichaIng
98 | HAProxy | 🈯️ | 🈯️ | 🈯️ | 🈯️ @MichaIng
56 | Single File PHP Gallery | 🈯️ | 🈯️ | 🈯️ | 🈯️ @MichaIng
42 | Plex Media Server | N/A | 🈯️ | 🈯️ | 🈯️ @MichaIng
50 | Syncthing | 🈯️ | 🈯️ | 🈯️ | 🈯️ @MichaIng
141 | Spotify Connect Web | N/A | 🈯️ | 🈯️ | N/A
143 | Koel (https://github.com/Fourdee/DietPi/pull/1789) | 🈴 (https://github.com/Fourdee/DietPi/issues/1340#issuecomment-391052726) | 🈯️ | 🈯️ | 🈯️ @MichaIng
168 | moOde (currently inactive anyway) | N/A | N/A | N/A | N/A

Fourdee on 14 May 2018

ARMv6 blynk (and all JAVA installs?)

Error occurred during initialization of VM
Server VM is only supported on ARMv7+ VFP
E: /etc/ca-certificates/update.d/jks-keystore exited with code 1.
done.
Errors were encountered while processing:
 ca-certificates-java
 openjdk-9-jre-headless:armhf
E: Sub-process /usr/bin/dpkg returned an error code (1)

[FAILED] DietPi-Software | G_AGI: ca-certificates-java

Fourdee on 15 May 2018

openjdk-9-jre-headless:armhf

Java 9?? Actually until Stretch default-jre-headless should be Java 8, or is this different on Raspbian repo? Here Raspbian is always a bid behind Debian: Raspbian Buster offers Java 9, while Debian Buster already Java 10.

I think to assure compatibility we should install openjdk-8-jre-headless / openjdk-8-jdk-headless packages and do a controlled move to/adding of Java 9/10 by times.

MichaIng on 15 May 2018

👍1

Blynk

On first install attempt I got an unlimited fast repeating error on both systems, Jessie and Stretch:

gyp WARN EACCES user "root" does not have permission to access the dev dir "/usr/local/lib/node_modules/onoff/node_modules/epoll/.node-gyp/10.1.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/onoff/node_modules/epoll/.node-gyp"

My scroll buffer was filled with this to fast, but according to error messages it should be the following within Blynk install step: npm install -g onoff
Interestingly I was able to manually run the command afterwards without issue. Another dietpi-software install 131 run through then nicely.
~~- Why do we do this node.js install etc actually? Can't find a hint about this within their install instructions: https://github.com/blynkkk/blynk-server#blynk-server~~
However not sure what caused this error on first attempt on both systems 🤔.

But runs fine afterwards including web UI. 🈯️

HAProxy

It's incompatible with webservers binding to port 80 as well of course.
If I am not mistaken , when installing a webserver in parallel, we need to configure it to listen to the haproxy backend port (9000, 9001 and 9002 by default)? Usually user should know this, when installing a load balancer, but just to have a nice installation, we could automate this.
€: 🈯️ Jep, adjust listening port of Lighttpd to 9000 works fine :).

Runs fine otherwise 🈯️

MichaIng on 15 May 2018

@MichaIng

I think to assure compatibility we should install openjdk-8-jre-headless / openjdk-8-jdk-headless packages and do a controlled move to/adding of Java 9/10 by times.

Yep agree, i'll make the change and test on systems 👍

Fourdee on 17 May 2018

@Fourdee

Koel 🈴

Some issues watched, at least the first one not being related with version:

If webserver (PHP) was installed with different or no database, php-mysql will be not installed any more, so Koel fails to connect. We need to either find a good way to reinstall webserver + PHP as well (currently we skip, if install state is found) or install the PHP modules as well on MariaDB installation, if PHP is found: https://github.com/Fourdee/DietPi/blob/testing/dietpi/dietpi-software#L2810
The ADMIN variables to adjust username, mail and password, do not exist in /var/www/koel/.env anymore, thus during installation this is asked for interactively. Not sure, where we can add this info now to allow automated installation: https://github.com/Fourdee/DietPi/blob/testing/dietpi/dietpi-software#L11620-L11622
Face this error on opening web ui: https://github.com/phanan/koel/issues/557
- I am currently trying npm install --global yarn && yarn install but the last step takes time...
  
  €: 🈴 process fails somehow
- 🈴 yarn dev && yarn prod both throw a lot of errors. mix-manifest.json is created but web ui throws the next errors...
Next try 🈴

yarn run v1.6.0
$ cross-env NODE_ENV=production node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js
 95% emitting

 ERROR  Failed to compile with 47 errors                                                                                                                                                                                             18:30:32

 error  in ./resources/assets/js/components/main-wrapper/main-content/users.vue

Module build failed:
      @mixin control($playBtnWidth, $fontSize, $textIndent) {
            ^
      Mixins may not be defined within control directives or other mixins.
      in /var/www/koel/resources/assets/sass/partials/_mixins.scss (line 79, column 14)

 @ ./node_modules/vue-style-loader!./node_modules/css-loader!./node_modules/vue-loader/lib/style-compiler?{"vue":true,"id":"data-v-9e154f4a","scoped":false,"hasInlineConfig":true}!./node_modules/sass-loader/lib/loader.js!./node_modules/vue-loader/lib/selector.js?type=styles&index=0!./resources/assets/js/components/main-wrapper/main-content/users.vue 4:14-378
 @ ./resources/assets/js/components/main-wrapper/main-content/users.vue
 @ ./node_modules/babel-loader/lib?{"cacheDirectory":true,"presets":[["es2015",{"modules":false}]]}!./node_modules/vue-loader/lib/selector.js?type=script&index=0!./resources/assets/js/components/main-wrapper/main-content/index.vue
 @ ./resources/assets/js/components/main-wrapper/main-content/index.vue
 @ ./node_modules/babel-loader/lib?{"cacheDirectory":true,"presets":[["es2015",{"modules":false}]]}!./node_modules/vue-loader/lib/selector.js?type=script&index=0!./resources/assets/js/components/main-wrapper/index.vue
 @ ./resources/assets/js/components/main-wrapper/index.vue
 @ ./node_modules/babel-loader/lib?{"cacheDirectory":true,"presets":[["es2015",{"modules":false}]]}!./node_modules/vue-loader/lib/selector.js?type=script&index=0!./resources/assets/js/app.vue
 @ ./resources/assets/js/app.vue
 @ ./resources/assets/js/app.js
 @ multi ./resources/assets/js/app.js ./resources/assets/sass/app.scss ./resources/assets/sass/remote.scss
...
many other errors of the same kind.

Later:

error /var/www/koel/node_modules/laravel-mix/node_modules/node-sass: Command failed.
Exit code: 1
...
binding.target.mk:115: recipe for target 'Release/obj.target/binding/src/binding.o' failed
make: Leaving directory '/var/www/koel/node_modules/laravel-mix/node_modules/node-sass/build'
make: *** [Release/obj.target/binding/src/binding.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/var/www/koel/node_modules/node-gyp/lib/build.js:258:23)
gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:235:12)
gyp ERR! System Linux 4.9.0-6-amd64
gyp ERR! command "/usr/local/bin/node" "/var/www/koel/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
gyp ERR! cwd /var/www/koel/node_modules/laravel-mix/node_modules/node-sass
gyp ERR! node -v v10.1.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
Build failed with error code: 1

🈴 Retry on fresh system: same errors. Sadly I can't do much debugging here, as I don't know what at least half of the commands do 😢 ...

Ref: https://koel.phanan.net/docs/#/?id=installation

No npm used in their official docs?

MichaIng on 17 May 2018

👍1

@MichaIng

gyp WARN EACCES user "root" does not have permission to access the dev dir "/usr/local/lib/node_modules/onoff/node_modules/epoll/.node-gyp/10.1.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/onoff/node_modules/epoll/.node-gyp"

--unsafe-perm will remove the root permissions warning, i'll send commit.

Fourdee on 17 May 2018

Blynk reinstall test:

x86_64 🈯️
ARMv6 🈴
ARMv8 🈴

Error: missing `server' JVM at `/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'.
Please install or use the JRE or JDK that contains these missing components.
E: /etc/ca-certificates/update.d/jks-keystore exited with code 1.
done.
Errors were encountered while processing:
 ca-certificates-java
 openjdk-8-jre-headless:armhf
 openjdk-8-jdk-headless:armhf
E: Sub-process /usr/bin/dpkg returned an error code (1)

Fourdee on 17 May 2018

G_AGI ca-certificates-java # installs java 9, but allows for install
####
G_AGI ca-certificates-java  openjdk-8-jre-headless openjdk-8-jdk-headless # fails on 1st attempt, has to be installed twice..

Fourdee on 17 May 2018

😕1

@Fourdee
Can you check which repo is actually used on these ARMs?

On Debian it should take Java 8: https://packages.debian.org/de/stretch/ca-certificates-java

The deps are a bid wired, but as openjdk-7-jre-headless is not available on Stretch, openjdk-8-jre-headless should be taken.

On my RPi with Raspbian Buster is shows the right deps as well, interestingly still Java 8 even that it's testing branch:
Depends: ca-certificates (>= 20121114), openjdk-8-jre-headless | java8-runtime-headless, libnss3 (>= 3.12.10-2~)

MichaIng on 17 May 2018

Raspbian Stretch:

root@DietPi:~# apt-cache depends ca-certificates-java
ca-certificates-java
  Depends: ca-certificates
 |Depends: <openjdk-7-jre-headless>
  Depends: <java7-runtime-headless>
    default-jre-headless
    openjdk-8-jre-headless
    openjdk-9-jre-headless
    oracle-java7-jdk
    oracle-java8-jdk
  Depends: libnss3

root@DietPi:~# apt-cache policy ca-certificates-java
ca-certificates-java:
  Installed: 20170531+nmu1
  Candidate: 20170531+nmu1
  Version table:
 *** 20170531+nmu1 500
        500 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages
        100 /var/lib/dpkg/status

root@DietPi:~# apt-cache policy openjdk-8-jre-headless
openjdk-8-jre-headless:
  Installed: 8u171-b11-1~deb9u1
  Candidate: 8u171-b11-1~deb9u1
  Version table:
 *** 8u171-b11-1~deb9u1 500
        500 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages
        100 /var/lib/dpkg/status

ARMv8 debian:

root@DietPi:~# apt-cache depends ca-certificates-java
ca-certificates-java
  Depends: ca-certificates
 |Depends: <openjdk-7-jre-headless>
  Depends: <java7-runtime-headless>
    default-jre-headless
    openjdk-8-jre-headless
    openjdk-9-jre-headless
  Depends: libnss3

root@DietPi:~# apt-cache policy ca-certificates-java
ca-certificates-java:
  Installed: 20170531+nmu1
  Candidate: 20170531+nmu1
  Version table:
 *** 20170531+nmu1 500
        500 https://deb.debian.org/debian stretch/main armhf Packages
        100 /var/lib/dpkg/status

root@DietPi:~# apt-cache policy openjdk-8-jre-headless
openjdk-8-jre-headless:
  Installed: 8u171-b11-1~deb9u1
  Candidate: 8u171-b11-1~deb9u1
  Version table:
 *** 8u171-b11-1~deb9u1 500
        500 https://deb.debian.org/debian-security stretch/updates/main armhf Packages
        100 /var/lib/dpkg/status
     8u151-b12-1~deb9u1 500
        500 https://deb.debian.org/debian stretch/main armhf Packages

#Seems security repo is being installed:
openjdk-8-jre-headless:armhf  8u171-b11-1~deb9u1

Fourdee on 17 May 2018

👍1

🈯️ Spotify web connect:
NB: didn't reboot to enable ALSA, working fine

[FAILED] DietPi-Services | spotify-connect-web  failed (Result: exit-code) since Thu 2018-05-17 17:13:17 BST; 21s ago
● spotify-connect-web.service - spotify-connect-web
   Loaded: loaded (/etc/systemd/system/spotify-connect-web.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2018-05-17 17:13:17 BST; 21s ago
  Process: 8422 ExecStart=/mnt/dietpi_userdata/spotify-connect-web/spotify-connect-web (code=exited, status=255)
 Main PID: 8422 (code=exited, status=255)

May 17 17:13:17 DietPi spotify-connect-web[8422]:     from connect import Connect
May 17 17:13:17 DietPi spotify-connect-web[8422]:   File "/mnt/dietpi_userdata/spotify-connect-web/connect.py", line 9, in <module>
May 17 17:13:17 DietPi spotify-connect-web[8422]:     from console_callbacks import audio_arg_parser, mixer, error_callback, connection_callbacks, debug_callbacks, playback_callbacks, playback_setup
May 17 17:13:17 DietPi spotify-connect-web[8422]:   File "/mnt/dietpi_userdata/spotify-connect-web/console_callbacks.py", line 25, in <module>
May 17 17:13:17 DietPi spotify-connect-web[8422]:     audio_arg_parser.add_argument('--mixer', '-m', help='alsa mixer name for volume control', default=alsa.mixers()[0])
May 17 17:13:17 DietPi spotify-connect-web[8422]: alsaaudio.ALSAAudioError: No such file or directory [default]
May 17 17:13:17 DietPi spotify-connect-web[8422]: Failed to execute script loader
May 17 17:13:17 DietPi systemd[1]: spotify-connect-web.service: Main process exited, code=exited, status=255/n/a
May 17 17:13:17 DietPi systemd[1]: spotify-connect-web.service: Unit entered failed state.
May 17 17:13:17 DietPi systemd[1]: spotify-connect-web.service: Failed with result 'exit-code'.

Fourdee on 17 May 2018

Ah jep apt-cache depends ca-certificates-java shows more of the truth, on Raspbian Buster:

2018-05-17 17:31:28 root@micha:/var/log# apt-cache depends ca-certificates-java
ca-certificates-java
  Depends: ca-certificates
 |Depends: openjdk-8-jre-headless
  Depends: <java8-runtime-headless>
    default-jre-headless
    openjdk-10-jre-headless
    openjdk-8-jre-headless
    openjdk-9-jre-headless
    oracle-java8-jdk
  Depends: libnss3

should install Java 10, which is also default-jdk on Debian Buster.

ARMv8 has the same issue without installing ca-certificates-java even that it is Debian repo?
Otherwise if it's just a Raspbian repo issue (as it works fine on my VM to install just openjdk-8-jdk-headless), we could open some bug report there, to have this ugly workaround fixed with Java 9 installed as well.

MichaIng on 17 May 2018

@MichaIng

ARMv8 has the same issue without installing ca-certificates-java even that it is Debian repo?

Yep, same issue, I think the cause is the actual package install script (limited to ARM?), and the order it runs in. Not much we can do about that, workaround required I believe for now.

we could open some bug report there, to have this ugly workaround fixed with Java 9 installed as well.

Yep, ideally we need to exclude our OS from tests, if we can replicate with default Raspbian/Debian (once packages removed), we can then send this off as a bug.

Fourdee on 17 May 2018

Kind of agree with this: https://gist.github.com/bplower/613a99156d603abac083#gistcomment-2226016

But i'll try and get it fixed.

Roger that!

yarn install v1.6.0
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. 

---
error /var/www/koel/node_modules/node-sass: Command failed.
Exit code: 1
Command: node scripts/build.js
Arguments:
Directory: /var/www/koel/node_modules/node-sass
Output:
Building: /usr/local/bin/node /var/www/koel/node_modules/node-gyp/bin/node-gyp.js rebuild --verbose --libsass_ext= --libsass_cflags= --libsass_ldflags= --libsass_library=

Use of G_CONFIG_INJECT (which is brilliant btw @MichaIng 😃 ), to add the missing entries, still prompts for initial setup of username etc.

Unable to find "latest" variables, no documentation
Nothing added to .env after manual setup, was hoping to pull that info and apply to our install.

Reverted install to previous version, automation is fine, however:

file_get_contents(/var/www/koel/public/mix-manifest.json): failed to open stream: No such file or directory (View: /var/www/koel/resources/views/index.blade.php)

Then yarn install fails. Same result as @MichaIng (i finally got there 😃 )

https://github.com/sass/node-sass/issues/1781#issuecomment-258069797 > https://github.com/yarnpkg/yarn/issues/1632

Looks dead.

Fourdee on 18 May 2018

@Fourdee

Kind of agree with this

Yes thought the same, so much install steps, so much pre-dependencies and so much warnings about deprecated, missing, skipped etc. modules/parts whatever. But I can't really give qualified criticism here, as I don't understand much of what's actually going on. Already the build process until make is in detail cryptic to me, okay at least I know in theory about compiling source code into binaries of course 😄.

At least, if after the build is fully done, if the binary is slim and fast and beautiful, everything is nice, and you can remove all the building tools, if wanted. We could think about the same, actually 😉.
But what I don't like more is software, that calls itself slim and fast, that needs to load heavy dependencies then to run. Better a built binary, than the source code need to be compiled on every start-up again by heavy compiler. Mainly this is what I don't like about most Java software, e.g. just watched AirSonic and SubSonic and some other Software I "like" (better need) to use on Windows 😉.

Admin info

https://github.com/phanan/koel/search?utf8=✓&q=ADMIN_NAME&type=
Thus, should actually still works this way. Maybe the errors we face lead to .env not being read correctly? Otherwise database info is successfully read/used... But better first fix the other errors, then see if/how to automate.
Bid similar, but not exactly the same: https://github.com/phanan/koel/issues/748
Will try around tomorrow, maybe never versions (Buster) work, or following the install instructions precisely...

€: Ah just saw the issues you linked above:

Hmm in my case the yarn cache dir exists, not sure if I should set it to different location, tried to find an npm env variable, that changes it.
Just playing around a bid:
npm test

...
Error in ./resources/assets/js/components/main-wrapper/sidebar/index.vue

   Error: Node Sass does not yet support your current environment: Linux 64-bit with Unsupported runtime (64)
  For more information on which environments are supported please see:
  https://github.com/sass/node-sass/releases/tag/v4.7.2

Error in ./resources/assets/js/components/auth/login-form.vue

   Error: Node Sass does not yet support your current environment: Linux 64-bit with Unsupported runtime (64)
  For more information on which environments are supported please see:
  https://github.com/sass/node-sass/releases/tag/v4.7.2
...

Found that for node 10 node-sass 4.9 is needed: https://github.com/sass/node-sass/commit/94ce8529486643f350d8a658791a4e6204db0e70#diff-ca276526c404f3a4be0d52f78b12ecbaR12

root@DietPi:/var/www/koel# npm --version
5.6.0
root@DietPi:/var/www/koel# node --version
v10.1.0
root@DietPi:/var/www/koel# npm ls node-sass
koel@ /var/www/koel
├─┬ [email protected]
│ └── [email protected]
└── [email protected]

npm install node-sass installs current version 4.9.0 (removes a mass of other modules, no idea if/why this is normal), but php artisan koel:init seems to break it again.
Something with laravel-mix which contains node-sass as well.
After updating any of both modules, every node-sass instance seems up-to-date:

root@DietPi:/var/www/koel# npm ls node-sass
koel@ /var/www/koel
├─┬ [email protected]
│ └── [email protected]  deduped
└── [email protected]

After php artisan koel:init, the folder structure within laravel-mix module changes, containing a CHANGELOG.md which indicates outdated version:

root@DietPi:/var/www/koel# cat node_modules/laravel-mix/node_modules/node-sass/CHANGELOG.md
## v4.5.0

€€: Okay, issue seems to be identified and workaround found: https://github.com/phanan/koel/issues/748#issuecomment-390477430
Though needs testing on different machines, as it still looks a bid fragile to me.

€€€: PR with workaround is up: https://github.com/Fourdee/DietPi/pull/1789
🈯️ Successfully tested on VM Jessie + Stretch + Buster

MichaIng on 19 May 2018

❤1 👍1

@MichaIng

Great work on Koel 👍

Just ARMv6 to test, leaving it installing over night 😉.

ToDo (me):

RPI Cam tests

Fourdee on 21 May 2018

Koel ARMv6:

file_get_contents(/var/www/koel/public/mix-manifest.json): failed to open stream: No such file or directory (View: /var/www/koel/resources/views/index.blade.php)

Fourdee on 22 May 2018

SABnzbd test install:

🈯️

Cava update, test installs:

🈯️ ARMv6
🈯️ ARMv7
🈴 ARMv8 | Illegal instruction, compiled twice... | 🈯️ previous binary works fine wget https://dietpi.com/downloads/binaries/all/cava_0.4.2_arm64.deb; dpkg -i *.deb
🈯️ AMD64

Fourdee on 25 May 2018

Squeezelite

Reason for our squeezelite binary install (vs Debian repo)

patch < scripts/squeezelite-ralphy-dsd.patch
OPTS="-DLINUX -DALSA -DEVENTFD -DDSD" make -j $(nproc --all)

We apply a DSD patch which enables DSD support, and, minimal binary with ALSA.

Fourdee on 26 May 2018

@Fourdee
Are the last errors (CAVA e.g.) resolved now? As v6.9 is a huge update with some deep changes, we have to take care to not forget testing/finishing everything.

Would suggest to stop new feature input for this update, just testing and bugfixing.

MichaIng on 30 May 2018

@MichaIng

Are the last errors (CAVA e.g.) resolved now?

Don't believe so, i'll recompile again and test.

As v6.9 is a huge update with some deep changes, we have to take care to not forget testing/finishing everything.

Yep 👍 we need to spend at least 1/2 days of testing everything, prior to release, that been changed/update, just incase we missed anything.

Fourdee on 30 May 2018

@MichaIng

🈯️ Cava build/runs fine on Rock64:

🈴 Cava still an issue with ARMv8, C2 compile:

Rock64 compiled binary also fails to run.
Missing CPU instructions/extensions on the C2?

[   22.039720] cava[1556]: undefined instruction: pc=0000007f95843000
[   22.039734] Code: 9e6703e8 aa0103f9 5280011a 5280003b (d53be057)

C2 only

root@DietPi:~# dpkg --print-foreign-architectures
armhf

root@DietPi:~# dpkg --remove-architecture armhf
dpkg: error: cannot remove architecture 'armhf' currently in use by the database

root@DietPi:~# dpkg -l | grep armhf
ii  gcc-6-base:armhf            6.3.0-18+deb9u1                  armhf        GCC, the GNU Compiler Collection (base package)
ii  libc6:armhf                 2.24-11+deb9u3                   armhf        GNU C Library: Shared libraries
ii  libgcc1:armhf               1:6.3.0-18+deb9u1                armhf        GCC support library
ii  zlib1g:armhf                1:1.2.8.dfsg-5                   armhf        compression library - runtime

 G_AGP libc6:armhf gcc-6-base:armhf libgcc1:armhf zlib1g:armhf

root@DietPi:~/cava# ./autogen.sh
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
root@DietPi:~/cava# ./configure --enable-debug
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking build system type... aarch64-unknown-linux-gnu
checking host system type... aarch64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert aarch64-unknown-linux-gnu file names to aarch64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert aarch64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for gcc option to accept ISO C99... none needed
checking for gcc option to accept ISO Standard C... (cached) none needed
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_create in -lpthread... yes
checking alloca.h usability... yes
checking alloca.h presence... yes
checking for alloca.h... yes
checking for snd_pcm_open in -lasound... yes
checking for pa_simple_new in -lpulse-simple... yes
checking for sio_open in -lsndio... no
configure: WARNING: No sndio dev files found building without sndio support
checking for sqrt in -lm... yes
checking for fftw_execute in -lfftw3... yes
checking for ncursesw6-config... no
checking for ncursesw5-config... /usr/bin/ncursesw5-config
checking for initscr in -lncursesw... yes
checking for initscr in -lncursesw... yes
checking curses.h usability... yes
checking curses.h presence... yes
checking for curses.h... yes
checking for library containing iniparser_load... -liniparser
checking iniparser.h usability... no
checking iniparser.h presence... no
checking for iniparser.h... no
configure: Building iniparser
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating iniparser/Makefile
config.status: creating Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
root@DietPi:~/cava#
root@DietPi:~/cava# make -j $(nproc --all)
Making all in iniparser
make[1]: Entering directory '/root/cava/iniparser'
depbase=`echo src/iniparser.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"cava\" -DPACKAGE_TARNAME=\"cava\" -DPACKAGE_VERSION=\"23db477\" -DPACKAGE_STRING=\"cava\ 23db477\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DPACKAGE=\"cava\" -DVERSION=\"23db477\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD_H=1 -DHAVE_CURSES_H=1 -I.   -DDEBUG -DHAVE_ALLOCA_H -DALSA -DPULSE -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw -DNCURSES  -g -O2 -MT src/iniparser.lo -MD -MP -MF $depbase.Tpo -c -o src/iniparser.lo src/iniparser.c &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo src/dictionary.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"cava\" -DPACKAGE_TARNAME=\"cava\" -DPACKAGE_VERSION=\"23db477\" -DPACKAGE_STRING=\"cava\ 23db477\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DPACKAGE=\"cava\" -DVERSION=\"23db477\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD_H=1 -DHAVE_CURSES_H=1 -I.   -DDEBUG -DHAVE_ALLOCA_H -DALSA -DPULSE -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw -DNCURSES  -g -O2 -MT src/dictionary.lo -MD -MP -MF $depbase.Tpo -c -o src/dictionary.lo src/dictionary.c &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  gcc -DPACKAGE_NAME=\"cava\" -DPACKAGE_TARNAME=\"cava\" -DPACKAGE_VERSION=\"23db477\" "-DPACKAGE_STRING=\"cava 23db477\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DPACKAGE=\"cava\" -DVERSION=\"23db477\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD_H=1 -DHAVE_CURSES_H=1 -I. -DDEBUG -DHAVE_ALLOCA_H -DALSA -DPULSE -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw -DNCURSES -g -O2 -MT src/dictionary.lo -MD -MP -MF src/.deps/dictionary.Tpo -c src/dictionary.c  -fPIC -DPIC -o src/.libs/dictionary.o
libtool: compile:  gcc -DPACKAGE_NAME=\"cava\" -DPACKAGE_TARNAME=\"cava\" -DPACKAGE_VERSION=\"23db477\" "-DPACKAGE_STRING=\"cava 23db477\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DPACKAGE=\"cava\" -DVERSION=\"23db477\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD_H=1 -DHAVE_CURSES_H=1 -I. -DDEBUG -DHAVE_ALLOCA_H -DALSA -DPULSE -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw -DNCURSES -g -O2 -MT src/iniparser.lo -MD -MP -MF src/.deps/iniparser.Tpo -c src/iniparser.c  -fPIC -DPIC -o src/.libs/iniparser.o
libtool: compile:  gcc -DPACKAGE_NAME=\"cava\" -DPACKAGE_TARNAME=\"cava\" -DPACKAGE_VERSION=\"23db477\" "-DPACKAGE_STRING=\"cava 23db477\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DPACKAGE=\"cava\" -DVERSION=\"23db477\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD_H=1 -DHAVE_CURSES_H=1 -I. -DDEBUG -DHAVE_ALLOCA_H -DALSA -DPULSE -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw -DNCURSES -g -O2 -MT src/dictionary.lo -MD -MP -MF src/.deps/dictionary.Tpo -c src/dictionary.c -o src/dictionary.o >/dev/null 2>&1
libtool: compile:  gcc -DPACKAGE_NAME=\"cava\" -DPACKAGE_TARNAME=\"cava\" -DPACKAGE_VERSION=\"23db477\" "-DPACKAGE_STRING=\"cava 23db477\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DPACKAGE=\"cava\" -DVERSION=\"23db477\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD_H=1 -DHAVE_CURSES_H=1 -I. -DDEBUG -DHAVE_ALLOCA_H -DALSA -DPULSE -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw -DNCURSES -g -O2 -MT src/iniparser.lo -MD -MP -MF src/.deps/iniparser.Tpo -c src/iniparser.c -o src/iniparser.o >/dev/null 2>&1
/bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2 -version-info 4  -o libiniparser.la -rpath /usr/local/lib src/iniparser.lo src/dictionary.lo  -liniparser  -lpthread -lasound -lpulse-simple -lpulse -lm -lfftw3 -lncursesw -ltinfo
libtool: link: gcc -shared  -fPIC -DPIC  src/.libs/iniparser.o src/.libs/dictionary.o   -liniparser -lpthread -lasound -lpulse-simple -lpulse -lm -lfftw3 -lncursesw -ltinfo  -g -O2   -Wl,-soname -Wl,libiniparser.so.4 -o .libs/libiniparser.so.4.0.0
libtool: link: (cd ".libs" && rm -f "libiniparser.so.4" && ln -s "libiniparser.so.4.0.0" "libiniparser.so.4")
libtool: link: (cd ".libs" && rm -f "libiniparser.so" && ln -s "libiniparser.so.4.0.0" "libiniparser.so")
libtool: link: ar cru .libs/libiniparser.a  src/iniparser.o src/dictionary.o
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libiniparser.a
libtool: link: ( cd ".libs" && rm -f "libiniparser.la" && ln -s "../libiniparser.la" "libiniparser.la" )
make[1]: Leaving directory '/root/cava/iniparser'
make[1]: Entering directory '/root/cava'
gcc -DPACKAGE_NAME=\"cava\" -DPACKAGE_TARNAME=\"cava\" -DPACKAGE_VERSION=\"23db477\" -DPACKAGE_STRING=\"cava\ 23db477\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DPACKAGE=\"cava\" -DVERSION=\"23db477\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD_H=1 -DHAVE_CURSES_H=1 -I.  -DPACKAGE=\"cava\" -DVERSION=\"23db477\" -D_POSIX_SOURCE -D _POSIX_C_SOURCE=200809L -Iiniparser/src -DDEBUG -DHAVE_ALLOCA_H -DALSA -DPULSE -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw -DNCURSES -std=c99 -Wall -Wextra -Wno-unused-result -Wno-maybe-uninitialized  -g -O2 -MT cava-cava.o -MD -MP -MF .deps/cava-cava.Tpo -c -o cava-cava.o `test -f 'cava.c' || echo './'`cava.c
cava.c: In function ‘main’:
cava.c:230:6: warning: variable ‘flastd’ set but not used [-Wunused-but-set-variable]
  int flastd[200];
      ^~~~~~
mv -f .deps/cava-cava.Tpo .deps/cava-cava.Po
/bin/bash ./libtool  --tag=CC   --mode=link gcc -std=c99 -Wall -Wextra -Wno-unused-result -Wno-maybe-uninitialized  -g -O2 -L/usr/local/lib -Wl,-rpath /usr/local/lib  -o cava cava-cava.o  -liniparser -Liniparser/.libs -liniparser  -lpthread -lasound -lpulse-simple -lpulse -lm -lfftw3 -lncursesw -ltinfo
libtool: link: gcc -std=c99 -Wall -Wextra -Wno-unused-result -Wno-maybe-uninitialized -g -O2 -Wl,-rpath /usr/local/lib -o cava cava-cava.o  -L/usr/local/lib -Liniparser/.libs /usr/local/lib/libiniparser.so -lpthread -lasound -lpulse-simple -lpulse -lm -lfftw3 -lncursesw -ltinfo
make[1]: Leaving directory '/root/cava'
root@DietPi:~/cava# ./cava
Illegal instruction

Fourdee on 30 May 2018

Cava Odroid C2

Issue with FIFO.

~We'll need to use the older binary, which works fine. The newer binary requires CPU instructions/extensions which are not available on the C2: https://github.com/Fourdee/DietPi/issues/1340#issuecomment-393206263~
~I don't have the time + enough knowledge to edit the makefile/cava source to resolve at this time.~
🈴 C2 install test with latest commit + older binary
-- Cava 0.4 binary works if installed on its own,
-- + install of MPD+YMPD results in illegal instruction again...

--- debugging

🈴 Another C2 board

G_AGI alsa-utils libpulse0 libfftw3-3
INSTALL_URL_ADDRESS='https://dietpi.com/downloads/binaries/all/cava_0.4.2_arm64.deb'
wget "$INSTALL_URL_ADDRESS" -O file.deb
dpkg -i file.deb

-- 🈯️ cava

Install conf

            mkdir -p "$HOME"/.config/cava
            cp /DietPi/dietpi/conf/cava.conf "$HOME"/.config/cava/config

-- 🈴 cava

Same again with 0.6.1
-- 🈴 cava
🈺 Issue appears to be caused by enabling FIFO (MPD) in the config file

root@DietPi:~# cava
Illegal instruction
[  482.109328] cava[7876]: undefined instruction: pc=0000007f85d00000
[  482.109344] Code: 9e6703e8 aa0103f9 5280011a 5280003b (d53be057)

-- 🈯️ Confirmed, ROCK64 works fine at this stage

Fourdee on 30 May 2018

Extended and moved table to Wiki: https://github.com/Fourdee/DietPi/wiki/DietPi-Software-list

MichaIng on 12 Jan 2019

❤1 👍1

@MichaIng