ripe-atlas: follow-up changes after PR which added package

[commodo]

📦 Package Details

Maintainer: @tiagogaspar8

Description:

Folow-up after PR #30030

---

🧪 Run Testing Details

• OpenWrt Version:
• OpenWrt Target/Subtarget:
• OpenWrt Device:

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

[openwrt-ai]

Reviewed 2 new commits; no new issues found.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 2 new commits; no new issues found.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit (cb42070). One inline finding on the busybox -fuse-ld= workaround — the commit message matches its diff.

---

Generated by Claude Code

[openwrt-ai]

Filtering only -fuse-ld=% treats a symptom, not the cause, so this likely does not close #30083. The bundled kbuild tree links built-in.o with $(LD) -nostdlib $(ld_flags) -r; busybox normally defines LD = $(CC) -nostdlib, but OpenWrt's default MAKE_FLAGS passes LD="$(TARGET_LD)" on the make command line, and TARGET_LD is ld.$(TARGET_LINKER) — the raw linker. This package sets no MAKE_FLAGS/MAKE_VARS of its own, so LDFLAGS reaches ld.bfd verbatim, and -fuse-ld=bfd is only one of several compiler-driver-only flags in there:

• hardening.mk:22 adds $(FPIC) -specs=$(INCLUDE_DIR)/hardened-ld-pie.specs under CONFIG_PKG_ASLR_PIE_ALL — -specs= triggers the exact same ld.bfd: -f may not be used without -shared message this patch is chasing.
• package.mk:57 adds -flto=auto -fuse-linker-plugin under CONFIG_USE_LTO.
• package.mk:52 adds -Wl,--gc-sections, which ld also does not understand.

The issue reporter tested this commit and reports the same failure, which matches the above. Restoring busybox's own LD looks like the more complete fix, e.g. instead of the filter-out:

# The bundled probe-busybox kbuild tree links built-in.o with "$(LD) -r" and
# passes LDFLAGS straight to it. It expects LD to be the compiler driver
# (busybox's own "LD = $(CC) -nostdlib"), but OpenWrt's MAKE_FLAGS point LD at
# ld.bfd, which chokes on -fuse-ld=/-specs=/-flto=/-Wl,... Restore the default.
MAKE_FLAGS += LD="$(TARGET_CC) -nostdlib"

(the later command-line assignment wins over the one in MAKE_FLAGS). Since I can't build this here, could you confirm which variant actually builds on the reporter's config before landing?

---

Generated by Claude Code

[openwrt-ai]

fixed, thanks — MAKE_FLAGS += LD="$(TARGET_CC) -nostdlib" is on master now.

---

Generated by Claude Code

[Copilot]

Pull request overview

This PR is a small follow-up for the net/ripe-atlas package, updating it to a newer upstream release and adjusting build packaging details to better fit the OpenWrt build environment.

Changes:

• Bump ripe-atlas from 5110 to 5120 (with updated source hash).
• Drop the now-unneeded uname patch (likely incorporated upstream).
• Filter -fuse-ld= out of TARGET_LDFLAGS to avoid failures with the bundled busybox build, and remove an explicit libopenssl dependency (still transitively pulled via OpenSSH packages).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
net/ripe-atlas/Makefile	Version/hash bump; adjust linker flags for bundled busybox; dependency cleanup.
net/ripe-atlas/patches/001-uname.patch	Removes a patch that is presumably upstreamed in the newer release.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[openwrt-ai]

Reviewed 1 new commit (f35064d); no new issues found.

The filter-out -fuse-ld=% workaround has been replaced with MAKE_FLAGS += LD="$(TARGET_CC) -nostdlib", which addresses my earlier comment — this restores the compiler driver that probe-busybox's kbuild expects instead of stripping one flag, so -specs=/-flto=/-Wl,... are covered too. The reporter confirmed this variant builds in #30083. The commit message matches its diff, and MAKE_FLAGS += with a duplicate LD= on the make command line is a pattern already in the feed (net/prosody/Makefile:52).

