July 2008 - openSUSE Features - openSUSE Mailing Lists

[openFate 305144] [Feature-request] Yast as a Linux learning tool
by fate_noreply＠suse.de 30 Jan '18

30 Jan '18

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305144, revision 1, last change by Title: [Feature-request] Yast as a Linux learning tool openSUSE-11.1: New Priority Requester: Desirable Requested by: Alexey Eremenko <al4321(a)gmail.com> Partner organization: openSUSE.org Description: Hi All ! I Have very good new idea: converting Yast into a Linux learning tool. This is very simple to achieve: Yast must show the commands it executes and files it modifies, in a nice GUI dialog. It will allow all kinds of Linux users understand how things really work. Enable learn new things or remind how old-but-forgotten things work for seasoned people. Great, isn't it ? P.S. Jay Vollmer recommends, that among the commands that Yast shows as it executing, it should also recommend "man pages" for the relevant underlying commands. -- -Alexey Eromenko "Technologov", 29.jul.2008. Discussion: #1: Alexey Eremenko <al4321(a)gmail.com> (2008-07-29 12:09:11) Rajko M. wrote: If one wants to see what is gong on in background, than look at logs in realtime. There is console (Konsole) and command tail. Run as root: tail -f /var/log/YaST2/y2log and then start YaST and play with. -- -Alexey Eromenko "Technologov", 29.jul.2008. #2: Jerry Houston <jerry.houston(a)comcast.net> (2008-07-29 15:41:34) Sounds like a great way for new users to learn more about what's under the hood. Or, what's under the bonnet, for the Brits. #3: Cyril Hrubis <chrubis(a)novell.com> (2008-07-31 07:11:21) Moving to maintainers to decide. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305144

1 19

[openFate 305099] please have yast do a fsck before attempting to mount existing filesystems
by fate_noreply＠suse.de 28 Jan '15

28 Jan '15

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305099, revision 1, last change by Title: please have yast do a fsck before attempting to mount existing filesystems openSUSE-11.2: New Priority Requester: Important Requested by: Per Jessen <per.jessen(a)enidan.com> Partner organization: openSUSE.org Description: I was doing a new install, but wanted to keep my /home filesystem (JFS). No problem, except that the filesystem wasn't clean and needed an fsck. As far as I can tell, yast didn't do this, so mounting of the /home filesystem failed, which caused the entirely installation process to abend and start over. Discussion: #1: Stefan Hundhammer <sh(a)novell.com> (2008-02-21 06:26:43) I'd really hate to have my 100+ GB ext3 partitions fscked. That takes forever. #2: Per Jessen <per.jessen(a)enidan.com> (2008-02-21 07:15:33) Even when they're clean? It's done on every bootup anyway. See /etc/init.d/boot.localfs #3: Jozef Uhliarik <juhliarik(a)novell.com> (2008-02-21 08:21:41) What is your opinion Thomas? #4: Thomas Fehr <fehr(a)novell.com> (2008-02-21 08:24:13) That would need an feature request, not a bug report. #6: Stephan Kulow <coolo(a)novell.com> (2008-02-21 12:04:27) I think it's not too uncommon that people reinstall their system _because_ the old one had a problem, so dirty file systems may not be too uncommon. #7: Thomas Fehr <fehr(a)novell.com> (2008-02-25 03:00:03) What the customer described happens on JFS, this is an unsupported filesystem exactly for the reason that it behaves quite fundamentally different to most other filesystems. Filesystems like ext3 or reiser simply do their log reply when they are dirty and all is fine. So if you want such things to be added, please specify it as a feature request. Since there needs to be an interactive user interface to the filesystem check program this is in no way a simple change. Or would you prefer for example do a rebuild of reiserfs internal tree as default without asking the user first? Problem is that the questions the filesystem check tools ask the user are quite special and of course totally different for different filesystem types. #8: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-07-17 08:13:00) I happen to suffer from this bug too once. I think the bug is not that the installation cleans the disk, but at least say that is not clean instead of crashing (in my case it was an installation where yast thought the disk was mounted but it was not) #9: Arvin Schnell <aschnell(a)novell.com> (2008-07-17 08:22:23) No time for 11.1. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305099

1 9

[openFate 305112] Add webcam configuration module for yast
by fate_noreply＠suse.de 19 Oct '12

19 Oct '12

Feature added by: Michael Loeffler <michl(a)novell.com> Feature #305112, revision 1, last change by Title: Add webcam configuration module for yast openSUSE-11.1: New Priority Requester: Desirable Requested by: Michael Loeffler <michl(a)novell.com> Partner organization: openSUSE.org Description: Webcam is configured automatically. But for users having trouble with configuration a webcam configuration module would be useful. See also bug #359729 Business case (Partner benefit): openSUSE.org: Users in trouble with webcam configuration need a webcam configuration possibility in YaST. As the usage of webcams is rising, eg. through instant messanger this feature request adresses more and more users -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305112

1 25

[openFate 305075] Allow to set the owner of a partition
by fate_noreply＠suse.de 16 Mar '11

16 Mar '11

Feature added by: Arvin Schnell (aschnell(a)novell.com) Feature #305075, revision 1 Title: Allow to set the owner of a partition openSUSE-11.1: New Priority Requester: Desirable Requested by: Sven Burmeister (sven.burmeister(a)gmx.net) Partner organization: openSUSE.org Description: If a user buys a new external harddrive and partitions it via YaST he will not be able to write on it, since the filesystem is owned by root. A normal user would need to know about how to use konsole and which command to use in order to change the owner. It would be a lot easier, if the user could change the owner within the partitioning module. Of course this should not be possible for system-partitions such as / and /usr etc, yet /windows and /media, as well as /home/xyz/ should be fine. Discussion: #1: Arvin Schnell(aschnell(a)novell.com) (2008-07-15 08:32:00) Do you want to set gui and uid in /etc/fstab? #2: Sven Burmeister(sven.burmeister(a)gmx.net) (2008-07-15 08:56:26) I'm not sure which is the best approach. Either the user could do something that replaces "chown user:group ." on the new partition or some predefined gui/uid to select from, because the normal user has no idea about those and the numbers that go with them. The goal is that a user that knows the root password can not only partition a new harddrive via GUI but also make it accessible (rw) to users without having to know anything about fstab-syntax and options. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305075

1 17

[openFate 305081] openSUSE Testfeature
by fate_noreply＠suse.de 11 Dec '10

11 Dec '10

Feature added by: Christopher Hofmann (cwh(a)novell.com) Feature #305081, revision 1 Title: openSUSE Testfeature openSUSE-11.1: New Priority Requester: Neutral Requested by: Christopher Hofmann (cwh(a)novell.com) Partner organization: openSUSE.org Description: Feel free to play aroud with this feature. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305081

1 34

[openFate 305104] Provide possibility to configure WEP/WPA/WPA2/... at installation
by fate_noreply＠suse.de 09 Mar '10

