|
Bugzilla – Full Text Bug Listing |
| Summary: | Regression: YOU don't automatically use full rpms | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.2 | Reporter: | Jan Kardell <jan> |
| Component: | YaST2 | Assignee: | Ladislav Slezák <lslezak> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | jsuchome, lslezak |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | openSUSE 10.2 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | yast2 logs | ||
|
Description
Jan Kardell
2007-09-07 11:24:11 UTC
Please add the YaST logfiles as described in http://en.opensuse.org/Bugs/YaST. Created attachment 162874 [details]
yast2 logs
Logs from a x86_64 system. I have several i586 with identical behavior.
I removed a couple of the oldest y2log-x files, the whole blob was to large for bugzilla.
Michael, how is the behavior in commit? @Jiri: Please check, I thought it is already fixed. Providing a package: after sending the 'start()' trigger a sequence of DeltaDownload/DeltaApply/PatchDownload actions may be performed, and lead to the 'finish()' trigger on success. Each Patch/Delta action starts sending it's 'start...()' trigger, followed by 'progress...()'. If the attempt is successfull a 'finish...()' trigger is sent, otherwise 'problem...()' to indicate, that we're going to try something different. This is no error the user should have to confirm, it's just an indication to reset the progress bar as we're starting to try something different. Only if the final attempt to provide the full package fails, reported by a 'problem()' trigger, the user should receive the error popup. I don't know to what you refer as "probably already fixed". I also don't understand which callback causes the reported action (so YaST Online Update might react inapproprietally...) AFAIR we already faced this, so it might be there some fix that didn't make it back into 10.2 branch. But I'm not shure. May even be Ladislav is able to handle this completely inside pkg-bindings/PackageCallbacks.ycp. Inside the DownloadResolvableReport providing some patch.rpm fails. This triggers MediaChangeReport passing MediaChangeReport::NOT_FOUND. But this should not cause any popup to appear. Inside DownloadResolvableReport only MediaChangeReport::WRONG indicating the wrong media is inserted should cause a popup - asking to insert the correct media. Or an error reported in the DoneProvide callback, as this indicates that even downloading the complete package failed. Any other problem reported here is just informal. I believe this is fixed now. Please, reopen if you can reproduce with 11.0. |