Hello,
I am looking to package two applications that use Node.JS. This email will focus on one of the two.
Z-Wave JS UI https://zwave-js.github.io/zwave-js-ui/ https://github.com/zwave-js/zwave-js-ui
The application is, I believe, the only open source Z-Wave controller at this time. I had previously maintained the OpenZWave C++ library, but development on it has ceased. Z-Wave is a wireless protocol to control lights, switches, relays, or gather information for uses in home automation. I need to package Z-Wave JS UI to replace OpenZWave in use with the Domoticz application that I also package.
I first read the Node.JS Packaging Guidelines, but initially struggled to know how to generate the bundled tarballs. Luckily I stumbled upon the tool to do that via nodejs-packaging-bundler. After generating an initial RPM spec file I generated an RPM but it fails to install. Would anyone be able to help?
https://michael.cronenworth.com/RPMS/zwave-js-ui.spec https://michael.cronenworth.com/RPMS/zwave-js-ui-9.27.2-0.1.fc41.src.rpm
dnf install ... Problem: conflicting requests - nothing provides libc++_shared.so needed by zwave-js-ui-9.27.2-0.1.noarch from @commandline - nothing provides libc++_shared.so()(64bit) needed by zwave-js-ui-9.27.2-0.1.noarch from @commandline - nothing provides libc.musl-x86_64.so.1()(64bit) needed by zwave-js-ui-9.27.2-0.1.noarch from @commandline - nothing provides libc.so needed by zwave-js-ui-9.27.2-0.1.noarch from @commandline - nothing provides libc.so()(64bit) needed by zwave-js-ui-9.27.2-0.1.noarch from @commandline [...] snipped out 10 more lines similar to the above...
The second application is the Jellyfin web client. I currently package it via a bundled tarball generated with my own bash script using a local npm registry and using npm install. It builds offline, but I notice your packaging guidelines don't want to do it that way. I'll mold any knowledge gained with zwave-js-ui into jellyfin-web.
Thanks, Michael
On Sat, Nov 16, 2024 at 11:19 AM Michael Cronenworth mike@cchtml.com wrote:
Hello,
I am looking to package two applications that use Node.JS. This email will focus on one of the two.
Z-Wave JS UI https://zwave-js.github.io/zwave-js-ui/ https://github.com/zwave-js/zwave-js-ui
The application is, I believe, the only open source Z-Wave controller at this time. I had previously maintained the OpenZWave C++ library, but development on it has ceased. Z-Wave is a wireless protocol to control lights, switches, relays, or gather information for uses in home automation. I need to package Z-Wave JS UI to replace OpenZWave in use with the Domoticz application that I also package.
I first read the Node.JS Packaging Guidelines, but initially struggled to know how to generate the bundled tarballs. Luckily I stumbled upon the tool to do that via nodejs-packaging-bundler. After generating an initial RPM spec file I generated an RPM but it fails to install. Would anyone be able to help?
https://michael.cronenworth.com/RPMS/zwave-js-ui.spec https://michael.cronenworth.com/RPMS/zwave-js-ui-9.27.2-0.1.fc41.src.rpm
dnf install ... Problem: conflicting requests
- nothing provides libc++_shared.so needed by
zwave-js-ui-9.27.2-0.1.noarch from @commandline
- nothing provides libc++_shared.so()(64bit) needed by
zwave-js-ui-9.27.2-0.1.noarch from @commandline
- nothing provides libc.musl-x86_64.so.1()(64bit) needed by
zwave-js-ui-9.27.2-0.1.noarch from @commandline
- nothing provides libc.so needed by zwave-js-ui-9.27.2-0.1.noarch from
@commandline
- nothing provides libc.so()(64bit) needed by
zwave-js-ui-9.27.2-0.1.noarch from @commandline [...] snipped out 10 more lines similar to the above...
The second application is the Jellyfin web client. I currently package it via a bundled tarball generated with my own bash script using a local npm registry and using npm install. It builds offline, but I notice your packaging guidelines don't want to do it that way. I'll mold any knowledge gained with zwave-js-ui into jellyfin-web.
Thanks, Michael
I tried building and installing it. It worked for me. The only dependencies it had was nodejs
Troy
On 11/18/24 9:34 AM, Troy Dawson wrote:
I tried building and installing it. It worked for me. The only dependencies it had was nodejs
:(
I am using mock to build and I'm getting extra dependencies.
mock -r fedora-41-x86_64 --rebuild ./zwave-js-ui-9.27.2-0.1.fc41.src.rpm
I also tried against rawhide. Same thing. I tried outside of mock with rpmbuild and I get the same extra dependencies.
On Tue, Nov 19, 2024 at 9:30 AM Michael Cronenworth mike@cchtml.com wrote:
On 11/18/24 9:34 AM, Troy Dawson wrote:
I tried building and installing it. It worked for me. The only dependencies it had was nodejs
:(
I am using mock to build and I'm getting extra dependencies.
mock -r fedora-41-x86_64 --rebuild ./zwave-js-ui-9.27.2-0.1.fc41.src.rpm
I also tried against rawhide. Same thing. I tried outside of mock with rpmbuild and I get the same extra dependencies.
Could you provide some logs? Something seems like it's different about your setup, because I can also build the RPM just fine using mock from that SRPM.
On 11/19/24 8:45 AM, Stephen Gallagher wrote:
Could you provide some logs? Something seems like it's different about your setup, because I can also build the RPM just fine using mock from that SRPM.
Sure.
https://michael.cronenworth.com/RPMS/zwave-js-ui-mock-41-logs.tar.xz
I tried building on a separate Fedora 41 computer and the same dependencies were generated on it. I guess I'll try a brand new F41 VM to try and get a different result.
On Tue, Nov 19, 2024 at 11:46 AM Michael Cronenworth mike@cchtml.com wrote:
On 11/19/24 9:38 AM, Michael Cronenworth wrote:
I tried building on a separate Fedora 41 computer and the same dependencies were generated on it. I guess I'll try a brand new F41 VM to try and get a different result.
A fresh F41 VM also generates the extra dependencies.
I misunderstood what the original problem was. It builds just find, but the automatic dependency generator is picking up and adding dependencies for a lot of shared objects that don't actually exist in Fedora.
You'll need to look at https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndReq... for details on how to clean that up.
On 11/20/24 11:52 AM, Stephen Gallagher wrote:
I misunderstood what the original problem was. It builds just find, but the automatic dependency generator is picking up and adding dependencies for a lot of shared objects that don't actually exist in Fedora.
You'll need to look at https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndReq... for details on how to clean that up.
Thanks, Stephen. I was considering filtering out the requires but I wanted to make sure I was not doing something wrong.
It is one of the bundled libraries pulling in those requires. Adding a filter allows me to install the package and it does run. Yay.
Package review bug coming soon...
On Wed, Nov 20, 2024 at 2:37 PM Michael Cronenworth mike@cchtml.com wrote:
On 11/20/24 11:52 AM, Stephen Gallagher wrote:
I misunderstood what the original problem was. It builds just find, but the automatic dependency generator is picking up and adding dependencies for a lot of shared objects that don't actually exist in Fedora.
You'll need to look at
https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndReq...
for details on how to clean that up.
Thanks, Stephen. I was considering filtering out the requires but I wanted to make sure I was not doing something wrong.
It is one of the bundled libraries pulling in those requires. Adding a filter allows me to install the package and it does run. Yay.
Package review bug coming soon...
Be careful; if a bundled library is doing that, it probably means that it is precompiled. That will need to be corrected before the package can be approved.
On 11/20/24 1:38 PM, Stephen Gallagher wrote:
Be careful; if a bundled library is doing that, it probably means that it is precompiled. That will need to be corrected before the package can be approved.
It's the "@serialport" library. It provides pre-built binaries for multiple architectures. I'll look into it further. Thanks.
On 11/20/24 1:38 PM, Stephen Gallagher wrote:
Be careful; if a bundled library is doing that, it probably means that it is precompiled. That will need to be corrected before the package can be approved.
How should nodejs native binaries be built today? The guidelines reference node-gyp, but the package has been retired since 2020. The "@serialport" library uses C++ bindings and uses node-gyp to build them.
On 11/20/24 9:54 PM, Michael Cronenworth wrote:
How should nodejs native binaries be built today? The guidelines reference node-gyp, but the package has been retired since 2020. The "@serialport" library uses C++ bindings and uses node-gyp to build them.
I built a new spec for node-gyp using the latest guidelines and the latest version and it builds and works with building the @serialport bindings-cpp binary. I was able to build a zwave-js-ui package from source and the resulting package works with my Z-Wave controller. I can see my devices.
Would anyone on this list be available to resurrect node-gyp? I would offer, but my time, as anyone's, is limited. I would offer to push through a review, but maintenance would best be served by others.
nodejs@lists.fedoraproject.org
-
Michael Cronenworth -
Stephen Gallagher -
Troy Dawson