Bug 394662

Created attachment 218548 [details]
screenshot

now i even needed to import the "SuSE Package Signing Key <build@suse.de>", even though i think this should already be on my system.

Those dialogs you see are >>YaST<< but YaST starts only by libzypp callbacks. Those two screenshots are different, of course, as they offer to import a different key.

In my opinion, it always offer to import a different key. But hard to say without logs. Anyway, keys are managed by libyzpp.

I'm quite sure that during the last 10 updates, i imported the same "build@suse.de" key at least 5 times.

What logs are needed? I'll attach them after it happens the next time.

You can attach them right now

See http://en.opensuse.org/Bugs/YaST

The problem is that yast2 piwo (I assume this module is called) doesn't initialize the target system so the keys are not read at start.

(I think the logs are not needed anymore.)

Created attachment 218908 [details]
patch for piwo.ycp

*** Bug 395052 has been marked as a duplicate of this bug. ***

The patch has been submitted in yast2-registration-2.16.7.

root@stoetzler:~# rpm -q yast2-registration
yast2-registration-2.16.7-5

However, i still saw this as i wanted to update from 11.0 to factory.
Will attach y2logs.

Created attachment 223839 [details]
yast2 logs

According to the log, you were asked to import the key during the installation itself, right? The "piwo" module is fixed. 

This issue seems to be related to the installation process. Lukas, please have a look.

isnt this bug 401259  fior which we released a libzypp update yesterday?

Possibly, but I can't tell myself.

(In reply to comment #12 from Marcus Meissner)
> isnt this bug 401259  fior which we released a libzypp update yesterday?

No, that's unrelated. 

It's the same workflow problem as above. At the time a key is needed to verify some file, the target is not initialized. We don't know the trusted keys, so we have to ask:

2008-06-23 19:37:57 
[liby2] genericfrontend.cc(main):561 Launched YaST2 component 'y2base' 'update' '-S' 'qt'

2008-06-23 19:38:10
Going to verify signature for /var/cache/zypp/raw/stable-x860CNf0N/content with /var/cache/zypp/raw/stable-x860CNf0N/content.asc

2008-06-23 19:38:24
User wants to trust key A84EDAE89C800ACA SuSE Package Signing Key <build@suse.de>

...

2008-06-23 19:38:41
Pkg Builtin called: TargetInit

2008-06-23 19:38:41
Syncronizing keys with zypp keyring


Target should be initialized (this does not mean you also have to load the solvables into the pool). Just checks the database and initializes the keys.

So, piwo is fixed (see comment #11) and the rest works as designed. No need to play bugzilla-ping-pong...

Still happens on FACTORY today.

Created attachment 228715 [details]
yast2 logs after starting "yast2 update" and (again) confirming all the keys

Executing:

  grep -i 'initializeTarget\|verifyFileSignatureWorkflow' y2log

I see no verifyFileSignatureWorkflow being executed __after__ initializeTarget.


Yast initializes the repos before the target:

13:29:44 [Pkg] Packages.ycp                Builtin called: SourceStartCache
13:29:44 [Pkg] PkgFunctions.cc(CreateRepoManager) ...
13:32:04 [Pkg] clients/update_proposal.ycp Builtin called: TargetInit


This is correct on installation (software selection done without target),
but on update we should make the target available earlier.

@Lucas: A matter of update_proposal.ycp?

Well, I'd say this is more generic problem. I see the very same issue in several YaST modules ... Lado?

I've just checked that the request to import the keys is not shown every time even with the same code and system used (yast2 update). Which really seems to move the responsibility to lower libraries.

(In reply to comment #20 from Lukas Ocilka)
> I've just checked that the request to import the keys is not shown every time
> even with the same code and system used (yast2 update).

Depends on whether we have to actually download and verify metadata. This might also be influenced by the repo.refresh.delay value in zypp.conf. Check for new metadata will not happen more often than repo.refresh.delay (def. 10) minutes.


Most probably pkg-bindings face the same problem as libzypp: The application has to indicate where the target system is located, as soon as we are allowed to access it. So we can't simply auto-launch the Target without this knowledge.

Currently this is indicated by a call to TargetInit, passing the location of 
the target system as argument. 

So update should initialize the target at the beginning if it's running in an installed system.

Index: run_update.ycp
===================================================================
--- run_update.ycp      (revision 49620)
+++ run_update.ycp      (working copy)
@@ -18,6 +18,7 @@
     import "ProductControl";
     import "Wizard";
     import "Update";
+    import "Installation";
 
     // check whether having the packager for ourselves
     if (! PackageLock::Check ())
@@ -41,6 +42,10 @@
     list<map> stage_mode = [$["stage": "normal",  "mode": Mode::mode() ]];
     ProductControl::AddWizardSteps(stage_mode);
 
+    // bnc #394662
+    // initialize target ASAP
+    Pkg::TargetInit (Installation::destdir, true);
+
     symbol ret = ProductControl::Run();
 
     Wizard::CloseDialog ();


yast2-update-2.17.1

This is an autogenerated message for OBS integration:
This bug (394662) was mentioned in
https://build.opensuse.org/request/show/844234 Factory / yast2-registration