[opensuse] yast online update
I'm having trouble understanding YaST Online Update in Suse 10.2. There are various aspects I don't understand and I'm having trouble finding the appropriate docs (probably through stupidity). The Help button says "Refer to the manual for details". I've looked through the "openSUSE Documentation Reference" - specifically II.3 Online Update - but it doesn't give much detail. Is there some other documentation I've missed? One aspect I don't understand is the meaning of the symbol consisting of a white box followed by a grey tick. This doesn't appear in the list of symbols on the help menu and the symbols aren't listed in the manual I've looked at. For example, timezone or wxGTK - the available and installed version are the same, so what are the patches? Another aspect is why some patches are shown with a white triangle and white box with a black tick when the packages themselves have a black triangle with a green and white Z (e.g. krb5). Other patches for packages marked in this way are themselves marked with a white triangle and a green and white Z (e.g. python). What's the difference? The final aspect is specific to gtk2. There is a patch for gtk2, which I have installed. Why can't I see a matching patch to gtk2-debuginfo? There's a version conflict. Am I misunderstanding something or is this a bug? Thanks, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, Jul 18, 2007 at 10:46:42PM +0100, Dave Howorth wrote:
I'm having trouble understanding YaST Online Update in Suse 10.2. There are various aspects I don't understand and I'm having trouble finding the appropriate docs (probably through stupidity). The Help button says "Refer to the manual for details". I've looked through the "openSUSE Documentation Reference" - specifically II.3 Online Update - but it doesn't give much detail. Is there some other documentation I've missed?
One aspect I don't understand is the meaning of the symbol consisting of a white box followed by a grey tick. This doesn't appear in the list of symbols on the help menu and the symbols aren't listed in the manual I've looked at. For example, timezone or wxGTK - the available and installed version are the same, so what are the patches?
This means that the packages for this patch are already installed, likely manually, but the "patch" isn't. You can just select the patch, click Accept and it will be gone.
Another aspect is why some patches are shown with a white triangle and white box with a black tick when the packages themselves have a black triangle with a green and white Z (e.g. krb5). Other patches for packages marked in this way are themselves marked with a white triangle and a green and white Z (e.g. python). What's the difference?
refresh, some packages have been installed that do not satisfy the patch.
The final aspect is specific to gtk2. There is a patch for gtk2, which I have installed. Why can't I see a matching patch to gtk2-debuginfo? There's a version conflict. Am I misunderstanding something or is this a bug?
We do not ship updates for -debuginfo packages, you need to deinstall gtk2-debuginfo before updating. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, 2007-07-19 at 00:05 +0200, Marcus Meissner wrote:
On Wed, Jul 18, 2007 at 10:46:42PM +0100, Dave Howorth wrote:
One aspect I don't understand is the meaning of the symbol consisting of a white box followed by a grey tick. This doesn't appear in the list of symbols on the help menu and the symbols aren't listed in the manual I've looked at. For example, timezone or wxGTK - the available and installed version are the same, so what are the patches?
This means that the packages for this patch are already installed, likely manually, but the "patch" isn't. You can just select the patch, click Accept and it will be gone.
Hi Marcus, Thanks for your reply, but I'm afraid I still don't understand some of it. If the package is installed but the patch isn't, I thought I should see a green and white Z. What's the difference in these cases? When you say 'it will be gone', do you mean the patch will be installed?
Another aspect is why some patches are shown with a white triangle and white box with a black tick when the packages themselves have a black triangle with a green and white Z (e.g. krb5). Other patches for packages marked in this way are themselves marked with a white triangle and a green and white Z (e.g. python). What's the difference?
refresh, some packages have been installed that do not satisfy the patch.
Sorry, I don't understand this at all. What's refresh? How can I see what doesn't satisfy the patch (Check says all dependencies are OK)? How can I see what rule it is using to decide that something should be autoinstalled?
The final aspect is specific to gtk2. There is a patch for gtk2, which I have installed. Why can't I see a matching patch to gtk2-debuginfo? There's a version conflict. Am I misunderstanding something or is this a bug?
We do not ship updates for -debuginfo packages, you need to deinstall gtk2-debuginfo before updating.
Have I understood you correctly: As soon as there's an update to a package, it's no longer possible to debug it? Thanks, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-07-18 at 23:35 +0100, Dave Howorth wrote:
We do not ship updates for -debuginfo packages, you need to deinstall gtk2-debuginfo before updating.
Have I understood you correctly: As soon as there's an update to a package, it's no longer possible to debug it?
Kind of. If you need to debug something requiring a debug info rpm, and there has been an update, then you can't proceed. I have been bitten a few times by this. The debug repository has no updates at all since release date of the distro. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGnpmatTMYHG2NR9URAqy2AKCQrYznj04cPiCT9z9ufytkEWqg4ACfQZl3 YVAZeMDAKezsrxOcDFBfmAY= =quaI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi Marcus,
Thanks for your reply, but I'm afraid I still don't understand some of it. If the package is installed but the patch isn't, I thought I should see a green and white Z. What's the difference in these cases? When you say 'it will be gone', do you mean the patch will be installed?
The patch will be installed in this case (and this fact recorded). The problem here is that a patch might not just require some specific package versions, but also run scripts, display licenses etc.
Another aspect is why some patches are shown with a white triangle and white box with a black tick when the packages themselves have a black triangle with a green and white Z (e.g. krb5). Other patches for packages marked in this way are themselves marked with a white triangle and a green and white Z (e.g. python). What's the difference?
refresh, some packages have been installed that do not satisfy the patch.
Sorry, I don't understand this at all. What's refresh? How can I see what doesn't satisfy the patch (Check says all dependencies are OK)? How can I see what rule it is using to decide that something should be autoinstalled?
You can check the versions of the packages in the upper-right window. I guess one or more might not be fulfilled yet, while others are.
The final aspect is specific to gtk2. There is a patch for gtk2, which I have installed. Why can't I see a matching patch to gtk2-debuginfo? There's a version conflict. Am I misunderstanding something or is this a bug?
We do not ship updates for -debuginfo packages, you need to deinstall gtk2-debuginfo before updating.
Have I understood you correctly: As soon as there's an update to a package, it's no longer possible to debug it?
You can still debug it and the debugger will show a backtrace at least, its just that the debuginfo package cannot be used. (The reason we leave them out is just bandwith and diskspace issues.) Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Dňa Št 19. Júl 2007 08:36 Marcus Meissner napísal:
Hi Marcus,
Thanks for your reply, but I'm afraid I still don't understand some of it. If the package is installed but the patch isn't, I thought I should see a green and white Z. What's the difference in these cases? When you say 'it will be gone', do you mean the patch will be installed?
The patch will be installed in this case (and this fact recorded).
The problem here is that a patch might not just require some specific package versions, but also run scripts, display licenses etc.
Additionally - if you have a patch installed, YaST will always use this information to keep you system consistent, so e.g. it will warn you if you try to downgrade a related package, because that would mean your system does not contain the fix completely (think patch = fix of a problem). Stano -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Marcus Meissner wrote:
The final aspect is specific to gtk2. There is a patch for gtk2, which I have installed. Why can't I see a matching patch to gtk2-debuginfo? There's a version conflict. Am I misunderstanding something or is this a bug? We do not ship updates for -debuginfo packages, you need to deinstall gtk2-debuginfo before updating. Have I understood you correctly: As soon as there's an update to a package, it's no longer possible to debug it?
You can still debug it and the debugger will show a backtrace at least, its just that the debuginfo package cannot be used. (The reason we leave them out is just bandwith and diskspace issues.)
"given enough eyeballs, all bugs are shallow" Helping to find bugs is one of the very few things I feel able to contribute back to the community. This policy means I can't help in such situations. There's a problem in gtk that apparently only shows up in some configurations. I happen to have a configuration where it shows up and was asked to try debugging with symbols to help locate it. I know I could in theory recompile everything myself but I'm not confident I know how to get exactly the same configuration and they couldn't be sure either, so lack of the debuginfo package is a high enough barrier in this case to reduce the number of eyeballs. If there's any possibility to change this policy, I believe it would be helpful to the goals of increasing quality and reducing costs. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, Jul 19, 2007 at 10:00:01AM +0100, Dave Howorth wrote:
Marcus Meissner wrote:
The final aspect is specific to gtk2. There is a patch for gtk2, which I have installed. Why can't I see a matching patch to gtk2-debuginfo? There's a version conflict. Am I misunderstanding something or is this a bug? We do not ship updates for -debuginfo packages, you need to deinstall gtk2-debuginfo before updating. Have I understood you correctly: As soon as there's an update to a package, it's no longer possible to debug it?
You can still debug it and the debugger will show a backtrace at least, its just that the debuginfo package cannot be used. (The reason we leave them out is just bandwith and diskspace issues.)
"given enough eyeballs, all bugs are shallow"
Helping to find bugs is one of the very few things I feel able to contribute back to the community. This policy means I can't help in such situations.
There's a problem in gtk that apparently only shows up in some configurations. I happen to have a configuration where it shows up and was asked to try debugging with symbols to help locate it.
I know I could in theory recompile everything myself but I'm not confident I know how to get exactly the same configuration and they couldn't be sure either, so lack of the debuginfo package is a high enough barrier in this case to reduce the number of eyeballs.
If there's any possibility to change this policy, I believe it would be helpful to the goals of increasing quality and reducing costs.
$ cd /mounts/mirror/SuSE/ftp.suse.com/pub/suse/update/10.1 $ du ... 18748580 . $ Currently we have nearly 19GB of updates in the 10.1 repo after a little over 1 year of updates. Now add 3 or 4 times the size for just the debuginfos. The mirrors likely will not cope. We are aware of the issue and try to fix it (by leaving out the sources from the debuginfo package likely). Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 19 July 2007 11:00:01 Dave Howorth wrote:
There's a problem in gtk that apparently only shows up in some configurations. I happen to have a configuration where it shows up and was asked to try debugging with symbols to help locate it.
Wasn't this problem solved already? Or is this something else? The problem you reported earlier had to do with connecting to dbus, and is not a bug, just a setup problem inherent in gnome -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anders Johansson wrote:
On Thursday 19 July 2007 11:00:01 Dave Howorth wrote:
There's a problem in gtk that apparently only shows up in some configurations. I happen to have a configuration where it shows up and was asked to try debugging with symbols to help locate it.
Wasn't this problem solved already? Or is this something else?
You diagnosed the gtk problem, I believe, though the gtk people haven't confirmed it to me yet. But this discussion is not about the gtk problem, it's about the fact that it's not possible to debug opensuse packages after they've been updated (except by jumping through extra hoops). The gtk problem is just an example for context. Thanks again for your help with gtk, and thanks to Marcus for explaining the difficulty with providing updated debuginfo packages. Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
I am truly frustrated at applications like online update, open suse update, Zen, what ever you like enforcing the application set standards on an acceptable response time from the update source. When are we going to stop dictating to the comms protocols, which are far more superior in making decisions, perform retries and have all the redundancy built in. - That why we have comms protocols - To work out all that stuff. Now we have various online update sources impose their time limits upon over and above what comms is designed to perform. I know there have been so may changes to online update for various reasons and I would issue extreme caution here in the people who are playing with absolute values for comms traffic over and above what it does best left alone. I want to see the total removal of all limiting factors zen updater imposes on comms right now. You never have an application decide on retries, redundancy issues, etc. ALL these factors are part of comms and the issue here is comms tries relentlessly to obtain a valid and intact packets from source and it will continue to use every means at its disposal - This is why we have such sophistication in our comms protocol. I would like to know WHY YAST2 imposes its own set of values to comms. This is the wrong way round - comms frailties are generally looked after by itself and will ultimately issue error responses at the last resort. We do not need application imposed values on a comms protocol. If we don't remove all application imposed limitations on comms traffic, AND stop playing with it we ALL we reach a stage where it will be impossible to correct the damage we may send out in a successful update to YAST2. For every single failure of an online update I would like a BUG report raised. We all do not have T3 comms lines that testing is done on at suse.de. at best I have a very fast 20/10 mb per sec and I still get error after error from Yast2 giving up and telling comms to give up on a online update as the redundancy imposed parameters by YAST2 are in conflict with the redundancy abilities of the protocol. Go back to the 10.0 suse updater, eradicate zen updater, eradicate open suse updater and leave comms alone to do what it does best. We have been trying to get online update working since the rubbish started poring out since 10.1 and it continues to get worse not better. OMG could you image M$ not being able to update its own M$ Windows an M$ Vista O/S. Has anyone ever heard of M$ online update fail. If M$ can distribute SP2 for XP which was in excess of 100mb of data without issue to a very large audience world wide; why the hell are we still struggling to update several small files to an infinitely smaller audience. If Novell can product such a sophisticated advanced file server in Netware then where are all those cleaver minds today - Certainly they are NOT at suse.de
Registration Account wrote:
I am truly frustrated at applications like online update, open suse update, Zen, what ever you like enforcing the application set standards on an acceptable response time from the update source.
Please don't hijack threads. Start your own if you want to start a new topic. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 20 July 2007 04:05:13 Registration Account wrote:
I am truly frustrated at applications like online update, open suse update, Zen, what ever you like enforcing the application set standards on an acceptable response time from the update source.
When are we going to stop dictating to the comms protocols, which are far more superior in making decisions, perform retries and have all the redundancy built in. - That why we have comms protocols - To work out all that stuff.
Just out of curiosity, what are you talking about? comms protocols? huh?
issue to a very large audience world wide; why the hell are we still struggling to update several small files to an infinitely smaller audience.
The problems aren't in the actual delivery of the files -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (7)
-
Anders Johansson -
Carlos E. R. -
Dave Howorth -
Dave Howorth -
Marcus Meissner -
Registration Account -
Stanislav Visnovsky