[Meson] Enter the edge examples only when nnstreamer is found

[myungjoo]

• What: fixes [nnstreamer-example] edgeAI_performance_benchmark is built without nnstreamer and fails to compile nnstreamer#5017 — with nnstreamer-edge installed and nnstreamer not, native/ fails to compile on a missing nnstreamer_plugin_api.h, because the edge examples are entered on nns_edge_dep alone while they also link nns_dep. On the way, it revives this repository's Tizen CI, which has not completed a run since August 2025: every job asked for the retired ubuntu-20.04 runner, stayed queued, and was cancelled after 24 hours.
• How: gate the edge block on both dependencies, plus a meson CI job that builds native/ with and without nnstreamer. Move the Tizen jobs to ubuntu-24.04, supplying what the Tizen SDK's package-name check needs there (python3.8 from deadsnakes, equivs name shims for three t64-renamed libraries), and pin the torch that the Yolo model export was written for.
• Result: all 10 checks pass on the head, including all 7 Tizen jobs, each uploading its tpk/wgt. With the meson fix reverted, the edge-only leg of the new job fails on the reported header while the other leg passes. The Debian and Tizen package builds are unaffected by the meson change — both always have nnstreamer.

Commits

1. [Meson] the fix. if nns_edge_dep.found() and nns_dep.found(), the way every other optional group in native/meson.build is gated on what its targets link. The failure looked like a missing include path rather than a missing dependency because nnstreamer-edge.pc sets includedir=/usr/include/nnstreamer, the directory nnstreamer-dev installs into.
2. [CI] meson job. Two matrix legs, the positive and negative halves of one gate: edge-only must build without the benchmarks, edge+nnstreamer must build them.
3. [CI] Tizen on ubuntu-24.04. Changing the label alone is not enough; the Tizen Studio package manager checks dependencies by package name, and noble fails that check twice (python3.8 is absent; libcurl3-gnutls, libglib2.0-0, libv4l-0 are only virtual after the t64 rename). Tizen Studio 6.1 asks for the same python3.8, so moving the SDK does not help. Both steps that run the package manager get the same block, as the file already duplicated the prerequisite list.
4. [CI] Yolo export. ultralytics==8.3.3 was pinned but its torch was not; torch 2.14's ONNX exporter needs onnxscript, and adding it only moves the failure to a SIGSEGV. torch 2.4.1 / torchvision 0.19.1 export successfully.

Note for maintainers: neither workflow gates merging until its checks are added to this repository's required status checks.

Context for agents

• #5017 was found by nnstreamer's Valgrind job; [CI/Valgrind] Memcheck the edge and query unit tests nnstreamer#5005 removes nnstreamer-edge-dev before the example build as a workaround, with a comment pointing at the issue. Those lines can go once this lands.
• Negative control for commit 2: the meson workflow run on a fork branch with commit 1 reverted fails in the edge-only leg at meson compile with fatal error: nnstreamer_plugin_api.h: No such file or directory.
• libpython2.7 is dropped: noble lacks it, and only the gcc-9.2 gdb binaries link it (readelf -d over the installed SDK tree), which these jobs never run. libtinfo5, needed by the bundled llvm-10 clang and also absent on noble, needs nothing: the SDK ships webkit-prerequisites/libtinfo5_*.deb and installs it itself. On jammy it does not, and the build fails on libtinfo.so.5 unless the distribution package is installed — one reason 22.04 was not the easier target.
• The equivs shims only satisfy the SDK's name check; the real libraries are the *t64 packages. Drop the shims and deadsnakes once Tizen Studio supports noble.
• Verification: the native job's steps run verbatim on a clean ubuntu:24.04 as a non-root user with sudo (the installer refuses root) up to a built binary; then the full PR run.
• torch A/B on real ubuntu-24.04 runners, same step with only the extra pip arguments varied: onnxscript → exit 139, torch==2.4.1 torchvision==0.19.1 → yolov8s_float32.tflite.
• Evidence for the SDK claims comes from ubuntu:24.04 / ubuntu:22.04 containers, not from this PR's CI: the package manager's failure lists on each distribution (libpython3.8 python3.8 with Tizen Studio 5.6 and 6.1 alike; then libcurl3-gnutls libglib2.0-0 libv4l-0 on noble; rpm2cpio acl cpio make on a bare jammy), readelf -d over the installed tree for the libpython2.7 / libpython3.8 / libncurses consumers, and dpkg -l + ldd of the bundled clang showing libtinfo5 6.3-2ubuntu0.1 installed from webkit-prerequisites/ on noble.
• web keeps the default fail-fast, so one failing leg cancels the others; a single-job rerun inherits the sibling failure and is cancelled at once. Not changed here.
• actionlint on tizen-build.yml still reports SC2086 info for the unquoted $TIZEN_STUDIO_URL; pre-existing, untouched.

