Bugzilla – Bug 1095749
Error message 'repository managed by service "' when managing freshly added repos via YaST
Last modified: 2024-03-27 14:49:38 UTC
Created attachment 772283 [details] screenshot Please see the attached screenshot. YaST is telling me that the repo is managed from a service called " Apart from the fact that I do not understand which service that might be it also doesn't tell me.
Translation: Repository 'mozilla-beta' is managed by service ". Your manual changes might be reset by the next service update!
This looks like the code location throwing that message: https://github.com/yast/yast-packager/blob/master/src/lib/packager/clients/repositories.rb#L2085 "git blame" says it's introduced by this commit: https://github.com/yast/yast-packager/commit/18383b497d914f0a7388b0c3f60e14c7a9613b8e which belongs to this pull request: https://github.com/yast/yast-packager/pull/346 which was the fix for bug #1078323.
So the message per se is probably valid (well, is it? Is that repo indeed managed by a service?), but the placeholder for the service is empty which is a real bug, albeit probabably a minor one. Wolfgang, please describe what you did (doesn't need to be in great detail, just a rough idea). Is it plausible that this repo is managed by a service? Or what kind of repo is it? What does "zypper lr" say about that repo?
What I did was: - installing Leap 15.0 in a new partition - after installation I copied of the repo files from /etc/zypp/repos.d from my existing 42.3 installation to the fresh install - afterwards I changed the 42.3 reference to 15.0 manually and got those messages for most of my repos I have no idea what kind of services we are talking about anyway. Probably some enterprise feature? Hygiea:/etc/zypp/repos.d # zypper lr -d mozilla-beta Alias : mozilla-beta Name : mozilla-beta URI : http://download.opensuse.org/repositories/mozilla:/beta/openSUSE_Leap_15.0 Aktiviert : Ja GPG-Überprüfung : (r ) Ja Priorität : 99 (Standard-Priorität) Automatische Aktualisierung : Am Pakete beibehalten : Aus Typ : rpm-md GPG-Schlüssel-URI : Pfad-Präfix : / übergeordneter Dienst : Schlüsselwörter : --- Repo-Info-Pfad : /etc/zypp/repos.d/mozilla-beta.repo MD-Cache-Pfad : /var/cache/zypp/raw/mozilla-beta (also nice: "Automatische Aktualisierung : Am" - "Am" - was?)
Hm - that does not look to me like that repo is indeed managed by a service. Those services are indeed enterprise features used by multi-machine managing software such as "SUSE Manager". But if you just use plain OpenSUSE Leap, this should not apply to you at all.
Just in case it is useful, I got the same error message on Leap 42.3. Steps I did: 1. I used Yast module "repositories" to change the priority of the official repositories to 1. 2. Then I added a home OBS repository (which got default 99 prio) 3. I change the prio of that new repo to 20 and I got that message. I suspect there is a wrong check that is showing this wrong error message on situation where there is a different issue.
Sergio, does the problem happen when you save the changes and exit YaST, start it again and then try changing the priority of the new repo? YaST caches the data for the new repositories, the changes are saved at exit. Maybe it is related. Please also check if there is any file under /etc/zypp/services.d/.
AFAICS this check here https://github.com/yast/yast-packager/blob/master/src/lib/packager/clients/repositories.rb#L2087 might be a bit over-optimistic. That "service" key might not even be in that hash, so accessing it would return 'nil' which is not checked at all. Also, it is pointless to construct that message and only afterwards check if it should be posted; this is an invitation to other problems. We should probably check like this at the very beginning of that function: def warn_service_repository(source_state) service = source_state["service"] return if service.nil? || service.empty? ... ... end
(In reply to Ladislav Slezák from comment #7) > Sergio, does the problem happen when you save the changes and exit YaST, > start it again and then try changing the priority of the new repo? > > YaST caches the data for the new repositories, the changes are saved at > exit. Maybe it is related. > > Please also check if there is any file under /etc/zypp/services.d/. The problem didn't happen after saving and opening again. I left the prio of the new repo as 99, then save, then reopen to just change the prio to 20. At the moment I don't have any file in that directory.
Thanks, so it seems there is some problem with processing the not yet saved repositories. As the workaround is to save the repositories first and set the priorities after starting again I'm setting it to P3.
I just tried a fresh Leap 15 installation, and it did not show this problem. That means that this is at least not a problem that will affect every user installing Leap 15, so IMHO we don't have to raise this to P1 or P2 priority.
I accept this may not be a general issue but I did nothing else as written above. So it's unclear to me why my fresh installation is different from yours ;-)
*** Bug 1096513 has been marked as a duplicate of this bug. ***
That duplicate bug also mentions a discussion in a German forum: https://linux-club.de/forum/viewtopic.php?f=89&t=122422&sid=68680e0ee5462d7b723048bec7269b2a It might be important that this seems to happen immediately after adding the repo, so it might be an initialization problem.
Just thinking aloud... https://github.com/yast/yast-packager/blob/master/src/lib/packager/clients/repositories.rb#L2087 If that entire source_state hash does not exist yet, for Ruby it's nil, and nil is definitely != "", so the first part of that condition might be true in surprising circumstances. We need to check that.
Lada, any comment from your side on this?
Yes, sounds like a possible reason.
I can also confirm that the bug is present on 42.3 - I just ran into it.
Moved to our Trello scrum task queue: https://trello.com/c/vSg1i0VK
When reviewing old bugs, I came across this one, and it sounded very familiar: This came again much later as bug #1218770 which turned out to be a duplicate of bug #1218399.
Even though this was the first of this kind, marking as duplicate of the one with the fix: bug #1218770. *** This bug has been marked as a duplicate of bug 1218770 ***