July 2008 - openSUSE Features - openSUSE Mailing Lists

[openFate 304889] needs_relogin/needs_reboot as a generic flag
by fate_noreply＠suse.de 17 Jul '08

17 Jul '08

Feature changed by: Martin Vidner (mvidner(a)novell.com) Feature #304889, revision 10 Title: needs_relogin/needs_reboot as a generic flag openSUSE-11.1: Candidate Priority Requester: Neutral Projectmanager: Mandatory Requested by: Stanislav Brabec (sbrabec(a)novell.com) + Partner organization: openSUSE.org Description: There are situations, where relogin or reboot are needed to activate update: * package updates * proxy settings Now this situation is not done in a consistent way (silently ignoring problem, note in help, abuse of License entry, pop-up...). Providing a common way for setting these flags (via package provides, YaST calls, sysconfig comments) (and maybe comment what will happen ignoring it) would help in user experience (user is notified about need of relogin/reboot in a consistent way and only once) and administration (automatic relogin or reboot during maintenance window). Discussion: #1: Stanislav Visnovsky(visnov(a)novell.com) (2008-06-26 14:15:12) needs_reboot is properly handled by our tools. needs_relogin does not exist. #2: Jiri Srain(jsrain(a)novell.com) (2008-07-07 10:46:59) (reply to #1) We handle reboot only for package management not for anything else (the question is whether it is relevant somewhere else), thus we will need to have a more generic solution. Martin, would you, please, have a look and suggest a generic handler? #3: Stanislav Brabec(sbrabec(a)novell.com) (2008-07-09 15:26:16) needs_relogin would be useful in these situations: * New package, which provides file in /etc/profile.d was installed (or /etc/profile.d was singnificantly modified by the update). Example: ladspa * Packages, that cause that /etc/profile will evaluate environment. Example: Install any KDE application in GNOME only system. /opt/kde3 is not in PATH until next login * Patches, that affect login related programs. Example: security update of ssh-agent or gnome-keyring * YaST settings, that cause environment variable changes. Example: System proxy settings -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304889

1 0

[Fate 302957] Combined "where am I" page
by fate_noreply＠suse.de 15 Jul '08

15 Jul '08

