May 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306460] Open Feature Filing to Non-Members
by fate_noreply＠suse.de 30 Jun '09

30 Jun '09

Feature added by: Stephan Binner (Beineri) Feature #306460, revision 1, last change by Title: Open Feature Filing to Non-Members openFATE: Unconfirmed Priority Requester: Mandatory Requested by: Stephan Binner (beineri) Description: During Community Week a regular complaint was that non-members are currently not allowed to file new entries to openFATE but can only comment/vote. -- openSUSE Feature: https://features.opensuse.org/306460

1 9

[openFate 305727] rpmbuild build should warn about possibly by mistake %excluded files
by fate_noreply＠suse.de 29 Jun '09

29 Jun '09

Feature added by: Stephan Binner (Beineri) Feature #305727, revision 1, last change by Title: rpmbuild build should warn about possibly by mistake %excluded files openSUSE-11.2: New Priority Requester: Desirable Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: If one works with %exclude macros in %files sections, esp with several sub-packages and wildcards in the %exclude statements, then it can easily happen that files installed to the RPM_BUILD_ROOT do not get packaged into a package at all. This case happens currently completely silent. rpmbuild should warn when an installed file gets only referenced by an %exclude statement but nowhere else. An option might be to make this warning a build error and to have a policy to allow installed files to be excluded from packages by well visible "rm $RPM_BUILD_ROOT/foo" calls within the .spec only. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305727

1 3

[openFATE 306102] add computer name in the automatic configuration install
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Alin M Elena (ealin) Feature #306102, revision 1, last change by Title: add computer name in the automatic configuration install openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Alin M Elena (ealin) Description: It may be very useful if the user can change the name of the computer even if is in Automatic configuration during the installation. Reason why? All other major OS let you do that. ubuntu and fedora do it too. Alin PS This issue was discussed here too https://bugzilla.novell.com/show_bug.cgi?id=478602 Unfortunately the person who closed it was not open to discussions. -- openSUSE Feature: https://features.opensuse.org/306102

1 5

[openFate 305721] Desktop should survive a dbus restart
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Vincent Untz (vuntz) Feature #305721, revision 1, last change by Title: Desktop should survive a dbus restart openSUSE-11.2: New Priority Requester: Important Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: Many applications have issues when dbus is restarted. It seems people want this to be possible, see for example https://bugzilla.novell.com/show_bug.cgi?id=439616 This is more than just a bug, and covers many packages, so I'm opening this feature to track this. On the GNOME side, the mandatory part are probably gdm and gnome-session, in order to not have the current sessions closed. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305721

1 2

[openFate 305683] Add web browser for SUSE Installation
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Vincent Steenhoute (civ75) Feature #305683, revision 1, last change by Title: Add web browser for SUSE Installation openSUSE-11.2: New Priority Requester: Desirable Requested by: Vincent Steenhoute (civ75) Interested: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: While installing SUSE with the classic installation CD/DVD, add a web browser. Somes peoples don't use LiveCD and prefer Install DVD, giving them possibility to browse internet while all the package are installed would be a must. I guess Webkit will fit nicely with the QT UI of our installation. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305683

1 14

[openFATE 306157] vserver for opensuse
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Jean-Daniel Dodin (jdd_sysop) Feature #306157, revision 1, last change by Title: vserver for opensuse openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Jean-Daniel Dodin (jdd_sysop) Description: Include vserver as vitual server in opensuse. It's a very usefull virtualization system for Linux only guest virtualization available for many distros but not yet openSUSE http://linux-vserver.org/Welcome_to_Linux-VServer.org -- openSUSE Feature: https://features.opensuse.org/306157

1 3

[openFate 305146] Use old system network configuration when updating instead of demanding a new one
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305146, revision 1, last change by Title: Use old system network configuration when updating instead of demanding a new one openSUSE-11.2: New Priority Requester: Desirable Requested by: Pacho Ramos <pacho(a)condmat1.ciencias.uniovi.es> Partner organization: openSUSE.org Description: Currently, when I try to update from opensuse 10.3 to 11.0 with DVD and I want to add network repositories, I have to configure again my network for opensuse installer even when it is already configured on my opensuse-10.3 I think that would be much better try to use network configuration from old installation and only ask user if a problem occurs Business case (Partner benefit): openSUSE.org: System update from media: Start installation / Update, select network-based repositories to be used, you will be asked to configure the network. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305146

1 5

[openFATE 306338] Package duplication check on create
by fate_noreply＠suse.de 15 Jun '09

15 Jun '09

Feature added by: Will Stephenson (wstephenson) Feature #306338, revision 1, last change by Title: Package duplication check on create Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Will Stephenson (wstephenson) Description: Have a check stage when creating a new package so that "The following 523 amarok packages already exist in the Build Service. Would you like to link one of them instead?" ... ... [ Link selected ] [ Create new ] " is shown. -- openSUSE Feature: https://features.opensuse.org/306338

1 2

[openFATE 306313] show clock and battery status in screensaver unlock window
by fate_noreply＠suse.de 14 Jun '09

14 Jun '09

Feature added by: Ludwig Nussel (lnussel) Feature #306313, revision 1, last change by Title: show clock and battery status in screensaver unlock window openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Ludwig Nussel (lnussel) Description: show the current time and battery status in the screensaver's unlock window Test Case: active the screen lock, check if the current time and battery status is displayed Use Case: When sitting in conferences with a laptop and one actually pays attention to the conference the screensaver often kicks in. Pressing a button only shows the unlock window which requires typing the password. Typing on the laptop might be considered impolite during though so it would be useful if the unlock screen would at least show the current time so you know how long the conference is going to take still. Also the remaining battery capacity would be interesting to avoid having the laptop suddenly shut down. -- openSUSE Feature: https://features.opensuse.org/306313

1 5

[openFATE 306231] provide config GUI for snd hda intel model selection
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature added by: Ludwig Nussel (lnussel) Feature #306231, revision 1, last change by Title: provide config GUI for snd hda intel model selection openSUSE-11.2: New Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Description: The intel HDA sound module is not always able to automatically detect the correct model of the sound card. This SDB page describes a long winded way to tell the module which model to use: http://en.opensuse.org/SDB:Intel-HDA_sound_problems It even requires installation of kernel-source just to get the docu file. The problem seems to be quite common on Laptops so yast should just offer a GUI option in the sound module to select the model. This probably requires a machine parsable file provided by alsa that can be read by yast. -- openSUSE Feature: https://features.opensuse.org/306231

1 6

[openFATE 306419] New version of storebackup available
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature added by: hou ghi (houghi) Feature #306419, revision 1, last change by Title: New version of storebackup available Requested by: hou ghi (houghi) Description: There is a new version of storebackup available. The version that can be downloaded is 1.19 http://software.opensuse.org/search?baseproject=openSUSE%3AFactory&p=1&q=st… (http://software.opensuse.org/search?baseproject=openSUSE%3AFactory&p=1&q=st…) One user has version 2.0 available The new version at this moment is 3.0 The current honmepages is NOT on sourceforge anymore. The user has moved his page to http://savannah.nongnu.org/projects/storebackup The direct link to the download page is http://www.very-clever.com/download/nongnu/storebackup/ (http://www.very-clever.com/download/nongnu/storebackup/) There also is a large PDF file available The reason the new version is much better is because there has been a huge increase in speed of backing up over e.g. NFS or rsync. Sometimes 10 times faster from the second backup on. Also it is unwise to have old software in the repo if newer is available. houghi -- openSUSE Feature: https://features.opensuse.org/306419

1 3

[openFATE 306459] Use speedboot on 11.2 or 11.3
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature added by: andrea florio (anubisg1) Feature #306459, revision 1, last change by Title: Use speedboot on 11.2 or 11.3 openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: andrea florio (anubisg1) Description: Mandriva is currently using Speedboot to allow the enduser the machine is booting faster: http://www.phoronix.com/scan.php?page=article&item=mandriva_speedboot&num=1 i think we could use it too, on my aspire one for example the machine boot in about 16 seconds (pretty fast eh?) fro grub lo SHELL or XDM login, the desktop manager take almost same time, about 15 seconds.. lots of time compared to boot time, infact if i use autologin before be able to use the pc i have to wait about 32seconds because, evenif earlyxdm is enable, xdm service itself is the last service before reaching init 5 -- openSUSE Feature: https://features.opensuse.org/306459

1 2

[openFATE 305846] Add the us_int (us international with euro sign keyboard)
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature added by: Joop Boonen (worldcitizen) Feature #305846, revision 1, last change by Title: Add the us_int (us international with euro sign keyboard) openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Joop Boonen (worldcitizen) Description: Add the us_int (us international with euro sign on "5" key keyboard) in the choices in the installation process (when the keyboard can be chosen). This way it'll be easier to choose this lay-out. -- openSUSE Feature: https://features.opensuse.org/305846

1 9

[openFate 305735] Correctly detect keyboard model on laptops
by fate_noreply＠suse.de 08 Jun '09

08 Jun '09

Feature added by: Vincent Untz (vuntz) Feature #305735, revision 1, last change by Title: Correctly detect keyboard model on laptops openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: The default configuration of X always gives you a keyboard using the microsoftpro model. However, on laptops, it'd be better to actually use the model of this laptop -- it's certainly possible to have a script to detect this. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305735

1 5

[openFATE 306428] Reduction and management of the proxy users in a OES deployment
by fate_noreply＠suse.de 08 Jun '09

