starred/uspot
1
0
Fork 0
mirror of https://github.com/f00b4r0/uspot.git synced 2026-04-26 06:35:54 +03:00
Code Issues 6 Projects Releases Packages Wiki Activity

[GH-ISSUE #56] build problems as of 389e48df4f #36

New issue
Closed
opened 2026-03-04 14:52:35 +03:00 by kerem · 7 comments
kerem commented 2026-03-04 14:52:35 +03:00
Owner
Copy link

Originally created by @systemcrash on GitHub (Dec 29, 2025).
Original GitHub issue: https://github.com/f00b4r0/uspot/issues/56

openwrt 25.12 compile problems. Seems like a bpf related change. Not certain:

uspot fused dependencies: ucode (>=, libc, conntrack, libblobmsg-json20251208, liblucihttp-ucode, libradcli, libubox20251208, libubus20251202, libuci20250120, uspotfilter, ucode-mod-log, ucode-mod-math, ucode-mod-nl80211, ucode-mod-rtnl, uhttpd-mod-ucode, ucode-mod-uloop, ucode-mod-bpf, ucode-mod-struct, kmod-sched-core, kmod-sched-bpf
uspot-www fused dependencies: libc, uspot
uspotfilter fused dependencies: ucode (>=, libc, conntrack, nftables-json, ucode-mod-rtnl, ucode-mod-uloop, ucode-mod-log
Not searching for unused variables given on the command line.
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.10 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.


-- The C compiler identification is GNU 14.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-14.3.0_musl/bin/aarch64-openwrt-linux-musl-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done (0.9s)
-- Generating done (0.1s)
-- Build files have been written to: /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df
ninja: Entering directory `/builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df'
ninja: warning: Ignoring jobserver: Pipe-based protocol is not supported! [--jobserver-auth=3,4]
[1/6] Building C object CMakeFiles/uam.dir/uam.c.o
[2/6] Linking C shared library libuam.so
[3/6] Building C object CMakeFiles/radius-client.dir/radius-client.c.o
In file included from /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:28:
/builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c: In function 'result':
/builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:212:43: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'uint64_t' {aka 'long unsigned int'} [-Wformat=]
  212 |                                 ULOG_NOTE("Ignoring unknown attribute in reply: %llu\n", vp->attribute);
      |                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~
      |                                                                                            |
      |                                                                                            uint64_t {aka long unsigned int}
/builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:212:84: note: format string is defined here
  212 |                                 ULOG_NOTE("Ignoring unknown attribute in reply: %llu\n", vp->attribute);
      |                                                                                 ~~~^
      |                                                                                    |
      |                                                                                    long long unsigned int
      |                                                                                 %lu
[4/6] Linking C executable radius-client
[5/6] Building C object CMakeFiles/uspot-das.dir/radius-das.c.o
[6/6] Linking C executable uspot-das
ninja: Entering directory `/builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df'
ninja: warning: Ignoring jobserver: Pipe-based protocol is not supported! [--jobserver-auth=3,4]
[0/1] Install the project...
-- Install configuration: "Release"
-- Installing: /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/ipkg-install/usr/sbin/radius-client
-- Installing: /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/ipkg-install/usr/sbin/uspot-das
-- Installing: /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/ipkg-install/usr/lib/libuam.so
ERROR: info field 'depends' has invalid value: dependency format is invalid
ERROR: failed to create package: dependency format is invalid
make[3]: *** [Makefile:136: /builder/shared-workdir/build/sdk/bin/packages/aarch64_cortex-a53/packages/uspotfilter-2025.11.20~389e48df-r1.apk] Error 99
time: package/feeds/packages/uspot/compile#1.80#1.01#5.50
Originally created by @systemcrash on GitHub (Dec 29, 2025). Original GitHub issue: https://github.com/f00b4r0/uspot/issues/56 openwrt 25.12 compile problems. Seems like a bpf related change. Not certain: ``` uspot fused dependencies: ucode (>=, libc, conntrack, libblobmsg-json20251208, liblucihttp-ucode, libradcli, libubox20251208, libubus20251202, libuci20250120, uspotfilter, ucode-mod-log, ucode-mod-math, ucode-mod-nl80211, ucode-mod-rtnl, uhttpd-mod-ucode, ucode-mod-uloop, ucode-mod-bpf, ucode-mod-struct, kmod-sched-core, kmod-sched-bpf uspot-www fused dependencies: libc, uspot uspotfilter fused dependencies: ucode (>=, libc, conntrack, nftables-json, ucode-mod-rtnl, ucode-mod-uloop, ucode-mod-log Not searching for unused variables given on the command line. CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required): Compatibility with CMake < 3.10 will be removed from a future version of CMake. Update the VERSION argument <min> value. Or, use the <min>...<max> syntax to tell CMake that the project requires at least <min> but has been updated to work with policies introduced by <max> or earlier. -- The C compiler identification is GNU 14.3.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-14.3.0_musl/bin/aarch64-openwrt-linux-musl-gcc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Configuring done (0.9s) -- Generating done (0.1s) -- Build files have been written to: /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df ninja: Entering directory `/builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df' ninja: warning: Ignoring jobserver: Pipe-based protocol is not supported! [--jobserver-auth=3,4] [1/6] Building C object CMakeFiles/uam.dir/uam.c.o [2/6] Linking C shared library libuam.so [3/6] Building C object CMakeFiles/radius-client.dir/radius-client.c.o In file included from /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:28: /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c: In function 'result': /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:212:43: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'uint64_t' {aka 'long unsigned int'} [-Wformat=] 212 | ULOG_NOTE("Ignoring unknown attribute in reply: %llu\n", vp->attribute); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ | | | uint64_t {aka long unsigned int} /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:212:84: note: format string is defined here 212 | ULOG_NOTE("Ignoring unknown attribute in reply: %llu\n", vp->attribute); | ~~~^ | | | long long unsigned int | %lu [4/6] Linking C executable radius-client [5/6] Building C object CMakeFiles/uspot-das.dir/radius-das.c.o [6/6] Linking C executable uspot-das ninja: Entering directory `/builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df' ninja: warning: Ignoring jobserver: Pipe-based protocol is not supported! [--jobserver-auth=3,4] [0/1] Install the project... -- Install configuration: "Release" -- Installing: /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/ipkg-install/usr/sbin/radius-client -- Installing: /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/ipkg-install/usr/sbin/uspot-das -- Installing: /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/ipkg-install/usr/lib/libuam.so ERROR: info field 'depends' has invalid value: dependency format is invalid ERROR: failed to create package: dependency format is invalid make[3]: *** [Makefile:136: /builder/shared-workdir/build/sdk/bin/packages/aarch64_cortex-a53/packages/uspotfilter-2025.11.20~389e48df-r1.apk] Error 99 time: package/feeds/packages/uspot/compile#1.80#1.01#5.50 ```
kerem 2026-03-04 14:52:35 +03:00
  • closed this issue
  • added the
    invalid
         label
kerem commented 2026-03-04 14:52:36 +03:00
Author
Owner
Copy link

@f00b4r0 commented on GitHub (Dec 29, 2025):

openwrt 25.12 compile problems. Seems like a bpf related change. Not certain:

This issue should be opened against https://github.com/openwrt/packages/blob/master/net/uspot/Makefile instead, it may gather more attention because I have no idea what's going on. uspot used to build just fine (I assume it was built tested when the package was last updated) and there was no recent change.

ERROR: info field 'depends' has invalid value: dependency format is invalid
ERROR: failed to create package: dependency format is invalid

I have no idea what that means, this looks like an OpenWrt-side change

<!-- gh-comment-id:3695655995 --> @f00b4r0 commented on GitHub (Dec 29, 2025): > openwrt 25.12 compile problems. Seems like a bpf related change. Not certain: This issue should be opened against https://github.com/openwrt/packages/blob/master/net/uspot/Makefile instead, it may gather more attention because I have no idea what's going on. uspot used to build just fine (I assume it was built tested when the package was last updated) and there was no recent change. > ERROR: info field 'depends' has invalid value: dependency format is invalid > ERROR: failed to create package: dependency format is invalid I have no idea what that means, this looks like an OpenWrt-side change
kerem commented 2026-03-04 14:52:36 +03:00
Author
Owner
Copy link

@systemcrash commented on GitHub (Dec 29, 2025):

Those warns for the logging look fixable here, though.

Thanks for uspot :)

BTW I added captive portal URI to both odhcpd and odhcp6c - I thought those might be of interest to you here.

<!-- gh-comment-id:3696605135 --> @systemcrash commented on GitHub (Dec 29, 2025): Those warns for the logging look fixable here, though. Thanks for uspot :) BTW I added captive portal URI to both odhcpd and odhcp6c - I thought those might be of interest to you here.
kerem commented 2026-03-04 14:52:36 +03:00
Author
Owner
Copy link

@f00b4r0 commented on GitHub (Dec 29, 2025):

Those warns for the logging look fixable here, though.

Sure but they are completely harmless. The build failure isn't though ;P

Thanks for uspot :)