Feature changed by: visnov Feature #302957, revision 33 Title: Combined "where am I" page openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Important SLED-11: Done Priority Requester: Mandatory SLES-11: Done Priority Requester: Mandatory Requested by: coolo(a)novell.com Partner organization: openSUSE.org Description: Our (openSUSE) statistics show that most of our users are not native english speakers. So I'm blindly assuming they do not have a english keyboard either and do not live in an english speaking timezone. So I want the first page to be not just the language in a blue box, but to have _one_ installation page with language, timezone and keyboard selection. These selections should depend on each other, so depending on where I click first the others change. To have a good looking addon, I picture the timezone selection as picture and not as fullscreen list boxes. + Documentation Impact: + Installation guide needs to be updated. Discussion: #1: coolo(a)novell.com (2007-11-09 11:48:30) An additional note, feature #302955 is related (split translations out of installation system). #2: jsrain(a)novell.com (2007-11-09 13:27:05) Isn't it easier for users who do not speak English to have the first dialog really as simple as possible (since they cannot read it)? Having just one selection box leads them straight where they need to get; I guess that most of them use mouse for installation, so keyboard is not an issue either... Also, we already have a support in isolinux to select language; then the first dialog is skipped. #3: coolo(a)novell.com (2007-11-09 14:13:14) If isolinux provides a language, then the page is not worse than the timezone page is now. Just that it also allows to change the language after the fact. If users do not grasp english _at all_, they will have a hard time booting the installation off the CD. So I would blindly assume that users have no problem with selecting Deutsch, русский or čeština when presented with a list even if they do not understand the exact context. And when next to that list is even a graphical presentation of the world, most will be able to select the part of the world they live in. #4: evamaria.fuchs(a)novell.com (2007-11-09 16:00:35) I think for the secondary target market of opensuse (first time user, home user)an installer wizard that consists of a series of screens would be convenient. Basically it's preferable that language-, time-zone- and keyboard- selection depend on each other so that modifying one will effect the others. But - as I prefer a picture (e.g. a rotating globe) for time- zone selection - sticking them together in one screen would clutter the whole thing up. #5: coolo(a)novell.com (2007-11-15 13:01:50) after some discussions with Eva, I want to reexpress my request: I want the language selection to be on one page together with license and a welcome text and the timezone dialog to be graphical and a proposed keyboard layout associated to the language from the first page. The license text doesn't have to be visible in full beauty. I talked with the lawyer and what I got was: it's ok if the license can be read, it doesn't have to optimized for scrolling. I'll work on a mockup. The challenge is that we might need a slightly different work flow for ncurses, but I think popups are ok for it. So you can write UI code, that either fills a special widget or opens a popup. #6: coolo(a)novell.com (2007-11-18 13:53:57) (reply to #5) Danger Mouse! I'm very far from a capable mockup designer. But here is my show: http://ktown.kde.org/~coolo/Namenlos.png #7: coolo(a)novell.com (2007-11-18 13:54:45) (reply to #6) Ciaran, just to verify: is this way to present the license ok? #9: cfarrell(a)suse.de (2007-11-19 08:51:13) (reply to #7) Provided that we maintain the status quo with regard to not proceeding with the installation until the user actually accepts the license. #8: coolo(a)novell.com (2007-11-18 14:39:45) (reply to #6) mocking up the timezone page, I leave to the interested reader. For reference: this is how unbuntu's installer looks like: https://help.ubuntu.com/community/GraphicalInstall?action=AttachFile&do=get… I would make the map a little smaller and do not show a region and not the name of the timezone again, but rather have the value of the combobox fill in what we have now as Europe/Berlin. Because I want a "Keyboard: English" with a little test field in there. But that is to be discussed. The main goal is to have a graphical selection instead of these fullscreen list boxes. #10: michl(a)novell.com (2007-11-19 13:28:22) Mockup looks good. And the whole thing should simplify and shorten the installation process. #11: jsrain(a)novell.com (2007-11-19 16:57:23) The timezone dialog looks good to me, however, we should not present the other one in the current form. Even if we have a different dialog for NCurses, we still must take care of Qt with the resolution of 800x600. With the current font size, the text itself will not fit into the screen if it is 800x600. Also consider the license - if one wants to read it, he wants to read a reasonable part of the license without scrolling - and not to scroll every 3rd line. IMO this suggestion puts the usability a huge step back #12: coolo(a)novell.com (2007-11-19 18:23:04) (reply to #11) damn, fate crashed on my comment ;( Again: I'm not a good designer But as a matter of fact: we do not design the default screen estate for reading the license, but of course a better design can add a popup to read the full text in full screen. #14: locilka(a)novell.com (2007-11-29 13:10:32) Additional step to help user understand where he is and what he can do there is to remove a [Show Release Notes] button and place that button to a Welcome Dialog only. The button doesn't need to occupy installation wizard screen all the time, it often rather confuses users. Frankly, this wasn't my idea but I found it useful :) ;) #15: jsuchome(a)novell.com (2007-12-20 16:19:25) Proposal of timezone dialog with a map: http://w3.suse.de/~jsuchome/screenshots/yast2-timezone-wordmap-zoomed.png BTW, it may not have a sense to offer keyboard configuration together with timezone. Keyboard layout is currently decided according to selected language, so it may better fit together with language. But the language dialog could get eventually too crowded. #16: coolo(a)novell.com (2007-12-22 14:05:24) new screenshot for the first page (I tried ycp): http://ktown.kde.org/~coolo/yast7.png Some icons and some more text would help the design I'd think. #17: coolo(a)novell.com (2008-01-08 12:40:13) http://en.opensuse.org/Image:Yast8.png is Martin's counter proposal. This one needs icons to differ the combo boxes though, but I believe a keyboard and an UN flag should make this obvious enough. #18: locilka(a)novell.com (2008-01-10 15:24:31) (reply to #17) BTW: This complex dialog will not be part of yast2-country (or similar) but directly yast2-installation because it contains more than just defining the language and keyboard settings. License handling needs to be reworked. #19: jsuchome(a)novell.com (2008-01-23 09:37:39) (reply to #18) Well, OK than. I expect you will ask for creating some API of Language (and maybe Keyboard) module, because current one probably is not sufficient. The API should be used instead writing whole stuff again separately, so we don't have the language handling on more places. #20: locilka(a)novell.com (2008-01-28 11:22:59) (reply to #19) Yes, Language API would probably help a lot. Please, propose, what you could create considering the default state at http://svn.opensuse.org/svn/yast/trunk/installation/src/clients/inst_comple… For instance, generating the combo boxes for language and keyboard selections might be moved to the API (I saw some functions in the current API though). The current implementation has been done in a hurry before the alpha deadline, it needs to be polished. Feel free to change it directly, it's open source. #21: jsuchome(a)novell.com (2008-01-28 11:32:01) (reply to #20) I agree, currently the API for generating the widget contents is needed, maybe that's all. I have to check it. #22: locilka(a)novell.com (2008-02-01 04:09:18) New "where am I page" with Language, Keyboard, and License will be in 11.0 Alpha2. #23: locilka(a)novell.com (2008-02-27 11:10:18) (reply to #22) Done in openSUSE 11.0 Alpha2 (and later). There were some bugfixes and internal changes though... -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=302957

