shim-unsigned-foo tagging for shim-16.1 in f44 #13050
Labels
No labels
after freeze
automation
backlog
blocked
change-ack
change-nak
change-noreleng
changes
Closed As
Can't Fix
Closed As
Duplicate
Closed As
Fixed
Closed As
Fixed with Explanation
Closed As
Get back later
Closed As
Grooming
Closed As
Insufficient data
Closed As
Invalid
Closed As
It's all good
Closed As
taiga
Closed As
upstream
day-to-day
dev
docs
easyfix
epel
f26
f27
f28
f29
f30
f31
f32
f33
f34
f35
f36
f37
f38
f39
f40
f41
f42
f43
f44
f45
fedora
groomed
high-gain
high-trouble
in-progress
in-review
investigation
legal
low-gain
low-trouble
mass rebuild
medium-gain
medium-trouble
meeting
mini-initiative
new_artifact
ops
pdc_retirement
rawhide
RCA
review
script
sidetarget
sprint-0
sprint-1
sprint-2
sprint-3
sprint-4
sprint-5
unfrozen
waiting on external
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
releng/tickets#13050
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the issue
We need shim-unsigned-aarch64-16.1-1 and shim-unsigned-x64-16.1-1 tagged into f44 so we can build the "signed" package.
When do you need this? (YYYY/MM/DD)
2025/10/30
When is this no longer needed or useful? (YYYY/MM/DD)
Next year
If we cannot complete your request, what is the impact?
Shim in f41 will be newer than in f44.
Please check https://www.fedorastatus.org/ for any known
outages before filing issues on an outage.
Discussed it on chat with nirik and we'd also like the following:
shim-unsigned-aarch64-16.1-1 tagged into f42-updates-testing
shim-unsigned-aarch64-16.1-1 tagged into f43-updates-testing
shim-unsigned-x64-16.1-1 tagged into f42-updates-testing
shim-unsigned-x64-16.1-1 tagged into f43-updates-testing
shim-16.1-2 tagged into f42-updates-testing
shim-16.1-2 tagged into f43-updates-testing
CC: @adamwill should we run any of these by openqa since we are bypassing bodhi here?
uh, sure, I can...
I tagged the f44 ones in.
I have not done the rest yet, let me know when it would be good to.
tests running:
tests looking good, just silverblue to finish up. ignore the upgrade_desktop_graphical failures on aarch64, that's a WIP I have going atm.
ok. good to tag then? and what critera should we use to move them from updates-testing to updates? I guess let them soak until next week?
Metadata Update from @jnsamyak:
Metadata Update from @jnsamyak:
Please also push https://src.fedoraproject.org/rpms/shim-unsigned-x64/c/d355c62164bd48c6f47774fe04b0d730d892e006?branch=f43 to the rawhide branch.
I was wondering why the tests I ran for this issue didn't show up the problems we saw when we landed new shim in rawhide, but I think I see why. In this ticket we're referring to shim-16.1-2 . That's https://koji.fedoraproject.org/koji/buildinfo?buildID=2851862 , which was built against an f41 buildroot. So it didn't get the auto-hardlink change. But for Rawhide we landed shim-16.1-4, which was built against a Rawhide buildroot, so it did get the auto-hardlink change.
So, I didn't actually tag these last week, I have been swamped with fires. ;(
Should it be ok to tag the f42/43 ones to testing? or just to updates?
ok, I have tagged the builds into f42-updates-testing and f43-updates-testing.
They should go out in the next updates push.
Early next week I will tag them over to updates if there's no issues reported.
Reading above, I think the work is done here. If not please feel free to reopen this, trying to clear out the backlogs.
This is not actually done. They were tagged into testing, but then there were problem reports, so I never tagged them into stable updates.
Right, and the thread just sort of died inconclusively. So I'm not sure what we should do. Still...the packages are still in u-t, right? So folks with u-t enabled should have them? In which case I'd kinda expect more noise by now if there was a wider problem..
Yeah. Probibly next week after checking in with @pjones we can move them to stable updates...