BTW I added captive portal URI to both odhcpd and odhcp6c - I thought those might be of interest to you here.

Cool, good to know thanks

<!-- gh-comment-id:3696630115 --> @f00b4r0 commented on GitHub (Dec 29, 2025): > Those warns for the logging look fixable here, though. Sure but they are completely harmless. The build failure isn't though ;P > Thanks for uspot :) > > BTW I added captive portal URI to both odhcpd and odhcp6c - I thought those might be of interest to you here. Cool, good to know thanks
kerem commented 2026-03-04 14:52:36 +03:00
Author
Owner
Copy link

@BKPepe commented on GitHub (Dec 30, 2025):

CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.10 will be removed from a future version of
CMake.

It is going to be fixed by https://github.com/f00b4r0/uspot/pull/57

In file included from /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:28:
/builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c: In function 'result':
/builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:212:43: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'uint64_t' {aka 'long unsigned int'} [-Wformat=]
  212 |                                 ULOG_NOTE("Ignoring unknown attribute in reply: %llu\n", vp->attribute);
      |                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~
      |                                                                                            |
      |                                                                                            uint64_t {aka long unsigned int}
/builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:212:84: note: format string is defined here
  212 |                                 ULOG_NOTE("Ignoring unknown attribute in reply: %llu\n", vp->attribute);
      |                                                                                 ~~~^
      |                                                                                    |
      |                                                                                    long long unsigned int
      |                                                                                 %lu