1 0

[Fate 302919] Improved argument handling for zypper
by fate_noreply＠suse.de 15 Jul '08

15 Jul '08

Feature changed by: visnov Feature #302919, revision 9 Title: Improved argument handling for zypper openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Important SLED-11: Done Priority Requester: Mandatory SLES-11: Done Priority Requester: Mandatory Requested by: kkaempf(a)novell.com Partner organization: openSUSE.org Description: Please improve argument handling on the zypper command line. zypper install foo should look for a package named foo and, if no such package exist, do an automatic fallback to a capability. The --name qualifier can be used to prevent this fallback (forces a package name. The --capability qualifier can be used to force a capability. - Specifying versions and operators should also be more flexible (Following the motto be generous in what you accept, and strict in what you send ) zypper in foo-1.2-3 should try to install package foo, version 1.2, release 3. zypper in foo-1.2 should try to install package foo, version 1.2, any release. zypper in foo should try to install package foo, any version, any release. When specifying operators, spaces should be accepted, i.e. zypper in foo = 1.2-3 - Forcing a specific repository could be done by prefixing the package name with the repository alias followed by a colon, i.e. zypper in opensuse:foo - To be discussed on opensuse-softwaremgmt and cross-checked with other tools like smart and yum. + Documentation Impact: + Please, consider this for the documentation update. Discussion: #1: visnov(a)novell.com (2007-11-23 11:24:48) zypper improvements. #2: jkupec(a)novell.com (2008-04-14 15:02:32) All of the orginal suggestions are implemented, except for per-package forcing of repositories. Can i mark as done? I also thought of install foo@arch postfix to force specific architecture. There is no libzypp API for per-package forcing of repository or architecture but it's doable in zypper the old (forced) way. Would take only few more hours. #3: jkupec(a)novell.com (2008-04-14 14:58:01) BTW, we've got wildcard support, install/remove in one go using +/- ~/! prefix (+maybe more i cannot recall now) as bonus :O) Details will be added to the man page and wiki later. #4: jkupec(a)novell.com (2008-04-21 13:29:15) All done in zypper 0.11.1 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=302919

1 0

[Fate 304395] Disabling (or handling) screensaver during installation
by fate_noreply＠suse.de 15 Jul '08

15 Jul '08