08 Jun '09

Feature added by: Haripriya Srinivasaraghavan (sharipriya) Feature #306428, revision 1, last change by Title: Reduction and management of the proxy users in a OES deployment Requested by: Haripriya Srinivasaraghavan (sharipriya) Description: ECO for: 1) A proxy user screen at the beginning of OES installation, where the following fields would be present * A proxy user input field which is auto-populated with a proxy user from the relevant scope - this could be a name of the user if already existing, or the name of a new user to create. The name entered in this field will become the default “OES proxy user” for all the services on that server. * A proxy user password field which will be filled by the install user. * A radio button which allows the administrator to select creation of proxy users at any of various levels/scope– * one proxy user per service per server * one proxy user per server (Default) * one proxy user per partition * one proxy user per tree * For all the services using proxy user, the proxy user and password fields will be auto-populated. The services will add the required rights or policies to this proxy user. * Based on the granularity of proxy users, this utility will allow the administrator to reset the proxy user passwords of the proxy user for all the services on a given OES box. 2) A utility to change all the proxy user passwords with one command. -- openSUSE Feature: https://features.opensuse.org/306428

1 7

[openFATE 306197] Ship multiple automake versions.
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature added by: Luis Medinas (lmedinas) Feature #306197, revision 1, last change by Title: Ship multiple automake versions. openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Luis Medinas (lmedinas) Description: In order to build gnome from svn (probably other projects need it too) we need automake-1.4 1.7 1.8 and 1.9. It would be good if we deliver an option to work with update-alternatives to choose the automake version. This should really be integrated in the base system. This is a goal for 11.2 from the GNOME team, having gnome svn build without building from source this dependencies. Usually this tools are used by Gnome developers. -- openSUSE Feature: https://features.opensuse.org/306197

1 4

[openFate 305681] yast2 remote and vnc server
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature added by: andrea florio (anubisg1) Feature #305681, revision 1, last change by Title: yast2 remote and vnc server openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: andrea florio (anubisg1) Partner organization: openSUSE.org Description: the remote yast module should start a vnc (and/or rdp) server too.. right now it simply open firewall ports, that means it is un-usefull like that... because it not allow you to control remotly the pc -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305681

1 4

[openFATE 305808] 1-click install without permanent subscription to repo
by fate_noreply＠suse.de 03 Jun '09

03 Jun '09

Feature added by: Johan Kotze (gogga) Feature #305808, revision 1, last change by Title: 1-click install without permanent subscription to repo openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Johan Kotze (gogga) Description: I would like to have the option of using 1-click install, but not be permanently subscribed to the repositories. Example. I am interested in qcad. It is in the education repository and it is the only package in that repository that I am interested in. I use 1-click install, but now my system is updated to be permanently subscribed to the education repo. This adds to the startup time of zypper and all other package management tools. This could be quite easily implemented by just disabling the repo once the install has finished or just remembering which repo's were added during the 1-click install and just remove them again. -- openSUSE Feature: https://features.opensuse.org/305808

1 6

[openFATE 302963] Rating support for FATE
by fate_noreply＠suse.de 30 May '09

30 May '09

Feature changed by: Rajko Matovic (rajko_m) Feature #302963, revision 26 Title: Rating support for FATE openFATE: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: FATE is becoming a huge database of useless information. Most of this come to the fact that there is only syntantic checking but not social checking. Usecase: Searching and navigating produces lot of: * Duplicate features * Incomplete features (no use cases, examples) * Vague features (a.k.a "#xxxxx YaST should be improved" ) * copy and paste features Features should support rating in the slashdot way (Insightful, Interesting, Informative, Troll, Funny) and rating from 1 to 5. The rating could be used so the same people using FATE could score down low- quality features than only make the process of information flow more difficult. Score threshold could be set by people so only high quality, well specified features are shown. It is important that searching could be done using this ratings. It should be possible to generate rankings over this ratings. Current status FATE does not offer anything to filter low quality features User Experience Query dialog would gain an option for searching. Feature editor would gain a rating dialog where different people would express their rating. Search would be over an average or agregation of this scores. Scores should be saved per rater. Contingency Plan No contingency plan at the software level. At the process level, add comments to every feature lacking business case, detailed description, real benefits, and more important, scope. Documentation Impact: Only needs to be mentioned in the handbook. Test Case: * rate a feature in one or two dimensions (score and category) * search for features >= or <= certain rating Business case (Partner benefit): openSUSE.org: Threshold for feature processing should save thousands of dollars in wasted time doing ping pong, needinfos for features with incomplete information. Even engineering could be optimized when features with no real business case dissapear by social tagging. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-04-02 01:26:51) Sounds like an interesting idea for openSUSE. I am looking forward towards considering this for some Phase 2 or so once openFATE (or whatever the name is going to be) is up and running. #3: Stephan Binner (beineri) (2009-01-17 16:03:07) (reply to #1) openFATE is now up and running. Can this request be made public to openSUSE.org partner? #2: Gerald Pfeifer (geraldpfeifer) (2008-11-14 18:05:55) Michl, for the openFATE work. (For SLE, I expect the PMs to take on much of this.) #4: Francis Giannaros (apokryphos) (2009-01-28 16:04:18) This would be great to see. For reference, see https://blueprints.launchpad.net/ubuntu with some good ideas. Also a tag cloud like the build service has might be nice. #5: Andre Duffeck (aduffeck) (2009-01-28 16:14:23) (reply to #4) We will release a new openFATE version by the end of the week with both voting and tagging support (including a cloud ;)) #7: Francis Giannaros (apokryphos) (2009-01-30 20:29:40) (reply to #5) Awesome! #6: Thomas Schmidt (digitaltomm) (2009-01-30 15:12:39) Rating features is available now in openfate with the three options -0 +. Searching for features with or above a certain score is not yet there. Do we need to integrate the voting and search by rating stuff in the FATE client or is this just a community feature? #8: Stephan Binner (beineri) (2009-01-31 11:46:14) (reply to #6) Can you please add a voting column to the browse/query result list and allow sorting by it? Atm you seem to be only able to view the top 5 voted requests (on the dashboard). #10: Michael Löffler (michl19) (2009-02-02 11:35:31) (reply to #8) Yes, it would be useful to see the score already while brosing through the features. #9: Michael Löffler (michl19) (2009-02-02 11:34:32) (reply to #6) Voting is not necessary for the internal client. Internal features should be more driven by use case and business case. For openFate the public opinion is more important to know. But the voting score of external features should be displayed internally. #11: Klaas Freitag (kfreitag) (2009-05-06 16:41:29) (reply to #6) I think what the currently implemented rating is a kind of value for "public interest" but not so much about the quality of a feature. How I understand this featurerequest it is about how helpful, interesting and complete a feature is. I think it would be good to have this kind of rating because that helps people to learn what good features are and hopefully improves the overall quality of the FATE contents. The only downside I see is that there are too many different "ratings" and users get confused. #12: Rajko Matovic (rajko_m) (2009-05-30 14:29:43) (reply to #11) It seems somewhat elitistic and inconsisten with openFATE idea that "public interest" is not the most important quality of the requested feature. Although there is a problem with current status of voting, it is now one way street, like in polls, you vote and forget. When someone adds comment that might change public opinion, there is no way for openFate users to change their vote, and all previous votes may, or may not have meaning, depends on the nature of added comment. #13: Rajko Matovic (rajko_m) (2009-05-30 14:47:27) Adding non-interactive voting to interactive discussion about feature is not the way to collect public opinion about feature. Voting has to be interactive, whith notification (email) to each user that there is a change requiring their attention. If user has not time or interest to partcipate then his vote has to be discarded, to keep validity of the rest of the votes. Voting can be made automatic via notification email with links to "no change", "change my vote", "cancel my partcipation in voting". + #14: Rajko Matovic (rajko_m) (2009-05-30 15:01:45) (reply to #13) + Beineri, just explained me that voting is interactive - which one has + to have a bit of adventurer nature to discover. Few icons that appear + are really not self explanatory - added help button that will explain + what each of them means before you press them would be appreciated. -- openSUSE Feature: https://features.opensuse.org/302963

1 0

[openFATE 302963] Rating support for FATE
by fate_noreply＠suse.de 30 May '09

30 May '09