For the record on CI: the four red Feeds Package Test Build jobs on f35064d all failed at Prepare all required actions with Failed to resolve action download info. Error: Service Unavailable — GitHub Actions infrastructure, not this PR. No build output was produced.

---

Generated by Claude Code

[BKPepe]

I hope I will run test it soon, dont want to lose probe id, etc. :)

[BKPepe]

I have this still on my to do list, quite busy with Rust on PowerPC.

[openwrt-ai]

Reviewed 2 new commits (435ac50d, 0acbc94e). Both commit messages match their diffs — 435ac50d restores exactly the +libopenssl line that bf43fb10 removed (the PKG_RELEASE half of that commit was already superseded by the 5120 bump), and 0acbc94e does what its body describes.

Three inline findings, all on the new 80-ripe-atlas uci-defaults script: one migration path that is missed (keys restored via atlas-sw-probe's load_backup never live under /etc/atlas), one value-format mismatch between the two packages' boolean options that can leave the probe refusing to start, and a nit about how narrowly the old init is disabled. Only the first two look like they should block a merge; neither affects the build, and CI on 0acbc94e is green across all 12 targets.

---

Generated by Claude Code

[openwrt-ai]

A probe whose key was restored from a backup has nothing under /etc/atlas, so it falls out at the first guard and loses exactly the probe ID this script exists to preserve. atlas-sw-probe's load_backup wrote the restored pair straight to $SCRIPTS_DIR/etc/ — mv "$tmp_dir/probe_key" "$PRIV_KEY_FILE" at atlas.init:32-33, with PRIV_KEY_FILE="$SCRIPTS_DIR/etc/probe_key" = /usr/libexec/atlas-probe-scripts/etc/probe_key. Only create_key ever put a key under /etc/atlas, and it warned explicitly when the two were out of sync ("Missing probe_key in /etc/atlas … The key will be lost on sysupgrade"), which is the state a load_backup probe is left in.

Falling back to the scripts-dir path is harmless in the common case: there $SCRIPTS_DIR/etc/probe_key is a symlink to /etc/atlas/probe_key, so [ -f ] and cp see the same bytes.

Same hunk, minor: cp creates the private key with the caller's umask (0644 under the usual 022) and it is only tightened to 0600 two lines further down; creating it restricted from the start closes that window.

Suggested change

	migrate_key()
	{
	[ -f "${OLD_ETC}/probe_key" ] || return 0
	# Never clobber a key this package already registered with.
	[ -f "${NEW_ETC}/probe_key" ] && return 0
	cp "${OLD_ETC}/probe_key" "${NEW_ETC}/probe_key" || return 0
	[ -f "${OLD_ETC}/probe_key.pub" ] &&
	cp "${OLD_ETC}/probe_key.pub" "${NEW_ETC}/probe_key.pub"
	migrate_key()
	{
	local old_key="${OLD_ETC}/probe_key"
	# A probe restored with atlas-sw-probe's load_backup has its key only
	# under the scripts dir, with nothing in /etc/atlas.
	[ -f "${old_key}" ] ||
	old_key=/usr/libexec/atlas-probe-scripts/etc/probe_key
	[ -f "${old_key}" ] || return 0
	# Never clobber a key this package already registered with.
	[ -f "${NEW_ETC}/probe_key" ] && return 0
	(umask 077; cp "${old_key}" "${NEW_ETC}/probe_key") || return 0
	[ -f "${old_key}.pub" ] &&
	cp "${old_key}.pub" "${NEW_ETC}/probe_key.pub"

---

Generated by Claude Code

[openwrt-ai]

The values are copied verbatim, but the two packages disagree on what a valid value is, so a non-numeric boolean carried over here stops the probe from starting at all.

atlas-sw-probe read all three of these with config_get_bool, which goes through get_bool (functions.sh:159-168) and accepts on/true/yes/enabled and off/false/no/disabled as well as 0/1. ripe-atlas instead validates them as uinteger (ripe-atlas.init:11-16), and start_instance aborts the whole instance when validation fails (ripe-atlas.init:82-85). So a user who had option rxtxrpt 'yes' ends up with a migrated key and a probe that prints validation failed and never runs.

Normalising through get_bool keeps the migration lossless. /lib/functions.sh is sourced in both contexts a uci-defaults script is run from (default_postinst, and /etc/init.d/boot via rc.common), so get_bool is in scope; add an explicit . /lib/functions.sh at the top if you would rather not rely on that. The defaults below match the old init's own (0 for the log options, 1 for rxtxrpt).

Suggested change

	for option in log_stdout log_stderr; do
	value="$(uci -q get "atlas.common.${option}")" &&
	uci -q set "ripe-atlas.@ripe-atlas[0].${option}=${value}"
	done
	# atlas-sw-probe spelled this one without the underscore.
	value="$(uci -q get atlas.common.rxtxrpt)" &&
	uci -q set "ripe-atlas.@ripe-atlas[0].rxtx_report=${value}"
	for option in log_stdout log_stderr; do
	value="$(uci -q get "atlas.common.${option}")" &&
	uci -q set "ripe-atlas.@ripe-atlas[0].${option}=$(get_bool "${value}" 0)"
	done
	# atlas-sw-probe spelled this one without the underscore.
	value="$(uci -q get atlas.common.rxtxrpt)" &&
	uci -q set "ripe-atlas.@ripe-atlas[0].rxtx_report=$(get_bool "${value}" 1)"

---

Generated by Claude Code

[openwrt-ai]

nit: the commit message says "The old init script is stopped and disabled if it is still around", but this block sits behind both guards at the top of migrate_key, so it is only reached when a key is actually migrated. If /etc/atlas/probe_key is missing, or /etc/ripe-atlas/probe_key already exists, migrate_key returns early and a still-installed atlas-sw-probe keeps its rc.d symlink and keeps running next to ripe-atlas.

Intentional? The "same key" argument in the comment does not apply in those cases (each probe would present its own key), so leaving it scoped this way is defensible — but then the commit message overstates it. Otherwise the stop/disable would want to move out to the top level, next to the migrate_key / migrate_config calls.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 5 new commits; no new issues found.

The push from 0acbc94e to 9e1119ff is a rebase onto a newer master and nothing else — git range-diff reports all five commits as unchanged (bf43fb10→7dab1842, 0c872fe1→1352b67f, f35064d9→8d921995, 435ac50d→850c1b34, 0acbc94e→9e1119ff), and git diff 0acbc94e..9e1119ff -- net/ripe-atlas is empty. No net/ripe-atlas commits landed on master in the rebase range either, so nothing new to compare against. All 14 checks on 9e1119ff are green, including the 10 target builds and FormalityCheck.

The three findings from my previous review are still open and still apply verbatim to the unchanged files/ripe-atlas.defaults; I have not re-posted them.

---

Generated by Claude Code

[polonec-dev]

RIPE Atlas upstream is already at 5130 and they are currently asking downstream distributions to update older installations. Would it make sense to bump this PR directly to 5130?

[commodo]

RIPE Atlas upstream is already at 5130 and they are currently asking downstream distributions to update older installations. Would it make sense to bump this PR directly to 5130?

we can probably spin-off a separate PR for the version bump and some other minor things (from this PR);

[openwrt]

Formality Check: Suggestions Available

We checked this pull request against the contribution guidelines. Here is what needs your attention:

⚠️ STYLISTIC WARNINGS & SUGGESTIONS

Package Release Audit:

• ⚠️ Content changed in these packages, but without a PKG_RELEASE or version bump:

  • net/ripe-atlas

  Increment PKG_RELEASE by 1 (or bump PKG_VERSION/PKG_SOURCE_DATE and reset PKG_RELEASE to 1) so users receive the update.

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

---

_{Something broken? Consider reporting an issue.
Running version 059e3de deployed on 2026-09-09 11:53:18 CEST}

[commodo]

@BKPepe

did a version bump in #30501

simplified this PR to just one commit #30501

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

---

Generated by Claude Code