Feature changed by: locilka Feature #304395, revision 14 Title: Disabling (or handling) screensaver during installation openSUSE-11.1: Done Priority Requester: Desirable Projectmanager: Important Requested by: locilka(a)novell.com Partner organization: openSUSE.org Description: We currently have screen-saver active during installation/upgrade. This is a bit problematic when some exception occurs and opens a pop-up window requesting some user-decision (Abort/Retry/Ignore/...). On slower networks, installation can take tens of minutes, even a few hours. It would be nice to disable the screen-saver (easy) or at least handle all the exceptions by disabling the screen-saver. References: Bug 393890 - How to disable screen blank during installation https://bugzilla.novell.com/show_bug.cgi?id=393890 Black monitor (thread): "The screen suudenly went black" http://lists.opensuse.org/opensuse-factory/2008-05/msg00675.html Use Case: Installation on slower computer and/or via slower network Discussion: #1: aschnell(a)novell.com (2008-05-27 15:10:07) On slow computers people might actually want the screensaver. Suppose you start the installation and go home or sleeping: I would expect that the monitor powers off after some time. We could add a call "xset dpms force on" to popups. But I doubt that this is worth the effort. #2: locilka(a)novell.com (2008-05-27 15:43:16) (reply to #1) Bug 393890 says exactly: During installation the screen will blank when for some period no keyboard and mouse activity is recognized. The drawback is, that you will not notice error messages that pop up. So one has to move the mouse every 5 minutes or so and is bound to the installation. It would be cool, if we could either do not blank the screen at all, or "deblank" it, when a error message pops up. ... and Stefan Hundhammer adds: The screen saver should be off during installation. Why would there be any exception to this rule? (It's not even that screen savers serve their real purpose these days - it was an issue with old (very old) CRT monitors that could "burn in" images that would be displayed for a long, long time - and then, we are talking about months, not about hours). #3: sh(a)novell.com (2008-05-27 16:10:19) (reply to #1) aschnell wrote: On slow computers people might actually want the screensaver. Suppose you start the installation and go home or sleeping: I would expect that the monitor powers off after some time. When I go home during such a lengthy operation, what's wrong with simply turning the monitor off? This is the most natural and the simplest thing to do. #4: sh(a)novell.com (2008-05-27 16:18:21) See also Bug #393890 (https://bugzilla.novell.com/show_bug.cgi?id=393890) Changing screen saver settings in a widget toolkit (!) such as the YaST2 Qt UI would affect ALL applications written with that toolkit. Right now, that's all YaST2 modules, but since this UI is now available as a general toolkit, you'll never know what other applications this might affect in the future. An X11 application is not to change the user's screen saver settings (unless it is a dedicated application to configure screen saver settings, of course), much less silently in the background. We'd get a lot of surprised and very angry users, and they would have every right to be angry with us. You wouldn't even be able to find out why your screen saver doesn't work any more. #5: locilka(a)novell.com (2008-05-27 16:27:02) (reply to #4) The feature request is about installation, not about running system. But it's a good point that we should not change that in general... (the whole toolkit). Thanks. #6: flucifredi(a)novell.com (2008-06-13 17:42:27) ...and we should look at powersave behavior too during these operations. #7: visnov(a)novell.com (2008-07-07 09:29:27) Let's see what can be done. I suggest to: 1) having a installation parameter to switch the screen saver off 2) error messages to stop screensaver if running #8: jsrain(a)novell.com (2008-07-11 10:08:35) The first part is easily possible and we can do it. Tracking all error pop-ups is not easy. I suggest to disable screensaver at the beginning of installation. Who is doing installation overnight usually switches off the display anyway. #9: locilka(a)novell.com (2008-07-14 17:09:48) (reply to #8) Adjusting DPMS 'off' (xset -dpms) when installation starts, DPMS 'on' (xset +dpms) when finishes (FATE #304395). Feature done in yast2-installation- 2.17.1 #10: jsuchome(a)novell.com (2008-07-15 07:51:02) (reply to #9) Ah, this means that xset call could be disabled from timezone client... + #11: locilka(a)novell.com (2008-07-15 10:08:30) (reply to #9) + Also screensaver had to be turned off/on to make it work. yast2- + installation- 2.17.2 + Disabling: + /usr/bin/xset dpms 0 0 0; /usr/bin/xset -dpms; /usr/bin/xset s 0 0 + Re-enabling: + /usr/bin/xset dpms 1200 1800 2400; /usr/bin/xset +dpms; + /usr/bin/xset s default -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=304395

1 0

[Fate 304395] Disabling (or handling) screensaver during installation
by fate_noreply＠suse.de 15 Jul '08

15 Jul '08

