chore: prepare 11.0.1

[oc-tmueller]

Release preparation for 11.0.1, which remediates #41824.

What this does

• Bumps version.php to 11.0.1 ($OC_Version = [11, 0, 1, 0]).
• Adds changelog/unreleased/41824 for the release tarball repackaging.

Why 11.0.1 rather than rebuilding 11.0.0

Both the standard and the complete tarball change content. Reusing the version would invalidate the already-published sha256/md5/asc sidecars — the issue itself cites one — so this is a new version.

It is also a genuine patch release, not only a repackaging: changelog/unreleased/ already holds eight queued fixes, which 11.0.1 picks up.

The problem being fixed

11.0.0 shipped 13 bundled apps as the working tree they were built in — 101.94 MB of the 441.8 MB uncompressed complete tarball, across 16 shipped git repositories. Three consequences beyond the dead weight:

1. files_antivirus carried its EICAR acceptance data, so a ClamAV scan of the tarball or of any image built from it reported Eicar-Test-Signature FOUND, and could be rejected at an anti-virus gate.
2. The files were covered by each app's appinfo/signature.json, so an administrator could not delete them without breaking occ integrity:check-app.
3. The shipped .git/ leaked the release engineer's name and e-mail from .git/logs/HEAD.

The standard tarball was affected too, through notifications — that part is not in the original report.

Root cause was not in this repository: the app release assets had been uploaded by hand from a build checkout instead of from build/artifacts/appstore/<app>.tar.gz.

Related

what	where
repin all 14 affected apps in the 11.0.1 specs	owncloud/server-release#53
fail the bundle build on a shipped build tree, and fix the same leak in the daily bundles	owncloud/server-release#54
reject such an artifact at publish time	owncloud/reusable-workflows#97
12 app release PRs	linked from owncloud/server-release#53

Deliberately not done here

ocrelease changelog --version 11.0.1 --date <release date> has not been run. It materialises changelog/unreleased/ into a changelog/11.0.1_<date>/ folder whose name embeds the release date and regenerates CHANGELOG.md, so it belongs immediately before tagging — otherwise it needs redoing if the release slips. Run it in this checkout, commit, then tag v11.0.1.

The calens render was checked locally: the new fragment appears correctly in both the summary and detail sections alongside the eight existing ones.

🤖 Generated with Claude Code

[oc-tmueller]

CI is red, and it is this PR's doing — but the fix belongs in another repo. Blocked on owncloud/testing#229.

All eight API and CLI acceptance checks fail in the Install Server step, before a single test runs:

In app.php line 1119:
  App "QA testing" cannot be installed because the following dependencies are
   not fulfilled: ownCloud 11.0.0 or lower is required.

owncloud/testing pins max-version="11.0.0", so bumping version.php to 11.0.1 makes occ app:enable testing refuse the app. Core CI clones and enables that app in every acceptance job, so the whole matrix goes red.

owncloud/testing#229 changes it to max-version="11", matching what all 43 apps bundled in the ownCloud 11 release specs already use — testing was the only app pinning a patch version. No release of that app is needed, since core CI clones it from master; merging it is enough, then this PR's checks need a re-run.

Worth noting the same failure would hit anyone installing a QA tarball of 11.0.1, since apps/testing ships in the -qa bundles. So this is a real release blocker, not only a CI artefact.

How I confirmed it is not flakiness or unrelated breakage:

• The merge base is master's HEAD (88f0b1a), whose own CI run was green.
• The diff here is two files — version.php (+2/-2) and a new changelog fragment. Nothing functional.
• Re-running the failed jobs reproduced the failure identically.
• #41805 and #41804 pass the same suites, so the infrastructure is fine.

I had assumed a version bump could not plausibly break maintenance:install and went looking for an infrastructure cause first — the install-time mysql.user grant warning in the log is a red herring, it appears on green runs too.

[oc-tmueller]

Correction to my previous comment: I wrote that the install-time mysql.user grant warning "appears on green runs too". It does not — I checked a green CLI Smoke run afterwards and the message is absent.

The asymmetry has a duller explanation: owncloud.log is only printed by the Display content of server settings and logs if tests failed step, which by definition runs only when the job fails. So the warning is invisible on green runs rather than absent from them.

The conclusion is unchanged — the failure is occ app:enable testing rejecting core 11.0.1, fixed by owncloud/testing#229. The mysql.setup line is still not the cause; I should have said it is unproven noise rather than asserting it was benign.

[phil-davis]

owncloud/testing#229 merged.
I restarted the acceptance test workflows.