🤖 Generated with Claude Code

[myungjoo]

Relayed review: this was produced by a separate reviewing agent and posted on its behalf.

Summary: this PR fixes nnstreamer/nnstreamer#5017 (build fails when nnstreamer-edge is installed but nnstreamer is not) and adds CI coverage for it. I checked the fix against the issue, the rest of native/meson.build, debian/control, the top-level meson.build dependency declarations, and validated the new workflow with actionlint and against the actual package availability in ppa:nnstreamer/ppa. I did not find any blocker or major issue.

Does it solve the stated problem?
Yes. if nns_edge_dep.found() and nns_dep.found() in native/meson.build is exactly the fix suggested in issue #5017, and it matches the convention already used by every other optional group in that file (gate on what the targets actually link — see example_early_exit/meson.build's own internal if nns_dep.found()). Re-indenting the nested nntrainer_dep block so it visibly sits inside the outer if is a correct, minimal, in-scope cleanup bundled with the block it touches.

Regression risk / other modules
None found. For the common case where both nnstreamer and nnstreamer-edge are installed, nns_dep.found() is true, so edgeAI_performance_benchmark (and example_training_offloading, when nntrainer is present) is entered exactly as before — no behavior change for users who already have a complete install. The Debian package build is unaffected, since debian/control already build-depends on nnstreamer-dev and nnstreamer-edge-dev together. No other module or file is touched.

Code size / scope
Appropriately small: the functional fix is a 4-line change to a single file. The new .github/workflows/meson-build.yml (50 lines) is scoped entirely to testing this fix and does not touch any other workflow or module.

Test coverage (minor, non-blocking observations)
The new workflow is a good regression test: it builds native/ in both the "edge + nnstreamer" and "edge only" configurations and asserts the two benchmark binaries are present/absent accordingly. I confirmed with actionlint that the YAML is syntactically valid, and via the Launchpad API that nnstreamer-dev and nnstreamer-edge-dev are both published for ubuntu-22.04/jammy in ppa:nnstreamer/ppa, so the job should behave as intended.

Two things worth flagging, both minor:

1. example_training_offloading (the nntrainer-gated branch nested inside the same block this PR fixes) is not exercised by either matrix leg, since nntrainer isn't published in ppa:nnstreamer/ppa. This is disclosed in the PR description, so it's not a blocker, but it means a future change that similarly desyncs that nested block's gate from what it links would not be caught by this new CI job.
2. The commit/PR description says the "yes" leg "builds six targets," but by my count it's seven: example_cam (1) + example_sink (2) + example_data_preprocessing_for_training (1) + example_early_exit (1, since nns_dep is found and the C-API packages aren't installed) + edgeAI_performance_benchmark (2). This doesn't affect correctness — the verification step checks presence/absence of the two edge binaries specifically, not a total count — it's just a narrative inaccuracy (nit).

Will a future-breaking CI failure actually block merge?
This is a minor point for maintainers rather than the PR author: adding the workflow only makes it run and report a status; whether it gates merging depends on this new check being added to the repository's required-status-checks list in branch protection, which isn't something this PR can configure. Worth a follow-up to make sure this check is marked required.

Architecture / API / docs
No architecture or public API changes here, and I didn't find any existing documentation describing the native/ meson dependency gating that would need a corresponding update.