Feature changed by: jsuchome Feature #304395, revision 13 Title: Disabling (or handling) screensaver during installation openSUSE-11.1: Done Priority Requester: Desirable Projectmanager: Important Requested by: locilka(a)novell.com Partner organization: openSUSE.org Description: We currently have screen-saver active during installation/upgrade. This is a bit problematic when some exception occurs and opens a pop-up window requesting some user-decision (Abort/Retry/Ignore/...). On slower networks, installation can take tens of minutes, even a few hours. It would be nice to disable the screen-saver (easy) or at least handle all the exceptions by disabling the screen-saver. References: Bug 393890 - How to disable screen blank during installation https://bugzilla.novell.com/show_bug.cgi?id=393890 Black monitor (thread): "The screen suudenly went black" http://lists.opensuse.org/opensuse-factory/2008-05/msg00675.html Use Case: Installation on slower computer and/or via slower network Discussion: #1: aschnell(a)novell.com (2008-05-27 15:10:07) On slow computers people might actually want the screensaver. Suppose you start the installation and go home or sleeping: I would expect that the monitor powers off after some time. We could add a call "xset dpms force on" to popups. But I doubt that this is worth the effort. #2: locilka(a)novell.com (2008-05-27 15:43:16) (reply to #1) Bug 393890 says exactly: During installation the screen will blank when for some period no keyboard and mouse activity is recognized. The drawback is, that you will not notice error messages that pop up. So one has to move the mouse every 5 minutes or so and is bound to the installation. It would be cool, if we could either do not blank the screen at all, or "deblank" it, when a error message pops up. ... and Stefan Hundhammer adds: The screen saver should be off during installation. Why would there be any exception to this rule? (It's not even that screen savers serve their real purpose these days - it was an issue with old (very old) CRT monitors that could "burn in" images that would be displayed for a long, long time - and then, we are talking about months, not about hours). #3: sh(a)novell.com (2008-05-27 16:10:19) (reply to #1) aschnell wrote: On slow computers people might actually want the screensaver. Suppose you start the installation and go home or sleeping: I would expect that the monitor powers off after some time. When I go home during such a lengthy operation, what's wrong with simply turning the monitor off? This is the most natural and the simplest thing to do. #4: sh(a)novell.com (2008-05-27 16:18:21) See also Bug #393890 (https://bugzilla.novell.com/show_bug.cgi?id=393890) Changing screen saver settings in a widget toolkit (!) such as the YaST2 Qt UI would affect ALL applications written with that toolkit. Right now, that's all YaST2 modules, but since this UI is now available as a general toolkit, you'll never know what other applications this might affect in the future. An X11 application is not to change the user's screen saver settings (unless it is a dedicated application to configure screen saver settings, of course), much less silently in the background. We'd get a lot of surprised and very angry users, and they would have every right to be angry with us. You wouldn't even be able to find out why your screen saver doesn't work any more. #5: locilka(a)novell.com (2008-05-27 16:27:02) (reply to #4) The feature request is about installation, not about running system. But it's a good point that we should not change that in general... (the whole toolkit). Thanks. #6: flucifredi(a)novell.com (2008-06-13 17:42:27) ...and we should look at powersave behavior too during these operations. #7: visnov(a)novell.com (2008-07-07 09:29:27) Let's see what can be done. I suggest to: 1) having a installation parameter to switch the screen saver off 2) error messages to stop screensaver if running #8: jsrain(a)novell.com (2008-07-11 10:08:35) The first part is easily possible and we can do it. Tracking all error pop-ups is not easy. I suggest to disable screensaver at the beginning of installation. Who is doing installation overnight usually switches off the display anyway. #9: locilka(a)novell.com (2008-07-14 17:09:48) (reply to #8) Adjusting DPMS 'off' (xset -dpms) when installation starts, DPMS 'on' (xset +dpms) when finishes (FATE #304395). Feature done in yast2-installation- 2.17.1 + #10: jsuchome(a)novell.com (2008-07-15 07:51:02) (reply to #9) + Ah, this means that xset call could be disabled from timezone + client... -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=304395

1 0

[Fate 304395] Disabling (or handling) screensaver during installation
by fate_noreply＠suse.de 14 Jul '08

14 Jul '08

