E: Repository 'https://download.owncloud.com/desktop/ownCloud/stable/latest/linux/Debian_11 InRelease' changed its 'Origin' value from 'https://minio.owncloud.services/clients/build-linux/${DRONE_BUILD_NUMBER}/repo/' to 'https://minio.owncloud.services/clients/build-linux/4640/repo/'
E: Repository 'https://download.owncloud.com/desktop/ownCloud/stable/latest/linux/Debian_11 InRelease' changed its 'Label' value from 'repo' to '4640/repo'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Steps to reproduce
Install ownCloud a week ago from repositories.
Try to update today.
Client configuration
Operating system: Debian 11
While of course things can change, it seems unwanted to me that ${DRONE_BUILD_NUMBER} is now replaced with a fixed number (4640 here). Checking out different kinds of builds (stable, daily etc.) all these have different numbers.
Are these numbers going to be stable across future releases, i.e. should I “update” my system / accept the change? Or will I have to re-accept the change for each update to come?
Ouch. I wasn’t aware that Debian checks for changes in these values.
But good news: such checks bite on the ‘stable/latest’ repo, which we updated inplace (obviously). These checks cannot bite if you use versioned repos instead.
https://download.owncloud.com/desktop/ownCloud/stable/2.10.0.6519/linux/
has the same contents as https://download.owncloud.com/desktop/ownCloud/stable/latest/linux/
You can use the repo with the version number meanwhile, while we look into fixing the stable/latest repo.
Thanks, indeed using the versioned repos seems a good workaround :-).
We’ll want to switch back to the latest branch in the future for unattended-upgrades to work out on our desktop machines, so I’ll not mark this as the solution yet. Many thanks for looking into fixing it!
This minio-URL is not even a useful download repo at all. I had considered the value of Origin: only an internal identifier. But apparently it is used (now?) -
It is the first time, that I see complaints, when that value changes. In the past we had URLs there starting with https://obs.int.owncloud.com … also not useful, but seems it was harmless then
We’ve updated the Linux repositories to avoid such error messages while upgrading to future releases by removing the two keys apt has complained about. From my tests, upgrading should now be possible just fine. Depending on apt's configuration, you might have to accept change manually once (apt is relatively complex and most distros have their own settings, unfortunately).
@olifre in case you have to manually confirm the transition, please let us know, since we might have to add a little hint to the installation instructions then to raise awareness of the issue. We do not want to hardcode the old broken value in the Release file (it should have never contained an escaped variable in the first place, so changing it to a real number is likely the result of a fix in another place), so we removed them completely.
Are these numbers going to be stable across future releases, i.e. should I “update” my system / accept the change? Or will I have to re-accept the change for each update to come?
Origin and Label are optional according to the apt man page, so we removed them altogether, rather than having to change them to the correct value.
This address cannot be reached from the Internet, and the value should have never ended up in the repository anyway. We no longer include the key it was contained in in the metadata.
If the install instructions have to be changed please let me know.
For new installations, the existing instructions continue to work fine.
@fmoc That’s indeed an interesting solution!
One nice feature about origin and other metadata is that it can be used to filter e.g. in unattended-upgrades on these values. However, even after dropping the metadata, filtering remains possible via the site attribute (c.f. https://unix.stackexchange.com/a/651958 ), so I think this is not really a loss, especially given the escaped variable was rather irritating before.
I migrated all of our Debian 11 nodes to use an explicitly versioned repository as temporary workaround.
I can confirm that migrating back from that to https://download.owncloud.com/desktop/ownCloud/stable/latest/linux/ worked without any manual intervention or confirmation, i.e. changing the repository URL, apt update was happy.
I did not test with a machine which was left configured to use latest, though (since we configured all nodes with fixed-version repositories as workaround). Maybe others in this thread can add information on whether manual intervention was required in such a case.
In any case, I’ll mark your comment as “solution” to the issue , many thanks for the fix!
We finally managed to fix the existing 2.10/2.10.0.6519/latest releases by uploading a fresh build of the Linux repositories. Upon updating, apt will prompt you because of the change in the metadata once:
root@b515eca4f7fc:/# apt update
Get:1 http://security.ubuntu.com/ubuntu focal-security InRelease [114 kB]
Hit:2 http://archive.ubuntu.com/ubuntu focal InRelease
Get:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease [114 kB]
Get:4 https://download.owncloud.com/desktop/ownCloud/stable/2.10/linux/Ubuntu_20.04 InRelease [1436 B]
Get:5 http://archive.ubuntu.com/ubuntu focal-backports InRelease [108 kB]
Get:6 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages [844 kB]
E: Repository 'https://download.owncloud.com/desktop/ownCloud/stable/2.10/linux/Ubuntu_20.04 InRelease' changed its 'Origin' value from 'https://minio.owncloud.services/clients/build-linux/4640/repo/' to ''
E: Repository 'https://download.owncloud.com/desktop/ownCloud/stable/2.10/linux/Ubuntu_20.04 InRelease' changed its 'Label' value from '4640/repo' to ''
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] y
Once you confirm the change one last time, updating will work normally again. In all builds since Jan 25, the metadata has not been included any more, so future releases should not generate such prompts any more.
Sorry for the long waiting time. We wanted to make sure everything works at last. In the unlikely event of further issues, please do not hesitate to contact us and let us know. We appreciate bug reports, especially when they are this detailed.
Many thanks! I marked this reply as the solution for the thread .
For future reference, a short pre-announcement of this (good and warranted!) change would have been helpful — we manage over 220 Debian nodes here (academia), and most of them are not online at the same time, so accepting things manually is definitely not an option.
I have now put all other work on immediate hold to implement this into our configuration management before unattended upgrades would start flooding us with errors. Our configuration management now purges the repository automatically once (if the Label / Origin are still set to the old values), and then adds it back, which implicitly accepts this change. This works well and is now rolling out to all the nodes when they come online.
Thanks a lot for the fix, and no worries if things take a bit — such changes naturally need some time to be tested.
Thanks for the hint, will keep it in mind. I’ve tested against the production setup because testing against a staging setup last time didn’t work sufficiently, but I should indeed have notified you and everyone else in here first. We will add a notice to future releases’ announcements, too.
.