Morning folks, Would this list be the best place to post feedback regarding the test build of the update stack packages you posted yesterday Andreas? Or is it better moved to bugzilla...? If so I can move all this to bugzilla with logs etc. Here are my observations so far anyway. 1. The 10.1 release update stack successfully installed the test builds after I added the URL as a YUM service via zen-updater. However the whole upgrade took an extremely long time ( 15 minutes approx ). I was unable to determine why it was taking so long, i dont *think* it was the downloading... 2. Adding services via rug is just fine, and as per the 10.1 release builds ZYPP services are synced with YaST, YUM services are not. Adding services via zen-updater, same as rug, it works and the synching is the same. 2. Adding a larger service such as main online installation from mirror( inst-sources ) is much smoother. The service itself was added to the list in yast inst_sources almost instantaneously and unlilke the 10.1 release the catalog was not immediately downloaded but was only fetched when the finish button was pressed. At a rough guess I would say the whole process of adding the main installation source is 50% quicker now. 3. ZMD scheduling seems to be a bit broken now. It appears that the service refresh happens at the same time as the hourly maintenance, even though it is scheduled for the next day. Once the full service refresh and maintenance has run ( hourly by default it seems ) the schedule is reset with an updated time for the service refresh 24 hours later and 1 hour later for the maintenance. Of course the service refresh still happens one hour later and another new time i scheduled for it. This has the side effect of a full service refresh will run if my system is booted outside of the hourly maintenance window, parse-metadata and update-status hogging 100% CPU for a few minutes on boot. If i reboot my system inside the hourly maintenance window this does not happen.
To add quick observations after updating the update stack posted by Andreas. 1. The Yast2 online updater hanged while trying to download the updated packages (it stopped downloading one of the packages mid-way and just sat there for a while.) Killed the process, downloaded and installed the packages manually. 2. After update, now the "Installation Source" panel shows all catalogs I test added before via rug, they did not show with the previous update stack. 3. Updating the causes one of the cpu cores to be used close to 100% by an "update-status" process. It completed in about 4 minutes. I've 4 online catalogs and one local. 4. Loading the "Software Management" panel takes a couple of minutes and uses up to close to 100% cpu. 5. The installer now notifies of automatically selected packages for installation. 6. When you select the "changelog" of a package, it is not clear which one you are looking at, if there is a new version available, the installed one or the available one. Also, sometimes it takes a significant amount of time to load the changelog into the GUI. Try to load the changelog for the kernel-source package. That's it for now. -- Rafael
"Rafael E. Herrera"
To add quick observations after updating the update stack posted by Andreas.
1. The Yast2 online updater hanged while trying to download the updated packages (it stopped downloading one of the packages mid-way and just sat there for a while.) Killed the process, downloaded and installed the packages manually.
Not good.
2. After update, now the "Installation Source" panel shows all catalogs I test added before via rug, they did not show with the previous update stack.
Good.
3. Updating the causes one of the cpu cores to be used close to 100% by an "update-status" process. It completed in about 4 minutes. I've 4 online catalogs and one local.
4 minutes for update-status is long - we have to speed it up.
4. Loading the "Software Management" panel takes a couple of minutes and uses up to close to 100% cpu.
Please file a bug report with more information.
5. The installer now notifies of automatically selected packages for installation.
6. When you select the "changelog" of a package, it is not clear which one you are looking at, if there is a new version available, the installed one or the available one. Also, sometimes it takes a significant amount of time to load the changelog into the GUI. Try to load the changelog for the kernel-source package.
Might be worth a bugreport, Thanks, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
"Rafael E. Herrera"
To add quick observations after updating the update stack posted by Andreas.
1. The Yast2 online updater hanged while trying to download the updated packages (it stopped downloading one of the packages mid-way and just sat there for a while.) Killed the process, downloaded and installed the packages manually.
Not good.
2. After update, now the "Installation Source" panel shows all catalogs I test added before via rug, they did not show with the previous update stack.
Good.
3. Updating the causes one of the cpu cores to be used close to 100% by an "update-status" process. It completed in about 4 minutes. I've 4 online catalogs and one local.
4 minutes for update-status is long - we have to speed it up.
4. Loading the "Software Management" panel takes a couple of minutes and uses up to close to 100% cpu.
Please file a bug report with more information.
5. The installer now notifies of automatically selected packages for installation.
6. When you select the "changelog" of a package, it is not clear which one you are looking at, if there is a new version available, the installed one or the available one. Also, sometimes it takes a significant amount of time to load the changelog into the GUI. Try to load the changelog for the kernel-source package.
Might be worth a bugreport, Thanks, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Graham Anderson
Morning folks,
Would this list be the best place to post feedback regarding the test build of the update stack packages you posted yesterday Andreas? Or is it better moved to bugzilla...? If so I can move all this to bugzilla with logs etc.
Please move it to bugzilla as commented below.
Here are my observations so far anyway.
1. The 10.1 release update stack successfully installed the test builds after I added the URL as a YUM service via zen-updater. However the whole upgrade took an extremely long time ( 15 minutes approx ). I was unable to determine why it was taking so long, i dont *think* it was the downloading...
It was quite fast for me, if you know why it's slow, it's worth a report otherwise I guess we cannot do much.
2. Adding services via rug is just fine, and as per the 10.1 release builds ZYPP services are synced with YaST, YUM services are not. Adding services via zen-updater, same as rug, it works and the synching is the same.
Please report a bug with yum - it might even be a design decision right now.
2. Adding a larger service such as main online installation from mirror( inst-sources ) is much smoother. The service itself was added to the list in yast inst_sources almost instantaneously and unlilke the 10.1 release the catalog was not immediately downloaded but was only fetched when the finish button was pressed. At a rough guess I would say the whole process of adding the main installation source is 50% quicker now.
Good.
3. ZMD scheduling seems to be a bit broken now. It appears that the service refresh happens at the same time as the hourly maintenance, even though it is scheduled for the next day. Once the full service refresh and maintenance has run ( hourly by default it seems ) the schedule is reset with an updated time for the service refresh 24 hours later and 1 hour later for the maintenance. Of course the service refresh still happens one hour later and another new time i scheduled for it.
This has the side effect of a full service refresh will run if my system is booted outside of the hourly maintenance window, parse-metadata and update-status hogging 100% CPU for a few minutes on boot. If i reboot my system inside the hourly maintenance window this does not happen.
Please file a bug against the component "ZENworks", Thanks, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Friday 26 May 2006 07:59, Andreas Jaeger wrote:
3. ZMD scheduling seems to be a bit broken now. It appears that the service refresh happens at the same time as the hourly maintenance, even though it is scheduled for the next day. Once the full service refresh and maintenance has run ( hourly by default it seems ) the schedule is reset with an updated time for the service refresh 24 hours later and 1 hour later for the maintenance. Of course the service refresh still happens one hour later and another new time i scheduled for it.
This has the side effect of a full service refresh will run if my system is booted outside of the hourly maintenance window, parse-metadata and update-status hogging 100% CPU for a few minutes on boot. If i reboot my system inside the hourly maintenance window this does not happen.
Please file a bug against the component "ZENworks",
Thanks, Andreas
#179042 The archive atached to this bug filing contains zmd-messages.log, zmd-backend.log and zmd.conf These logs were started fresh and ZMD was left to run for an hour or so without any package management interaction with rug or zen-updater. Cheers Graham
Hi, also indirectly related to the test packages: Is it known that the set of test packages will make ruby-zypp uninstallable? It needs libzypp.so.0, but the set of test packages replaces that with libzypp.so.1. ruby-zypp doesn't seem to be used by anything so far, but still, some people might unintentionally downgrade their package management stuff by accidentally installing ruby-zypp after applying the update. => Bugzilla? Andreas Hanke -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
=> Bugzilla? Done and reported as #179018. Andreas Hanke -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
andreas.hanke@gmx-topmail.de writes:
=> Bugzilla?
Done and reported as #179018.
Thanks - and I've just updated my packages on the ftp server to include this one as well, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hi, I'd like to know if / propose that the following bugs are candidates for inclusion in the package management update: - Option to disable missing signature complaints is not persistent https://bugzilla.novell.com/show_bug.cgi?id=175845 Not because of its severity - it's actually labelled as "Minor" in Bugzilla - but because of the number of duplicates. It seems to annoy quite a lot of people. Fix available - can it be included? - Too many YaST/zmd related directories left behind in /var/tmp https://bugzilla.novell.com/show_bug.cgi?id=178292 Probably rather cosmetic, but ugly. No fix available so far according to Bugzilla, and not that important. But maybe later? - "Taboo" flag is not persistent in the package manager https://bugzilla.novell.com/show_bug.cgi?id=164445 https://bugzilla.novell.com/show_bug.cgi?id=153337 This one has several duplicates which are not yet marked as such. Doesn't seem to be implemented at all right now, but is a needed feature. Later? Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Andreas Hanke
Hi,
I'd like to know if / propose that the following bugs are candidates for inclusion in the package management update:
- Option to disable missing signature complaints is not persistent
It will go in since it's fixed.
Not because of its severity - it's actually labelled as "Minor" in Bugzilla - but because of the number of duplicates. It seems to annoy quite a lot of people. Fix available - can it be included?
Yes, already in my internal test build. We just wait for a fix for zen-updater that crashes on some systems in a reliable way (we had to take another update for it). As soon as that is fixed, we release new packages for testing - and mark them official. The current packages are good - but do not refresh with the ZENworks tools, so if something is newer on the server you will not notice it. Workaround: Run yast online_update. This is fixed now, so these fixes will also go out: * Optimize and fix downloading of type zypp * Fix refreshing repositories of type zypp (#154990) * Add support for key handling to zmd, rug, zen-updater (#173920) * Fix zen-updater to handle installation of patch and package together (#178015) I did not list each bugzilla number in my README.
- Too many YaST/zmd related directories left behind in /var/tmp
https://bugzilla.novell.com/show_bug.cgi?id=178292
Probably rather cosmetic, but ugly. No fix available so far according to Bugzilla, and not that important. But maybe later?
We're working on it, it might go out as well.
- "Taboo" flag is not persistent in the package manager
https://bugzilla.novell.com/show_bug.cgi?id=164445 https://bugzilla.novell.com/show_bug.cgi?id=153337
This one has several duplicates which are not yet marked as such. Doesn't seem to be implemented at all right now, but is a needed feature. Later?
Yes, will come later, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 1 Jun 2006 at 16:40, Andreas Hanke wrote:
Hi,
I'd like to know if / propose that the following bugs are candidates for inclusion in the package management update:
- Option to disable missing signature complaints is not persistent
https://bugzilla.novell.com/show_bug.cgi?id=175845
Not because of its severity - it's actually labelled as "Minor" in Bugzilla - but because of the number of duplicates. It seems to annoy quite a lot of people. Fix available - can it be included?
I think that's basically a dangerous option (Think of your webbrowser having a global option "trust expired and invalid certificates for secure connections": You would want it per certificate, not globally)
- Too many YaST/zmd related directories left behind in /var/tmp
OK, /var/tmp is "semi-permanent"; only /tmp is really /tmp. Meaning: No file should be in /tmp if the application terminated, but that's permissible for /var/tmp. So it depends on the details.
Probably rather cosmetic, but ugly. No fix available so far according to Bugzilla, and not that important. But maybe later?
- "Taboo" flag is not persistent in the package manager
https://bugzilla.novell.com/show_bug.cgi?id=164445 https://bugzilla.novell.com/show_bug.cgi?id=153337
Was it before? I don't think so. That would be bad for future updates. I think it shpould not be persistent.
This one has several duplicates which are not yet marked as such. Doesn't seem to be implemented at all right now, but is a needed feature. Later?
Regards, Ulrich
Andreas Hanke
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Dňa Pi 2. Jún 2006 08:37 Ulrich Windl napísal:
On 1 Jun 2006 at 16:40, Andreas Hanke wrote:
[snip]
Probably rather cosmetic, but ugly. No fix available so far according to Bugzilla, and not that important. But maybe later?
- "Taboo" flag is not persistent in the package manager
https://bugzilla.novell.com/show_bug.cgi?id=164445 https://bugzilla.novell.com/show_bug.cgi?id=153337
Was it before? I don't think so. That would be bad for future updates. I think it shpould not be persistent.
No, it was not persistent before. Stano --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Hi, Ulrich Windl schrieb:
I think that's basically a dangerous option (Think of your webbrowser having a global option "trust expired and invalid certificates for secure connections": You would want it per certificate, not globally)
But in any case there's a problem there, an option in the UI that doesn't behave as expected. If the option is there, it should do something and if it's decided that the option is dangerous, it should be removed. Otherwise Bugzilla will be flooded by complaints about unexpected behaviour.
OK, /var/tmp is "semi-permanent"; only /tmp is really /tmp. Meaning: No file should be in /tmp if the application terminated, but that's permissible for /var/tmp. So it depends on the details.
I'm not sure. Looking at the increased number of YaST-related directories in /var/tmp after each YaST session, it seems that new temp files are created each time and the old ones are not used again, so it doesn't seem necessary to keep them around. Actually I think it should be the other way round: If they are just used during one YaST session and never used again, they should be in /tmp, not /var/tmp.
- "Taboo" flag is not persistent in the package manager
https://bugzilla.novell.com/show_bug.cgi?id=164445 https://bugzilla.novell.com/show_bug.cgi?id=153337
Was it before? I don't think so.
You are right, it wans't. I never noticed that because I never needed it before.
That would be bad for future updates. I think it shpould not be persistent.
I think it should be. There are not only security updates, but also optional ones which might introduce problems - there's always a risk that an update can introduce problems. At least for optional, not security critical updates, not installing them is a viable solution. There should be an option to block these permanently. Actually the first dhcp update for 10.1 *was* broken, I was offline after applying it. That's why I noticed it. Right now the "taboo" option doesn't seem to do anything else than the "do not install" option. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
participants (7)
-
Andreas Hanke -
Andreas Jaeger -
andreas.hanke＠gmx-topmail.de
-
Graham Anderson -
Rafael E. Herrera -
Stanislav Visnovsky -
Ulrich Windl