April 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 303493] zypper: add separate messages for Required and Recomended packages
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Stephan Kulow (coolo) Feature #303493, revision 11 Title: zypper: add separate messages for Required and Recomended packages openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-03-27 13:50:16 reject reason: Not enough time to look into this. Priority Requester: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-08-01 18:27:34 reject reason: Cutting scope to match project schedule. Priority Requester: Important Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stephan Kulow (coolo) + reject date: 2009-04-16 13:39:02 + reject reason: Out of agreed focus for 11.2 development Priority Requester: Important Requested by: Cristian Rodríguez (elvigia) Description: currenly when you install a package with zypper, you just get the packages that are going to be installed, regardless if the are required or Reccommended,.. will be nice if the messages can be arranged to be more explict about what the package manager is doing. "The following NEW [required|reccomended] package is going to be installed: foo" also an informative message about Suggested packages should be shown "The following package(s) is(are) suggested but are not going to be installed foo bar " unless user pass --install-suggested or use a boolean configuration directive on zypp.conf or something, suggested packages should not be installed by default ..currently it seems to be completely ignored and does nothing. -- openSUSE Feature: https://features.opensuse.org/303493

1 0

[openFATE 303460] Redesign of Sound Card Module
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Stephan Kulow (coolo) Feature #303460, revision 18 Title: Redesign of Sound Card Module openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-03-26 16:04:06 reject reason: Out of time for 11.0. Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-06-25 15:09:08 reject reason: Postponing, out of focus. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: Currently the sound card module in YaST hides many options within an "Others" menu button. When adding a sound card the user needs to choose between three configuration ways: automatic, normal and advanced. It is very difficult for the user to choose the appropriate way for him. Ideas for Improvement: * Moving "Volume" and "Start Sequencer" to the "Edit" section. * "Set As Primary Card" is now visible at once to the user * "Play Test Sound" is integrated into the "Edit" section Workflow for "Add" a new sound card: * The user chooses only the vendor and the model. * All the other settings (volume and some advanced settings) can be adjusted via "Edit". * Joystick settings can be done in the "Joystick" module. Mock ups for the redesign are available at: http://en.opensuse.org/Usability/Sound Relations: - feature/id: 304936 Discussion: #2: Guy Lunardi (glunardi) (2008-05-19 00:50:40) mschmidkunz: I believe that re-designing this module is probably a good idea. I hate to mix technology in design and feature discussions but in this case... I wonder if we need to make the module Pulse audio aware. #3: Matthias Eckermann (mge1512) (2008-06-17 17:28:14) (reply to #2) I agree. Just open another FATE regarding Pulse Audio awareness of the YaST module in addition to this one, ...:-) #4: Guy Lunardi (glunardi) (2008-06-18 09:44:48) (reply to #3) Done, I have created 304936 to track the pulse-audio need in YaST. + #5: Stephan Kulow (coolo) (2009-04-16 13:37:20) + looking for community volunteers -- openSUSE Feature: https://features.opensuse.org/303460

1 0