Feature changed by: Rajko Matovic (rajko_m) Feature #302963, revision 24 Title: Rating support for FATE openFATE: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: FATE is becoming a huge database of useless information. Most of this come to the fact that there is only syntantic checking but not social checking. Usecase: Searching and navigating produces lot of: * Duplicate features * Incomplete features (no use cases, examples) * Vague features (a.k.a "#xxxxx YaST should be improved" ) * copy and paste features Features should support rating in the slashdot way (Insightful, Interesting, Informative, Troll, Funny) and rating from 1 to 5. The rating could be used so the same people using FATE could score down low- quality features than only make the process of information flow more difficult. Score threshold could be set by people so only high quality, well specified features are shown. It is important that searching could be done using this ratings. It should be possible to generate rankings over this ratings. Current status FATE does not offer anything to filter low quality features User Experience Query dialog would gain an option for searching. Feature editor would gain a rating dialog where different people would express their rating. Search would be over an average or agregation of this scores. Scores should be saved per rater. Contingency Plan No contingency plan at the software level. At the process level, add comments to every feature lacking business case, detailed description, real benefits, and more important, scope. Documentation Impact: Only needs to be mentioned in the handbook. Test Case: * rate a feature in one or two dimensions (score and category) * search for features >= or <= certain rating Business case (Partner benefit): openSUSE.org: Threshold for feature processing should save thousands of dollars in wasted time doing ping pong, needinfos for features with incomplete information. Even engineering could be optimized when features with no real business case dissapear by social tagging. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-04-02 01:26:51) Sounds like an interesting idea for openSUSE. I am looking forward towards considering this for some Phase 2 or so once openFATE (or whatever the name is going to be) is up and running. #3: Stephan Binner (beineri) (2009-01-17 16:03:07) (reply to #1) openFATE is now up and running. Can this request be made public to openSUSE.org partner? #2: Gerald Pfeifer (geraldpfeifer) (2008-11-14 18:05:55) Michl, for the openFATE work. (For SLE, I expect the PMs to take on much of this.) #4: Francis Giannaros (apokryphos) (2009-01-28 16:04:18) This would be great to see. For reference, see https://blueprints.launchpad.net/ubuntu with some good ideas. Also a tag cloud like the build service has might be nice. #5: Andre Duffeck (aduffeck) (2009-01-28 16:14:23) (reply to #4) We will release a new openFATE version by the end of the week with both voting and tagging support (including a cloud ;)) #7: Francis Giannaros (apokryphos) (2009-01-30 20:29:40) (reply to #5) Awesome! #6: Thomas Schmidt (digitaltomm) (2009-01-30 15:12:39) Rating features is available now in openfate with the three options -0 +. Searching for features with or above a certain score is not yet there. Do we need to integrate the voting and search by rating stuff in the FATE client or is this just a community feature? #8: Stephan Binner (beineri) (2009-01-31 11:46:14) (reply to #6) Can you please add a voting column to the browse/query result list and allow sorting by it? Atm you seem to be only able to view the top 5 voted requests (on the dashboard). #10: Michael Löffler (michl19) (2009-02-02 11:35:31) (reply to #8) Yes, it would be useful to see the score already while brosing through the features. #9: Michael Löffler (michl19) (2009-02-02 11:34:32) (reply to #6) Voting is not necessary for the internal client. Internal features should be more driven by use case and business case. For openFate the public opinion is more important to know. But the voting score of external features should be displayed internally. #11: Klaas Freitag (kfreitag) (2009-05-06 16:41:29) (reply to #6) I think what the currently implemented rating is a kind of value for "public interest" but not so much about the quality of a feature. How I understand this featurerequest it is about how helpful, interesting and complete a feature is. I think it would be good to have this kind of rating because that helps people to learn what good features are and hopefully improves the overall quality of the FATE contents. The only downside I see is that there are too many different "ratings" and users get confused. #12: Rajko Matovic (rajko_m) (2009-05-30 14:29:43) (reply to #11) It seems somewhat elitistic and inconsisten with openFATE idea that "public interest" is not the most important quality of the requested feature. Although there is a problem with current status of voting, it is now one way street, like in polls, you vote and forget. When someone adds comment that might change public opinion, there is no way for openFate users to change their vote, and all previous votes may, or may not have meaning, depends on the nature of added comment. + #13: Rajko Matovic (rajko_m) (2009-05-30 14:47:27) + Adding non-interactive voting to interactive discussion about feature + is not the way to collect public opinion about feature. Voting has to + be interactive, whith notification (email) to each user that there is a + change requiring their attention. If user has not time or interest to + partcipate then his vote has to be discarded, to keep validity of the + rest of the votes. Voting can be made automatic via notification email + with links to "no change", "change my vote", "cancel my partcipation in + voting". -- openSUSE Feature: https://features.opensuse.org/302963

1 0

[openFATE 302963] Rating support for FATE
by fate_noreply＠suse.de 30 May '09

30 May '09

Feature changed by: Rajko Matovic (rajko_m) Feature #302963, revision 23 Title: Rating support for FATE openFATE: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: FATE is becoming a huge database of useless information. Most of this come to the fact that there is only syntantic checking but not social checking. Usecase: Searching and navigating produces lot of: * Duplicate features * Incomplete features (no use cases, examples) * Vague features (a.k.a "#xxxxx YaST should be improved" ) * copy and paste features Features should support rating in the slashdot way (Insightful, Interesting, Informative, Troll, Funny) and rating from 1 to 5. The rating could be used so the same people using FATE could score down low- quality features than only make the process of information flow more difficult. Score threshold could be set by people so only high quality, well specified features are shown. It is important that searching could be done using this ratings. It should be possible to generate rankings over this ratings. Current status FATE does not offer anything to filter low quality features User Experience Query dialog would gain an option for searching. Feature editor would gain a rating dialog where different people would express their rating. Search would be over an average or agregation of this scores. Scores should be saved per rater. Contingency Plan No contingency plan at the software level. At the process level, add comments to every feature lacking business case, detailed description, real benefits, and more important, scope. Documentation Impact: Only needs to be mentioned in the handbook. Test Case: * rate a feature in one or two dimensions (score and category) * search for features >= or <= certain rating Business case (Partner benefit): openSUSE.org: Threshold for feature processing should save thousands of dollars in wasted time doing ping pong, needinfos for features with incomplete information. Even engineering could be optimized when features with no real business case dissapear by social tagging. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-04-02 01:26:51) Sounds like an interesting idea for openSUSE. I am looking forward towards considering this for some Phase 2 or so once openFATE (or whatever the name is going to be) is up and running. #3: Stephan Binner (beineri) (2009-01-17 16:03:07) (reply to #1) openFATE is now up and running. Can this request be made public to openSUSE.org partner? #2: Gerald Pfeifer (geraldpfeifer) (2008-11-14 18:05:55) Michl, for the openFATE work. (For SLE, I expect the PMs to take on much of this.) #4: Francis Giannaros (apokryphos) (2009-01-28 16:04:18) This would be great to see. For reference, see https://blueprints.launchpad.net/ubuntu with some good ideas. Also a tag cloud like the build service has might be nice. #5: Andre Duffeck (aduffeck) (2009-01-28 16:14:23) (reply to #4) We will release a new openFATE version by the end of the week with both voting and tagging support (including a cloud ;)) #7: Francis Giannaros (apokryphos) (2009-01-30 20:29:40) (reply to #5) Awesome! #6: Thomas Schmidt (digitaltomm) (2009-01-30 15:12:39) Rating features is available now in openfate with the three options -0 +. Searching for features with or above a certain score is not yet there. Do we need to integrate the voting and search by rating stuff in the FATE client or is this just a community feature? #8: Stephan Binner (beineri) (2009-01-31 11:46:14) (reply to #6) Can you please add a voting column to the browse/query result list and allow sorting by it? Atm you seem to be only able to view the top 5 voted requests (on the dashboard). #10: Michael Löffler (michl19) (2009-02-02 11:35:31) (reply to #8) Yes, it would be useful to see the score already while brosing through the features. #9: Michael Löffler (michl19) (2009-02-02 11:34:32) (reply to #6) Voting is not necessary for the internal client. Internal features should be more driven by use case and business case. For openFate the public opinion is more important to know. But the voting score of external features should be displayed internally. #11: Klaas Freitag (kfreitag) (2009-05-06 16:41:29) (reply to #6) I think what the currently implemented rating is a kind of value for "public interest" but not so much about the quality of a feature. How I understand this featurerequest it is about how helpful, interesting and complete a feature is. I think it would be good to have this kind of rating because that helps people to learn what good features are and hopefully improves the overall quality of the FATE contents. The only downside I see is that there are too many different "ratings" and users get confused. + #12: Rajko Matovic (rajko_m) (2009-05-30 14:29:43) (reply to #11) + It seems somewhat elitistic and inconsisten with openFATE idea that + "public interest" is not the most important quality of the requested + feature. Although there is a problem with current status of voting, it + is now one way street, like in polls, you vote and forget. When someone + adds comment that might change public opinion, there is no way for + openFate users to change their vote, and all previous votes may, or may + not have meaning, depends on the nature of added comment. -- openSUSE Feature: https://features.opensuse.org/302963

1 0

[openFATE 305885] Handle the metadata "dirty" bit when an ISW array contains the root file system
by fate_noreply＠suse.de 29 May '09

29 May '09

Feature changed by: Marc Ruehrschneck (macrue) Feature #305885, revision 8 Title: Handle the metadata "dirty" bit when an ISW array contains the root file system openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) - Partner organization: Intel + Partner organization: openSUSE.org Description: Shutdown scripts need to wait until all the MDRAID arrays are marked clean: The dirty bit dictates whether an array needs to be resynced. The OS must block writes to the array until the dirty bit is set, and it should allow for the bit to be cleared as a part of the system shutdown process. For rootfs-raid the metadata handler will need to be started in the early userspace environment as even mounting the root- filesystem read-only may cause writes to be issued due to journal recovery. This involves including mdmon in the initrd and and using the "--switch-root" option to switch the monitor to the final rootfs environment. At shutdown the OS must allow for the metadata handler to stay running across the "mark root-filesystem readonly" event, i.e. it must be excluded from the general killall events. Once all filesystems are readonly a call to "mdadm --wait-clean --scan" will quiesce all writes and clear the metadata dirty bit. Business case (Partner benefit): - Intel: Enable feature parity with the Windows IMSM stack for Linux - customers + openSUSE.org: Enable feature parity with the Windows IMSM stack for + Linux customers -- openSUSE Feature: https://features.opensuse.org/305885