Feature changed by: locilka Feature #304395, revision 12 Title: Disabling (or handling) screensaver during installation - openSUSE-11.1: Candidate + openSUSE-11.1: Done Priority Requester: Desirable Projectmanager: Important Requested by: locilka(a)novell.com Partner organization: openSUSE.org Description: We currently have screen-saver active during installation/upgrade. This is a bit problematic when some exception occurs and opens a pop-up window requesting some user-decision (Abort/Retry/Ignore/...). On slower networks, installation can take tens of minutes, even a few hours. It would be nice to disable the screen-saver (easy) or at least handle all the exceptions by disabling the screen-saver. References: Bug 393890 - How to disable screen blank during installation https://bugzilla.novell.com/show_bug.cgi?id=393890 Black monitor (thread): "The screen suudenly went black" http://lists.opensuse.org/opensuse-factory/2008-05/msg00675.html Use Case: Installation on slower computer and/or via slower network Discussion: #1: aschnell(a)novell.com (2008-05-27 15:10:07) On slow computers people might actually want the screensaver. Suppose you start the installation and go home or sleeping: I would expect that the monitor powers off after some time. We could add a call "xset dpms force on" to popups. But I doubt that this is worth the effort. #2: locilka(a)novell.com (2008-05-27 15:43:16) (reply to #1) Bug 393890 says exactly: During installation the screen will blank when for some period no keyboard and mouse activity is recognized. The drawback is, that you will not notice error messages that pop up. So one has to move the mouse every 5 minutes or so and is bound to the installation. It would be cool, if we could either do not blank the screen at all, or "deblank" it, when a error message pops up. ... and Stefan Hundhammer adds: The screen saver should be off during installation. Why would there be any exception to this rule? (It's not even that screen savers serve their real purpose these days - it was an issue with old (very old) CRT monitors that could "burn in" images that would be displayed for a long, long time - and then, we are talking about months, not about hours). #3: sh(a)novell.com (2008-05-27 16:10:19) (reply to #1) aschnell wrote: On slow computers people might actually want the screensaver. Suppose you start the installation and go home or sleeping: I would expect that the monitor powers off after some time. When I go home during such a lengthy operation, what's wrong with simply turning the monitor off? This is the most natural and the simplest thing to do. #4: sh(a)novell.com (2008-05-27 16:18:21) See also Bug #393890 (https://bugzilla.novell.com/show_bug.cgi?id=393890) Changing screen saver settings in a widget toolkit (!) such as the YaST2 Qt UI would affect ALL applications written with that toolkit. Right now, that's all YaST2 modules, but since this UI is now available as a general toolkit, you'll never know what other applications this might affect in the future. An X11 application is not to change the user's screen saver settings (unless it is a dedicated application to configure screen saver settings, of course), much less silently in the background. We'd get a lot of surprised and very angry users, and they would have every right to be angry with us. You wouldn't even be able to find out why your screen saver doesn't work any more. #5: locilka(a)novell.com (2008-05-27 16:27:02) (reply to #4) The feature request is about installation, not about running system. But it's a good point that we should not change that in general... (the whole toolkit). Thanks. #6: flucifredi(a)novell.com (2008-06-13 17:42:27) ...and we should look at powersave behavior too during these operations. #7: visnov(a)novell.com (2008-07-07 09:29:27) Let's see what can be done. I suggest to: 1) having a installation parameter to switch the screen saver off 2) error messages to stop screensaver if running #8: jsrain(a)novell.com (2008-07-11 10:08:35) The first part is easily possible and we can do it. Tracking all error pop-ups is not easy. I suggest to disable screensaver at the beginning of installation. Who is doing installation overnight usually switches off the display anyway. + #9: locilka(a)novell.com (2008-07-14 17:09:48) (reply to #8) + Adjusting DPMS 'off' (xset -dpms) when installation starts, DPMS 'on' + (xset +dpms) when finishes (FATE #304395). + Feature done in yast2-installation- 2.17.1 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=304395

1 0

