Fedora ELN broken repository checksums #13398
Labels
No labels
announcement
anubis
authentication
aws
backlog
blocked
bodhi
ci
cloud
communishift
copr
database
day-to-day
dc-move
deprecated
dev
discourse
dns
downloads
easyfix
epel
firmitas
forgejo_migration
Gain
High
Gain
Low
Gain
Medium
gitlab
greenwave
hardware
help wanted
high-trouble
koji
koschei
lists
low-trouble
medium-trouble
mirrorlists
monitoring
Needs investigation
odcs
OpenShift
ops
outage
packager_workflow_blocker
pagure
permissions
Priority
Needs Review
Priority
Next Meeting
Priority
🔥 URGENT 🔥
Priority
Waiting on Assignee
Priority
Waiting on External
Priority
Waiting on Reporter
rabbitmq
release-monitoring
releng
request-for-resources
s390x
security
SMTP
sprint-0
sprint-1
src.fp.o
staging
unfreeze
waiverdb
websites-general
wiki
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
infra/tickets#13398
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?
Description of request
Howdy,
We are doing CI against Fedora ELN, can something be done with the following problem? We can see this now on Fedora ELN. Ideally find out why it happens and fix it. Previously similar issues were in CentOS Stream, so I hope it can be fixed long term :)
I think it should be working again now.
The fullfiletimelist wasn't updated, so mirrormanager didn't update.
I am not sure why, we will need to see if it correctly updates on the next compose.
Thanks for looking so quickly 🙏 Retesting
Looks resolved, closing.
Seems this one popped up again
Yep, seeing the same in openQA.
releng/tooling#13036 should fix this, I think. The last call in eln-nightly.sh is a
send_fedora_message. That fails because of the incorrect path the PR fixes. Since it's the last call I believe eln-nightly.sh will exit non-zero, which means the cron job won't proceed pasteln-nightly.sh, which means we don't run/usr/local/bin/update-fullfiletimelistwhich causes this.Merged. We could keep this open to confirm or just close...
We should know when the currently-running ELN compose finishes (assuming it doesn't fail).
.n.2 has finished.
It looks like it's good. Messages were sent, and the file list was updated when the compose synced. Sync sure seems to take a while, though.
Oh, hah, no, I see:
# Only do the sync and report on the first successful compose of a particular dayso the 09.n.2 compose was not synced, but the 10.n.0 one was. I thought 09.n.2 took a long time to sync but actually I just saw when 10.n.0 synced. Anyway, everything is fine.