1 0

[openFATE 305883] Install and boot support for MDRAID External Metadata (ISW)
by fate_noreply＠suse.de 29 May '09

29 May '09

Feature changed by: Michael Löffler (michl19) Feature #305883, revision 8 Title: Install and boot support for MDRAID External Metadata (ISW) openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) - Partner organization: Intel + Partner organization: openSUSE.org Description: Support for MDRAID External Metadata ISW for raid 0, 1, 10 and 5, 6 (??). User should have a choice between DMRAID and MDRAID or have no DMRAID support. This feature request has three aspects: 1) Detection of RAID arrays and platform capabilities Currently SLES can detect raid arrays but it does not confirm whether raid is enabled in the platform BIOS. If raid support has been disabled in the BIOS then arrays should not be presented as candidates for installation Currently "mdadm --detail-platform -e imsm" could be used for this detection as it returns true when the platform has Intel(R) Matrix Storage Manager support enabled. 2) Creating an initrd with support for assembling ISW raid arrays This has dependencies on how FR#781 is resolved (mdp versus kpartx) and needs support for handling the metadata dirty bit FR#782. At a minimum it involves adding something akin to the following commands to the initrd init script: ... mdadm -Asc mdadm.conf mount /dev/md/Volume0p1 /sysroot mdmon --switch-root /sysroot /dev/md/imsm0 ... 3) Installing the bootloader on a RAID device Fortunately the version of grub in SLES11-beta6 seems to already understand/expect partitionable md arrays as the following grub commands: root (hd0,0) setup (hd0) ...ends in a failure to access /dev/md/Volume0p1. So this may add weight to the mdp case for FR#781. Adding a link to the kpartx partition, that SLES11 currently creates, allows this to grub installation to complete successfully. However, this required hand editing of /boot/grub/device.map so the final solution will probably require a utility to dump the grub device to raid device mapping, or the restriction that the raid device must be grub device (hd0). Business case (Partner benefit): - Intel: Enable feature parity with the Windows IMSM stack for Linux - customers + openSUSE.org: Enable feature parity with the Windows IMSM stack for + Linux customers -- openSUSE Feature: https://features.opensuse.org/305883

1 0

[openFATE 305886] SGPIO support for MD
by fate_noreply＠suse.de 29 May '09

29 May '09

Feature changed by: Michael Löffler (michl19) Feature #305886, revision 11 Title: SGPIO support for MD - openSUSE-11.2: Rejected by Stephan Kulow (coolo) - reject date: 2009-05-20 13:21:33 - reject reason: out of focus for 11.2 + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) - Partner organization: Intel + Partner organization: openSUSE.org Description: md-sgpio application is a standalone application that monitors raid arrays via sysfs. Events shall trigger LED change request via a sgpio application Business case (Partner benefit): - Intel: Enable feature parity with the Windows IMSM stack for Linux - customers + openSUSE.org: Enable feature parity with the Windows IMSM stack for + Linux customers Discussion: #4: Michael Löffler (michl19) (2009-05-27 18:56:36) (reply to #3) I wonder here as well. If not in openSUSE where is the place for upstream devlopment. And I wonder if we can open up the feature to openFATE so the community can comment here as well. -- openSUSE Feature: https://features.opensuse.org/305886

1 0

[openFATE 305884] Support for creating partitions on ISW arrays
by fate_noreply＠suse.de 29 May '09

29 May '09

Feature changed by: Michael Löffler (michl19) Feature #305884, revision 10 Title: Support for creating partitions on ISW arrays - openSUSE-11.2: Rejected by Stephan Kulow (coolo) - reject date: 2009-05-20 13:19:33 - reject reason: out of focus for 11.2 + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) - Partner organization: Intel + Partner organization: openSUSE.org Description: Boot and install support for partitioned devices for MD external format (ISW) for supported raid levels (0, 1, 10, 5, 6?). Enable yast-storage to create partitions on ISW arrays. Either enable yast-storage to understand mdp devices (partitionable md devices), or use kpartx to expose the individual array partitions Business case (Partner benefit): - Intel: Enable feature parity with the Windows IMSM stack for Linux - customers + openSUSE.org: Enable feature parity with the Windows IMSM stack for + Linux customers Discussion: #3: Michael Löffler (michl19) (2009-05-27 18:57:38) (reply to #2) I wonder here as well. If not in openSUSE where is the place for upstream devlopment. And I wonder if we can open up the feature to openFATE so the community can comment here as well. -- openSUSE Feature: https://features.opensuse.org/305884

1 0

[openFATE 305584] Do not assume fixed and contiguous device numbers in installation and management tools for storage
by fate_noreply＠suse.de 29 May '09

29 May '09

Feature changed by: Tejun Heo (teheo) Feature #305584, revision 12 Title: Do not assume fixed and contiguous device numbers in installation and management tools for storage openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Matthias Eckermann (mge1512) Requested by: Tejun Heo (teheo) Description: Subject: [Research] head up on upcoming extended block devt change From: Tejun Heo <tj(a)kernel.org> Date: Thu, 18 Dec 2008 12:59:21 +0900 Reply-To: research(a)suse.de Hello, all. From soon to be released 2.6.28, the kernel contains extended block devt support, which basically allocates block device numbers dynamically from major number 259 (might expand to other major numbers if ever necessary). This means that device numbers belonging to the same device become non-contiguous and can be on different major numbers. This will remove the 15 partition limit on /dev/sdX's and increase the total number of supported SCSI disks considerably. Also, it's used by md to allow partitioning of /dev/mdX's thus removing the distinction of partitionable and non-partitionable md devices. For example, /dev/sda with 60 partitions can look like as follows. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 8 1 8001 sda1 8 2 8032 sda2 8 3 8032 sda3 8 4 1 sda4 ... 8 15 8001 sda15 259 0 8001 sda16 259 1 8001 sda17 259 2 8001 sda18 ... 259 43 8001 sda59 259 44 8001 sda60 For detailed overview, please take a look at the following message. http://article.gmane.org/gmane.linux.kernel/701825 As device node creation is completely dynamic these days, installed systems usually can cope fine with this change; however, in installation and management tools, there seem to be many places which assume fixed and contiguous device numbers. To ease hunting down those areas, a debug option is available which forces every block device to be allocated on the dynamic major non-consecutively. With the debug option turned on, the above disk will look like the following. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 259 262144 8001 sda1 259 786432 8032 sda2 259 131072 8032 sda3 259 655360 1 sda4 259 393216 8001 sda5 259 917504 8001 sda6 259 65536 8001 sda7 ... 259 114688 8001 sda55 259 638976 8001 sda56 259 376832 8001 sda57 259 901120 8001 sda58 259 245760 8001 sda59 259 770048 8001 sda60 So, the installation / management tools need to follow /sys/block/*/device/driver to determine which type of device it is and use /sys/block/*/dev to determine its device number. I'll add a kernel parameter (say, block.force_ext_devt) so that this debug option can be turned on and off during boot so that people who don't work on related subsystems don't have to suffer. I'm not sure how and when to proceed with this yet but I definitely think we'll need plenty of time to sort this out completely. Any ideas on how to proceed on this? Thanks. -- tejun Discussion: #1: Tejun Heo (teheo) (2008-12-22 13:31:11) So... when and how do we proceed with things like this? I wanna enable it in HEAD but SLES11 hasn't branched out from HEAD yet but I don't think we should wait till SLES11 is released. #2: Matthias Eckermann (mge1512) (2008-12-22 10:24:58) (reply to #1) SLE 11 has precedence over anything else we currently do - with respect to focus and time spent on it. Thus we should concentrate on SLE 11 and wait with those changes after release of SLE 11. There are more than enough P1 and P2 issues with the SLE 11 kernel to work on, ... Vojtech? #3: Vojtech Pavlik (vojtech_pavlik) (2008-12-22 12:14:19) I agree, Matthias, and I see no reason why this couldn't wait until SLES11 branches out of HEAD. #4: Tejun Heo (teheo) (2008-12-23 11:52:19) Alright, then. I'll enable it when SLES11 branches out. Thanks. + #5: Tejun Heo (teheo) (2009-05-29 16:55:23) + Added genhd.mangle_devt parameter and enabled DEBUG_BLOCK_EXT_DEVT for + all configs except for vanilla's and ppc/ps3. Ext major and mangled + minor can be enabled by specifying "genhd.mangle_devt=1" as kernel + parameter. Have fun. :-) -- openSUSE Feature: https://features.opensuse.org/305584

1 0

[openFATE 305588] kdump support for autoyast installation
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305588, revision 13 Title: kdump support for autoyast installation - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: Stefan Fent (sfent) Description: In SLES11 it is possible to add an autoyast section for kdump to the autoyast.xml file. This does not work in openSUSE11.1. Please add support for this in openSUSE as well. See bug #456707 for reference. Discussion: #2: Jozef Uhliarik (juhliarik) (2009-05-18 16:54:53) added kdump support for autoyast installation to trunk. changes only for control file in installation. the feature will be available with package yast2-installation 2.18.15. IMHO it is done #3: Jozef Uhliarik (juhliarik) (2009-05-28 17:26:47) yast2-installation 2.18.15 is submitted. The feature is done. -- openSUSE Feature: https://features.opensuse.org/305588

