Repository navigation
chore(deps): bump github.com/xuri/excelize/v2 to 20261003002531 - #731
Merged
Merged
Conversation
Bumps github.com/xuri/excelize/v2 from v2.11.1-0.20260915055537-22f76f9acb94 to v2.11.1-0.20261003002531-6258dcebc4e2, which also bumps the indirect dependency github.com/xuri/efp from v0.0.1 to v0.0.2. github.com/richardlehane/mscfb remains at v1.0.8, so the patched version excelize requires is retained. Note that this excelize revision raises its own minimum Go version from 1.25.0 to 1.26.0. PerfSpect already declares go 1.26.0 and the build container uses golang:1.27.2, so no toolchain change is needed. Verified: - amd64 and arm64 binaries build; no API changes in the surface used by internal/report/render_excel.go or cmd/benchmark/benchmark.go - all unit tests pass - gofmt, go vet, staticcheck and golangci-lint report no issues - generated a report with --format xlsx and confirmed the workbook is a valid archive with the expected sheets and cell values - govulncheck reports no vulnerabilities in excelize or its dependencies; vulnerabilities in imported packages drop from 17 to 14 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
adgubrud
added a commit
to adgubrud/PerfSpect
that referenced
this pull request
Oct 21, 2026
Removes the code changes merged in intel#720 from this branch: - the "pmu enumeration safety" probe script and the perfEnumerationFaultsKernel predicate in cmd/metrics/metadata.go - the sysfs-based event enumeration scripts that replaced 'perf list --json' on affected targets - the enumerateEventsFromSysfs parameter on getMetadataScripts and its use from the x86 and ARM metadata collectors - cmd/metrics/metadata_pmu_safety_test.go - the 'perf list tracepoint' change in the telemetry syscall enumeration script The go.mod/go.sum excelize and mscfb bumps that intel#720 also carried are intentionally left in place: main has since moved excelize forward again in intel#731, and reverting them here would downgrade a patched dependency. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps
github.com/xuri/excelize/v2fromv2.11.1-0.20260915055537-22f76f9acb94tov2.11.1-0.20261003002531-6258dcebc4e2, which also bumps the indirect dependencygithub.com/xuri/efpfromv0.0.1tov0.0.2.github.com/richardlehane/mscfbremains atv1.0.8, so the patched version excelize requires is retained.Heads-up on the Go version
This excelize revision raises its own minimum Go version from
1.25.0to1.26.0. No toolchain change is needed — PerfSpect already declaresgo 1.26.0andbuilder/build.Dockerfileusesgolang:1.27.2. It does mean thegodirective can't be lowered below 1.26 while on this excelize.Verification
makeandmake perfspect-aarch64both build. The excelize API surface we use (internal/report/render_excel.go,cmd/benchmark/benchmark.go) is unchanged.make testpasses for all packages.check_format,check_vet,check_staticandcheck_lintreport no issues.--format xlsxand confirmed the workbook is a valid archive containing the expected sheets and cell values. Also round-tripped the single-target and multi-target renderers plus the styling APIs throughexcelize.OpenReader.govulncheckreports no vulnerabilities in excelize or its dependencies. Against this baseline, vulnerabilities in imported packages drop from 17 to 14; the stdlib findings andgosecresults are unchanged and unrelated to this bump.🤖 Generated with Claude Code