[Fate 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 14 Jul '08

14 Jul '08

Feature changed by: jsuchome Feature #303517, revision 10 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: lslezak(a)novell.com Partner organization: openSUSE.org Description: Autorefresh configured repositories at certain times, this could be on certain days, or time of day, etc. A mockup and more details are in https://bugzilla.novell.com/show_bug.cgi?id=346966 Discussion: #1: flucifredi(a)novell.com (2008-06-13 15:12:52) there are some caveats I can think of requiring silent fail (for instance, a laptop), or requiring randomization (not hitting NCC with a volley all at the same time), but I think the idea is good. #2: dmacvicar(a)novell.com (2008-07-07 11:13:37) If you think you can make it work in a reliable way, please present a concept. Right now PackageKit and updater applets do refresh often before checking for updates so the system repos _are_ refreshed. So I don't see much value in this feature (unless a concept is presented). #3: visnov(a)novell.com (2008-07-07 12:34:19) (reply to #2) We have a concept in the automatic online update configuration. #4: jsrain(a)novell.com (2008-07-07 12:58:59) (reply to #3) You mean running online update from cron? It should involve metadata refresh, but I do not see any reason for a separate metadata download from cron. #5: lslezak(a)novell.com (2008-07-09 10:30:09) (reply to #4) The feature should allow to disable "autorefresh" flag for all repositories so the package management can be started quickly without connecting to network. The cronjob would keep the metadata uptodate. Of course, there might be a problem when metadata are changed too often on the server, but in my opinion that's not a usual case in the real world. #6: jsrain(a)novell.com (2008-07-10 12:16:08) Let's extend the "automatic online update" module so that it offers whether to do real automatic online update, or just refresh the metadata (via one check box) + #7: jsuchome(a)novell.com (2008-07-14 14:46:01) + Daniel, what's the status of the plan to merge "online update + configuration" into registration module? -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303517

1 0

[Fate 302923] handle redirection to mirrors robustly
by fate_noreply＠suse.de 14 Jul '08

14 Jul '08

Feature changed by: jkupec Feature #302923, revision 11 Title: handle redirection to mirrors robustly openSUSE-11.0: Rejected by visnov(a)novell.com reject date: 2007-11-28 15:42:20 reject reason: Out of scope for 11.0 Priority Requester: Neutral openSUSE-11.2: New Priority Requester: Neutral SLED-11: Rejected by visnov(a)novell.com reject date: 2008-07-08 12:13:52 reject reason: Postponing, will not be ready. Priority Requester: Neutral SLES-11: Rejected by visnov(a)novell.com reject date: 2008-07-08 12:13:49 reject reason: Postponing, will not be ready. Priority Requester: Neutral Requested by: jkupec(a)novell.com Partner organization: openSUSE.org Description: The proposal is to try other mirrors from a mirror list (from the redirector?) if an error occurs on some of the mirrors while providing a file from http/ftp repository. See the references for more details. References: https://bugzilla.novell.com/show_bug.cgi?id=337410 http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00170.html + http://en.opensuse.org/Libzypp/Failover + http://code.google.com/soc/2008/suse/appinfo.html?csaid=6F1844AB23B67E06 Discussion: #1: coolo(a)novell.com (2007-11-20 11:15:49) I would be strictly against having an own mirror list. The decision was to go with the redirector (or NCC for SLE) and be done with mirrors. If that does not work, then we have to do this whole thing again, not adding untested work arounds to the product. #2: coolo(a)novell.com (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: freitag(a)novell.com (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: freitag(a)novell.com (2008-06-12 10:06:42) I have to revert my statement that I made before in comment #3, this problem is more serious than realised in the first look. First, it should be noted that we do not control mirrors nor we do have the chance to really influence them. That means that if a mirrors decides to not longer mirror or to switch off or whatever, we have to live with it. However if a customer is sticky to a mirror that is not longer available he would not get any packages from it and thus installation or update fails. The worst thing about that is that this seems to happen regularly but we do not realise that because we're not involved. A solution would be to have a list of possible mirrors that is used by the software installation stack to find a working mirror. Peter knows much more here. But I am not sure at the moment if not Yast/zypper already has this functionality in 11.0? -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=302923

1 0

[Fate 304429] Package cache handling in yast
by fate_noreply＠suse.de 11 Jul '08

11 Jul '08

Feature changed by: visnov Feature #304429, revision 6 Title: Package cache handling in yast - openSUSE-11.1: Evaluation + openSUSE-11.1: Rejected by visnov(a)novell.com + reject date: 2008-07-11 21:45:10 + reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: New Priority Requester: Important - SLES-11: Evaluation + SLES-11: Rejected by visnov(a)novell.com + reject date: 2008-07-11 21:44:51 + reject reason: This needs to wait, zypper already supports this + behavior. Priority Requester: Important Projectmanager: Important Requested by: lslezak(a)novell.com Partner organization: openSUSE.org Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=304429

1 0

[Fate 304429] Package cache handling in yast
by fate_noreply＠suse.de 11 Jul '08

11 Jul '08

Feature changed by: jsrain Feature #304429, revision 5 Title: Package cache handling in yast openSUSE-11.1: Evaluation Priority Requester: Important Projectmanager: Important + openSUSE-11.2: New + Priority + Requester: Important SLES-11: Evaluation Priority Requester: Important Projectmanager: Important Requested by: lslezak(a)novell.com Partner organization: openSUSE.org Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=304429

1 0