1 0

[openFATE 305588] kdump support for autoyast installation
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305588, revision 12 Title: kdump support for autoyast installation openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Stefan Fent (sfent) Description: In SLES11 it is possible to add an autoyast section for kdump to the autoyast.xml file. This does not work in openSUSE11.1. Please add support for this in openSUSE as well. See bug #456707 for reference. Discussion: #2: Jozef Uhliarik (juhliarik) (2009-05-18 16:54:53) added kdump support for autoyast installation to trunk. changes only for control file in installation. the feature will be available with package yast2-installation 2.18.15. IMHO it is done + #3: Jozef Uhliarik (juhliarik) (2009-05-28 17:26:47) + yast2-installation 2.18.15 is submitted. The feature is done. -- openSUSE Feature: https://features.opensuse.org/305588

1 0

[openFATE 305443] Support of Bluetooth Mouse and Keyboard on installation
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305443, revision 9 Title: Support of Bluetooth Mouse and Keyboard on installation openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-05-28 15:38:59 reject reason: Out of resources for 11.2. Priority Requester: Desirable - openSUSE-11.3: New - Priority - Requester: Desirable Requested by: Vladimir Botka (vbotka) Description: On Installation the user should be able to decide to use the bluetooth mouse/keyboard. Maybe just in the case that no other mouse/keyboard is detected. Relations: - Bluetooth mouse not detected (novell/bugzilla/id: 445583) https://bugzilla.novell.com/show_bug.cgi?id=445583 Discussion: #2: Vladimir Botka (vbotka) (2009-05-28 17:01:06)  I suggest to throw away this feature request completely. Here are the reasons. Blueooth (BT) keyboard/mouse sets are equipped with proprietary usb bluetooth dongles and works as a standard usb keyboard/mouse from the computer point of view. After the startup the usb dongle is running in the " Human interface device" (HID) mode. This behaviour enables to use the BT keyboard/mouse with BIOS only. Then, when the system is booted and the bluetooth subsystem is operational the usb dongle can be switched to to the "Host Controller Interface" (HCI) mode. Then the usb dongle operates as a BT controller and the keyboard/mouse are connected to the system as BT devices. The utility hid2hci should cover the whole transfer, but it works only for a couple of devices (which I have heard of, I have seen none). Generally I have seen either the BT keyboard/mouse is used in the HID mode with the proprietary usb dongle or the BT keyboard/mouse is used as a BT devices secondary input connected to the bt HCI controller (typically notebook). The only situation for which this feature really make sens is the BT mouse and the notebook. There is no HID mode during the installation. - + #3: Christoph Thiel (cthiel1) (2009-05-28 17:07:49) (reply to #2) + Agreed. -- openSUSE Feature: https://features.opensuse.org/305443

1 0

[openFATE 305443] Support of Bluetooth Mouse and Keyboard on installation
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Vladimir Botka (vbotka) Feature #305443, revision 8 Title: Support of Bluetooth Mouse and Keyboard on installation openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-05-28 15:38:59 reject reason: Out of resources for 11.2. Priority Requester: Desirable openSUSE-11.3: New Priority Requester: Desirable Requested by: Vladimir Botka (vbotka) Description: On Installation the user should be able to decide to use the bluetooth mouse/keyboard. Maybe just in the case that no other mouse/keyboard is detected. Relations: - Bluetooth mouse not detected (novell/bugzilla/id: 445583) https://bugzilla.novell.com/show_bug.cgi?id=445583 + Discussion: + #2: Vladimir Botka (vbotka) (2009-05-28 17:01:06) +  + I suggest to throw away this feature request completely. Here are the + reasons. + Blueooth (BT) keyboard/mouse sets are equipped with proprietary usb + bluetooth dongles and works as a standard usb keyboard/mouse from the + computer point of view. After the startup the usb dongle is running in + the " Human interface device" (HID) mode. This behaviour enables to use + the BT keyboard/mouse with BIOS only. Then, when the system is booted + and the bluetooth subsystem is operational the usb dongle can be + switched to to the "Host Controller Interface" (HCI) mode. Then the usb + dongle operates as a BT controller and the keyboard/mouse are connected + to the system as BT devices. The utility hid2hci should cover the whole + transfer, but it works only for a couple of devices (which I have heard + of, I have seen none). Generally I have seen either the BT + keyboard/mouse is used in the HID mode with the proprietary usb dongle + or the BT keyboard/mouse is used as a BT devices secondary input + connected to the bt HCI controller (typically notebook). + The only situation for which this feature really make sens is the BT + mouse and the notebook. There is no HID mode during the installation. + -- openSUSE Feature: https://features.opensuse.org/305443

1 0

[openFATE 305584] Do not assume fixed and contiguous device numbers in installation and management tools for storage
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305584, revision 11 Title: Do not assume fixed and contiguous device numbers in installation and management tools for storage openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Important Requested by: Matthias Eckermann (mge1512) Requested by: Tejun Heo (teheo) Description: Subject: [Research] head up on upcoming extended block devt change From: Tejun Heo <tj(a)kernel.org> Date: Thu, 18 Dec 2008 12:59:21 +0900 Reply-To: research(a)suse.de Hello, all. From soon to be released 2.6.28, the kernel contains extended block devt support, which basically allocates block device numbers dynamically from major number 259 (might expand to other major numbers if ever necessary). This means that device numbers belonging to the same device become non-contiguous and can be on different major numbers. This will remove the 15 partition limit on /dev/sdX's and increase the total number of supported SCSI disks considerably. Also, it's used by md to allow partitioning of /dev/mdX's thus removing the distinction of partitionable and non-partitionable md devices. For example, /dev/sda with 60 partitions can look like as follows. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 8 1 8001 sda1 8 2 8032 sda2 8 3 8032 sda3 8 4 1 sda4 ... 8 15 8001 sda15 259 0 8001 sda16 259 1 8001 sda17 259 2 8001 sda18 ... 259 43 8001 sda59 259 44 8001 sda60 For detailed overview, please take a look at the following message. http://article.gmane.org/gmane.linux.kernel/701825 As device node creation is completely dynamic these days, installed systems usually can cope fine with this change; however, in installation and management tools, there seem to be many places which assume fixed and contiguous device numbers. To ease hunting down those areas, a debug option is available which forces every block device to be allocated on the dynamic major non-consecutively. With the debug option turned on, the above disk will look like the following. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 259 262144 8001 sda1 259 786432 8032 sda2 259 131072 8032 sda3 259 655360 1 sda4 259 393216 8001 sda5 259 917504 8001 sda6 259 65536 8001 sda7 ... 259 114688 8001 sda55 259 638976 8001 sda56 259 376832 8001 sda57 259 901120 8001 sda58 259 245760 8001 sda59 259 770048 8001 sda60 So, the installation / management tools need to follow /sys/block/*/device/driver to determine which type of device it is and use /sys/block/*/dev to determine its device number. I'll add a kernel parameter (say, block.force_ext_devt) so that this debug option can be turned on and off during boot so that people who don't work on related subsystems don't have to suffer. I'm not sure how and when to proceed with this yet but I definitely think we'll need plenty of time to sort this out completely. Any ideas on how to proceed on this? Thanks. -- tejun Discussion: #1: Tejun Heo (teheo) (2008-12-22 13:31:11) So... when and how do we proceed with things like this? I wanna enable it in HEAD but SLES11 hasn't branched out from HEAD yet but I don't think we should wait till SLES11 is released. #2: Matthias Eckermann (mge1512) (2008-12-22 10:24:58) (reply to #1) SLE 11 has precedence over anything else we currently do - with respect to focus and time spent on it. Thus we should concentrate on SLE 11 and wait with those changes after release of SLE 11. There are more than enough P1 and P2 issues with the SLE 11 kernel to work on, ... Vojtech? #3: Vojtech Pavlik (vojtech_pavlik) (2008-12-22 12:14:19) I agree, Matthias, and I see no reason why this couldn't wait until SLES11 branches out of HEAD. #4: Tejun Heo (teheo) (2008-12-23 11:52:19) Alright, then. I'll enable it when SLES11 branches out. Thanks. -- openSUSE Feature: https://features.opensuse.org/305584

1 0

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305317, revision 8 Title: Default to hidden bootloader menu openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. + #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) + How should it behave with option to keep kernels from updates (libzypp + option)? What about failsafe? -- openSUSE Feature: https://features.opensuse.org/305317

1 0

[openFATE 305313] creating nonexistent directories with Autoyast
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305313, revision 10 Title: creating nonexistent directories with Autoyast openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Uwe Gansert (ug) Description: from bug #429491 It should be possible to create directories just like files with its permissions and ownership. Today it is impossible (using just "files") to put for example /root/.ssh/authorized_keys. To anticipate possible comments, the "file_script" is not IMHO the right way to deal with the problem since it is invoked after writing the file to a filesystem. Yet it may be considered a workaround as of today. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:19:55) up for Engineering's comment. Is workaround adequate ? #2: Milisav Radmanic (radmanic) (2009-04-16 14:06:01) The workaround is effective but technically not adequate. We should support creating directories like we do it for files. The request is off the mailinglist and makes sense. + #3: Stanislav Visnovsky (visnov) (2009-05-28 16:41:02) + Isn't it better to have support for untarring root.tar.gz to the + filesystem like kiwi does? -- openSUSE Feature: https://features.opensuse.org/305313

1 0