[openFATE 301791] "Report a bug" a-la-Safari for Mozilla Firefox
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Stephan Kulow (coolo) Feature #301791, revision 35 Title: "Report a bug" a-la-Safari for Mozilla Firefox openSUSE-11.0: Rejected by Stefan Behlert (sbehlert) reject date: 2008-10-14 10:33:33 reject reason: Clearly not done Priority Requester: Mandatory Projectmanager: Desirable openSUSE-11.1: Rejected by Stefan Behlert (sbehlert) reject date: 2008-12-03 14:23:26 reject reason: Nothing done for 11.1 Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stephan Kulow (coolo) + reject date: 2009-04-16 13:32:35 + reject reason: don't see any use case for openSUSE - if mozilla + upstream doesn't need more information, then openSUSE doesn't need it + either Priority Requester: Mandatory Requested by: Guy Lunardi (glunardi) Developer: Michael Wolf (maw) Description: Apple's Safari web browser introduced a really easy for end-users to report public URLs which didn't render properly in Safari. It would be very nice if we could offer something similar for our Firefox. what you should be able to send: - Once Address URL - Description - Problem: other problem, missing content, imcorrect behavior, incorrect aspect, empty page, unable to load the page or unable to connect. - Send screenshot - Send source code Discussion: #1: JP Rosevear (jproseve) (2008-02-28 23:27:20) How is this fundamentally different from Help->Report Broken Website in 2.0.12> I guess code is not sent nor is the screenshot, but this is all the upstream developers are requesting. Or are you intending submission to bugzilla.novell.com? #2: Guy Lunardi (glunardi) (2008-03-05 18:26:47) (reply to #1) JP, thanks for pointing this out. The solution is very close right now. What it doesn't support is the sharing information for pages that are 'Intranet-based' and not 'Internet-based'. One of our customer may want to report a problem with Firefox with an homegrown application which the developers looking at the results of this submission can't access. Embedding the results (as MTHML or html source) would be the one missing feature. The other thing is that this content probably goes upstream. Should it come to Novell? #3: Gary Ekker (gekker) (2008-05-09 10:23:42) Michael, does this like something you could do? Or do we need to find another developer? #4: Michael Wolf (maw) (2008-05-30 18:27:09) (reply to #3) Not sure yet, but I'll look into it. #6: Gary Ekker (gekker) (2008-09-11 19:00:59) Proxying this for Michael: It seems like the best thing to do would be to use what's already in place. The reporting functionality can be configured. The source to the reporter contains the following: | pref("extensions.reporter.privacyURL", "http://reporter.mozilla.org/privacy/"); | pref("extensions.reporter. serviceURL", "http://reporter.mozilla.org/service/0.3/"); They can be changed in about:config, presumably sitewide. (This might need to be hooked into the gconf stuff.) So I think it would be a matter of setting up a hypothetical http://reporter.novell.com/ and/or http://reporter.example.com/. The source for the server-side part of the reporter is at hosted on mozilla cvs and can be checked out with "cvs -d :pserver: anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/tools/reporter" The maintainers of said server(s) could then deal with problem reports as seems fit. If we choose in SLED to change the default to the hypothetical http://reporter.novell.com/, it would be trivial to do so via the MozillaFirefox-branding-SLED package. (I don't think this package actually exists yet.) #7: Gary Ekker (gekker) (2008-09-11 19:01:59) Adding Federico and Stano as we might want to look at this in the context of onstar. #8: Stefan Behlert (sbehlert) (2008-10-14 10:34:08) What's the status here? #9: Stefan Behlert (sbehlert) (2008-10-24 17:23:17) (reply to #8) Gary, Michael? #10: Stefan Behlert (sbehlert) (2008-11-13 23:46:50) Guy, we need to reject this as there was no progress. Gary, could you provide an ECO for that? -- openSUSE Feature: https://features.opensuse.org/301791

1 0

[openFATE 305574] Integrate ftrace
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Michael Löffler (michl19) Feature #305574, revision 4 Title: Integrate ftrace - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Jan Blunck (janblunck) Description: The ftrace infrastructure currently available in upstream kernels comes with different tracers. Having these tracers general available would enable us to find performance and functional regressions more easily during development and in support. Some of them need further work to be included in production kernels (so they don't depend on frame pointers etc.). Discussion: #1: Greg Kroah-Hartman (gregkh) (2009-01-20 05:11:51) We will get these automatically with the 11.2 release, so I don't see this as a big issue at all. Is there something different that we need to do to support these tracers? -- openSUSE Feature: https://features.opensuse.org/305574

1 0

[openFATE 305772] Move to hal-cups-utils instead of cups-autoconfig
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature added by: Vincent Untz (vuntz) Feature #305772, revision 1, last change by Title: Move to hal-cups-utils instead of cups-autoconfig openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: We're the only one using cups-autoconfig and everybody else is using hal-cups-utils, so it's probably working a bit better. And switching to it means lower maintenance on our side. Packages are ready for testing in home:vuntz:factory-playground -- openSUSE Feature: https://features.opensuse.org/305772

1 3

