gnunet, libextractor: update to 0.29.0, 1.19

[dangowrt]

📦 Package Details

Maintainer: @dangowrt
_{(You can find this by checking the history of the package Makefile.)}

Description:
Two commits, clustered because gnunet-fs depends on libextractor; built and validated together.

libextractor 1.19 (from 1.14): adds RTF and msoffice plugins; fixes bugs/performance issues in the unzip logic, an offset calculation issue in the WAV extractor, minor memory leaks in the ELF extractor; adds OSS-Fuzz support. Also includes a 1.16 security fix (LIBEXTRACTOR_PREFIX honoured when linked into a SUID binary running as root) and a stack-overflow fix in the OLE2 plugin (1.15).

gnunet 0.29.0 (from 0.27.0, note: uscan still showed 0.28.0 as latest, but 0.29.0 was released upstream the same day this PR was prepared): new GNUNET_CURL_job_add_stream/job_set_paused, a documented single termination signal for GNUNET_PEERSTORE_Processor, a handshake nonce-selection bugfix, new GNUNET_TIME_round_up_utc/round_down_utc, a fix so GNUNET_static_assert actually asserts at compile time, and a namecache cache-drop API. 0.28.0 also switched several crypto primitives from gcrypt to libsodium and deprecated ECDSA in favour of EdDSA where applicable.

Refreshed 0005-meson-detect-libcurl-gnutls.patch (hunk offsets only).

---

🧪 Run Testing Details

• OpenWrt Version: SNAPSHOT (main, reboot-35870-gc0262ed5af)
• OpenWrt Target/Subtarget: x86/64
• OpenWrt Device: generic

---

✅ Formalities

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

If your PR contains a patch:

• It can be applied using git am
• It has been refreshed to avoid offsets, fuzzes, etc., using

  make package/<your-package>/refresh V=s

• It is structured in a way that it is potentially upstreamable
  _{(e.g., subject line, commit description, etc.)
  We must try to upstream patches to reduce maintenance burden.
  (No new patch content here, this is only a hunk-offset refresh of an existing local patch against the new upstream source.)}

[openwrt-ai]

Reviewed 2 new commits. Both commit messages match what their diffs do (version + hash + release reset for libextractor, version + hash + patch-offset refresh for gnunet), and PKG_RELEASE handling is correct in both.

Nothing here blocks a merge on its own — the one item that needs a look before this leaves draft is the gnunet build failure across all ten CI architectures, noted inline; the libextractor plugin remark is a nit.

---

Generated by Claude Code

[openwrt-ai]

All ten Feeds Package Test Build jobs on this head stop at the gnunet build, so no gnunet or libextractor package is produced on any architecture:

make: *** [/builder/include/toplevel.mk:226: package/gnunet/compile] Error 2
  make package/index
...
cp: cannot stat 'bin/packages/x86_64/packages_ci/*': No such file or directory
ls: cannot access '*.apk': No such file or directory

(verbatim from the x86_64 job; the arm_cortex-a9_vfpv3-d16 job fails at the identical target). The per-package output is only inside the run's *-logs artifact, so the actual compile/patch error is not visible in the job console — the kconfig "recursive dependency detected" lines further down are pre-existing noise, they also fire for PACKAGE_libcurl/LIBCURL_LDAP.

The commit message says this was built and validated on x86/64, so this may be an SDK-vs-tree gap rather than a defect in the bump; flagging it rather than calling it, since the log detail isn't reachable from here. One thing worth checking while the PR is still draft: whether 0005-meson-detect-libcurl-gnutls.patch still applies to the 0.29.0 meson.build — the refresh shifts all three hunks by exactly +3 lines, which would mean nothing between lines 197 and 492 of meson.build moved across two upstream releases.

---

Generated by Claude Code

[openwrt-ai]