[openFATE 306327] Add DB2 Express-C
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Robert Schweikert (rjschwei) Feature #306327, revision 8 Title: Add DB2 Express-C openSUSE-11.2: New Priority Requester: Desirable Requested by: Robert Schweikert (rjschwei) Description: IBM is interested to providing an easy mechanism for users to install DB2 Express C, the free version of DB2. It would be nice if we could add DB2 Express C to the openSUSE non-oss repository. + Relations: Discussion: #3: Glenn Doig (doiggl) (2009-04-24 06:16:56) http://www-01.ibm.com/software/data/db2/express/ http://www-01.ibm.com/software/data/db2/express/download.html #4: Pascal Bleser (pbleser) (2009-05-20 22:00:05) Why not, let's go for it. If IBM wants to see openSUSE as a vehicle to drive the adoption of their products, even if not opensource, and as long as it doesn't affect the license/EULA/redistribution of the distribution itself, I don't see any reason not to support that initiative. IBM can choose to either have it in the non-OSS repository, or host it in a repository of their own, with openSUSE builds. What is involved on our side of things ? + #5: Robert Schweikert (rjschwei) (2009-05-28 09:21:00) + - IBM has a distribution agreement that needs to be signed. + In addition I think when somone installs DB2-Express C from the non-oss + repo we should pop up a box telling them about the agreement if they + intend to distribute DB2 Express with a product. No registration + required for private use. + #6: Robert Schweikert (rjschwei) (2009-05-28 09:22:04) + Added attachment Distribution agreement + (IBM_DB2_and_WAS_CE_Distribution_Form_and_Agreement_4_17_2009.pdf) -- openSUSE Feature: https://features.opensuse.org/306327

1 0

[openFate 305272] Definition in the Yast2 samba server module for "workgroup" host
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305272, revision 1, last change by Title: Definition in the Yast2 samba server module for "workgroup" host openSUSE-11.2: New Priority Requester: Desirable Requested by: Andreas van dem Helge <andrew(a)joako.net> Partner organization: openSUSE.org Description: Add a definition in the samba server module for "workgroup" host. I.E. in a SOHO it isn't always necessary to setup a true "domain" server, however if there were a set of options for things like "LMB" aka "local master browser" and a quick set of clicks to join a "Workgrp" as a client. this tutorial highlights the amount of script editing that could be avoided if the samba server were more "workgroup" friendly http://www.swerdna.net.au/linhowtolanprimer.html#samba (http://www.swerdna.net.au/linhowtolanprimer.html#samba) References: Originally reported as BNC #420766 (https://bugzilla.novell.com/show_bug.cgi?id=420766) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305272

1 3

[openFATE 305403] Bootloader beep configuration
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305403, revision 10 Title: Bootloader beep configuration openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Jiri Srain (jsrain) Description: Allow to configure whether the acoustic signal should be used for installed bootloader. Acoustic signal is valuable for visually impaired people, while it may be disturbing e.g. in libraries. Discussion: #1: Jiri Srain (jsrain) (2008-11-12 15:58:43) Default can be set depending on whether braille display was found or whether text-to-speech in isolinux was used. #2: Stefan Behlert (sbehlert) (2008-11-12 17:15:07) Is this feature meant as 'allow atuomatic setting of'? The beep is afaik already configurable to be 'off'. If not, this would be a bug. #3: Stefan Seyfried (seife) (2008-11-12 18:09:40) Please reject this feature. This is seriously overengineered. The beep now defaults to off int the installed system. If somebody wants to enable it, he can do so with gfxboot --change-config "boot::beep=1" Marco only needs to document that for his customers and everything is fine. Please, no YaST module for that. #4: Jiri Srain (jsrain) (2008-11-13 09:39:44) (reply to #3) It's not about a new module, just about a check box in the bootloader configuration. -- openSUSE Feature: https://features.opensuse.org/305403

1 0

[openFATE 305443] Support of Bluetooth Mouse and Keyboard on installation
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305443, revision 7 Title: Support of Bluetooth Mouse and Keyboard on installation - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-05-28 15:38:59 + reject reason: Out of resources for 11.2. Priority Requester: Desirable + openSUSE-11.3: New + Priority + Requester: Desirable Requested by: Vladimir Botka (vbotka) Description: On Installation the user should be able to decide to use the bluetooth mouse/keyboard. Maybe just in the case that no other mouse/keyboard is detected. Relations: - Bluetooth mouse not detected (novell/bugzilla/id: 445583) https://bugzilla.novell.com/show_bug.cgi?id=445583 -- openSUSE Feature: https://features.opensuse.org/305443

1 0

[openFATE 305535] Improve samba yast modules
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305535, revision 11 Title: Improve samba yast modules openSUSE-11.2: Evaluation Priority Requester: Important Requested by: James McDonough (jmcdough) Partner organization: openSUSE.org Description: Improve the design of the yast samba modules. More details to come. References: https://bugzilla.novell.com/show_bug.cgi?id=444603 Business case (Partner benefit): openSUSE.org: Many customers report difficulties with various areas of samba yast administration, both with new features requested and layout of current ones. + Discussion: + #1: Christoph Thiel (cthiel1) (2009-05-28 15:34:16) + James, do you have more details yet? Otherwise, we'll have to reject it + for openSUSE 11.2 right away. -- openSUSE Feature: https://features.opensuse.org/305535

1 0

[openFATE 305546] Support for NTLM authentication (proxy) in YaST and libzypp
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305546, revision 7 Title: Support for NTLM authentication (proxy) in YaST and libzypp openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Katarina Machalkova (kmachalkova) Partner organization: openSUSE.org Description: YaST and libzypp should work in an environment with proxy server requiring NTLM authentication. The feature consists of two parts: 1) YaST proxy module has to provide UI to let user choose NTLM and write configuration file (/root/.curlrc) accordingly 2) libzypp media backend needs to be adapted to read and understand such configuration( that is, accept also --proxy-ntlm option instead of bare --proxy only) References: https://bugzilla.novell.com/show_bug.cgi?id=440296 https://bugzilla.novell.com/show_bug.cgi?id=412137 Business case (Partner benefit): openSUSE.org: Significant for adoption in mixed datacenters where the proxy infrastruture is on MSFT assets. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:57:23) Sadly, there is a realistic business case for this in mixed datacenters. Some odd people like to use NTLM proxies, I will never understand why. this will be a headache to do :-/ -- openSUSE Feature: https://features.opensuse.org/305546

1 0

[openFATE 303555] Create a home-user-readable partitioning summary
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303555, revision 8 Title: Create a home-user-readable partitioning summary openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 15:38:07 reject reason: Postponing. More important stuff to do. Priority Requester: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Duplicate of #305158 Priority Requester: Important Requested by: Jiri Srain (jsrain) Description: The partitoiner installation summary contains all detailed information about the disk changes, however, for home users it is not easily understandable. If we have a workflow prior the partitioning proposal, it will not be that important to contain all detailed information in the proposal. + Relations: + - feature/duplicate: 305158 Discussion: #1: Arvin Schnell (aschnell) (2008-03-28 16:27:43) I don't understand the reasoning: If the user doesn't understand the summary in the installation proposal neither can he understand the proposal in the workflow before. If that is the case we have to change both. #2: Jiri Srain (jsrain) (2008-03-31 13:39:55) (reply to #1) You are right, that with current workflow anything that contains less information is bad. However, for 11.1, we should improve the workflow and afterwards we can also simplify the summary. -- openSUSE Feature: https://features.opensuse.org/303555

1 0

[openFATE 303400] Allow to enable the backend error handler (beh) from the YaST printer module
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303400, revision 14 Title: Allow to enable the backend error handler (beh) from the YaST printer module openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 09:39:42 reject reason: Postponing. Priority Requester: Desirable - openSUSE-11.2: Evaluation + openSUSE-11.2: Done Priority Requester: Desirable Requested by: Lars Müller (lmuelle) Description: It should be possible to enable the backend error handler (beh) from the YaST printer module. This is usefull if a network printer isn't always reachable. Think of a printer switched on later than the startup of cups happens. Discussion: #1: Johannes Meixner (jsmeix) (2009-03-27 09:46:06) I wonder why I am not included in such requests? It is already implemented in the new yast printer module for openSUSE 11.1 and accordingly also for SLE11 via the "Connection Wizard". How to use it: 0. Usually one would first set up the queue as usual (i.e. without beh). 1. In case of backend errors and when additionally the default error handling is not what is wanted, one would first try if another CUPS error policy helps. One can change the CUPS error policy in YaST via "Policies". 2. If even another CUPS error policy does not do what is wanted, one could daisy-chain beh: Select the queue and "Edit" it. In the "Modify" dialog select "Connection Wizard" and therein "Daisy-Chain Backend Error Handler (beh)" usually leave the defaults for beh (or adapt them, read the help text in YaST), klick "OK" to go back to the "Modify" dialog. Now there is a new connection using "beh" available. Select this new connection in the "Modify" dialog and klick "OK" to apply the change to the queue. -- openSUSE Feature: https://features.opensuse.org/303400

1 0

