Repository changed Origin and Label, apt-get update fails

[vnovakovic-godaddy]

Bug Report

Describe the bug
After commit 38ddbef, apt-get update fails with message

E: Repository 'https://packages.fluentbit.io/ubuntu/jammy jammy InRelease' changed its 'Origin' value from '. jammy' to 'packages.fluentbit.io'
E: Repository 'https://packages.fluentbit.io/ubuntu/jammy jammy InRelease' changed its 'Label' value from '. jammy' to 'fluent-bit'

To Reproduce

• Rubular link if applicable:
• Example log message if applicable:

E: Repository 'https://packages.fluentbit.io/ubuntu/jammy jammy InRelease' changed its 'Origin' value from '. jammy' to 'packages.fluentbit.io'
E: Repository 'https://packages.fluentbit.io/ubuntu/jammy jammy InRelease' changed its 'Label' value from '. jammy' to 'fluent-bit'

• Steps to reproduce the problem:

Expected behavior

apt-get update doesn't fail on already added repos

Screenshots

Your Environment

• Version used: N/A
• Configuration: N/A
• Environment name and version (e.g. Kubernetes? What version?): prod
• Server type and version:
• Operating System and version: Ubuntu Jammy
• Filters and plugins:

Additional context

[davidlawson83]

We're also experiencing the same issue and it's breaking puppet from running across all our servers but we're using Debian 12 Bookworm.

[patrick-stephens]

This may be down to the PR here: #9949
It is the only change since last release.

[patrick-stephens]

Presumably @davidlawson83 @vnovakovic-godaddy it functions for newly added repos but not for existing repos, it's down to the change in origin/label which seems to be required to resolve that other issue?

Does sudo apt-get update --allow-releaseinfo-change allow it to accept the new info?

[patrick-stephens]

We could revert the PR and re-deploy the repos then with the old information but I'd rather come up with a solution that resolves it for both if possible.

I'll send a PR for docs anyway to indicate the change for now: fluent/fluent-bit-docs#1580

[davidlawson83]

@patrick-stephens Thanks for the quick response. Yes it's for existing repos but I've not needed to add a new repo so can't comment on that.

I'd appreciate a revert and re-deploy if possible as it's currently stopping me from running updates via puppet across my whole estate. I understand the reasoning behind the repo labels change and of course it would be great to resolve both but for now a revert and redeploy would aid me greatly.

Yes running sudo apt-get update --allow-releaseinfo-change does fix the issue for us. I wanted to add this to my pupup command but I can't pupup to get it changed in the pupup file so I would need to manually run the command per server.

[vnovakovic-godaddy]

@patrick-stephens Yep, --allow-releaseinfo-change works as quick solution, but revert + some backwards compatible solution would be preferred.

Agree with @davidlawson83, I see the reasoning but doing it this way breaks added repos.

[patrick-stephens]

Yeah, ultimately I'm not sure there is a good way to handle this - I was hoping there would be an option to notify of upcoming changes or similar. We either have to stick with the current values forever or get people to update.

I am going to revert the change and regenerate today to resolve.

[patrick-stephens]

https://github.com/fluent/fluent-bit/actions/runs/13673226103/job/38228444565 seems to be picking up the revert now - this is the staging release so I will promote once it is complete.

+ APTLY_ORIGIN='. bullseye'
+ APTLY_LABEL='. bullseye'

I force-pushed the tag for the same commit to re-trigger the workflow as rerunning the old job seems to sometimes just pick up the old master commit used at the time. Ultimately there is no change in the underlying ref for the code, I just force-pushed it to retrigger with the latest updates on master for packaging.

[patrick-stephens]

As always, the longest path is always the Windows builds :(
Once complete I will promote to release and this should resolve the issue.