Update Manager: allow for "information change" confirmation (Opera Software ASA)

[rene]

The Opera web browser repository recently changed its 'Origin' value from 'Opera Software ASA' to 'Opera Software AS' which has Update Manager trip without any apparent method of bypassing it. From a terminal confirmation is requested:

Code: Select all

rene@hp8k:~$ apt update
[sudo] password for rene: 
[ ... ]
Get:3 https://deb.opera.com/opera-stable stable InRelease [2591 B]
E: Repository 'https://deb.opera.com/opera-stable stable InRelease' changed its 'Origin' value from 'Opera Software ASA' to 'Opera Software AS'
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

It seems Update Manager would want to throw up a dialog.

[ScabOfTriton]

I have the same problem and I'm not sure what to do.

[smurphos]

I have the same problem and I'm not sure what to do.

What rene did...

Run apt update in a terminal. You should be prompted to accept the change. apt update -y will accept the change with no further interaction. Update manager will now work.

[pompeylion]

Thank you Smurphos, so simple when you know how

[gm10]

It seems Update Manager would want to throw up a dialog.

In an ideal world. This sort of thing happens once in a blue moon, it's unfortunate we've got Google and Opera both doing it within a few months.

[rene]

Ah, that was it. Thought I had heard/read this before; don't use Google Chrome but supposedly read it here on the forums.

Even for blue moons I'd consider this worth fixing though. Haven't looked at mintupdate, and I understand it being possible/trivial to do depends on the "information change" status in fact being (readiliy) available to wrappers such as mintupdate, but having it choke like this even only occasionally does, I feel, give a pretty bad impression. I.e., maybe not a big priority time-wise, but would feel it worth fixing eventually.

I read you added mainline kernel support to mintupdate recently; if that means you're familiar with the thing already: project idea?

[gm10]

I added a ton of things, and there's always more that could be added, so it's about priorities. And frankly how I feel like, this is not my job and I don't use Chrome, either, so I can't say I feel motivated.

Also I don't think it's that trivial. We're currently using Synaptic for the manual refresh, and I don't think it can handle that error. So all we get back is the error message. Which I assume is localized and thus not easily usable. To even look into this further I guess I'd have to create a local repository to build a test case to see what exactly we get back. And then a GUI would have to be added to handle this, I'd have to figure out how to actually handle this (I don't think it can even be handled other than during a refresh because you need to be overwriting old repo info with the new one - so basically I'd either need to patch Synaptic or create my own refresh dialog). The GUI would need a bunch of new strings which all would need to get translated by other volunteers into all the supported languages (including Klingon and I don't know what because some people have too much time on their hands apparently ). And maybe we'd want to backport it to the 3 other supported releases, further increasing the work load.

So basically you can take your

possible/trivial to do

and stick to you know where.

[rene]

We're currently using Synaptic for the manual refresh [ ... ]

So I noticed; odd choice it seems, building a GUI around a GUI, even if if I'd ever feel motivated to go find out why there's probably some point.

I'll go watch TV again....

[gm10]

Before my time but the point is likely that nobody wanted to write it from scratch and when they could simply use what was already there. Synaptic is also being used for all installs/removals.