[openFATE 302573] Make auto-selected-packages popup configurable
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #302573, revision 9 Title: Make auto-selected-packages popup configurable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-03-27 15:37:25 reject reason: Postponing to be considered for future YaST swmgmt UI changes. Priority Requester: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 12:53:40 reject reason: More important tasks to solve. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Lukas Ocilka (locilka) Description: YaST Packager has a special popup after the the list of selected packages is accepted. This popup says something like: These packages were automatically added to the list of packages: * package A * package B Some think that it is a bug and such popup should not appear at all (and packages should be added without asking), some think that it is a nice feature. Having it configurable, e.g., [x] Do not show this dialog again should be good enough for both. Note: this touches both installation and running system, so if decision is made in the installation, it should be copied to the installed system as well. References: Bug 298565 - package selector shouldn't ask about installing more packages (https://bugzilla.novell.com/show_bug.cgi?id=298565) -- openSUSE Feature: https://features.opensuse.org/302573

1 0

[openFATE 305623] Remove gnomesu dependancies from YaST
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305623, revision 8 Title: Remove gnomesu dependancies from YaST openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Mandatory Requested by: Federico Lucifredi (flucifredi) Description: The Gnome team informs me gnomesu is obsoleted. We need to stop depending on gnomesu on YaST, ideally moving towards PolicyKit as much as possible but at a minimum matching the current mainline Gnome behavior. -- openSUSE Feature: https://features.opensuse.org/305623

1 0

[openFATE 305682] Implement the possibility to allow Add-on source from remote "Plain RPM directory"
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305682, revision 5 Title: Implement the possibility to allow Add-on source from remote "Plain RPM directory" openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stefan Assmann (assmannst) Partner organization: openSUSE.org Description: During installation when configuring an add-on product there is an option called "Local Directory". If you choose that the next window will have a checkbox "Plain RPM Directory" which allows to add a directory that only contains RPMs as an add-on source. Unfortunately this seems not to be available if you try to configure an add-on product that is not stored locally. Neither FTP, HTTP, SMB, NFS etc... have an option to add a "Plain RPM Directory". This is really useful for exchanging single or multiple RPMs during development without the need to wait for the next development snapshot to verify changes made to the RPMs install fine. Support for this should be implemented into autoyast as well. Gives the opportunity to automatically configure a plain rpm update add-on source for easy exchange of RPMs. Business case (Partner benefit): openSUSE.org: Improves development process because developers can test the influence of their changes to RPMs during installation without having to wait for the next development snapshot. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 19:43:30) This is nice candy for developers. Good idea. + #2: Christoph Thiel (cthiel1) (2009-05-28 14:30:47) (reply to #1) + I'm unsure if remote plain rpm dirs make much sense. Directory listing + + getting the metadata would be a pain. How about adding a hint on how + to simply create a remote repo with just a few RPMs in there by running + "createrepo" on that directory? -- openSUSE Feature: https://features.opensuse.org/305682

1 0

[openFATE 303534] Extend BarGraph Widget
by fate_noreply＠suse.de 27 May '09