[openFATE 305301] Central Regulatory Domain Agent (for 802.11)
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Michael Löffler (michl19) Feature #305301, revision 12 Title: Central Regulatory Domain Agent (for 802.11) - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Helmut Schaa (hschaa) Description: The regulatroy domain handling for wireless cards was done by each driver seperately before mac80211/cfg80211. cfg80211 is used to unify the handling of regulatory domains for wireless devices. However cfg80211 depends on the user space configuring the regulatory domain. A user space daemon is currently developed (see [1]). It basically provides the allowed channels for all known regulatory domains. Additionally it would be nice to allow the configuration of the regulatory domain from the Yast network module. [1] http://wireless.kernel.org/en/developers/Regulatory/CRDA Partly based on bnc#392853 Discussion: #1: Helmut Schaa (hschaa) (2009-02-03 12:04:57) I've already packaged crda and wireless-regdb in my buildservice project home:hschaa:CRDA. #2: Helmut Schaa (hschaa) (2009-02-09 11:37:20) What we additionally need for this feature is some integration with Yast or NetworkManager such that the user is able to set the regulatory domain (maybe based on the selected time zone). A command line tool for setting the domain is already available (iw) but needs to be updated. #3: Helmut Schaa (hschaa) (2009-02-09 16:09:28) (reply to #2) Just submitted an update for Factory. #4: Helmut Schaa (hschaa) (2009-02-10 10:59:40) (reply to #2) wpa_supplicant 0.6.7 already has support for setting the regulatory domain. We'll get that with the next version update. #5: Helmut Schaa (hschaa) (2009-02-10 13:40:25) (reply to #2) iw, crda and wireless-regdb are part of factory now #6: Kshitij Kulshreshtha (polyconvex) (2009-03-25 11:53:33) Sometimes on a short visit abroad a user might not bother to update their timezone information on their laptop but still want to use a wireless network. In this case setting the regulatory domain based on timezone is not the right thing to do. Why not let the networkmanager applet ask the user himself to provide the country as a part of the dialog to setup the network? (A map similar to the yast timezone selector built into KNetworkManager?) -- openSUSE Feature: https://features.opensuse.org/305301

1 0

[openFATE 305542] Installation: Detect TabletPC and select TabletPC pattern
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Michael Löffler (michl19) Feature #305542, revision 8 Title: Installation: Detect TabletPC and select TabletPC pattern - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Michael Löffler (michl19) + reject date: 2009-04-16 12:32:02 + reject reason: out of scope for 11.2 Priority Requester: Neutral Requested by: Michael Andres (mlandres) Description: As it looks yast2 don't select the TabletPC pattern automatically if the install get started on a TabletPC (as it's done for the laptop pattern and it should be easy to detect a tabletPC since HAL tells it via system.formfactor.subtype = 'tabletpc'). References: https://bugzilla.novell.com/show_bug.cgi?id=449770 -- openSUSE Feature: https://features.opensuse.org/305542

1 0

[openFATE 300689] TabletPC: Support Touchscreen and Wacom decives during installation
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Michael Löffler (michl19) Feature #300689, revision 30 Title: TabletPC: Support Touchscreen and Wacom decives during installation openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-08-03 09:39:40 reject reason: installation is frozen Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-16 09:02:38 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Michael Löffler (michl19) + reject date: 2009-04-16 12:28:26 + reject reason: out of scope for 11.2 Priority Requester: Important Projectmanager: Important Requested by: Stefan Behlert (sbehlert) Description: Tablet PCs are normally produced in two kinds of flavours: Convertibles, which have a keyboard, and Slates, which have none (only pens or touchscreens). If a user installs a Slate, he has no keyboard and no (pohysical) mouse device, only the touchscreen. We should on TabletPCs automatically recognize that it is a TabletPC and configure the Wacom or other Touchscreen device where possible. Thus would enhance the usability of the product on TabletPCs. Discussion: #1: Gary Ekker (gekker) (2007-07-17 11:24:05) Stefan, do you see this as work that your team would do, something that needs to be done by the YaST installer, or both? -- openSUSE Feature: https://features.opensuse.org/300689

1 0