Overall: no blockers or major issues. The two points above are minor/nit and don't need to hold up the PR.

[myungjoo]

Relayed review: this was produced by a separate reviewing agent and posted on its behalf.

This is round 2, re-checking the follow-up to the first review against the current head (792b0d4). The diff itself is unchanged from what that review covered (native/meson.build gate fix + .github/workflows/meson-build.yml, confirmed via gh pr diff 371 and gh api .../pulls/371/commits); only the commit messages and PR description were reworded, so this round focuses only on whether the two minor/nit items from round 1 were actually addressed.

1. Target-count nit — fixed (was nit). The PR description and the second commit message now say the two configurations build "seven and four targets" instead of the original "six." I recounted independently from each subdirectory's meson.build (example_cam=1, example_sink=2, example_data_preprocessing_for_training=1, example_early_exit=1 when nns_dep is found and 0 otherwise since it's gated on nns_dep.found(), edgeAI_performance_benchmark=2): edge+nnstreamer leg = 7, edge-only leg = 4. The corrected numbers are accurate and match the matrix order in the PR body. Resolved.

2. Required-status-checks caveat — addressed (was minor). The PR body now includes: "Note for maintainers: the job reports a status but does not gate merging until it is added to this repository's required status checks." That's exactly the concern raised in round 1 (a new workflow reporting green doesn't by itself block a future regression from merging) — flagged clearly for maintainers to act on when merging. No further action expected from the PR author.

3. example_training_offloading/nntrainer coverage gap — unchanged, still a disclosed limitation (minor, non-blocking). As in round 1, neither matrix leg installs nntrainer, so the nested if nntrainer_dep.found() branch inside the fixed block is still untested by this new CI job. This was already disclosed in the "Context for agents" section in round 1 and remains disclosed now; it isn't something this PR can fix given nntrainer isn't published in ppa:nnstreamer. Restating only so it isn't lost — not a blocker.

CI status on 792b0d4: both new jobs ("native examples (nnstreamer-edge only)" and "native examples (nnstreamer and nnstreamer-edge)") are green on the current head, confirming the fix and the regression test both work as described.

No remaining blocker, major, or minor issues beyond the disclosed (and unfixable within this PR) nntrainer coverage gap noted above. This PR is mergeable from a code-review standpoint.

[myungjoo]

Relayed review: this was produced by a separate reviewing agent and posted on its behalf. It is not a committer approval, and the PR is still a draft carrying DO NOT MERGE.

This is round 3. Rounds 1 and 2 already stand on this PR; rather than restating them, this round re-derives the conclusions independently at head 792b0d45 and adds the checks those rounds did not make.

Verdict

No blocking issue. The fix is correct and minimal, and the new job detects the regression it targets. Three non-blocking notes.

Independently verified