09 Mar '10

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305104, revision 1, last change by Title: Provide possibility to configure WEP/WPA/WPA2/... at installation openSUSE-11.1: New Priority Requester: Desirable Requested by: Jim Creech <jacreech(a)suddenlink.net> Partner organization: openSUSE.org Description: It is possible to configure a network in the first stage installation but it is only possible to select DHCP or Static + configure proxy. It is impossible to configure a secure wireless connection. See also: Bug 293609 (https://bugzilla.novell.com/show_bug.cgi?id=293609) - No provision for entering WEP at installation -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305104

1 9

[openFate 305077] Improve support for macbook/pro
by fate_noreply＠suse.de 10 Sep '08

10 Sep '08

Feature added by: Michael Loeffler (michl(a)novell.com) Feature #305077, revision 1 Title: Improve support for macbook/pro openSUSE-11.1: Evaluation Priority Requester: Desirable Requested by: Michael Loeffler (michl(a)novell.com) Partner organization: openSUSE.org Description: The recent ubuntu 7.10 release had really really good macbook pro support. Since it is doable, it would be great to have better support in opensuse 11.0 for the macbook/pro. ie, mouse (trackpad), keyboard, wireless, bluetooth, sound, etc. http://en.opensuse.org/MacBook_Pro_Specials http://en.opensuse.org/Installation_on_MacBook_Pro_Intel_(x86) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305077

1 2

[openFate 303520] Default NTP Setup
by fate_noreply＠suse.de 31 Jul '08

31 Jul '08

Feature changed by: Stephan Kulow <coolo(a)novell.com> Feature #303520, revision 16 Title: Default NTP Setup openSUSE-11.1: Candidate Priority Requester: Mandatory Projectmanager: Mandatory SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Mandatory SLES-11: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Federico Lucifredi <flucifredi(a)novell.com> Partner organization: openSUSE.org Description: A Yast pane should prompt for NTP set up, which should be configured by default, but of course can also be disabled there. Documentation Impact: Installation guide needs to be updated. Discussion: #1: Stanislav Visnovsky <visnov(a)novell.com> (2008-06-17 12:56:47) Federico, NTP setup is already possible. Do you want it in a more prominent place? Also I see a missing way for the product to pre-define the value, correct? #2: Federico Lucifredi <flucifredi(a)novell.com> (2008-06-23 21:03:12) (reply to #1) right. I want to see it pre-enabled by default againt a dedicated suse. pool.ntp.org / time.novell.com server (separate feature for that). We are lagging a bit behind Win and Mac where the vendos provide their own time source, and we need to catch up there. #3: Jiri Srain <jsrain(a)novell.com> (2008-07-07 12:18:32) We will need not only to enable NTP during installation, but display this information in the installation proposal (and possibly time zone dialog) as well. + #4: Stephan Kulow <coolo(a)novell.com> (2008-07-31 16:15:46) + for openSUSE it's 0.opensuse.pool.ntp.org 1.opensuse.pool.ntp.org 2. + opensuse.pool.ntp.org 3.opensuse.pool.ntp.org, for SLE there is no NTP + server. time.novell.com can not be used, IS&T does not provide that + level of service. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303520

1 0

[openFate 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 29 Jul '08

29 Jul '08

Feature changed by: Juergen Weigert <jw(a)novell.com> Feature #302921, revision 22 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger <aj(a)novell.com> Partner organization: openSUSE.org Description: Just a test - should go to opensuse-features(a)opensuse.org Discussion: #1: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:46:33) wswdds #11: Michael Loeffler <michl(a)novell.com> (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang <hvogel(a)novell.com> (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer <gp(a)novell.com> (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. + #19: Juergen Weigert <jw(a)novell.com> (2008-07-29 21:53:03) + ping-pong. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302921

1 0

[openFate 304937] Wireless dynamic WEP connection with 802.1x authentication in Yast/sysconfig
by fate_noreply＠suse.de 29 Jul '08

29 Jul '08

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #304937, revision 5 Title: Wireless dynamic WEP connection with 802.1x authentication in Yast/sysconfig - openSUSE-11.1: Evaluation + openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> + reject date: 2008-07-29 15:43:08 + reject reason: This cannot be done in time for openSUSE 11.1. Priority Requester: Important + openSUSE-11.2: New + Priority + Requester: Important Requested by: Helmut Schaa <hschaa(a)novell.com> + Partner organization: openSUSE.org Description: Yast/sysconfig does already support WPA-EAP wireless connections but is missing support for dynamic WEP connections using 802.1x authentication. wpa_supplicant is able to start such a connection with a network block which uses key_mgmt=IEEE8021X instead of key_mgmt=WPA- EAP. Example: network={ ssid=xxx key_mgmt=IEEE8021X eap=TTLS identity=xxx password=xxx ... } Based on bug #380671 comment #16 and #19. Discussion: #2: Helmut Schaa <hschaa(a)novell.com> (2008-07-09 13:34:35) (reply to #1) This request is about dynamic WEP, not static WEP keys (which is already supported). The 802.1x authentication is used to derive dynamic WEP keys repeatedly. It is much more secure then plain static WEP (although not as secure as WPA of course) and still widely used. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304937

1 0

[openFate 303700] Ability to log all configuration changes done via YaST
by fate_noreply＠suse.de 29 Jul '08

29 Jul '08

Feature changed by: Federico Lucifredi <flucifredi(a)novell.com> Feature #303700, revision 13 Title: Ability to log all configuration changes done via YaST openSUSE-11.1: Candidate Priority Requester: Mandatory Projectmanager: Mandatory SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Mandatory SLES-11: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Matthias Eckermann <mge(a)novell.com> Partner organization: openSUSE.org Description: Provide the ability to log all configuration changes done via YaST. Additionally, in this mode an admin would be prompted to document what was the nature/purpose of the change as the module is being closed, akin to commit messages in a versioning system. Documentation Impact: The new log file needs to be documentated in admin guide. Discussion: #1: Federico Lucifredi <flucifredi(a)novell.com> (2008-04-30 15:27:04) note fate 303688 related: packaging CFT. I am not sure CFT is the right way to provide this functionality, but a consideration is that an admin using CFT will probably log both manual-editing and YaST-driven conf changes via the same tool. #2: Stanislav Visnovsky <visnov(a)novell.com> (2008-06-03 12:40:41) Duncan, Jiri, this might be an architectural change, please, look into this. Also, we might need to define scope of which changes we are able to track. #3: Jiri Srain <jsrain(a)novell.com> (2008-07-07 10:45:35) Martin, please, have a look at possibilities to record all changes and suggest an infrastructure. Federico, we will hardly be able to make all modules record all the changes they do. Could you, please, give us some priorities for SLE11? + #6: Federico Lucifredi <flucifredi(a)novell.com> (2008-07-28 19:58:20) + (reply to #3) + Sure: network, users+groups would be a start. #4: Martin Vidner <mvidner(a)novell.com> (2008-07-08 11:44:54) This looks like a superset of feature 100386. Note that that one was downgraded because it is large (it requires touching all YaST modules). #5: Stanislav Visnovsky <visnov(a)novell.com> (2008-07-08 12:08:56) (reply to #4) Please, look into enabling of the stuff, not covering all YaST modules. + #7: Federico Lucifredi <flucifredi(a)novell.com> (2008-07-28 19:59:34) + (reply to #5) + Indeed. Look at this architecturally. Also please keep in mind that the + maintainer of CFT will help in getting that too to work on SLE + (eventually, not for 11 GA timeframe), so please keep in mind these + logs could feed into CFT eventually (and we would not want to change + too much to make that happen :-) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303700

1 0

[openFate 305131] connecting an unpartitioned disk should bring up a partitioner
by fate_noreply＠suse.de 28 Jul '08

28 Jul '08

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #305131, revision 3 Title: connecting an unpartitioned disk should bring up a partitioner - openSUSE-11.1: New + openSUSE-11.1: Evaluation Priority Requester: Desirable Requested by: Juergen Weigert <jw(a)novell.com> + Partner organization: openSUSE.org Description: USB or Firewire disks can be easily connected at runtime. For a newly bought disk, nothing happens, when it is connected for the first time. Unlike e.g. a USB-Memory-stick, which immediatly opens a filebrowser, when first connected. The technical difference is, disks come unformatted, USB-sticks come formatted. We should recognize this difference and pop up an easy to use partitioner. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305131

1 0

[openFate 303730] Add "command not found" handling to the shell
by fate_noreply＠suse.de 28 Jul '08

28 Jul '08

Feature changed by: Dr. Werner Fink <werner(a)novell.com> Feature #303730, revision 11 Title: Add "command not found" handling to the shell openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Important SLED-11: Done Priority Requester: Mandatory Projectmanager: Important SLES-11: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Federico Lucifredi <flucifredi(a)novell.com> Partner organization: openSUSE.org Description: Ubuntu has a very friendly message when one types the name of an executable coming from a package not installed: "the program fulano can be found in the following packages: * foo * bar * baz try: apt-get install <package>" now that we will have the pool channels online, we can leverage them, and make things friendlier for entry-level users. Discussion: #1: Federico Lucifredi <flucifredi(a)novell.com> (2008-04-25 15:17:08) this was implemented as part of hack-week: http://urtax.ms.mff.cuni.cz/~stick/stick/projects/command-not-found/ #2: Thorsten Kukuk <kukuk(a)novell.com> (2008-06-30 15:16:58) Sounds usefull to me (but I have to admit more for SLED and openSUSE) and it does not lok like as if it would make scripts, especially login/start scripts, slower. #3: Hendrik Vogelsang <hvogel(a)novell.com> (2008-07-11 15:06:24) We will add support for the package into bash. We will not maintain the scout package. That will be done by Vladimir. #4: Pavol Rusnak <prusnak(a)novell.com> (2008-07-23 16:40:56) Scout is maintained in openSUSE BuildService - home:prusnak:scout project http://download.opensuse.org/repositories/home:/prusnak:/scout/ #5: Dr. Werner Fink <werner(a)novell.com> (2008-07-24 16:49:23) I've added the patch for scout support #6: Pavol Rusnak <prusnak(a)novell.com> (2008-07-25 23:36:23) Werner: could you also add Provides: bash(CommandNotFound) or something similar? So packages could require bash with this feature enabled + #7: Dr. Werner Fink <werner(a)novell.com> (2008-07-28 12:12:31) (reply to + #6) + Why should I do this? There is only *one* bash and this includes now this + feature. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303730

1 0

[openFate 303730] Add "command not found" handling to the shell
by fate_noreply＠suse.de 25 Jul '08

25 Jul '08

Feature changed by: Pavol Rusnak <prusnak(a)novell.com> Feature #303730, revision 10 Title: Add "command not found" handling to the shell openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Important SLED-11: Done Priority Requester: Mandatory Projectmanager: Important SLES-11: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Federico Lucifredi <flucifredi(a)novell.com> Partner organization: openSUSE.org Description: Ubuntu has a very friendly message when one types the name of an executable coming from a package not installed: "the program fulano can be found in the following packages: * foo * bar * baz try: apt-get install <package>" now that we will have the pool channels online, we can leverage them, and make things friendlier for entry-level users. Discussion: #1: Federico Lucifredi <flucifredi(a)novell.com> (2008-04-25 15:17:08) this was implemented as part of hack-week: http://urtax.ms.mff.cuni.cz/~stick/stick/projects/command-not-found/ #2: Thorsten Kukuk <kukuk(a)novell.com> (2008-06-30 15:16:58) Sounds usefull to me (but I have to admit more for SLED and openSUSE) and it does not lok like as if it would make scripts, especially login/start scripts, slower. #3: Hendrik Vogelsang <hvogel(a)novell.com> (2008-07-11 15:06:24) We will add support for the package into bash. We will not maintain the scout package. That will be done by Vladimir. #4: Pavol Rusnak <prusnak(a)novell.com> (2008-07-23 16:40:56) Scout is maintained in openSUSE BuildService - home:prusnak:scout project http://download.opensuse.org/repositories/home:/prusnak:/scout/ #5: Dr. Werner Fink <werner(a)novell.com> (2008-07-24 16:49:23) I've added the patch for scout support + #6: Pavol Rusnak <prusnak(a)novell.com> (2008-07-25 23:36:23) + Werner: could you also add Provides: bash(CommandNotFound) or something + similar? So packages could require bash with this feature enabled -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303730

1 0

[openFate 303730] Add "command not found" handling to the shell
by fate_noreply＠suse.de 24 Jul '08

24 Jul '08

Feature changed by: Dr. Werner Fink <werner(a)novell.com> Feature #303730, revision 9 Title: Add "command not found" handling to the shell - openSUSE-11.1: Candidate + openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Important - SLED-11: Candidate + SLED-11: Done Priority Requester: Mandatory Projectmanager: Important - SLES-11: Candidate + SLES-11: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Federico Lucifredi <flucifredi(a)novell.com> Partner organization: openSUSE.org Description: Ubuntu has a very friendly message when one types the name of an executable coming from a package not installed: "the program fulano can be found in the following packages: * foo * bar * baz try: apt-get install <package>" now that we will have the pool channels online, we can leverage them, and make things friendlier for entry-level users. Discussion: #1: Federico Lucifredi <flucifredi(a)novell.com> (2008-04-25 15:17:08) this was implemented as part of hack-week: http://urtax.ms.mff.cuni.cz/~stick/stick/projects/command-not-found/ #2: Thorsten Kukuk <kukuk(a)novell.com> (2008-06-30 15:16:58) Sounds usefull to me (but I have to admit more for SLED and openSUSE) and it does not lok like as if it would make scripts, especially login/start scripts, slower. #3: Hendrik Vogelsang <hvogel(a)novell.com> (2008-07-11 15:06:24) We will add support for the package into bash. We will not maintain the scout package. That will be done by Vladimir. #4: Pavol Rusnak <prusnak(a)novell.com> (2008-07-23 16:40:56) Scout is maintained in openSUSE BuildService - home:prusnak:scout project http://download.opensuse.org/repositories/home:/prusnak:/scout/ #5: Dr. Werner Fink <werner(a)novell.com> (2008-07-24 16:49:23) I've added the patch for scout support -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303730

1 0

[openFate 303730] Add "command not found" handling to the shell
by fate_noreply＠suse.de 24 Jul '08

24 Jul '08

Feature changed by: Dr. Werner Fink <werner(a)novell.com> Feature #303730, revision 8 Title: Add "command not found" handling to the shell openSUSE-11.1: Candidate Priority Requester: Mandatory Projectmanager: Important SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Important SLES-11: Candidate Priority Requester: Mandatory Projectmanager: Important Requested by: Federico Lucifredi <flucifredi(a)novell.com> Partner organization: openSUSE.org Description: Ubuntu has a very friendly message when one types the name of an executable coming from a package not installed: "the program fulano can be found in the following packages: * foo * bar * baz try: apt-get install <package>" now that we will have the pool channels online, we can leverage them, and make things friendlier for entry-level users. Discussion: #1: Federico Lucifredi <flucifredi(a)novell.com> (2008-04-25 15:17:08) this was implemented as part of hack-week: http://urtax.ms.mff.cuni.cz/~stick/stick/projects/command-not-found/ #2: Thorsten Kukuk <kukuk(a)novell.com> (2008-06-30 15:16:58) Sounds usefull to me (but I have to admit more for SLED and openSUSE) and it does not lok like as if it would make scripts, especially login/start scripts, slower. #3: Hendrik Vogelsang <hvogel(a)novell.com> (2008-07-11 15:06:24) We will add support for the package into bash. We will not maintain the scout package. That will be done by Vladimir. #4: Pavol Rusnak <prusnak(a)novell.com> (2008-07-23 16:40:56) Scout is maintained in openSUSE BuildService - home:prusnak:scout project http://download.opensuse.org/repositories/home:/prusnak:/scout/ + #5: Dr. Werner Fink <werner(a)novell.com> (2008-07-24 16:49:23) + I've added the patch for scout support -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303730

1 0

[openFate 303730] Add "command not found" handling to the shell
by fate_noreply＠suse.de 23 Jul '08

23 Jul '08

Feature changed by: Pavol Rusnak <prusnak(a)novell.com> Feature #303730, revision 7 Title: Add "command not found" handling to the shell openSUSE-11.1: Candidate Priority Requester: Mandatory Projectmanager: Important SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Important SLES-11: Candidate Priority Requester: Mandatory Projectmanager: Important Requested by: Federico Lucifredi <flucifredi(a)novell.com> Partner organization: openSUSE.org Description: Ubuntu has a very friendly message when one types the name of an executable coming from a package not installed: "the program fulano can be found in the following packages: * foo * bar * baz try: apt-get install <package>" now that we will have the pool channels online, we can leverage them, and make things friendlier for entry-level users. Discussion: #1: Federico Lucifredi <flucifredi(a)novell.com> (2008-04-25 15:17:08) this was implemented as part of hack-week: http://urtax.ms.mff.cuni.cz/~stick/stick/projects/command-not-found/ #2: Thorsten Kukuk <kukuk(a)novell.com> (2008-06-30 15:16:58) Sounds usefull to me (but I have to admit more for SLED and openSUSE) and it does not lok like as if it would make scripts, especially login/start scripts, slower. #3: Hendrik Vogelsang <hvogel(a)novell.com> (2008-07-11 15:06:24) We will add support for the package into bash. We will not maintain the scout package. That will be done by Vladimir. + #4: Pavol Rusnak <prusnak(a)novell.com> (2008-07-23 16:40:56) + Scout is maintained in openSUSE BuildService - home:prusnak:scout + project + http://download.opensuse.org/repositories/home:/prusnak:/scout/ -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303730

1 0

[openFate 303730] Add "command not found" handling to the shell
by fate_noreply＠suse.de 23 Jul '08

23 Jul '08

Feature changed by: Stephan Binner <stbinner(a)novell.com> Feature #303730, revision 6 Title: Add "command not found" handling to the shell openSUSE-11.1: Candidate Priority Requester: Mandatory Projectmanager: Important SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Important SLES-11: Candidate Priority Requester: Mandatory Projectmanager: Important Requested by: Federico Lucifredi <flucifredi(a)novell.com> + Partner organization: openSUSE.org Description: Ubuntu has a very friendly message when one types the name of an executable coming from a package not installed: "the program fulano can be found in the following packages: * foo * bar * baz try: apt-get install <package>" now that we will have the pool channels online, we can leverage them, and make things friendlier for entry-level users. Discussion: #1: Federico Lucifredi <flucifredi(a)novell.com> (2008-04-25 15:17:08) this was implemented as part of hack-week: http://urtax.ms.mff.cuni.cz/~stick/stick/projects/command-not-found/ #2: Thorsten Kukuk <kukuk(a)novell.com> (2008-06-30 15:16:58) Sounds usefull to me (but I have to admit more for SLED and openSUSE) and it does not lok like as if it would make scripts, especially login/start scripts, slower. #3: Hendrik Vogelsang <hvogel(a)novell.com> (2008-07-11 15:06:24) We will add support for the package into bash. We will not maintain the scout package. That will be done by Vladimir. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303730

1 0

[openFate 303520] Default NTP Setup
by fate_noreply＠suse.de 22 Jul '08

22 Jul '08

Feature changed by: Matthias Eckermann <mge(a)novell.com> Feature #303520, revision 15 Title: Default NTP Setup + openSUSE-11.1: Candidate + Priority + Requester: Mandatory + Projectmanager: Mandatory SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Mandatory SLES-11: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Federico Lucifredi <flucifredi(a)novell.com> Partner organization: openSUSE.org Description: A Yast pane should prompt for NTP set up, which should be configured by default, but of course can also be disabled there. Documentation Impact: Installation guide needs to be updated. Discussion: #1: Stanislav Visnovsky <visnov(a)novell.com> (2008-06-17 12:56:47) Federico, NTP setup is already possible. Do you want it in a more prominent place? Also I see a missing way for the product to pre-define the value, correct? #2: Federico Lucifredi <flucifredi(a)novell.com> (2008-06-23 21:03:12) (reply to #1) right. I want to see it pre-enabled by default againt a dedicated suse. pool.ntp.org / time.novell.com server (separate feature for that). We are lagging a bit behind Win and Mac where the vendos provide their own time source, and we need to catch up there. #3: Jiri Srain <jsrain(a)novell.com> (2008-07-07 12:18:32) We will need not only to enable NTP during installation, but display this information in the installation proposal (and possibly time zone dialog) as well. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303520

1 0

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

22 Jul '08

Feature changed by: Matthias Eckermann <mge(a)novell.com> Feature #302957, revision 34 Title: Combined "where am I" page openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Important + openSUSE-11.1: Done + Priority + Requester: Mandatory + Projectmanager: Important SLED-11: Done Priority Requester: Mandatory SLES-11: Done Priority Requester: Mandatory Requested by: Stephan Kulow <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: Stephan Kulow <coolo(a)novell.com> (2007-11-09 11:48:30) An additional note, feature #302955 is related (split translations out of installation system). #2: Jiri Srain <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: Stephan Kulow <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 <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: Stephan Kulow <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: Stephan Kulow <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: Stephan Kulow <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: Ciaran Farrell <cfarrell(a)novell.com> (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: Stephan Kulow <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: Michael Loeffler <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: Jiri Srain <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: Stephan Kulow <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: Lukas Ocilka <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: Jiří Suchomel <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: Stephan Kulow <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: Stephan Kulow <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: Lukas Ocilka <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: Jiří Suchomel <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: Lukas Ocilka <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: Jiří Suchomel <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: Lukas Ocilka <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: Lukas Ocilka <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... -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302957

1 0

[openFate 302988] Don't Zap by default
by fate_noreply＠suse.de 22 Jul '08

22 Jul '08

Feature changed by: Matthias Eckermann <mge(a)novell.com> Feature #302988, revision 13 Title: Don't Zap by default openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Important + openSUSE-11.1: Done + Priority + Requester: Mandatory SLED-11: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Stephan Kulow <coolo(a)novell.com> Partner organization: openSUSE.org Description: We have this long standing issue that ctrl-alt-backspace is exiting the desktop without much the user can do about it, while every **** web site asks you if you want to discard random information if you browse away. While the zap functionality is useful for some and essential for some situations, where your X server is broken _and_ the keyboard combination is not _that_ easy to trigger, shutting it off completely is not preferred. So we discussed and what seems reasonable is press once -> beep, press twice -> zap. Egbert and Luc say this can be implemented in the X server and then we can leave the option on by default. Documentation Impact: yes Discussion: #1: Stephan Kulow <coolo(a)novell.com> (2007-11-27 13:36:58) If this feature can't be implemented by let's say alpha 2 due to other constraints, I would like to change the default to not zapp for beta1. #2: Michael Loeffler <michl(a)novell.com> (2007-11-27 14:41:40) fully in agreement with coolo. Do it with few effort asap or leave it. #3: Stefan Dirsch <sndirsch(a)novell.com> (2008-01-05 13:07:34) Sounds like extortion to me. Not nice. And won't help in the end. People will complain again and we need to revert it again. #4: Luc Verhaegen <lverhaegen(a)novell.com> (2008-03-20 02:12:54) Implemented in server and input driver code. Mailing patches to sndirsch for integration into packages. The Sax (or whatever) integration needed to specify this option at install time still needs to be done (i have no clue there). Implementation details: xorg.conf: Option "ZapWarning" "True" Uses PCSpeaker for beep. Press once, beep. Press again within 2s (which is ample), terminate. Documented in xorg.conf manpage. Users will be _so_ thrilled about this cool new feature in openSuSE. #5: Stefan Dirsch <sndirsch(a)novell.com> (2008-03-20 16:21:16) sax2, which sets this option by default, xorg-x11-server and xorg-x11- driver-input has now been submitted to STABLE. ==> FIXED for STABLE/Factory *and* openSUSE 11.0 Beta1. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302988

1 0

[openFate 302924] use the raw meta-data cache to save downloads
by fate_noreply＠suse.de 22 Jul '08

22 Jul '08

Feature changed by: Matthias Eckermann <mge(a)novell.com> Feature #302924, revision 7 Title: use the raw meta-data cache to save downloads openSUSE-11.0: Done Priority Requester: Desirable Projectmanager: Mandatory + openSUSE-11.1: Done + Priority + Requester: Desirable SLED-11: Done Priority Requester: Desirable SLES-11: Done Priority Requester: Desirable Requested by: Ján Kupec <jkupec(a)novell.com> Partner organization: openSUSE.org Description: At least for http, zypp shouldn't download a file which already is (unchanged) in its meta-data cache again. This will most probably need to make the media back-end aware of the raw cache. Also, this feature can be implemented keeping the rpm file caching in mind (FATE #302159). References: https://bugzilla.novell.com/show_bug.cgi?id=307098 https://bugzilla.novell.com/show_bug.cgi?id=348050 FATE #302159 Discussion: #1: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-06 10:02:49) Crucial functionality to further improve the stack. #2: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2007-12-10 16:44:18) This can be fixed if we use Fetcher on commit and set the right cache paths. #3: Cristian Rodriguez <crrodriguez(a)novell.com> (2007-12-14 12:52:15) Critical enhacement, will make zypp lots of faster and more importantly friendly with the mirror infraestructure. #4: Ján Kupec <jkupec(a)novell.com> (2008-02-19 15:54:32) Done by Duncan using Fetcher. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302924

1 0

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

22 Jul '08

Feature changed by: Matthias Eckermann <mge(a)novell.com> Feature #302923, revision 12 Title: handle redirection to mirrors robustly openSUSE-11.0: Rejected by Stanislav Visnovsky <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.1: Rejected by Matthias Eckermann <mge(a)novell.com> + reject date: 2008-07-22 23:04:50 + reject reason: Postponing, will not be ready. + Priority + Requester: Neutral openSUSE-11.2: New Priority Requester: Neutral SLED-11: Rejected by Stanislav Visnovsky <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 Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-08 12:13:49 reject reason: Postponing, will not be ready. Priority Requester: Neutral Requested by: Ján Kupec <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: Stephan Kulow <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: Stephan Kulow <coolo(a)novell.com> (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag <freitag(a)novell.com> (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag <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? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302923

1 0

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

22 Jul '08

Feature changed by: Matthias Eckermann <mge(a)novell.com> Feature #302919, revision 10 Title: Improved argument handling for zypper openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Important + openSUSE-11.1: Done + Priority + Requester: Mandatory SLED-11: Done Priority Requester: Mandatory SLES-11: Done Priority Requester: Mandatory Requested by: Klaus Kämpf <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: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-23 11:24:48) zypper improvements. #2: Ján Kupec <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: Ján Kupec <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: Ján Kupec <jkupec(a)novell.com> (2008-04-21 13:29:15) All done in zypper 0.11.1 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302919

1 0

[openFate 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 21 Jul '08

21 Jul '08

Feature changed by: JP Rosevear (jpr(a)novell.com) Feature #302119, revision 25 Title: Load package selector and libzypp only when needed openSUSE-10.3: Rejected by <visnov(a)novell.com> reject date: 2007-08-01 16:40:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by <visnov(a)novell.com> reject date: 2008-04-28 13:42:30 reject reason: Did not make it, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Candidate Priority Requester: Desirable Projectmanager: Important Requested by: Stefan Hundhammer <sh(a)novell.com> Partner organization: openSUSE.org Description: The YaST2 UI should load the code for the package selector and libzypp only when needed. Not all applications / YaST2 modules need package selection code, yet for all of them the respective code from the YaST2 UI and libzypp is loaded. Discussion: #1: Stefan Hundhammer <sh(a)novell.com> (2007-04-13 18:13:44) In the YaST2 Qt the package management related code is now moved to a separate plugin that is loaded upon demand only if the calling YCP application actually requests a PackageSelector widget. This reduces the memory footprint from 20 MB VmRSS minimum (HelloWorld. ycp) to 18 MB minimum (PackageSelector-empty.ycp). #3: Katarina Machalkova <kmachalkova(a)novell.com> (2007-04-16 14:41: 35) Stano, do we want this for curses UI as well? If yes, than it's not 'done' ... #4: Stanislav Visnovsky <visnov(a)novell.com> (2007-04-16 14:47:02) (reply to #3) Agreed. Reopening for ncurses and possibly gtk+. #5: Jiri Srain <jsrain(a)novell.com> (2007-06-13 13:54:26) JP, both Qt and NCurses are done, but GTK is still missing. #6: Stefan Hundhammer <sh(a)novell.com> (2007-06-13 15:08:58) Looks like yast2-pkg-bindings are also loaded unconditionally. It shouldn't be too hard to do that with "lazy initialization" like UI built-ins: Postpone loading the Y2Component until it's really needed. #7: Stanislav Visnovsky <visnov(a)novell.com> (2007-06-19 15:01:54) (reply to #6) Jiri, if Pkg bindings problem is not addressed, it does not make sense to fix Gtk UI. #8: Jiri Srain <jsrain(a)novell.com> (2007-07-18 13:59:50) (reply to #7) Sorry for missing this. Martin, please, solve this for the Pkg bindings. #10: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-08 11:38:22) (reply to #9) Please, follow up on this. #11: Martin Vidner <mvidner(a)novell.com> (2008-04-10 15:23:51) yast2-perl-bindings-2.16.6 no longer links to libzypp, which means libzypp will not be loaded at the very start of yast (perl still will be loaded, but that is relatively cheap). That helps in some cases, but mostly it only delays loading of libzypp, which occurs as soon as Pkg (or Package) is imported. Now I need to make Pkg lazy. #12: Martin Vidner <mvidner(a)novell.com> (2008-04-21 15:32:09) I have it almost working, but got stopped by bug 381917 (https://bugzilla.novell.com/show_bug.cgi?id=381917) : problems with destructors of static objects + #13: JP Rosevear <jpr(a)novell.com> (2008-07-21 13:59:18) (reply to #12) + Martin, what's the status here? Will we need to do anything explicit in + packagekit to get this functionality? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302119

1 0

[openFate 303367] Better Beagle Acceptance
by fate_noreply＠suse.de 21 Jul '08

21 Jul '08

Feature changed by: JP Rosevear (jpr(a)novell.com) Feature #303367, revision 11 Title: Better Beagle Acceptance openSUSE-11.0: Rejected by Gary Ekker(gekker(a)novell.com) reject date: 2008-05-27 09:03:27 reject reason: Not done for 11.0. Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.1: Evaluation + openSUSE-11.1: Candidate Priority Requester: Mandatory Projectmanager: Important - SLED-11: Evaluation + SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Important Requested by: Andreas Jaeger (aj(a)novell.com) Partner organization: openSUSE.org Description: There have been several discussions on the public openSUSE mailing lists, e.g. http://lists.opensuse.org/opensuse-factory/2008-01/msg00157.html where people complain about resource usage or garbage from beagle. I suggest that we analyze the current situation and check where are real problems and consider solutions. One option would be to make it easier for users to not enable beagle on their systems. Note: The feature request is about getting a better acceptance by our users of our indexing technology - and therefore let's figure out what are the problems they are hitting in real life. References: https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Andreas Jaeger(aj(a)novell.com) (2008-01-20 11:12:58) See also bug 282678. #2: Andreas Jaeger(aj(a)novell.com) (2008-01-23 16:23:51) Note: powertop advises "Suggestion: Disable or remove 'beagle' from your system. Beagle is the program that indexes for easy desktop search, however it's not very efficient and costs a significant amount of battery life.". #3: JP Rosevear(jpr(a)novell.com) (2008-01-23 10:38:58) (reply to #2) Yes, this is well known and was covered extensively last year and caused by polling for battery status in some cases. 0.3.2 uses hal to detect battery status: http://www.mail-archive.com/dashboard-hackers@gnome.org/msg03464.html #4: JP Rosevear(jpr(a)novell.com) (2008-01-23 10:41:35) (reply to #3) Also part of it was a mono issue: http://www.nabble.com/Beagle-indexing-when-running-on-batteries-td13842939.… -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303367

1 0

[openFate 305080] Enable runlevel 4
by fate_noreply＠suse.de 21 Jul '08

21 Jul '08

Feature changed by: Matthias Eckermann (mge(a)novell.com) Feature #305080, revision 6 Title: Enable runlevel 4 - openSUSE-11.1: New + openSUSE-11.1: Duplicate of #303798 Priority Requester: Important - SLED-11-SP1: New + SLED-11: Duplicate of #303798 Priority Requester: Important - SLES-11-SP1: New + SLES-11: Duplicate of #303798 Priority Requester: Important Requested by: Peter Bowen (pzb(a)novell.com) Partner organization: openSUSE.org Description: Currently we do disable runlevel 4. We should update the inittab to enable runlevel 4 and update initscripts to run at 4 if they run at 3. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305080

1 0

[openFate 304928] LSB build target
by fate_noreply＠suse.de 18 Jul '08

18 Jul '08

Feature changed by: Darren Davis (ddavis(a)novell.com) Feature #304928, revision 12 Title: LSB build target Buildservice: Evaluation Priority Requester: Important Requested by: Adrian Schröter (adrian(a)novell.com) Requested by: Michael Loeffler (michl(a)novell.com) Partner organization: openSUSE.org Description: A LSB build target is requested from PM. This does mean we need * A usable base distribution, which avoids to generate binaries with non-LSB requirements. * Additional LSB validation checks packaged. We could integrate these as rpmlint checks for example. Jiri, how can we setup such a distribution, using selected packages from a SUSE distro plus lsb-build-cc as compiler ? Jiri, can you package the lsb validation checks as rpmlint packages or shall we run them in a different way ? Discussion: #1: Jiri Dluhos(jdluhos(a)novell.com) (2008-06-18 13:55:50) The task has two sides: Checking binaries for LSB compliance is relatively easy; I will investigate how the checks could be incorporated into rpmlint. Building in LSB-pure environment is a conceptually different, and significantly more complex task. We have already tried to implement a pure LSB build target for buildservice, but the straightforward strategy failed because LSB-pure environment is too restricted to build essential system binaries (like mount). The Linux Foundation uses a specially crafted host distro for their builds, which is not LSB compliant per se, and then do an additional round of checks and purifications on the built binaries. We can mimic this process. #2: Jiri Dluhos(jdluhos(a)novell.com) (2008-06-18 14:23:32) What we will need is probably the lsbappchk tool from the LSB Application Testkit (downloadable at http://www.linuxfoundation.org/en/Download (http://www.linuxfoundation.org/en/Download) ). I will look at the sources to see if we can easily build it on- site. #3: Jiri Dluhos(jdluhos(a)novell.com) (2008-06-18 15:51:49) For the record (and for the curious :-) ), the database of LSB- compliant interfaces is here: http://bzr.freestandards.org/lsb/devel/specdb (http://bzr.freestandards.org/lsb/devel/specdb) #4: Darren Davis(ddavis(a)novell.com) (2008-06-30 07:55:35) I would also be nice if after they build their LSB Compliant Application in the Build Service, that they could also do the part of submitting the results for the LSB Navigator that the ATK provides. https://www.linuxfoundation.org/dbadmin/commons/welcome.php #5: Gerald Pfeifer(gp(a)novell.com) (2008-06-30 22:53:24) Michl is out right now, so let me play Michl on TV. Important for PM, and on to Adrian. ;-) #6: Martin Mrazik(mmrazik(a)novell.com) (2008-07-01 06:08:50) (reply to #5) Maybe before evaluating this it would be better to split this fate entry into two: * Create a LSB build target * Package ATK and integrate with rpmlint + #7: Darren Davis(ddavis(a)novell.com) (2008-07-18 12:35:52) (reply to + #6) + We could keep this FATE for the build target. I have created FATE 305085 + for the ATK. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304928

1 0

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

18 Jul '08

Feature changed by: J. Daniel Schmidt (jdsn(a)novell.com) Feature #303517, revision 11 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Ladislav Slezak (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: Federico Lucifredi(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: Duncan Mac-Vicar(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: Stanislav Visnovsky(visnov(a)novell.com) (2008-07-07 12:34:19) (reply to #2) We have a concept in the automatic online update configuration. #4: Jiri Srain(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: Ladislav Slezak(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: Jiri Srain(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) + #8: J. Daniel Schmidt(jdsn(a)novell.com) (2008-07-18 18:13:38) (reply to + #6) + This would hide the feature in an update related module. But the feature + does not restrict this only to update repositories. Build-Service Repos + might need a refresh as well or think of Factory. The right place for + this feature is the Repository Manager. It has no relation to the + update process or a configuration concerning updates. #7: Jiří Suchomel(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? + #9: J. Daniel Schmidt(jdsn(a)novell.com) (2008-07-18 18:15:46) (reply to + #7) + Currently I plan to merge it into a new module together with "Online Update + Configuration" related settings. Please do not extend it with this + unrelated repo refreshing dialog. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 305080] Enable runlevel 4
by fate_noreply＠suse.de 18 Jul '08

18 Jul '08

Feature changed by: Peter Bowen (pzb(a)novell.com) Feature #305080, revision 4 Title: Enable runlevel 4 openSUSE-11.1: New Priority Requester: Important SLED-11-SP1: New Priority Requester: Important SLES-11-SP1: New Priority Requester: Important Requested by: Peter Bowen (pzb(a)novell.com) + Partner organization: openSUSE.org Description: Currently we do disable runlevel 4. We should update the inittab to enable runlevel 4 and update initscripts to run at 4 if they run at 3. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305080

1 0

[openFate 305018] Get bugowner ID from buildservice without login
by fate_noreply＠suse.de 18 Jul '08

18 Jul '08

Feature changed by: Michael Loeffler (michl(a)novell.com) Feature #305018, revision 3 Title: Get bugowner ID from buildservice without login - Buildservice: New + Buildservice: Evaluation Priority Requester: Desirable Requested by: Jan Blunck (jblunck(a)novell.com) Partner organization: openSUSE.org Description: For automatic crash reporting it is useful to get information about the buildservice project the package is coming from. If the bugowner is set by the project the report can be assigned to him. If the bugowner is not set the crash report can be skipped. I need a way to get the bugowner id or email adress without forcing the user to have a buildservice login. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305018

1 0

[openFate 303873] Reducing pop ups during installation
by fate_noreply＠suse.de 18 Jul '08

18 Jul '08

Feature changed by: Michael Loeffler (michl(a)novell.com) Feature #303873, revision 11 Title: Reducing pop ups during installation openSUSE-11.1: Rejected by Stanislav Visnovsky(visnov(a)novell.com) reject date: 2008-07-08 11:01:26 reject reason: This can wait. Postponing. Priority Requester: Important - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important SLED-11: Rejected by Stanislav Visnovsky(visnov(a)novell.com) reject date: 2008-07-08 11:01:16 reject reason: This can wait. Postponing. Priority Requester: Important SLED-11-SP1: New Priority Requester: Important SLES-11: Rejected by Stanislav Visnovsky(visnov(a)novell.com) reject date: 2008-07-08 11:01:18 reject reason: This can wait. Postponing. Priority Requester: Important SLES-11-SP1: New Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz(a)novell.com) + Partner organization: openSUSE.org Description: Before installing the system the user is asked to confirm various licenses. Each license is presented via pop up. Depending on the selected packages the user might be forced to accept quite a lot of them. This is quite unusable and we should think about how to reduce these. One idea might be: http://en.opensuse.org/Image:Installation_nopopups.png Not for SLES: Furthermore after accepting all these licenses the user has to confirm the installation in an extra pop up. I do not see the necessity for that pop up as users made the experience with other operating systems who do not ask the user for comfirmation (Apple Mac OS, MS Windows, Ubuntu, Red Hat Enterprise Linux, Fedora) that installation means that something will happen to their hard drive. Discussion: #1: Matthias Eckermann(mge(a)novell.com) (2008-05-15 12:10:27) I agree with and like: http://en.opensuse.org/Image:Installation_nopopups.png But the extra pop-up for "YES, I really want to wipe my harddisk" must remain, as it is a security and safetiness issue. Marking this part of the idea as "Not for SLES". Federico, what is your opinion here? #2: Michael Loeffler(michl(a)novell.com) (2008-05-15 12:27:44) Ciaran can you give the view from a legal perspective? #3: Ciaran Farrell(cfarrell(a)novell.com) (2008-05-16 11:51:38) I like the setup described in the screenshot and believe that it certainly gives the person installing the opportunity to review every license individually. In fact, I'm going to suggest to Patrick Mc Bride that this could be a default license acceptance method as it is far better than what we currently have available (i.e. all or nothing system). I'll ask Christopher De Nicolo for his opinion (from a german legal perspective). #4: Federico Lucifredi(flucifredi(a)novell.com) (2008-05-22 15:47:44) I just went through the 11.0 beta 3 workflow, and I am satisfied with the current state. the mock-up is ok, but consider this: while it is true that you get prompted 5 times to approve licenses, if there is something that users are trained to do, in all platforms, is precisely click accept :-) I would say we can proceed with it, but I don't consider it a major issue, and not a usability problem. by the way, the 11.0 install workflow rocks :-) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303873

1 0

[openFate 305018] Get bugowner ID from buildservice without login
by fate_noreply＠suse.de 17 Jul '08

17 Jul '08

Feature changed by: Adrian Schröter (adrian(a)novell.com) Feature #305018, revision 2 Title: Get bugowner ID from buildservice without login Buildservice: New Priority Requester: Desirable Requested by: Jan Blunck (jblunck(a)novell.com) + Partner organization: openSUSE.org Description: For automatic crash reporting it is useful to get information about the buildservice project the package is coming from. If the bugowner is set by the project the report can be assigned to him. If the bugowner is not set the crash report can be skipped. I need a way to get the bugowner id or email adress without forcing the user to have a buildservice login. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305018

1 0

[openFate 305015] support noarch via own scheduler in Build Service
by fate_noreply＠suse.de 17 Jul '08

17 Jul '08

Feature changed by: Adrian Schröter (adrian(a)novell.com) Feature #305015, revision 2 - Title: support noarch via own scheduler in internal Build Service + Title: support noarch via own scheduler in Build Service Buildservice: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Adrian Schröter (adrian(a)novell.com) Requested by: Lars Vogdt (lrupp(a)novell.com) + Partner organization: openSUSE.org Description: We would like to build noarch packages only once to avoid multiple builds and wasted space on the server. This can be reached by building noarch packages only via an dedicated scheduler. However, we need to avoid that have a horrible project configuration, where all BuildRequired noarch packages needs to get submitted into all other architecture repository :full trees. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305015

1 0

[openFate 304928] LSB build target
by fate_noreply＠suse.de 17 Jul '08

17 Jul '08

Feature changed by: Adrian Schröter (adrian(a)novell.com) Feature #304928, revision 11 Title: LSB build target Buildservice: Evaluation Priority Requester: Important Requested by: Adrian Schröter (adrian(a)novell.com) Requested by: Michael Loeffler (michl(a)novell.com) + Partner organization: openSUSE.org Description: A LSB build target is requested from PM. This does mean we need * A usable base distribution, which avoids to generate binaries with non-LSB requirements. * Additional LSB validation checks packaged. We could integrate these as rpmlint checks for example. Jiri, how can we setup such a distribution, using selected packages from a SUSE distro plus lsb-build-cc as compiler ? Jiri, can you package the lsb validation checks as rpmlint packages or shall we run them in a different way ? Discussion: #1: Jiri Dluhos(jdluhos(a)novell.com) (2008-06-18 13:55:50) The task has two sides: Checking binaries for LSB compliance is relatively easy; I will investigate how the checks could be incorporated into rpmlint. Building in LSB-pure environment is a conceptually different, and significantly more complex task. We have already tried to implement a pure LSB build target for buildservice, but the straightforward strategy failed because LSB-pure environment is too restricted to build essential system binaries (like mount). The Linux Foundation uses a specially crafted host distro for their builds, which is not LSB compliant per se, and then do an additional round of checks and purifications on the built binaries. We can mimic this process. #2: Jiri Dluhos(jdluhos(a)novell.com) (2008-06-18 14:23:32) What we will need is probably the lsbappchk tool from the LSB Application Testkit (downloadable at http://www.linuxfoundation.org/en/Download (http://www.linuxfoundation.org/en/Download) ). I will look at the sources to see if we can easily build it on- site. #3: Jiri Dluhos(jdluhos(a)novell.com) (2008-06-18 15:51:49) For the record (and for the curious :-) ), the database of LSB- compliant interfaces is here: http://bzr.freestandards.org/lsb/devel/specdb (http://bzr.freestandards.org/lsb/devel/specdb) #4: Darren Davis(ddavis(a)novell.com) (2008-06-30 07:55:35) I would also be nice if after they build their LSB Compliant Application in the Build Service, that they could also do the part of submitting the results for the LSB Navigator that the ATK provides. https://www.linuxfoundation.org/dbadmin/commons/welcome.php #5: Gerald Pfeifer(gp(a)novell.com) (2008-06-30 22:53:24) Michl is out right now, so let me play Michl on TV. Important for PM, and on to Adrian. ;-) #6: Martin Mrazik(mmrazik(a)novell.com) (2008-07-01 06:08:50) (reply to #5) Maybe before evaluating this it would be better to split this fate entry into two: * Create a LSB build target * Package ATK and integrate with rpmlint -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304928

1 0

[openFate 303559] @opensuse.org mail forward support in users.opensuse.org
by fate_noreply＠suse.de 17 Jul '08

17 Jul '08

Feature changed by: Adrian Schröter (adrian(a)novell.com) Feature #303559, revision 2 Title: @opensuse.org mail forward support in users.opensuse.org Buildservice: New Priority Requester: Mandatory Requested by: Adrian Schröter (adrian(a)novell.com) + Partner organization: openSUSE.org Description: We have the request to support the membership management of opensuse. org via users.opensuse.org. This require the following: * Admin (can be defined via hard coded list for now) can enable a "Membership Flag" for dedicated users. * Users with Membership Flag can enter an email forwarding adress. * Regular export of forwarding adresses for Boetti to support the new forwarders. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303559

1 0

[openFate 303520] Default NTP Setup
by fate_noreply＠suse.de 17 Jul '08

17 Jul '08

Feature changed by: Martin Vidner (mvidner(a)novell.com) Feature #303520, revision 14 Title: Default NTP Setup SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Mandatory SLES-11: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Federico Lucifredi (flucifredi(a)novell.com) + Partner organization: openSUSE.org Description: A Yast pane should prompt for NTP set up, which should be configured by default, but of course can also be disabled there. Documentation Impact: Installation guide needs to be updated. Discussion: #1: Stanislav Visnovsky(visnov(a)novell.com) (2008-06-17 12:56:47) Federico, NTP setup is already possible. Do you want it in a more prominent place? Also I see a missing way for the product to pre-define the value, correct? #2: Federico Lucifredi(flucifredi(a)novell.com) (2008-06-23 21:03:12) (reply to #1) right. I want to see it pre-enabled by default againt a dedicated suse. pool.ntp.org / time.novell.com server (separate feature for that). We are lagging a bit behind Win and Mac where the vendos provide their own time source, and we need to catch up there. #3: Jiri Srain(jsrain(a)novell.com) (2008-07-07 12:18:32) We will need not only to enable NTP during installation, but display this information in the installation proposal (and possibly time zone dialog) as well. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303520

1 0

[openFate 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 17 Jul '08

17 Jul '08

Feature changed by: Martin Vidner (mvidner(a)novell.com) Feature #302119, revision 24 Title: Load package selector and libzypp only when needed openSUSE-10.3: Rejected by Stanislav Visnovsky(visnov(a)novell.com) reject date: 2007-08-01 16:40:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky(visnov(a)novell.com) reject date: 2008-04-28 13:42:30 reject reason: Did not make it, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Candidate Priority Requester: Desirable Projectmanager: Important Requested by: Stefan Hundhammer (sh(a)novell.com) + Partner organization: openSUSE.org Description: The YaST2 UI should load the code for the package selector and libzypp only when needed. Not all applications / YaST2 modules need package selection code, yet for all of them the respective code from the YaST2 UI and libzypp is loaded. Discussion: #1: Stefan Hundhammer(sh(a)novell.com) (2007-04-13 18:13:44) In the YaST2 Qt the package management related code is now moved to a separate plugin that is loaded upon demand only if the calling YCP application actually requests a PackageSelector widget. This reduces the memory footprint from 20 MB VmRSS minimum (HelloWorld. ycp) to 18 MB minimum (PackageSelector-empty.ycp). #3: Katarina Machalkova(kmachalkova(a)novell.com) (2007-04-16 14:41:35) Stano, do we want this for curses UI as well? If yes, than it's not 'done' ... #4: Stanislav Visnovsky(visnov(a)novell.com) (2007-04-16 14:47:02) (reply to #3) Agreed. Reopening for ncurses and possibly gtk+. #5: Jiri Srain(jsrain(a)novell.com) (2007-06-13 13:54:26) JP, both Qt and NCurses are done, but GTK is still missing. #6: Stefan Hundhammer(sh(a)novell.com) (2007-06-13 15:08:58) Looks like yast2-pkg-bindings are also loaded unconditionally. It shouldn't be too hard to do that with "lazy initialization" like UI built-ins: Postpone loading the Y2Component until it's really needed. #7: Stanislav Visnovsky(visnov(a)novell.com) (2007-06-19 15:01:54) (reply to #6) Jiri, if Pkg bindings problem is not addressed, it does not make sense to fix Gtk UI. #8: Jiri Srain(jsrain(a)novell.com) (2007-07-18 13:59:50) (reply to #7) Sorry for missing this. Martin, please, solve this for the Pkg bindings. #10: Stanislav Visnovsky(visnov(a)novell.com) (2007-11-08 11:38:22) (reply to #9) Please, follow up on this. #11: Martin Vidner(mvidner(a)novell.com) (2008-04-10 15:23:51) yast2-perl-bindings-2.16.6 no longer links to libzypp, which means libzypp will not be loaded at the very start of yast (perl still will be loaded, but that is relatively cheap). That helps in some cases, but mostly it only delays loading of libzypp, which occurs as soon as Pkg (or Package) is imported. Now I need to make Pkg lazy. #12: Martin Vidner(mvidner(a)novell.com) (2008-04-21 15:32:09) I have it almost working, but got stopped by bug 381917 (https://bugzilla.novell.com/show_bug.cgi?id=381917) : problems with destructors of static objects -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302119

1 0

[openFate 303700] Ability to log all configuration changes done via YaST
by fate_noreply＠suse.de 17 Jul '08

17 Jul '08

Feature changed by: Martin Vidner (mvidner(a)novell.com) Feature #303700, revision 12 Title: Ability to log all configuration changes done via YaST openSUSE-11.1: Candidate Priority Requester: Mandatory Projectmanager: Mandatory SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Mandatory SLES-11: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Matthias Eckermann (mge(a)novell.com) + Partner organization: openSUSE.org Description: Provide the ability to log all configuration changes done via YaST. Additionally, in this mode an admin would be prompted to document what was the nature/purpose of the change as the module is being closed, akin to commit messages in a versioning system. Documentation Impact: The new log file needs to be documentated in admin guide. Discussion: #1: Federico Lucifredi(flucifredi(a)novell.com) (2008-04-30 15:27:04) note fate 303688 related: packaging CFT. I am not sure CFT is the right way to provide this functionality, but a consideration is that an admin using CFT will probably log both manual-editing and YaST-driven conf changes via the same tool. #2: Stanislav Visnovsky(visnov(a)novell.com) (2008-06-03 12:40:41) Duncan, Jiri, this might be an architectural change, please, look into this. Also, we might need to define scope of which changes we are able to track. #3: Jiri Srain(jsrain(a)novell.com) (2008-07-07 10:45:35) Martin, please, have a look at possibilities to record all changes and suggest an infrastructure. Federico, we will hardly be able to make all modules record all the changes they do. Could you, please, give us some priorities for SLE11? #4: Martin Vidner(mvidner(a)novell.com) (2008-07-08 11:44:54) This looks like a superset of feature 100386. Note that that one was downgraded because it is large (it requires touching all YaST modules). #5: Stanislav Visnovsky(visnov(a)novell.com) (2008-07-08 12:08:56) (reply to #4) Please, look into enabling of the stuff, not covering all YaST modules. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303700

1 0

[openFate 100386] Support a verbose logging mode in yast
by fate_noreply＠suse.de 17 Jul '08

17 Jul '08

Feature changed by: Martin Vidner (mvidner(a)novell.com) Feature #100386, revision 27 Title: Support a verbose logging mode in yast openSUSE-10.2: Rejected by Andreas Jaeger(aj(a)novell.com) reject date: 2006-09-30 20:43:33 reject reason: for 10.3. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky(visnov(a)novell.com) reject date: 2007-08-01 10:24:26 reject reason: Postponing, needs more research. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Federico Lucifredi(flucifredi(a)novell.com) reject date: 2008-06-28 19:27:16 reject reason: fixing my typo. Mandatories in the past don't work (yet). Priority Requester: Important Projectmanager: Important openSUSE-11.1: Candidate Priority Requester: Important Projectmanager: Important SL-10.0: Rejected by Andreas Jaeger(aj(a)novell.com) reject date: 2005-12-02 14:56:13 reject reason: not done. Priority Requester: Desirable SLES-11: Candidate Priority Requester: Important Projectmanager: Important Requested by: Andreas Jaeger (aj(a)novell.com) + Partner organization: openSUSE.org Description: Create a verbose logging mode in yast, where any action yast performs is logged. Any file yast touches should be logged (to /var/log/YaST2/y2log AND clean up the structure of that log file, to make it easier to read and interpret) and all changes on the systems configuration. The goal is to make it really transparent what yast does. Documentation Impact: Admin guide needs to contain information about the new log file. Discussion: #1: Edith Parzefall(emap(a)novell.com) (2006-09-28 17:17:54) Can't be done for 10.2. Back to TPMs. #2: Edith Parzefall(emap(a)novell.com) (2007-07-31 16:17:45) Sorry, couldn't be done for 10.3. We need a concept for this. Even within the team different developers have different needs. Improving the logging to give all developers the best possible debugging information will be difficult, but it's definitely something we should attempt in the near future. #3: Stanislav Visnovsky(visnov(a)novell.com) (2007-11-08 10:48:48) Can we get some traction here finally? #4: Stanislav Visnovsky(visnov(a)novell.com) (2007-11-28 10:16:38) Reopening, the YaST transparency is often cited as a problem for users. #6: Federico Lucifredi(flucifredi(a)novell.com) (2008-06-28 17:13:54) I think this has enough user benefit and is trivial enough, we should just get it done. #7: Federico Lucifredi(flucifredi(a)novell.com) (2008-06-28 19:28:04) PM-Priority for product openSUSE-11.0 downgraded from mandatory to : oops. Too many widgets for my tired brain. #8: Stanislav Visnovsky(visnov(a)novell.com) (2008-07-01 16:49:08) (reply to #7) This cannot be done completely - this is non-trivial amount of work. I suggest to start this though, having the YaST infrastructure in place ASAP. Federico, please, downgrade the priority. #9: Federico Lucifredi(flucifredi(a)novell.com) (2008-07-02 14:01:05) PM-Priority for product SLES-11 downgraded from mandatory to important: too much work for a one-off apparently. #10: Federico Lucifredi(flucifredi(a)novell.com) (2008-07-02 14:01:27) PM-Priority for product openSUSE-11.1 downgraded from mandatory to important: too much work for a one-shot. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=100386

1 0

[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

[Fate 303527] Resolve dependencies after ignoring package download failure
by fate_noreply＠suse.de 11 Jul '08

11 Jul '08

Feature changed by: jsrain Feature #303527, revision 11 Title: Resolve dependencies after ignoring package download failure - openSUSE-11.1: Evaluation + openSUSE-11.1: Candidate Priority Requester: Desirable Projectmanager: Desirable Requested by: jkupec(a)novell.com Partner organization: openSUSE.org Description: YaST and Zypper should run the solver before resuming installation if download of a package fails and the user chooses to ignore that package. Currently YaST continues withough solving which makes the ignore button useful only if the user knows how the missing package will affect the system. References: https://bugzilla.novell.com/show_bug.cgi?id=340345#c4 http://lists.opensuse.org/zypp-devel/2008-03/msg00025.html Discussion: #1: flucifredi(a)novell.com (2008-06-13 15:13:41) bit of a corner case. #2: jkupec(a)novell.com (2008-06-16 11:44:24) Well, yes. An idea to cover it easily to some extent: let's advice users to run 'zypper verify' (or the YaST equivalent) in such case, after the installation is finished. This will fix hard dependencies. #3: visnov(a)novell.com (2008-06-24 15:32:30) (reply to #2) Yes, I would just suggest to add a message with instructions for the user. + #4: jsrain(a)novell.com (2008-07-11 10:22:19) (reply to #3) + That should be pretty simple. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303527

1 0

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

11 Jul '08

Feature changed by: jsrain Feature #304395, revision 11 Title: Disabling (or handling) screensaver during installation - openSUSE-11.1: Evaluation + openSUSE-11.1: Candidate 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. -- 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 10 Jul '08

10 Jul '08

Feature changed by: jsrain Feature #303517, revision 9 Title: Configure a cronjob for refreshing repositories - openSUSE-11.1: Evaluation + 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) -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303517

1 0

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

09 Jul '08

Feature changed by: lslezak Feature #303517, revision 8 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Evaluation 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. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303517

1 0

[Fate 303708] Mascot for YaST
by fate_noreply＠suse.de 09 Jul '08

09 Jul '08

Feature changed by: visnov Feature #303708, revision 10 Title: Mascot for YaST - openSUSE-11.1: Evaluation + openSUSE-11.1: Candidate Priority Requester: Mandatory + Projectmanager: Desirable Requested by: aj(a)novell.com Partner organization: openSUSE.org Description: Every successfull product has it's own logo and mascot. We should create and market one for YaST as well, display it prominently on all YaST project pages and also in YaST, e.g. in any About screens or as easter egg. Discussion: #2: michl(a)novell.com (2008-04-24 12:46:55) I'm fine with that. I think this should come out of the inner YaST circle with some help from design people like Jakub. #3: michl(a)novell.com (2008-04-24 19:54:31) (reply to #2) And we should inlcude the community on that. Zonker might call for ideas/participation for logo creation on his blog and news.openSUSE. org #4: dmacvicar(a)novell.com (2008-04-25 12:08:16) # zypper moo \\\\\ \\\\\\\__o __\\\\\\\'/_ http://en.wikipedia.org/wiki/Hedgehog -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303708

1 0

[Fate 304911] Import all GPG keys at once before downloading the metadata from new repositories
by fate_noreply＠suse.de 09 Jul '08

09 Jul '08

Feature changed by: visnov Feature #304911, revision 5 Title: Import all GPG keys at once before downloading the metadata from new repositories - openSUSE-11.1: Evaluation + openSUSE-11.1: Rejected by visnov(a)novell.com + reject date: 2008-07-09 07:54:32 + reject reason: Cannot be done in time. Priority Requester: Desirable - SLES-11: Evaluation + openSUSE-11.2: New Priority Requester: Desirable + SLES-11: Rejected by visnov(a)novell.com + reject date: 2008-07-09 07:54:36 + reject reason: Cannot be done in time. + Priority + Requester: Desirable Requested by: lslezak(a)novell.com Partner organization: openSUSE.org Description: If e.g. 10 different repositories are added yast asks to import the GPG key for each repository so the user cannot leave the computer while the metadata are downloaded. References: https://bugzilla.novell.com/show_bug.cgi?id=399253 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=304911

1 0

[Fate 304894] Yast Product Creator - create a product based on the current system
by fate_noreply＠suse.de 08 Jul '08

08 Jul '08

Feature changed by: mge Feature #304894, revision 3 Title: Yast Product Creator - create a product based on the current system - openSUSE-11.1: New + openSUSE-11.1: Duplicate of #303047 Priority Requester: Desirable Requested by: lslezak(a)novell.com Partner organization: openSUSE.org Description: The product creator module should be able to create a product with "Restore" pattern based on the current system. It would allow to easy reinstall the system using the same packages. The current product creator creates the product from scratch. This new option would use the currently installed packages to create a new pattern with all packages to ensure that they are installed at "Restore". References: https://bugzilla.novell.com/show_bug.cgi?id=392772 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=304894

1 0

[Fate 304911] Import all GPG keys at once before downloading the metadata from new repositories
by fate_noreply＠suse.de 08 Jul '08

08 Jul '08

Feature changed by: mge Feature #304911, revision 2 Title: Import all GPG keys at once before downloading the metadata from new repositories - openSUSE-11.1: New + openSUSE-11.1: Evaluation Priority Requester: Desirable + SLES-11: Evaluation + Priority + Requester: Desirable Requested by: lslezak(a)novell.com Partner organization: openSUSE.org Description: If e.g. 10 different repositories are added yast asks to import the GPG key for each repository so the user cannot leave the computer while the metadata are downloaded. References: https://bugzilla.novell.com/show_bug.cgi?id=399253 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=304911

1 0

[Fate 303736] yast and libzypp should respect the disk space reserved for root
by fate_noreply＠suse.de 08 Jul '08

08 Jul '08

Feature changed by: visnov Feature #303736, revision 5 Title: yast and libzypp should respect the disk space reserved for root - openSUSE-11.1: Evaluation + openSUSE-11.1: Rejected by visnov(a)novell.com + reject date: 2008-07-08 12:18:47 + reject reason: Postponing. This is nice to have. Priority Requester: Desirable + openSUSE-11.2: New + Priority + Requester: Desirable Requested by: lslezak(a)novell.com Partner organization: openSUSE.org Description: If e.g. root partition has 70MB free user space and 500MB free space reserved for root user yast reports 570MB total free space. But installation of a package which is greater than 70MB fails: installing package kdelibs3-devel-doc-3.5.5-45 needs 335MB on the / filesystem Yast should display the non-root free space (70MB in this case). It seems that it is valid only for ext2/ext3 filesystems (XFS and ReiserFS seem to not support root space). Default reserved space for ext2/ext3 is 5%. References: https://bugzilla.novell.com/show_bug.cgi?id=237309 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303736

1 0

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

08 Jul '08

Feature changed by: visnov Feature #302923, revision 10 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 - SLED-11: Evaluation + openSUSE-11.2: New Priority Requester: Neutral - SLES-11: Evaluation + 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 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 303527] Resolve dependencies after ignoring package download failure
by fate_noreply＠suse.de 07 Jul '08

07 Jul '08

Feature changed by: visnov Feature #303527, revision 10 Title: Resolve dependencies after ignoring package download failure openSUSE-11.1: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: jkupec(a)novell.com Partner organization: openSUSE.org Description: YaST and Zypper should run the solver before resuming installation if download of a package fails and the user chooses to ignore that package. Currently YaST continues withough solving which makes the ignore button useful only if the user knows how the missing package will affect the system. References: https://bugzilla.novell.com/show_bug.cgi?id=340345#c4 http://lists.opensuse.org/zypp-devel/2008-03/msg00025.html Discussion: #1: flucifredi(a)novell.com (2008-06-13 15:13:41) bit of a corner case. #2: jkupec(a)novell.com (2008-06-16 11:44:24) Well, yes. An idea to cover it easily to some extent: let's advice users to run 'zypper verify' (or the YaST equivalent) in such case, after the installation is finished. This will fix hard dependencies. #3: visnov(a)novell.com (2008-06-24 15:32:30) (reply to #2) Yes, I would just suggest to add a message with instructions for the user. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303527

1 0

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

07 Jul '08

Feature changed by: jsrain Feature #303517, revision 7 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Evaluation 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. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303517

1 0

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

07 Jul '08

Feature changed by: visnov Feature #303517, revision 6 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Evaluation 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. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303517

1 0

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

07 Jul '08

Feature changed by: dmacvicar Feature #303517, revision 5 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Evaluation 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). -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303517

1 0

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

07 Jul '08

Feature changed by: visnov Feature #304395, revision 10 Title: Disabling (or handling) screensaver during installation openSUSE-11.1: Evaluation 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 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=304395

1 0

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

01 Jul '08

Feature changed by: visnov Feature #304429, revision 4 Title: Package cache handling in yast openSUSE-11.1: Evaluation Priority Requester: Important + Projectmanager: 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