nit: the commit message for this bump states that 1.19 "add[s] RTF and msoffice plugins", but the PLUGINS list at libs/libextractor/Makefile:30-54 is untouched, so libextractor_rtf.so / libextractor_msoffice.so are built but never packaged — no libextractor-plugin-rtf / libextractor-plugin-msoffice is generated, and the files are simply dropped. Is that deliberate (e.g. the msoffice plugin pulling in deps you don't want on target), or should the two entries be added to PLUGINS?

---

Generated by Claude Code

[dangowrt]

Checked the actual *-logs artifact (x86_64 run) — this is the same known blocker, not a gnunet-specific defect. The top-level error.txt says plainly:

ERROR: package/feeds/packages_ci/python3 [host] failed to build.

Gnunet's own check-refresh step completed cleanly (Successfully remade target file '.refresh', no errors/fuzz) — including 0005-meson-detect-libcurl-gnutls.patch, so the +3-line uniform hunk shift is exactly what it looks like: nothing in that range of meson.build moved between releases, not a masked failure. The real failure happens later, when host python3 fails to build as a transitive dependency somewhere else in the chain — the same ncursesw header-detection mismatch tracked in #30341. This PR should go green once that lands; nothing to fix here.

[dangowrt]

Real finding, thanks — checked upstream's src/plugins/Makefile.am: both plugins were built but never packaged.

• libextractor_rtf is unconditional, same group as the already-packaged riff/ps plugins — no new dependency.
• libextractor_msoffice only requires HAVE_ZLIB, same group as the already-packaged deb/odf/zip plugins — already satisfied, no new dependency either.

Added both to PLUGINS with no dependency suffix, matching their sibling plugins exactly. Folded into the same libextractor commit (kept isolated from the gnunet commit, which is otherwise untouched).

Not build-verified end to end — the same host python3/ncurses issue from the other thread means the build never reaches libextractor's own compile step at all right now. Static verification against upstream's build rules is what I have to go on until #30341 lands.

[openwrt-ai]

Re-reviewed at e105770. The only code change since 8f5ec2f is the two new PLUGINS entries in libs/libextractor/Makefile; the gnunet commit content is byte-identical to what I reviewed last time, so nothing new there. The added lines themselves look right — correct alphabetical position, tab + trailing \ matching their neighbours, and no dependency suffix, consistent with the other plugins in the same autoconf groups.

Commit checks

• e105770 "gnunet: update to 0.29.0" — the message still claims "Built and validated against the libextractor 1.19 bump in this branch (gnunet-fs depends on libextractor)", but the sibling commit 39cbe50 in the same series now states the opposite: "Not build-verified end to end in this environment ... the build never reaches libextractor's own compile step at all". CI at this head agrees with the second claim — every architecture stops at make: *** [/builder/include/toplevel.mk:226: package/gnunet/compile] Error 2 and produces no .apk, so neither package has actually been built here. Two commits in one series asserting opposite things about the same build is the kind of thing that gets noticed at merge time; the validation claim should be reworded or dropped.
• 39cbe50 "libextractor: update to 1.19" — subject and the version/hash/PKG_RELEASE/PLUGINS changes match, and the rationale for adding the two plugins is well documented. One thing to reconsider before this leaves draft: the closing paragraph is PR-review context ("Not build-verified end to end in this environment: blocked by ... #30341"), which will outlive the PR in git log where "this environment" has no referent and the issue link is only meaningful for a few weeks. That belongs in the PR description rather than the permanent commit message.

The CI failure itself I'm not re-flagging — I re-read the powerpc_8548 and x86_64 job logs at this head and the failing target is unchanged (package/gnunet/compile, not package/libextractor/compile), consistent with your read that host python3 blows up earlier in the dependency chain. Worth noting only that this means the new PLUGINS entries are the one part of the PR that CI has not exercised at all yet, since the run stops before libextractor is built — so a green run after #30341 lands is what would confirm libextractor_msoffice.so / libextractor_rtf.so really are produced under the current CONFIGURE_ARGS. PluginInstall uses $(INSTALL_BIN) on an exact path, so a naming or detection mismatch would fail the build loudly rather than silently, which is the good outcome.

---

Generated by Claude Code

[openwrt-ai]

nit: these two lines (and rtf at line 50) add two new binary packages — libextractor-plugin-msoffice and libextractor-plugin-rtf — but the PR body still describes 1.19 only as an upstream changelog ("adds RTF and msoffice plugins"), which reads as a description of the release rather than of a packaging change made here. Worth a line in the PR description before this leaves draft, so the new package names are visible without opening the commit.

Placement, indentation and the no-dependency-suffix form all match the surrounding entries (deb/odf/zip for the HAVE_ZLIB group, riff/ps for the unconditional group), and both stay in alphabetical order — no issue with the diff itself.

---

Generated by Claude Code

[dangowrt]

Both real, thanks:

• The gnunet commit's "Built and validated" claim was stale/wrong — dropped it, replaced with an honest statement matching what CI actually shows (blocked before gnunet/compile).
• Reworded both commits' closing paragraphs to be timeless — no PR-specific "in this environment" phrasing, no issue-number reference that goes stale. The specific pointer to python3: stop forcing the ncursesw/* header checks to "no" for the host build #30341 stays here in the PR thread where it belongs, not baked into permanent history.

git diff e105770..HEAD is empty — message-only rewrite on both commits, no tree changes.

[openwrt-ai]

Reviewed 2 new commits; no new issues found.

Confirmed your note: git diff e105770..4dfd38e is empty, so this is a message-only rewrite of both commits and the tree is byte-identical to what I reviewed at e105770. Both points from the last round are addressed:

• The contradiction is gone — 4dfd38e no longer claims the change was "built and validated", and both commits now carry the same "Not build-verified" statement, which matches what CI actually shows.
• Both closing paragraphs are now timeless: no "in this environment", no issue-number reference that goes stale in git log. The #30341 pointer stays here in the PR thread, which is the right place for it.

Commit messages match their diffs in both cases — version + hash + PKG_RELEASE reset to 1 and the two PLUGINS additions in 63e44f0, version + hash + patch offset refresh in 4dfd38e.

No CI observations this round: the three FormalityCheck jobs are green at this head and the ten build jobs are still queued, so there is nothing failing to attribute to this PR yet. The one thing a later run would still confirm is the msoffice/rtf plugin entries, since the build has not reached package/libextractor/compile in any run so far.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 2 new commits; no new issues found.

Since my last review at 4dfd38e, the head moved to 4a0b582 only through a rebase onto a newer master — git diff over the three PR paths (libs/libextractor/Makefile, net/gnunet/Makefile, net/gnunet/patches/0005-meson-detect-libcurl-gnutls.patch) is empty, so the tree is byte-identical to what I reviewed before. Both commit messages still match their diffs (libextractor: 1.14→1.19, PKG_RELEASE reset 2→1, hash, +msoffice/+rtf; gnunet: 0.27.0→0.29.0, hash, patch offset-only refresh).

What is new and worth recording: CI has now actually built this PR at the current head, which none of the earlier runs got to do. The Test mipsel_24kc job is green with the changeset PACKAGES: gnunet libextractor, and it produced the full package set including libextractor-plugin-msoffice-1.19-r1.apk and libextractor-plugin-rtf-1.19-r1.apk. That confirms the one part of the PR that static review couldn't — the two new PLUGINS entries really do build and get packaged under the current CONFIGURE_ARGS, with no new dependency needed.

Five of the ten build jobs are red, but I don't attribute those to this PR. On the failing arches the run gets past the build and well into the runtime-test phase over a much broader package set (perlbase-*, pgsql, pulseaudio, unbound, xz, zstd, …); gnunet and libextractor themselves build there too (the test phase would not otherwise run), and no Test failed marker lands on either of this PR's packages — the aggregate Some tests failed is raised by an unrelated package in that wider set. A defect in the gnunet bump or the new libextractor plugins would fail deterministically across all arches, not on 5 of 10 while mipsel_24kc builds them cleanly. Leaving the red-vs-green call to you, as before.

---

Generated by Claude Code