[4/6] Linking C executable radius-client

PR created: https://github.com/f00b4r0/uspot/pull/58

Leaving warnings unresolved breaks the "clean build" principle and creates noise that hides real issues.

Casting to unsigned long long is a standard defensive practice for logging: it acts as a "catch-all" for any integer type up to 64 bits. If the underlying type changes to something smaller (e.g. uint32_t), the cast handles it safely. If it changes to a non-integer, the compiler will still flag it. I believe resolving the warning cleanly via a widening cast is safer than ignoring it.

uspot fused dependencies: ucode (>=, libc, conntrack, libblobmsg-json20251208, liblucihttp-ucode, libradcli, libubox20251208, libubus20251202, libuci20250120, uspotfilter, ucode-mod-log, ucode-mod-math, ucode-mod-nl80211, ucode-mod-rtnl, uhttpd-mod-ucode, ucode-mod-uloop, ucode-mod-bpf, ucode-mod-struct, kmod-sched-core, kmod-sched-bpf
uspot-www fused dependencies: libc, uspot
uspotfilter fused dependencies: ucode (>=, libc, conntrack, nftables-json, ucode-mod-rtnl, ucode-mod-uloop, ucode-mod-log

and this one:

ERROR: info field 'depends' has invalid value: dependency format is invalid
ERROR: failed to create package: dependency format is invalid

are connected and were fixed by merging https://github.com/openwrt/packages/pull/28221

<!-- gh-comment-id:3698733732 --> @BKPepe commented on GitHub (Dec 30, 2025): > CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required): > Compatibility with CMake < 3.10 will be removed from a future version of > CMake. It is going to be fixed by https://github.com/f00b4r0/uspot/pull/57 ______ ``` In file included from /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:28: /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c: In function 'result': /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:212:43: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'uint64_t' {aka 'long unsigned int'} [-Wformat=] 212 | ULOG_NOTE("Ignoring unknown attribute in reply: %llu\n", vp->attribute); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ | | | uint64_t {aka long unsigned int} /builder/shared-workdir/build/sdk/build_dir/target-aarch64_cortex-a53_musl/uspot-2025.11.20~389e48df/src/radius-client.c:212:84: note: format string is defined here 212 | ULOG_NOTE("Ignoring unknown attribute in reply: %llu\n", vp->attribute); | ~~~^ | | | long long unsigned int | %lu [4/6] Linking C executable radius-client ``` PR created: https://github.com/f00b4r0/uspot/pull/58 Leaving warnings unresolved breaks the "clean build" principle and creates noise that hides real issues. Casting to unsigned long long is a standard defensive practice for logging: it acts as a "catch-all" for any integer type up to 64 bits. If the underlying type changes to something smaller (e.g. uint32_t), the cast handles it safely. If it changes to a non-integer, the compiler will still flag it. I believe resolving the warning cleanly via a widening cast is safer than ignoring it. _____ ``` uspot fused dependencies: ucode (>=, libc, conntrack, libblobmsg-json20251208, liblucihttp-ucode, libradcli, libubox20251208, libubus20251202, libuci20250120, uspotfilter, ucode-mod-log, ucode-mod-math, ucode-mod-nl80211, ucode-mod-rtnl, uhttpd-mod-ucode, ucode-mod-uloop, ucode-mod-bpf, ucode-mod-struct, kmod-sched-core, kmod-sched-bpf uspot-www fused dependencies: libc, uspot uspotfilter fused dependencies: ucode (>=, libc, conntrack, nftables-json, ucode-mod-rtnl, ucode-mod-uloop, ucode-mod-log ``` and this one: ``` ERROR: info field 'depends' has invalid value: dependency format is invalid ERROR: failed to create package: dependency format is invalid ``` are connected and were fixed by merging https://github.com/openwrt/packages/pull/28221
kerem commented 2026-03-04 14:52:36 +03:00
Author
Owner
Copy link

@f00b4r0 commented on GitHub (Dec 30, 2025):

PR created: #58

Leaving warnings unresolved breaks the "clean build" principle and creates noise that hides real issues.

Casting to unsigned long long is a standard defensive practice for logging: it acts as a "catch-all" for any integer type up to 64 bits. If the underlying type changes to something smaller (e.g. uint32_t), the cast handles it safely. If it changes to a non-integer, the compiler will still flag it. I believe resolving the warning cleanly via a widening cast is safer than ignoring it.

Feel free to argument outside of the PR, and feel free to ignore my change request, I'll feel equally free to ignore your PR.

If the underlying type changes to say an array (a pointer), no warning will be emitted, you'll just get the pointer's address printed out.

uspot fused dependencies: ucode (>=, libc, conntrack, libblobmsg-json20251208, liblucihttp-ucode, libradcli, libubox20251208, libubus20251202, libuci20250120, uspotfilter, ucode-mod-log, ucode-mod-math, ucode-mod-nl80211, ucode-mod-rtnl, uhttpd-mod-ucode, ucode-mod-uloop, ucode-mod-bpf, ucode-mod-struct, kmod-sched-core, kmod-sched-bpf
uspot-www fused dependencies: libc, uspot
uspotfilter fused dependencies: ucode (>=, libc, conntrack, nftables-json, ucode-mod-rtnl, ucode-mod-uloop, ucode-mod-log

and this one:

ERROR: info field 'depends' has invalid value: dependency format is invalid
ERROR: failed to create package: dependency format is invalid

are connected and were fixed by merging openwrt/packages#28221

This suggests the new build system is incredibly brittle. Furthermore github.com/openwrt/packages@1352f3f006 will now make cherry-picking backports to 24.10 impossible. Thanks.

I now wonder what the PKG_MAINTAINER field is for if I don't get to review proposed changes.

<!-- gh-comment-id:3698807072 --> @f00b4r0 commented on GitHub (Dec 30, 2025): > > PR created: [#58](https://github.com/f00b4r0/uspot/pull/58) > > Leaving warnings unresolved breaks the "clean build" principle and creates noise that hides real issues. > > Casting to unsigned long long is a standard defensive practice for logging: it acts as a "catch-all" for any integer type up to 64 bits. If the underlying type changes to something smaller (e.g. uint32_t), the cast handles it safely. If it changes to a non-integer, the compiler will still flag it. I believe resolving the warning cleanly via a widening cast is safer than ignoring it. Feel free to argument outside of the PR, and feel free to ignore my change request, I'll feel equally free to ignore your PR. If the underlying type changes to say an array (a pointer), no warning will be emitted, you'll just get the pointer's address printed out. > > ``` > uspot fused dependencies: ucode (>=, libc, conntrack, libblobmsg-json20251208, liblucihttp-ucode, libradcli, libubox20251208, libubus20251202, libuci20250120, uspotfilter, ucode-mod-log, ucode-mod-math, ucode-mod-nl80211, ucode-mod-rtnl, uhttpd-mod-ucode, ucode-mod-uloop, ucode-mod-bpf, ucode-mod-struct, kmod-sched-core, kmod-sched-bpf > uspot-www fused dependencies: libc, uspot > uspotfilter fused dependencies: ucode (>=, libc, conntrack, nftables-json, ucode-mod-rtnl, ucode-mod-uloop, ucode-mod-log > ``` > > and this one: > > ``` > ERROR: info field 'depends' has invalid value: dependency format is invalid > ERROR: failed to create package: dependency format is invalid > ``` > > are connected and were fixed by merging [openwrt/packages#28221](https://github.com/openwrt/packages/pull/28221) This suggests the new build system is incredibly brittle. Furthermore https://github.com/openwrt/packages/commit/1352f3f006b15a85be3cabc0df4d92c2117b546f will now make cherry-picking backports to 24.10 impossible. Thanks. I now wonder what the `PKG_MAINTAINER` field is for if I don't get to review proposed changes.
kerem commented 2026-03-04 14:52:36 +03:00
Author
Owner
Copy link

@BKPepe commented on GitHub (Dec 30, 2025):

Feel free to argument outside of the PR, and feel free to ignore my change request, I'll feel equally free to ignore your PR.

Given that there were three distinct errors, we need a summary and a reference so this doesn't get lost. Regarding the warning: if you prefer not to address it now, that's fine. However, keep in mind that this warning will likely turn into an error eventually, requiring a rewrite down the line anyway. If you want to disregard the fixes in my PR, that's on you—but I won't be doing a full rewrite. We have already spent more time discussing this than the actual rewrite would require.

This suggests the new build system is incredibly brittle.

I actually disagree that the build system is 'incredibly brittle.' On the contrary, it correctly caught a bug introduced in commit github.com/openwrt/packages@bc33522715. Discussing the human factor is out-of-scope here; simply put, the issue is present in that commit. Since other packages don't have this extra space, I consider that matter settled.

Furthermore openwrt/packages@1352f3f will now make cherry-picking backports to 24.10 impossible. Thanks.

Regarding the backports to OpenWrt 24.10: I don't see why that would be impossible. I simply bumped PKG_RELEASE, moved EXTRA_DEPENDS, and removed the space. This shouldn't negatively impact anything. Have you tried it locally? I did, and it works fine.

<!-- gh-comment-id:3698872914 --> @BKPepe commented on GitHub (Dec 30, 2025): > Feel free to argument outside of the PR, and feel free to ignore my change request, I'll feel equally free to ignore your PR. Given that there were three distinct errors, we need a summary and a reference so this doesn't get lost. Regarding the warning: if you prefer not to address it now, that's fine. However, keep in mind that this warning will likely turn into an error eventually, requiring a rewrite down the line anyway. If you want to disregard the fixes in my PR, that's on you—but I won't be doing a full rewrite. We have already spent more time discussing this than the actual rewrite would require. > This suggests the new build system is incredibly brittle. I actually disagree that the build system is 'incredibly brittle.' On the contrary, it correctly caught a bug introduced in commit https://github.com/openwrt/packages/commit/bc33522715342e04461000fc119ec71df12514a1. Discussing the human factor is out-of-scope here; simply put, the issue is present in that commit. Since other packages don't have this extra space, I consider that matter settled. > Furthermore [openwrt/packages@1352f3f](https://github.com/openwrt/packages/commit/1352f3f006b15a85be3cabc0df4d92c2117b546f) will now make cherry-picking backports to 24.10 impossible. Thanks. Regarding the backports to OpenWrt 24.10: I don't see why that would be impossible. I simply bumped ``PKG_RELEASE``, moved ``EXTRA_DEPENDS``, and removed the space. This shouldn't negatively impact anything. Have you tried it locally? I did, and it works fine.
kerem commented 2026-03-04 14:52:36 +03:00
Author
Owner
Copy link

@f00b4r0 commented on GitHub (Dec 30, 2025):

This suggests the new build system is incredibly brittle.

I actually disagree that the build system is 'incredibly brittle.' On the contrary, it correctly caught a bug introduced in commit openwrt/packages@bc33522. Discussing the human factor is out-of-scope here; simply put, the issue is present in that commit.

If variables ordering can break the build, I consider that very brittle yes. The whitespace change should also have been documented and/or better handled: it used to work just fine.

Since other packages don't have this extra space, I consider that matter settled.

openwrt_packages(master)]% $ git grep EXTRA_DEPENDS | grep '>= '
mail/pigeonhole/Makefile:  EXTRA_DEPENDS:=dovecot (>= $(PKG_VERSION_DOVECOT))
<!-- gh-comment-id:3698909483 --> @f00b4r0 commented on GitHub (Dec 30, 2025): > > This suggests the new build system is incredibly brittle. > > I actually disagree that the build system is 'incredibly brittle.' On the contrary, it correctly caught a bug introduced in commit [openwrt/packages@bc33522](https://github.com/openwrt/packages/commit/bc33522715342e04461000fc119ec71df12514a1). Discussing the human factor is out-of-scope here; simply put, the issue is present in that commit. If variables ordering can break the build, I consider that very brittle yes. The whitespace change should also have been documented and/or better handled: it used to work just fine. > Since other packages don't have this extra space, I consider that matter settled. ``` openwrt_packages(master)]% $ git grep EXTRA_DEPENDS | grep '>= ' mail/pigeonhole/Makefile: EXTRA_DEPENDS:=dovecot (>= $(PKG_VERSION_DOVECOT)) ```
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
next
TIP
No results found.
Labels
Clear labels   
bug

   
enhancement

   
invalid

   
invalid

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
wontfix
No labels
bug
enhancement
invalid
invalid
pull-request
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/uspot#36
No description provided.