27 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303534, revision 29 Title: Extend BarGraph Widget openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Neutral Requested by: Arvin Schnell (aschnell) Requested by: Matthias Eckermann (mge1512) Description: The latest mockups for the partitioner contain an BarGraph with additional features: * legend * several areas with same color/legend * a bit small (maybe not so important) Here is a picture (http://w3.suse.de/~aschnell/bg2.png) from the mockup. Relations: - Enhance partitioner to be more user friendly (novell/bugzilla/id: 390213) https://bugzilla.novell.com/show_bug.cgi?id=390213 - Graphical Display of Hard Disk partitions (novell/bugzilla/id: 414322) https://bugzilla.novell.com/show_bug.cgi?id=414322 - Blog Comment praising GParted (url: http://lizards.opensuse.org/2009/03/06/context-menus-in-yast-partitioner/#c…) Discussion: #1: Federico Lucifredi (flucifredi) (2008-06-13 15:15:21) Stano, if we need it it is of course M. Let me know, I just have no business reasons, this is entirely an engineering decision. #2: Stefan Hundhammer (sh-sh-sh) (2008-06-17 15:29:07) What's wrong with using the _existing_ widget with its existing features? #3: Stanislav Visnovsky (visnov) (2008-06-17 15:54:05) Agreement is that this is not needed. #4: Katarina Machalkova (kmachalkova) (2009-02-25 16:43:41) Can we please re-consider this for openSUSE 11.2 ? Some visualization of used/free space ratio on the disk/partition, or the whole disk layout in the partitioner overviews would be nice. The problem (not the only one) with current bar graph widget is that if some portion of the graph becomes too small, the text on it is no longer readable. A legend of the graph (as depicted above) would help a lot, but at the very minimum, some tooltips over the graph parts could be added #5: Michael Löffler (michl19) (2009-03-25 17:27:12) (reply to #4) It looks still like an engineering decsion. Stano please re-consider or reject ;-) #6: Arvin Schnell (aschnell) (2009-03-25 17:53:24) (reply to #5) I don't understand why this should be an engineering decision. This feature will directly influence what the users see. It's not a detail hidden deep in source code that makes geeks say "wow" if they should find it while being bored to death. This is a feature users are constantly asking for! #11: Jean-Daniel Dodin (jdd_sysop) (2009-04-08 20:53:33) gparted is much friendly than YaST. shame. jdd #12: FERNANDO RUBEN ESPINOSA RAMIREZ. (fersito) (2009-04-09 04:01:51) You must to do what ever you want Katarina so in order to learn like myself.-fernando (from Leòn GTO. Mexico)greetings. #13: Duncan Mac-Vicar (dmacvicar) (2009-04-09 11:03:22) (reply to #12) This is even a fake email. Final-Recipient: rfc822; ferub(a)att.net.mx Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host mailin-02.mx.aol.com[64.12.137.89] said: 550 MAILBOX NOT FOUND (in reply to RCPT TO command) #14: Marc Telesha (mtelesha) (2009-05-10 08:03:28) Persoanlly I used a LiveCD of Parted Parted (Gpartitioner) before installing OpenSUSE everytime. It is much easier to do it this way when setting up a dual booting computer.I really think if it had a better GUI for partitions it would make this partitioning easier for people to understand, especially people giving Linux a try.-Marc -- openSUSE Feature: https://features.opensuse.org/303534

1 0

[openFATE 303736] yast and libzypp should respect the disk space reserved for root
by fate_noreply＠suse.de 27 May '09

27 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303736, revision 9 Title: yast and libzypp should respect the disk space reserved for root openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 12:18:47 reject reason: Postponing. This is nice to have. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Ladislav Slezak (lslezak) 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 -- openSUSE Feature: https://features.opensuse.org/303736

1 0

[openFATE 303809] Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1
by fate_noreply＠suse.de 27 May '09

27 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303809, revision 20 Title: Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 openSUSE-11.1: Rejected by Matthias Eckermann (mge1512) reject date: 2008-07-30 16:50:50 reject reason: Moving to SLE 11 SP 1 / openSUSE 11.2 Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Matthias Eckermann (mge1512) Description: Proposal is to offer an option in YaST to clone a disk layout for RAID use and probably jump into the RAID-creation-mode directly Below the original request from C. Boltz / openSUSE community: ----------------------------------------------------------------------------------------------------- It would be good to have an easier way to setup a raid 1 (mirroring). Currently you have to: * create partitions on first disk * create partitions on the second disk (usually using the same layout). * put the corresponding partitions (sda1+sdb1, sda2+sdb2, ...) into a raid array. The easier way would be * [x] I want to create a raid 1 * define the partitioning once for both disks YaST should then partition both disks as requested and create the raid volumes This would save the user/admin some time. However, the traditional method should still be available in case someone wants to have a different layout for some partitions for whatever reason. Relations: - Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 (novell/bugzilla/id: 387373) https://bugzilla.novell.com/show_bug.cgi?id=387373 Discussion: #2: Matthias Eckermann (mge1512) (2008-05-06 20:10:22) Thanks for the proposal. I am happy that there are more people out there sharing my problems:-) Yet, looking at the current "model" we have in mind for partitioner enhancements, I wonder, if we could probably make that more "generic" by adding something like a "clone disk partitioning scheme" button: You would partition hd0 first and then say: please clone this to hd1, hd2, ... and be able to adjust settings on hd1, ... later. Would that fit? so long - MgE #3: Christian Boltz (cboltz) (2008-05-08 05:07:14) Cloning the disk layout sounds like a good idea and would help. To make it more useful for RAID creation, add "clone to md*", maybe combined with a selection dialog to choose the disks to use. #4: Matthias Eckermann (mge1512) (2008-05-08 05:26:16) Well, you know, we indeed are planning to have such a dialog for creation of raids in the future, ...:-) I changed the "title" according to our discussion, and will 1transfer the request into our internal Feature tracking system soon. Thanks! so long - MgE #6: Martin Schmidkunz (mschmidkunz) (2008-05-15 11:37:58) AFAIK it is currently possible to create one partition after the other. So it does not make sense for me to have a "Clone this partition for future use" at the end. Instead I thought of: http://en.opensuse.org/Image:Idea_303809_1.png When the user presses "Add" in the "partitioning" tab he can choose whether to create one new partition or to use the whole partition scheme from another physical harddisk. Does that make sense? #7: Matthias Eckermann (mge1512) (2008-05-15 12:05:53) (reply to #6) Well, no:-( We are not asking for _partition_ cloning, but _disk_ cloning, i.e. if you have several harddisks, and you want to copy the partitioning from sda to sdb or the like. #8: Martin Schmidkunz (mschmidkunz) (2008-05-16 10:01:41) As discussed live with mge we agree on my proposal. #9: Arvin Schnell (aschnell) (2008-05-16 10:33:01) (reply to #8) That approach has some problems: 1) Hiding "Cloning" behind "Add Partition" is incomprehensible. Cloning affect the whole disk, adding a partition not really. 2) The step to select the partition type is omitted if only one type of partition can be selected. 3) The complete workflow of adding a partition is omitted when no partitions can be created. We (mge, mschmidkunz and aschnell) now agreed upon adding an entry to the "expert" menubutton in the partition overview. #16: Arvin Schnell (aschnell) (2009-02-04 11:08:08) Summarising the request: Add a entry "Close disk layout" to the "Expert" button in the disk view. This opens a dialog showing all disks that are suitable for being a clone (constraints: new disks must have equal or larger size). Several disks can be selected. On the selected disks: Delete everything (including RAIDs and LVMs somehow using that disk), create new partition table (if different from existing) and create partitions with same start and sizes (in cylinders as libstorage calculates internally) and partition IDs. Other parameters, e.g. filesystem, are not copied. -- openSUSE Feature: https://features.opensuse.org/303809

1 0

[openFATE 304971] Improved Popup support from libyui
by fate_noreply＠suse.de 27 May '09

27 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #304971, revision 10 Title: Improved Popup support from libyui openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-16 09:22:38 reject reason: Not needed anymore. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Arvin Schnell (aschnell) Description: Currently writing popups with longer texts is difficult: Line wrapping must be done in YCP and thus cannot take font metrics into account. Using RichText widget is also difficult since it's not possible to know the correct height in advance. What I would like to see is a popup that does line wrapping (preserving parapraphs) and adjusts the height of the whole popup accordingly. The popup width should be a parameter or the popup could find a good ratio between width and height. Relations: - missing linebreak in german YaST2 partitioner message (novell/bugzilla/id: 190817) https://bugzilla.novell.com/show_bug.cgi?id=190817 Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-06-27 19:50:50) I guess this is something to leave for our colleagues in engineering to prioritize, thus labeling neutral for PM. #2: Stanislav Visnovsky (visnov) (2008-07-01 13:37:34) (reply to #1) Duncan, this is in your team, up to you if you need this. #3: Arvin Schnell (aschnell) (2008-07-16 10:18:29) Why isn't this needed anymore? What do we have instead? -- openSUSE Feature: https://features.opensuse.org/304971

1 0

[openFATE 306237] yast textmode: displaying release notes
by fate_noreply＠suse.de 27 May '09

27 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #306237, revision 9 Title: yast textmode: displaying release notes - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Karl Eichwalder (keichwa) Description: In YaST ncurses UI, even if the screen is large (more than 100 characters), do not use more than 79/80 width for displaying the frame containing the release notes text. Lines longer than 80 characters are hard to read. Relations: Discussion: #2: Gabriele Mohr (gabi2) (2009-03-25 14:41:44) I have discussed with Karl. The problem also exits for Qt. Therefore a change in YCP layout is necessary. I have attached a suggestion for a layout change in inst_release_notes.ycp. I have used `Empty and `HWeight to add a margin at the left and right side of the text. This approach works for Qt and ncurses. Karl agrees that a stretchable text (width changes depending on total size) is better than a fix width. #4: Karl Eichwalder (keichwa) (2009-03-25 15:16:03) (reply to #2) Thanks, Gabi! > Karl agrees that a stretchable text (width changes depending on total size) is better than a fix width. Yes, at least, it looks better for normal use cases. The patch will probably improve the readability for most users. #3: Gabriele Mohr (gabi2) (2009-03-25 14:43:38) Added attachment patch for inst_release_notes.ycp (HWeight.diff) -- openSUSE Feature: https://features.opensuse.org/306237

1 0

[openFATE 302485] sync GPT and MBR on MacBook (mactel)
by fate_noreply＠suse.de 27 May '09

27 May '09

Feature changed by: Eddy Figueroa (efiggy) Feature #302485, revision 33 Title: sync GPT and MBR on MacBook (mactel) openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-10-01 12:11:18 reject reason: not done from what I heared Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-04-28 09:46:04 reject reason: lacking parted maintainer for the moment Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Done Priority Requester: Mandatory Requested by: Ruediger Oertel (oertel) Description: on multiboot setups on MacBooks and other mactel machines, using a combination of GPT and MBR is pretty common (and necessary if you either want to use grub or are also using Windows) for installation on these machines we need to offer a way to sync the GPT to the MBR whenever a change to the GPT is made. There exists a patch for parted to do just this (see bugzilla#220839) and also the sources of refit (refit.sourceforge.net, tool gptsync). Relations: - GPT partitioning and boot support (feature/id: 303026) - fully support disks with GPT (feature/id: 303924) Discussion: #1: Stephan Kulow (coolo) (2007-08-01 12:37:33) sounds like a dataloss we should fix for 10.3 too #2: Edith Parzefall (emapedl) (2007-08-01 17:42:46) We need to find out more about what actually needs to be done, before we can consider making an attempt for 10.3 despite the approaching deadline. #3: Edith Parzefall (emapedl) (2007-08-07 11:53:32) There's not enough time left, please reject for 10.3. #4: Ruediger Oertel (oertel) (2007-11-06 12:29:36) for reference, the patch for parted is in bug#220839. This patch adds the method "map_gpt_to_msdos" to parted and was written by Olaf Hering and discussed on the parted mailing list in May 2007. #5: Duncan Mac-Vicar (dmacvicar) (2008-02-04 21:29:52) Olaf, you wrote the patch, can you please describe us what is exactly needed so YaST makes this kind of configuration to work? There is little knowledge about this situation and we imagine adding the patch to parted is not the only required step. Some additional code in YaST and while setting up the bootloader might be required. Do you know about it? #6: Olaf Hering (olh) (2008-02-18 10:04:25) (reply to #5) There are comments in the patch. Once the GPT partitioning is done, map one GPT partition to a primary msdos partition. yast2-storage knows what the boot partition is, so it can force the mapping. #7: Arvin Schnell (aschnell) (2008-04-03 17:11:26) Duncan asked me to summarise the task for implementation: 1) Include parted patch "parted.msdos-on-gpt.patch". Thomas saw the risk of breaking parted by this. Issue for parted maintainer (we have none). 2) Add new calls to parted to establish the mapping from GPT to MSDOS disk labels. Issue for yast2-bootloader and/or yast2-storage. 3) Fix bootloader config to not call "parted ... boot on" when it's already on. Should fix the update problem Rudi has. Issue for yast2- bootloader. AFAIS not required with patched parted. #8: Duncan Mac-Vicar (dmacvicar) (2008-04-14 11:43:17) Coolo, points 1 and 3 call for reject until bootloader situation and parted one is better. #9: Joachim Plack (jplack) (2008-04-28 12:30:48) michl@ : AFAIK The MacBooks are to date not handled as a supported platform. But they should be last but not least due to there pretty wide spread of that thingy. Please check, define and prioritize. Thanks. BTW there are some booting issues involved #10: Michael Loeffler (sprudel24) (2008-04-28 13:36:54) (reply to #9) That's a clear "nice to have" feature. Needed ressources and involved risks need to be low. #11: Stephan Kulow (coolo) (2008-06-12 12:39:54) (reply to #10) I'm not so sure about this. Depending on what market you look at, you get a market share of 10 - 50 percentage. I didn't fail to notice that Saturn Fürth's laptop departement is basically built around macbooks. #12: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:21:19) Please reject for 11.0. All resources allocated with mandatory features already. #13: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:46:29) (reply to #12) meant SLE11/openSUSE11.1 #14: Alexander Graf (algraf) (2008-08-22 19:54:25) (reply to #13) For openSUSE 11.1 / SLES11 it's done already. I checked in a patch for parted a while ago. #15: Stephan Kulow (coolo) (2009-04-22 14:22:43) (reply to #14) opening to openfate to have a link #16: Lars Vogdt (lrupp) (2009-05-13 12:43:12) (reply to #14) For me it doesn't look like "done already". I've a MacBook Pro here and tried to install openSUSE 11.1 without success. FYI: I'm using rEFIt as "bootloader" here - and after each installation, rEFit tells me that the MBR and GPT is out of sync and can't be repared. With the older openSUSE (10.3) it works with this workaround: http://en.opensuse.org/Installation_on_MacBook_Pro_Intel_(x86) <-- grub is not installed Sadly I need the MacBook for my work, but if you can't find another one, I can run a backup and reproduce my problems for you. + #17: Eddy Figueroa (efiggy) (2009-05-27 03:41:47) (reply to #16) + I can verify that I'm still having the issue here with openSuSE 11.1 + and 11.2 Milestone 1. I've got the MacBook Pro 2,2 (late 2006) model. I + tried to configure the partitions (just a swap and ext3 partition, + nothing special) with gParted and was able to successfully sync the GPT + and MBR tables. Then I installed openSuSE and even though I didn't even + have it format or recreate the partitions my MBR was destroyed; I could + no longer sync the GPT and MBR tables. + If there is a clear, definitive guide on what needs to be done to work + around this issue I would love to see it... I haven't run into anything + that has helped (including the guide that Lars linked to) and I would + really love to see openSuSE running on my MacBook Pro. I don't want to + give up! + Thank you for all your hard work, guys (and gals)! -- openSUSE Feature: https://features.opensuse.org/302485

1 0