alde103
Issues compiling a nerves custom system with v1.29.1 (buildroot 2024.08.3)
Hello everyone, I believe this issue is more related to Buildroot version (2024.08.3) than to Nerves itself, but I would still like to hear your thoughts.
I am trying to upgrade my custom_system based on rpi4 from version 1.27 to 1.29.1. However, when I try to compile, I get the following error:
** (Mix) Nerves encountered an error while constructing the artifact
/home/alde/Documents/Elixir/Nerves/repos/valiot_system_rpi4/packages/cloudflared/cloudflared.mk:19: *** Package 'cloudflared' defined a second time in '/home/alde/Documents/Elixir/Nerves/repos/valiot_system_rpi4/packages/cloudflared'; previous definition was in 'package/cloudflared'. Stop.
make: *** [Makefile:23: _all] Error 2
It seems that in this new Buildroot version, the package I had manually added was included by default, causing a conflict. To resolve this, I had to rename the package (cloudflared → cloudflared-bin, since Buildroot does not have the latest version available). Everything seemed to work fine until another error appeared with the mosquitto package:
>>> mosquitto 2.0.19 Extracting
gzip -d -c /home/alde/.nerves/dl/mosquitto/mosquitto-2.0.19.tar.gz | /home/alde/Documents/Elixir/Nerves/repos/valiot_system_rpi4/.nerves/artifacts/valiot_system_rpi4-portable-1.29.1-valiot.16/host/bin/tar --strip-components=1 -C /home/alde/Documents/Elixir/Nerves/repos/valiot_system_rpi4/.nerves/artifacts/valiot_system_rpi4-portable-1.29.1-valiot.16/build/mosquitto-2.0.19 --no-same-owner -xf -
>>> mosquitto 2.0.19 Patching
Applying 0001-Revert-Fix-NetBSD-build.patch using patch:
The next patch would create the file lib/dummypthread.h,
which already exists! Skipping patch.
1 out of 1 hunk ignored
patching file lib/handle_pubackcomp.c
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file lib/handle_pubackcomp.c.rej
patching file lib/mosquitto_internal.h
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file lib/mosquitto_internal.h.rej
patching file lib/packet_mosq.c
Reversed (or previously applied) patch detected! Skipping patch.
15 out of 15 hunks ignored -- saving rejects to file lib/packet_mosq.c.rej
The next patch would delete the file lib/pthread_compat.h,
which does not exist! Skipping patch.
1 out of 1 hunk ignored
patching file lib/util_mosq.c
Reversed (or previously applied) patch detected! Skipping patch.
8 out of 8 hunks ignored -- saving rejects to file lib/util_mosq.c.rej
make[1]: *** [package/pkg-generic.mk:247: /home/alde/Documents/Elixir/Nerves/repos/valiot_system_rpi4/.nerves/artifacts/valiot_system_rpi4-portable-1.29.1-valiot.16/build/mosquitto-2.0.19/.stamp_patched] Error 1
make: *** [Makefile:23: _all] Error 2
It seems that in this Buildroot version, the patch doesn’t works. My question is: what would be the best way to handle this situation?
I could do the same as with the cloudflared package—create an external package for Buildroot (mosquitto-2), disable mosquitto (from Buildroot), and enable mosquitto-2. However, I’m not sure if that is the best approach. What do you think?
P.S. To check if there were other problematic packages, I removed mosquitto from the system, and the compilation completed successfully 
.
Most Liked
alde103
Just to wrap up the topic, I created a mosquitto-external package as an external Buildroot package. I copied the mosquitto package from the Buildroot 2024.11.2 release (which appears to have been updated to mosquitto 2.0.20), adjusted some environment variables to match the new package name, and it compiled successfully. 
Thanks, everyone!
jjcarstens
FWIW, both cloudflared and mosquito provide prebuilt binaries and I’ve used them with previous firmwares just downloading the version I need. It doesn’t answer the original question, but my preference is always prebuilt binaries over buildroot unless it’s absolutely required to use and compile myself
abelino
You can take a similar approach to what you did with cloudflared-bin by creating a new mosquitto package in your Nerves system under a different name. Thanks to Git history, you can easily retrieve a previous working version [0].
Alternatively, if you’re able to debug and fix the issue in the latest Mosquitto version, you could create a patch for it. Since Buildroot tends to lag behind on package versions, someone else might have already addressed the problem. The key is to find the relevant patch in the upstream project repo and incorporate it into your Nerves system.
Popular in Questions
Other popular topics
Latest Nerves Threads
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"