gnupg-related failures possibly hide their output
Metadata
Current evaluation
Maintainer-filed improvement: craft-archives logs only that the gpg command failed without exposing gpg's stderr/verbosity, making keyserver failures hard to diagnose (e.g. rockcraft#287). No labels or follow-up comments yet.
Suggested action: needs triage
Reason: The issue has zero labels, no assignee, no comments and no activity for ~519 days, so it shows no sign of having been categorised or prioritized by maintainers — the default for needs_triage. The underlying problem is valid (per canonical/rockcraft#287, whose summary confirms the DNS misconfiguration was a user config problem and that 'a separate craft-archives error-reporting bug' was filed, i.e. this one), but the body is exploratory rather than scoped ('see if there's a way to improve that (e.g. see if there's more output in gpg's stderr, check verbosity flags, etc)'), so it needs investigation to identify the gpg call sites and pick an error-reporting mechanism. I could not inspect craft_archives/repo sources to confirm which subprocess invocations drop stderr, which caps my confidence.
Evaluated by: mr-cal-bot
Issue body
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
28
Quick Win:
9
Complexity:
32
Confidence:
68
Actionability:
48
|
needs triage | Maintainer-filed improvement: craft-archives logs only that the gpg command failed without exposing gpg's stderr/verbosity, making keyserver failures hard to diagnose (e.g. rockcraft#287). No labels or follow-up comments yet. | |
| qwen/qwen3.6-35b-a3b |
Impact:
30
Quick Win:
13
Complexity:
30
Confidence:
70
Actionability:
60
|
needs triage | Improve GPG error messaging in craft-archives to expose stderr output for easier diagnosis of keyserver failures. | |
| qwen/qwen3.8-27b |
Impact:
25
Quick Win:
20
Staleness:
70
Complexity:
20
Confidence:
70
Support Request:
10
|
keep open | craft-archives should log gpg command output (stderr) on failure to improve debugging; partially addressed with log=True in install_key and stderr in error messages, but key receive path still lacks debug logging | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
30
Confidence:
85
Support Request:
20
|
close stale | Issue reports that gnupg-related failures in rockcraft hide output, suggesting improvements to capture stderr or verbosity flags. No maintainer response or labels after over 3 years. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
90
Complexity:
20
Confidence:
80
Support Request:
10
|
close stale | Minor logging improvement suggestion for GPG command failures, reported 3 years ago with no comments or maintainer engagement. Currently unlabelled and inactive. |
Update history
No update history recorded yet.
Related work
-
Related To:
canonical/rockcraft#287
(confidence 88%)
Cited in the issue body as the motivating example; that issue was closed as a user DNS configuration problem and explicitly spawned this craft-archives error-reporting issue.
Related issues
No related issues found above the similarity threshold.