[openFATE 300688] Show virtual keyboard on TabletPC during installation
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Michael Löffler (michl19) Feature #300688, revision 43 Title: Show virtual keyboard on TabletPC during installation openSUSE-10.2: Rejected by Jiri Srain (jsrain) reject date: 2006-09-25 14:06:21 reject reason: Not enough resources. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Edith Parzefall (emapedl) reject date: 2007-07-24 14:21:32 reject reason: Sorry, not doable for 10.3. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Michael Löffler (michl19) reject date: 2008-01-11 16:39:04 reject reason: out of scope for openSUSE Priority Requester: Mandatory - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Michael Löffler (michl19) + reject date: 2009-04-16 12:27:27 + reject reason: tablet PC not in scope for 11.2 Priority Requester: Mandatory Requested by: Stefan Behlert (sbehlert) Description: Tablet PCs are normally produced in two kinds of flavours: Convertibles, which have a keyboard, and Slates, which have none (only pens or touchscreens). If a user installs a Slate, he has to press e.g. buttons without having a keyboard to do it. Additionally he has no mouse device (except his pen) to press buttons. To do so, two ways are possible: Either using some kind of graffiti scribbling, which makes entering e. g. the password an adventure, or by providing a virtual keyboard where the user can select the characters. The second possibility is far superior and also used by Windows. It should be simply to blend xvkbd into the screen. Only possible problems: If a 800x600 resolution is used, the display is really small for both Yast and the keyboard. Discussion: #3: Edith Parzefall (emapedl) (2006-09-20 17:04:28) Jiri, do you see any chance to have it done in your team? Otherwise, I'd reject it. #6: Stephan Kulow (coolo) (2008-01-11 13:50:29) I would think that such devices are out of context for openSUSE 11.0, but asking Michl. How would this look like? Would the xvkbd always be visible and yast screen reduced accordingly? #7: Michael Löffler (michl19) (2008-01-11 16:38:08) As long as this is not required by SLED this is out of scope for openSUSE. #9: Michael Löffler (michl19) (2008-01-11 17:11:57) (reply to #8) Even vision and innovation need to be prioritized. Correct me if I'm wrong - but tablet PC still has a very minor market share. #10: Guy Lunardi (glunardi) (2008-01-18 17:34:09) Gartner projects 5% to 20% market penetration for Tablet PCs in the Healthcare. It is positioned as: "Tablet PCs meet all the criteria for a notebook PC and are equipped with a pen and an on-screen digitizer". "The tablet PC is solid and mature for vertical applications where it solves a specific problem. Of course there are 2 kinds of tablets, with physical keyboard and without (slab). I had to install openSUSE 10.3 on a slab myself and must admit that on-screen would have been nice. Is there an engineering effort estimate that could be looked at before we reject it for SLED11? #11: Stefan Behlert (sbehlert) (2008-05-21 21:39:58) (reply to #10) Duncan, any effort estimation? #13: Guy Lunardi (glunardi) (2008-06-23 11:44:51) (reply to #11) As we discussed, support for tablet is primarly critical at runtime. if we can add support for the install, that would be great even for accessibility reasons. I think we should focus our resources on making sure that tablets work well once the system is installed. #14: Duncan Mac-Vicar (dmacvicar) (2008-11-18 13:38:12) (reply to #13) Sure, but this was rejected because there are no resources to do it. So what did we had to drop in order to make it? Without reprioritization there is nothing we can do. I will provide an effort estimation for a next cycle. Estimating the effort here means basically prototyping it, and that just can't be done. -- openSUSE Feature: https://features.opensuse.org/300688

1 0

[openFATE 305351] pam_mount update to latest stable version
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Thorsten Kukuk (kukuk) Feature #305351, revision 9 Title: pam_mount update to latest stable version openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Michael Calmer (mcalmer) Description: The author of pam_mount declared the current version 0.X as unsupported. We should update 11.2 to the newest version. We can also think about an update for SLE11 SP1 if possible. The problem here are massive changes in the configuration file again. A clean and safe convert of the configuration might not be possible. Relations: - pam_mount: update to latest (novell/bugzilla/id: 438457) https://bugzilla.novell.com/show_bug.cgi?id=438457 Discussion: #2: Jan Engelhardt (jengelh) (2009-03-01 16:34:42) Anything but the latest two top releases are basically unsupported. The config file has been stripped of most built-in defaults that nobody ever changes anyway. For a conversion, just strip everything but < mntoptions>, <volume> and <luserconf>. -- openSUSE Feature: https://features.opensuse.org/305351

1 0