• The gate matches what the targets link. Both executables in native/edgeAI_performance_benchmark/meson.build and the one in native/example_training_offloading/meson.build list nns_dep in dependencies:, so if nns_edge_dep.found() and nns_dep.found() is exactly the condition those targets need. The nested-block change is indentation only; meson if bodies are not whitespace-sensitive, so it carries no semantic change.
• No residual instance of this defect class. Enumerating every dependencies: list under native/: after this PR, every reachable target that links nns_dep is gated on nns_dep.found() — either here (the edge block) or inside its own file (example_early_exit/meson.build:2, example_query_object_detection/meson.build:2). The two ungated ones, example_repo_custom_easy and example_tensor_mux, are the commented-out TODO lines in native/meson.build, so they are unreachable. Nothing else in the tree still needs the same treatment.
• The target counts are right. Recomputed from each subdirectory: example_cam 1 + example_sink 2 + example_data_preprocessing_for_training 1 + example_early_exit 1 (the C-API packages are not installed, so only the first of its two targets) + edgeAI_performance_benchmark 2 = 7, and 4 without nnstreamer-dev because example_early_exit is itself gated on nns_dep.found(). The matrix order in the body matches.
• Debian is unaffected, as claimed: debian/control build-depends on nnstreamer-dev and nnstreamer-edge-dev together, and debian/nnstreamer-example.install globs /usr/lib/nnstreamer/bin/* rather than naming the binaries.
• Tizen is unaffected too — not covered by the earlier rounds. packaging/nnstreamer-example.spec:27 has BuildRequires: pkgconfig(nnstreamer) unconditionally, while nnstreamer-edge-devel (line 45) sits behind %if 0%{?nnstreamer_edge_support}. So nns_dep.found() is true in every Tizen build configuration and the new conjunct can never subtract a target there; %files globs %{nnstexampledir}/*, so there is no explicit file list that an absent binary could break.
• The verification step really fails the job. GitHub runs run: blocks with bash -e, and test -x / test ! -e are the last commands of an if branch rather than a condition, so set -e applies and a mismatch aborts the step instead of being swallowed by the loop.
• CI on 792b0d45: both legs green in ~40 s.

NITs (non-blocking)

1. .github/workflows/meson-build.yml:1 — the workflow declares no permissions: block, so for push and same-repo pull_request events it inherits the repository default GITHUB_TOKEN scope. Impact: a build-only job holds a token wider than it needs; permissions: contents: read is a one-line fix. (tizen-build.yml has none either, so this is new-file hygiene rather than an inconsistency.)
2. .github/workflows/meson-build.yml:40 — in the regression this PR targets, the "Check which examples the edge dependency brought in" step never runs: reverting the gate makes meson compile fail first, so the build step is the actual detector. The check step guards the opposite mistake — a gate too strict to enter the block, caught by test -x in the yes leg. Impact: none on detection power in either direction; only the step name suggests it is doing work it does not do in the reverted case.
3. example_training_offloading is still unexercised by either leg, since nntrainer is not published in ppa:nnstreamer. Already disclosed in the body; restated only because it is the one nested block whose gate this PR re-indented, so a future desync there stays uncaught. Impact: the coverage gap is the same one that exists today, not one this PR introduces.

Out of scope, for maintainers

tizen-build.yml pins runs-on: ubuntu-20.04. On this PR all seven of its jobs sit at pending with 0 s and never start, which is consistent with that runner label no longer being served. That is why "nothing in this repository builds the meson tree today" holds in practice, and it means the job this PR adds will be the only workflow here that actually runs until those labels are bumped. Not this PR's to fix, but worth a separate issue.

[myungjoo]

Relayed review: this was produced by a separate reviewing agent and posted on its behalf. It is not a committer approval, and the PR is still a draft carrying DO NOT MERGE.

This is round 4, at head 33fd009. Rounds 1-3 already cover commit 1 (the meson gate fix) and commit 2 (the meson-build.yml regression job); this round does not restate those and focuses on the two new commits — 3 ([CI] Run the Tizen app builds on ubuntu-24.04) and 4 ([CI] Pin torch for the Yolo model export) — plus checking that commit 2's round-3 NITs were actually applied.

Verified independently

• All 10 checks are green on 33fd009, confirmed via gh api .../commits/33fd009.../check-runs: DCO, csharp x2, native (yolo_model_training), native examples x2, web x4. tizen-build.yml's native matrix has a single app (yolo_model_training), web has 4 apps, csharp has 2 — 1+4+2 = 7, matching the PR body's "all 7 Tizen jobs" claim.
• Commit 2's round-3 NITs are both applied. Diffing the current meson-build.yml against what round 3 reviewed: it now declares permissions: / contents: read at the top level, and the verification step is renamed from "Check which examples the edge dependency brought in" to "Check that the built examples match the dependencies" — exactly the two NITs raised in round 3. No other change to that file.
• The t64/equivs mechanism actually runs as described. Pulled the full log of the native (yolo_model_training) job (gh run view ... --job 107132651917 --log). It shows two distinct things happening for libcurl3-gnutls/libglib2.0-0/libv4l-0: (1) apt resolves the plain apt-get install request for those names to the real *t64 packages already on the runner image ("libcurl3t64-gnutls is already the newest version", "... set to manually installed"), and (2) tizen-sdk-prerequisites.sh separately builds and installs empty equivs packages literally named libcurl3-gnutls/libglib2.0-0/libv4l-0 at version 99:0 ("dpkg-buildpackage: info: source package libcurl3-gnutls" -> "Unpacking libcurl3-gnutls (99:0)" -> "Setting up libcurl3-gnutls (99:0)"). So the design is not redundant: apt satisfies the real runtime library via virtual Provides resolution, and the equivs shim separately satisfies whatever literal-name lookup Tizen Studio's package manager performs; the two package names coexist without conflict since the shim ships no files.
• python3.8 is real and comes from deadsnakes as claimed. Same log shows ppa:deadsnakes/ppa added, then python3.8, libpython3.8, libpython3.8-minimal, libpython3.8-stdlib at 3.8.20-1+noble1 installed without error, and the subsequent package-manager-cli.bin install NativeToolchain-Gcc-9.2 NativeCLI TIZEN-8.0 TIZEN-8.0-NativeAppDevelopment completes ("Installation has been completed.") and produces a built/packaged .tpk.
• Torch pin (commit 4) does fix the export, confirmed end-to-end. The web (ImageClassificationOffloadingYolo) job log shows pip install ultralytics==8.3.3 torch==2.4.1 torchvision==0.19.1 succeeding, and no onnxscript appears anywhere in the installed-package list. The export step logs "ONNX: export success", "TensorFlow SavedModel: export success", and "TensorFlow Lite: export success ... yolov8s_float32.tflite". This is a real, positive confirmation that the pinned versions work on ubuntu-24.04, not just a claim.
• Scope is minimal for both commits. Commit 3 touches only tizen-build.yml (label bump + de-duplicating the prerequisite list into a new script) and the new tizen-sdk-prerequisites.sh; commit 4 is a single-line version pin inside the one if: matrix.app == 'ImageClassificationOffloadingYolo' step. Neither touches unrelated jobs, and (checked) neither native/meson.build, debian/control, nor packaging/nnstreamer-example.spec is touched by these two commits.
• No stale documentation found. Checked Tizen.native/README.md, Tizen.web/README.md, Tizen.web/ImageClassificationOffloadingYolo/README.md, get_tflite_model.py, and bash_script/example_yolo/README.md (the only other place ultralytics/pip install appears) for anything asserting the old runner OS, libpython2.7, or an unpinned torch version — none of them mention CI environment details or version pins, so nothing is left inconsistent by this change.

Could not verify (stated as such per the review instructions)

• libtinfo5 self-install by the SDK. Neither the native job log nor the web (ImageClassificationOffloading) job log (which also runs tizen-sdk-prerequisites.sh for the hybrid native build) contains any line mentioning "tinfo" at all — not an installation, not an error. The build succeeds either way, which is consistent with the commit message's claim that the SDK bundles and silently installs its own webkit-prerequisites/libtinfo5_*.deb, but package-manager-cli.bin's own package installation progress is a black-box progress bar in the log, so this could not be positively confirmed from CI output alone.
• libpython2.7 being needed only by the gcc-9.2 gdb binaries. This rests on a local readelf -d inspection of the installed SDK tree (per the PR's "Context for agents" section), which this review has no way to redo from the GitHub-hosted CI logs. No contrary evidence either — the build completes without it — but this specific claim is taken on trust.
• Tizen Studio 6.1 also requiring python3.8. Not exercised anywhere in this PR (the PR stays on 5.6), so nothing in this PR's CI can confirm or refute it.
• The torch 2.14 + onnxscript -> SIGSEGV failure mode. This PR's CI only contains the fixed (pinned) path; there is no negative-control job in this PR reproducing the crash. The PR body says this was validated via a throwaway fork workflow outside this PR, which is a reasonable way to validate a pin without permanently carrying a failing job, but it means this repository's CI history alone does not contain independent proof of the crash. Not a blocker — the fix is minimal, plausible (torch's ONNX exporter did start requiring onnxscript around that version range), and the positive result is fully verified above — just noting the gap as instructed.

Notes (non-blocking)

1. Minor — tizen-sdk-prerequisites.sh adds a new third-party APT source (ppa:deadsnakes/ppa) to CI. This is a reasonable and disclosed way to get python3.8 on noble (deadsnakes is a long-standing, widely-used PPA and there is no upstream noble package), and the risk is CI-only/ephemeral-runner scoped, but it is a new trust-surface addition worth maintainers being aware of.
2. Nit — the equivs shims are built at a synthetic Version: 99:0 (epoch 99). That's fine for this workflow (nothing installs real libcurl3-gnutls/libglib2.0-0/libv4l-0-named packages afterward), but if a future step in the same job ever ran a plain apt-get install naming one of those three packages again, the inflated epoch could interact oddly with version constraints. Not a problem today since no such step exists after the prerequisite install in either job that calls this script.

Verdict

No blocker or major issues found in commits 3 and 4. The Tizen-runner-recovery approach is verifiable where CI evidence exists (the t64/equivs mechanism, the python3.8 install, and the torch pin's actual export success are all directly confirmed in the run logs) and honestly scoped where it isn't (the libtinfo5 self-install and the pre-fix SIGSEGV are asserted, not reproduced, in this PR's own CI — flagged above as unverifiable rather than assumed true). Commit 2's round-3 NITs are both genuinely resolved. No remaining issues beyond the two non-blocking notes above.

[myungjoo]

Relayed review: this was produced by a separate reviewing agent and posted on its behalf. It is not a committer approval, and the PR is still a draft carrying DO NOT MERGE.

This is round 5, at head 8949373. Rounds 1-4 found no remaining issues as of head 33fd009. The only change since then is commit 6f1b674, which inlines the removed .github/scripts/tizen-sdk-prerequisites.sh into the two tizen-build.yml steps that used it (native's "Install Tizen Studio" and web's "Build native service and create hybrid application"), per maintainer request to match the file's existing style of duplicating the prerequisite list across steps rather than sharing it through a helper. This round is scoped to that inlining only; the intentional duplication itself is not flagged.

Verified:

• The two inlined copies are byte-identical to each other.
• Diffing the whole workflow file against the pre-inlining version (33fd009) shows the only change in either step is the bash .../tizen-sdk-prerequisites.sh line being replaced by the script's former body; nothing else in either step moved or changed.
• The new printf '%s\n' "line1" "line2" ... form produces the same six-line equivs control file as the old script's single printf 'line1\nline2\n...%s...' "${name}" call, since printf recycles its format string over each positional argument. This is confirmed at runtime: the actual job logs show Unpacking libcurl3-gnutls (99:0), libglib2.0-0 (99:0), libv4l-0 (99:0) in both steps, i.e. the shim .debs were built and installed correctly.
• All 10 checks pass on 8949373 (gh pr checks 371). Pulled the raw logs for the native (yolo_model_training) job and the web (ImageClassificationOffloading) job: both "Install Tizen Studio" / "Build native service and create hybrid application" steps actually executed the inlined block (deadsnakes PPA added, python3.8/libpython3.8 installed, the three equivs shims built and dpkg -i'd) rather than being skipped, with the identical install sequence in both.
• Commit 6f1b674's message no longer carries the superseded 78374b57's closing line ("The two copies of the prerequisite list move into one script."), so it doesn't describe a helper script that no longer exists. The PR body's commit-3 bullet was likewise updated to "Both steps that run the package manager get the same block, as the file already duplicated the prerequisite list" - consistent with the new structure; no stale references to the removed script file were found anywhere in the body.

Findings:

1. (minor) Loss of an isolated staging directory for the equivs .deb build. The old script built the three shim .debs in a dedicated ${RUNNER_TEMP:-/tmp}/tizen-sdk-shims/ directory before dpkg -i "${workdir}"/*.deb. The inlined version writes the .ctl/.deb files straight into ${RUNNER_TEMP} and then runs sudo dpkg -i "${RUNNER_TEMP}"/*.deb. On today's job graphs this is harmless - nothing else in either the native job or the web job's ImageClassificationOffloading leg drops a .deb into $RUNNER_TEMP before this step runs, and the logs confirm exactly the three intended shims get unpacked - but the wildcard is no longer scoped to files this step created. A .deb placed into $RUNNER_TEMP by some step added earlier in either job in the future would silently get dpkg -i'd as well. Since this narrows an existing safety margin without a stated reason, restoring a one-line subdirectory (e.g. mkdir -p "${RUNNER_TEMP}/tizen-sdk-shims" and using it in the two paths that follow) would bring back the original isolation at negligible cost.

2. (nit) sudo apt update / sudo apt install replaces the old script's apt-get update / apt-get install. Debian/Ubuntu guidance is to prefer apt-get/apt-cache in scripts because apt's CLI is documented as unstable across versions; it works today (confirmed in the logs) and is a purely cosmetic deviation from the script it replaces, not a functional one.

No blocker or major issues found in the inlined block. Both copies are equivalent to each other and to the script they replace, and the CI run logs show the substitution behaves identically at runtime.

[myungjoo]

Relayed review: this was produced by a separate reviewing agent and posted on its behalf. It is not a committer approval, and the PR is still a draft carrying DO NOT MERGE.

This is round 6, at head 358882a. Scope per the requester: only re-check (a) whether round 5's minor finding (loss of an isolated staging directory for the equivs shim .debs) was correctly addressed, and (b) whether leaving round 5's nit (apt/apt install instead of apt-get) unaddressed is justified. Everything else covered in rounds 1-5 is not repeated here. Commits 1, 2 and 4 are unchanged since round 5; only commit 3 (3167817f, "[CI] Run the Tizen app builds on ubuntu-24.04") changed.

Verified:

• Diffed .github/workflows/tizen-build.yml at 358882a against nnstreamer/nnstreamer-example@main. The only functional change versus round 5's version of this file is the two equivs-shim blocks each gaining shims="${RUNNER_TEMP}/tizen-sdk-shims", mkdir -p "${shims}", writing the .ctl/.deb files under ${shims}, and sudo dpkg -i "${shims}"/*.deb in place of the old bare ${RUNNER_TEMP} paths.
• The block in the native job's "Install Tizen Studio" step and the block in the web job's "Build native service and create hybrid application" step are byte-identical (diffed and hashed both spans - identical).
• Shell syntax is sound: mkdir -p is idempotent regardless of pre-existing state, the for loop writes one .ctl per shim name and builds it via equivs-build in a subshell cd (no need to cd back), and the final dpkg -i "${shims}"/*.deb glob is now scoped to only the three .debs this step just built, closing the gap round 5 flagged (a .deb dropped into $RUNNER_TEMP by an unrelated earlier step can no longer be swept in by this wildcard).
• Confirmed at runtime, not just by reading YAML: pulled the raw logs for the native (yolo_model_training) job and the web (ImageClassificationOffloading) job on the 358882a run. Both show shims="${RUNNER_TEMP}/tizen-sdk-shims" executing, followed by Unpacking libcurl3-gnutls (99:0), Unpacking libglib2.0-0 (99:0), Unpacking libv4l-0 (99:0) - i.e. all three shims are still built and installed correctly from the dedicated subdirectory in both copies.
• gh pr checks 371 on 358882a: all 10 checks pass (DCO, both csharp legs, native (yolo_model_training), both native examples legs, all four web legs).
• On the second point (nit, not fixed): diffed 358882a's tizen-build.yml against main's pre-PR version of the same file. main already uses sudo apt update / sudo apt install -y ... inline in these same two steps, before this PR ever touched the file - the apt-get form only ever existed in the now-removed standalone tizen-sdk-prerequisites.sh script, not in the workflow file itself. So keeping apt/apt install when inlining the script's body back into the workflow is not a new deviation introduced by this PR; it restores the file's own pre-existing convention, consistent with the maintainer's direction to follow the original file's style. Declining the nit on that basis is reasonable.

Findings: none. Round 5's minor finding is resolved correctly and identically in both copies, and round 5's nit is knowingly and correctly left as-is for a verifiable reason (matches the file's own pre-PR style, not a stylistic regression). No remaining issues.