February 2011 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 16 Feb '11

16 Feb '11

Feature changed by: Mindaugas Baranauskas (embar-) Feature #305394, revision 45 Title: Move KDE software updates notifications to upstream infrastructure openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:29:01 reject reason: out of resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Rejected by Sascha Peilicke (saschpe) reject reason: 11.3 is out for a while, wasn't done Priority Requester: Important openSUSE-11.4: Unconfirmed Priority Requester: Neutral Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Technical Contact: (Novell) Technical Contact: Stephan Binner (beineri) Partner organization: openSUSE.org Description: As kpackagekit matures, it may be the case that for 11.2 it is mature enough for replacing kupdateapplet. It already implements various aspects of kupdateapplet: * notifications (knotify) using a kded service (which takes care of refreshing too) * single update selection (kpackagekit gui) * uses a upstream client library for communication with PackageKit, which are better than our PackageKit communication code. Scope kpackagekit is meant here only to replace kupdateapplet. There is not relation with YaST here. Open Issues: * tray notification: may require implementing a plasma tray icon * SUSE specific code (smolt, registration, hardware search) * Requires some research how to introduce those extensions in kpackagekit, or move SUSE specific parts out, like another kded service. User experience Should stay the same Dependencies * PackageKit * libpackagekit-qt Contingency Plan In the case kpackagekit is not yet mature enough, the same resources invested now in kupdateapplet can be invested in improving kpackagekit. Otherwise, we can stay with kupdateapplet as a fallback. Relations: - kpackagekit author interview (url: http://polishlinux.org/kde/kpackagekit-interview/) - kpackagekit screenshot (url: http://www.packagekit.org/img/kpk-update.png) Test Case: * new patches should be notified by knotify * user should be able to see update availability * user should be able to see detailed update information, as well as selecting individual updates * user should get informed if the update repositories configuration has a problem * user should be informed of (available) drivers for plugged hardware Business case (Partner benefit): openSUSE.org: Right now software notifications are done using the kupdateapplet, which comes from the opensuse-updater code,(renamed in a non sucessful attept to upstream it). This applet come from a summer of code project, originally done as a zmd client, then evoluted to a zypper client, and now working as a PackageKit client. Sadly, during 10.3 cycle this applet got the feature to select updates individually and other small stuff which turned it into a very complicated piece of code, and started to became a package manager on its own. Later it became the favorite place to plug any kind of notifications, like registration needed, smolt participation, etc, and right now the code is much more complex that it should be (thus taking more maintenance and testing than it should require). This feature has the objective of cleaning up this situation to free resources in this area. With the progress of packagekit and recently, kpackagekit, this should be possible. kpackagekit already implements various of the needed aspects, and therefore it would mean getting rid of in house code for upstream code. Additionally, it would result in a much more consistant user experience as the tools would be similar across distributions. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:24:20) Looks like Duncan is in favor of this. Stano? If you guys are comfortable with the change, I am all for it. But remember, priority #1 is dist-upgrade. #5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 18:00:54) I will evaluate this feature later, we don't know the status of KPackageKit, we have the package and Thomas contributed patches, so only the decision to switch or not to switch is important. Feedback from the KDE team about upstream KDE 4.3 would also be useful. #8: Lubos Lunak (llunak) (2010-03-12 11:40:52) Is it written down somewhere what are the requirements for a KUpdateApplet replacement? What is listed here as 'Testcase' looks incomplete to me. I'd personally prefer if KDE stayed away from this strange PackageKit experiment (in my experience most KUpdateApplet problems are in fact PackageKit problems), and in fact there are some plans upstream to have a KDE wrapper API for packaging (basically like PackageKit, but without the overdesigning and sucking). That would also solve the problem of switching to upstream infrastructure, and that's why I'd like to know the openSUSE requirements. The expected timeframe is KDE SC 4.4 or 4.5, i.e. too late for 11.3. #9: Martin Seidler (pistazienfresser) (2010-06-22 22:31:15) Is the proposal not just like the status with Gnome (in 11.2)? If so I would not recomend that (way of) change: I use the PackageKit Software in Gnome now only for notiforcation and not for making updates as I (and seems so - also many other users in the forums) had often problems that seems to be related to that applet (or simply the use of different applets for updating software). #10: Federico Lucifredi (flucifredi) (2010-06-22 22:50:50) (reply to #9) Bugs on the Gnome PK applet should be fixed -- lets make sure they are reported. -- The proposal here, as I understand it, was to bring about coherence with upstream in the KDE space. That is a valid objective, and quality is something that would be addressed as part of any change. No one is rushing. #11: Martin Seidler (pistazienfresser) (2010-06-28 23:29:07) (reply to #10) Sorry if my first comment seems to be so contra. I have only voted neutral and am not sure. If this proposted way would really work it seems to me desirable (if I could understand it at all ;-) ). If it would lead to a stable and easy way to update (without the possibility to add completely new programms) it may be also make sence to give a normal user access to that update tool (again?). But the developers may also look at possible complications or unreported bugs (just seach for "update" and "applet" or something like this in the forums - maybe that indicates more to replacing kupdateapplet than against?): for example (some of the first results of "update" and "applet" - some of 300): http://forums.opensuse.org/get-help-here/applications/441112-updater-applet… http://forums.opensuse.org/get-help-here/applications/440994-kupdater-apple… http://forums.opensuse.org/get-help-here/applications/440391-problem-updati… http://forums.opensuse.org/get-help-here/applications/440082-opensuse-updat… ... #12: Petar Petrov (siminin) (2010-07-02 09:23:55) (reply to #11) I also have problems with kpackagekit. That's why i uninstall packagekit and install kupdateapplet-zypp and the notification works like a charm. That's why i dislike this proposal and vote it down. #15: Duncan Mac-Vicar (dmacvicar) (2011-02-14 10:31:49) (reply to #12) If you have problems, please report concrete bugs. #13: Sascha Peilicke (saschpe) (2010-12-17 09:20:10) Seems like this is done for 11.4 #14: Fahim Murshed (inverbrass) (2011-02-11 19:28:25) Nice + #16: Mindaugas Baranauskas (embar-) (2011-02-16 13:48:26) (reply to + #14) + I have openSUSE 11.4RC1 and the first time I used KpackageKit to install + an RPM pakage - it chashed! see + https://bugs.kde.org/show_bug.cgi?id=266448 -- openSUSE Feature: https://features.opensuse.org/305394

1 0

[New: openFATE 309322] L2TP support in openSUSE
by fate_noreply＠suse.de 16 Feb '11

16 Feb '11

Feature added by: Yasha Gindikin (SlonoInquisitor) Feature #309322, revision 1 Title: L2TP support in openSUSE openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Yasha Gindikin (slonoinquisitor) Partner organization: openSUSE.org Description: Please, add the xl2tpd package to the installation DVD and official repository, and provide a way to configure the L2TP connection through the Network Manager. Business case (Partner benefit): openSUSE.org: Currently, many internet providers switch from the older Point-to-Point Tunneling Protocol (PPTP) to a newer one, called Layer 2 Tunneling Protocol (L2TP). This transition is especially noticeable in Russia, where both large and smaller ISP companies tend to obtrude it without any alternative upon the end-user. However, the support for L2TP is totally missing in openSUSE. Specifically, the xl2tpd package to provide the support is absent in official repositories and has no assigned maintainer. Which is a shame, since most solid distribution, including Ubuntu, Debian and Mandriva, have this package in their repos. Then, no support for L2TP is provided in Network Manager. Generally, there is not any configuration tool for L2TP in openSUSE, apart from manual tuning the text configuration files. The situation should be improved. -- openSUSE Feature: https://features.opensuse.org/309322

1 27

[openFATE 72] Thank good brainshare is over
by fate_noreply＠suse.de 15 Feb '11

15 Feb '11

Feature changed by: Thomas Schmidt (digitaltomm) Feature #72, revision 237 Title: Thank good brainshare is over - Buildservice: Validation + Buildservice: Done Priority Requester: Mandatory Requested by: Thomas Schmidt (digitaltomm) Technical Contact: (Novell) - Partner organization: Stratus + Partner organization: openSUSE.org Description: We are all tired. Feet are hurtingXXX Rejected: Was just a test dummy during feature tool training. dbxml updated to 2.2.13 testing partner notification + new keeper testing partner notification CC testing testing new notification system test References: http://www.pfeifer.com/gerald/gerald.jerus.png Relations: - 55555 (novell/bugzilla/id: 55555) https://bugzilla.novell.com/show_bug.cgi?id=55555 - Test Case (novell/testopia/case: 12345) https://bugzilla.novell.com/tr_show_case.cgi?case_id=12345 Documentation Impact: tremendous Test Case: foo bar external ID: 123 Discussion: #1: Inttools Team (inttools) (2005-11-02 16:06:21) Remove some comments, test utf8 with kate: ???????????? #2: Gerald Pfeifer (geraldpfeifer) (2007-10-25 09:51:22) (reply to #1) Dudle. #17: Andre Duffeck (aduffeck) (2008-05-20 06:59:31) (reply to #2) test #25: Thomas Schmidt (digitaltomm) (2008-07-17 13:37:50) (reply to #17) test +šščřžčřýřáýáí #51: Michael Löffler (michl19) (2009-03-13 14:02:34) (reply to #1) blabla #4: Andre Duffeck (aduffeck) (2007-10-25 14:17:35) webfate test #5: Gerald Pfeifer (geraldpfeifer) (2007-10-26 14:58:39) blub #6: Stephan Kulow (coolo) (2007-11-19 18:20:44) testing if this crashes too #7: Stephan Kulow (coolo) (2007-11-19 18:21:17) (reply to #6) hmm, this works #8: Andre Duffeck (aduffeck) (2008-01-07 19:10:09) test #9: Thomas Schmidt (digitaltomm) (2008-01-07 19:13:11) test #10: Andre Duffeck (aduffeck) (2008-01-07 19:43:19) test #11: Sukanta Dash (sukantadash) (2008-01-30 10:18:52) Test entry added as advised by Gerald. #12: Stephan Kulow (coolo) (2008-02-13 12:45:46) please do not use a product we're currently looking at for such tests #13: Thomas Schmidt (digitaltomm) (2008-02-20 16:14:01) test #14: Christopher Hofmann (cwh) (2008-02-21 19:32:56) Hallo, Mary Lou #15: Matthias Eckermann (mge1512) (2008-02-22 15:26:03) Brainshare will restart soon, ... #16: Andre Duffeck (aduffeck) (2008-03-05 13:20:23) blubb #19: Andre Duffeck (aduffeck) (2008-05-23 11:35:26) test #20: Gerald Pfeifer (geraldpfeifer) (2008-05-24 12:55:27) (reply to #19) Tst. #32: Juergen Weigert (jnweiger) (2008-07-23 11:31:38) (reply to #19) mal dere kleine crash zwischendurch von JW. #33: Juergen Weigert (jnweiger) (2008-07-23 11:47:57) (reply to #32) der war einfach. nochmal crash mit kdebugdialog --fullmode #41: Juergen Weigert (jnweiger) (2008-07-23 15:04:45) (reply to #33) so, und nun nochmal mit [x] enable cache .... #42: Juergen Weigert (jnweiger) (2008-07-23 15:06:09) (reply to #41) viel besser jetzt! #21: Christopher Hofmann (cwh) (2008-06-04 13:27:58) linkszwodreivier #22: Andre Duffeck (aduffeck) (2008-06-11 07:37:50) test #23: Andre Duffeck (aduffeck) (2008-06-11 07:38:18) testzwei #24: Thomas Schmidt (digitaltomm) (2008-06-11 12:15:59) Added attachment (patch_information.xml) #27: Andre Duffeck (aduffeck) (2008-07-17 16:36:20) test #30: Thomas Schmidt (digitaltomm) (2008-07-21 20:09:23) tuut #31: Andre Duffeck (aduffeck) (2008-07-23 11:22:26) test #34: Juergen Weigert (jnweiger) (2008-07-23 14:09:20) noch ein crash! #35: Andre Duffeck (aduffeck) (2008-07-23 14:11:00) blubb #36: Juergen Weigert (jnweiger) (2008-07-23 14:13:25) ghjhghj #37: Juergen Weigert (jnweiger) (2008-07-23 14:14:03) dsfgdfgfhh #38: Andre Duffeck (aduffeck) (2008-07-23 14:15:48) testcrash #39: Andre Duffeck (aduffeck) (2008-07-23 14:20:13) ttttt #40: Andre Duffeck (aduffeck) (2008-07-23 14:28:26) asdf #43: Andre Duffeck (aduffeck) (2008-07-30 07:29:33) test #44: Thomas Roelz (tomout) (2008-07-31 18:17:36) sdgdfhdfhd #45: Gerald Pfeifer (geraldpfeifer) (2008-08-15 15:36:13) (reply to #44) d #46: Andre Duffeck (aduffeck) (2008-08-26 13:56:51) test #47: Andre Duffeck (aduffeck) (2008-11-28 18:18:55) bla #49: Gerald Pfeifer (geraldpfeifer) (2009-02-09 17:16:42) (reply to #47) Nein! #50: Andre Duffeck (aduffeck) (2009-02-25 09:11:25) Changed attachment patch (patch_information.xml) #52: Thomas Schmidt (digitaltomm) (2010-08-11 14:43:33) test #53: Andre Duffeck (aduffeck) (2011-01-31 11:11:33) test -- openSUSE Feature: https://features.opensuse.org/72

1 0

[New: openFATE 311295] Translate openFATE
by fate_noreply＠suse.de 15 Feb '11

15 Feb '11

Feature added by: Anton Reznik (reanxp-rus) Feature #311295, revision 1 Title: Translate openFATE openFATE: Unconfirmed Priority Requester: Important Requested by: Anton Reznik (reanxp-rus) Partner organization: openSUSE.org Description: Hi, guys! Have an idea to translate openFATE on other languages. We can use great tool Transifex http://www.transifex.net/. For example, russian community have experience with work with Transifex (see http://www.transifex.net/projects/p/openSUSE-packages/resource/gnome/ , here we translate descriptions of GNOME packages in openSUSE). What you think about that? -- openSUSE Feature: https://features.opensuse.org/311295

1 0

[New: openFATE 311290] Pulseaudio stutters after almost any sound played
by fate_noreply＠suse.de 14 Feb '11

14 Feb '11

Feature added by: Daniel Stephen (Stephloda) Feature #311290, revision 1 Title: Pulseaudio stutters after almost any sound played openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Daniel Stephen (stephloda) Partner organization: openSUSE.org Description: Almost every time pidgin plays a sound, or after each song I'm listening to, pulseaudio stutters, like it's reopening after each sound. I don't know how to explain this further, is there anyone having the same problem? I have this problem in 11.3, 11.4 milestone 6, 11.4 rc1, kde and gnome. Is there any setting I should change ? -- openSUSE Feature: https://features.opensuse.org/311290

1 1

[New: openFATE 311284] Use .DEB as packaging system
by fate_noreply＠suse.de 14 Feb '11

14 Feb '11

Feature added by: Kim Banga (nomadewolf) Feature #311284, revision 1 Title: Use .DEB as packaging system openSUSE Distribution: Unconfirmed Priority Requester: Mandatory Requested by: Kim Banga (nomadewolf) Partner organization: openSUSE.org Description: There are many things i don't like in SuSE, but what drove me away was the RPM packaging system. It works very well... until you start removing stuff... Can't use an OS with such a flaw, when there an easy solution. -- openSUSE Feature: https://features.opensuse.org/311284

1 6

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 14 Feb '11

14 Feb '11

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305394, revision 44 Title: Move KDE software updates notifications to upstream infrastructure openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:29:01 reject reason: out of resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Rejected by Sascha Peilicke (saschpe) reject reason: 11.3 is out for a while, wasn't done Priority Requester: Important openSUSE-11.4: Unconfirmed Priority Requester: Neutral Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Technical Contact: (Novell) Technical Contact: Stephan Binner (beineri) Partner organization: openSUSE.org Description: As kpackagekit matures, it may be the case that for 11.2 it is mature enough for replacing kupdateapplet. It already implements various aspects of kupdateapplet: * notifications (knotify) using a kded service (which takes care of refreshing too) * single update selection (kpackagekit gui) * uses a upstream client library for communication with PackageKit, which are better than our PackageKit communication code. Scope kpackagekit is meant here only to replace kupdateapplet. There is not relation with YaST here. Open Issues: * tray notification: may require implementing a plasma tray icon * SUSE specific code (smolt, registration, hardware search) * Requires some research how to introduce those extensions in kpackagekit, or move SUSE specific parts out, like another kded service. User experience Should stay the same Dependencies * PackageKit * libpackagekit-qt Contingency Plan In the case kpackagekit is not yet mature enough, the same resources invested now in kupdateapplet can be invested in improving kpackagekit. Otherwise, we can stay with kupdateapplet as a fallback. Relations: - kpackagekit author interview (url: http://polishlinux.org/kde/kpackagekit-interview/) - kpackagekit screenshot (url: http://www.packagekit.org/img/kpk-update.png) Test Case: * new patches should be notified by knotify * user should be able to see update availability * user should be able to see detailed update information, as well as selecting individual updates * user should get informed if the update repositories configuration has a problem * user should be informed of (available) drivers for plugged hardware Business case (Partner benefit): openSUSE.org: Right now software notifications are done using the kupdateapplet, which comes from the opensuse-updater code,(renamed in a non sucessful attept to upstream it). This applet come from a summer of code project, originally done as a zmd client, then evoluted to a zypper client, and now working as a PackageKit client. Sadly, during 10.3 cycle this applet got the feature to select updates individually and other small stuff which turned it into a very complicated piece of code, and started to became a package manager on its own. Later it became the favorite place to plug any kind of notifications, like registration needed, smolt participation, etc, and right now the code is much more complex that it should be (thus taking more maintenance and testing than it should require). This feature has the objective of cleaning up this situation to free resources in this area. With the progress of packagekit and recently, kpackagekit, this should be possible. kpackagekit already implements various of the needed aspects, and therefore it would mean getting rid of in house code for upstream code. Additionally, it would result in a much more consistant user experience as the tools would be similar across distributions. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:24:20) Looks like Duncan is in favor of this. Stano? If you guys are comfortable with the change, I am all for it. But remember, priority #1 is dist-upgrade. #5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 18:00:54) I will evaluate this feature later, we don't know the status of KPackageKit, we have the package and Thomas contributed patches, so only the decision to switch or not to switch is important. Feedback from the KDE team about upstream KDE 4.3 would also be useful. #8: Lubos Lunak (llunak) (2010-03-12 11:40:52) Is it written down somewhere what are the requirements for a KUpdateApplet replacement? What is listed here as 'Testcase' looks incomplete to me. I'd personally prefer if KDE stayed away from this strange PackageKit experiment (in my experience most KUpdateApplet problems are in fact PackageKit problems), and in fact there are some plans upstream to have a KDE wrapper API for packaging (basically like PackageKit, but without the overdesigning and sucking). That would also solve the problem of switching to upstream infrastructure, and that's why I'd like to know the openSUSE requirements. The expected timeframe is KDE SC 4.4 or 4.5, i.e. too late for 11.3. #9: Martin Seidler (pistazienfresser) (2010-06-22 22:31:15) Is the proposal not just like the status with Gnome (in 11.2)? If so I would not recomend that (way of) change: I use the PackageKit Software in Gnome now only for notiforcation and not for making updates as I (and seems so - also many other users in the forums) had often problems that seems to be related to that applet (or simply the use of different applets for updating software). #10: Federico Lucifredi (flucifredi) (2010-06-22 22:50:50) (reply to #9) Bugs on the Gnome PK applet should be fixed -- lets make sure they are reported. -- The proposal here, as I understand it, was to bring about coherence with upstream in the KDE space. That is a valid objective, and quality is something that would be addressed as part of any change. No one is rushing. #11: Martin Seidler (pistazienfresser) (2010-06-28 23:29:07) (reply to #10) Sorry if my first comment seems to be so contra. I have only voted neutral and am not sure. If this proposted way would really work it seems to me desirable (if I could understand it at all ;-) ). If it would lead to a stable and easy way to update (without the possibility to add completely new programms) it may be also make sence to give a normal user access to that update tool (again?). But the developers may also look at possible complications or unreported bugs (just seach for "update" and "applet" or something like this in the forums - maybe that indicates more to replacing kupdateapplet than against?): for example (some of the first results of "update" and "applet" - some of 300): http://forums.opensuse.org/get-help-here/applications/441112-updater-applet… http://forums.opensuse.org/get-help-here/applications/440994-kupdater-apple… http://forums.opensuse.org/get-help-here/applications/440391-problem-updati… http://forums.opensuse.org/get-help-here/applications/440082-opensuse-updat… ... #12: Petar Petrov (siminin) (2010-07-02 09:23:55) (reply to #11) I also have problems with kpackagekit. That's why i uninstall packagekit and install kupdateapplet-zypp and the notification works like a charm. That's why i dislike this proposal and vote it down. + #15: Duncan Mac-Vicar (dmacvicar) (2011-02-14 10:31:49) (reply to #12) + If you have problems, please report concrete bugs. #13: Sascha Peilicke (saschpe) (2010-12-17 09:20:10) Seems like this is done for 11.4 #14: Fahim Murshed (inverbrass) (2011-02-11 19:28:25) Nice -- openSUSE Feature: https://features.opensuse.org/305394

1 0

[New: openFATE 311291] A better workflow for KSUSEInstall
by fate_noreply＠suse.de 13 Feb '11

13 Feb '11

Feature added by: Christopher Yeleighton (yecril71pl) Feature #311291, revision 1 Title: A better workflow for KSUSEInstall openSUSE Infrastructure: Unconfirmed Priority Requester: Important Requested by: Christopher Yeleighton (yecril71pl) Partner organization: openSUSE.org Description: The current workflow for KSUSEInstall for application/x-perl: 1) Look up matches in known repositiories (time-consuming). 2) Offer to add another repository (puzzling). 3) Fail and open in the inherited handler (kwrite) A better workflow: 1) If there is a cached result for application/x-perl, go to 5. 2) Open in the inherited handler (kwrite). 3) Look up matches in known repositories. 4) Cache the results and stop. 5) Display the possibilities and act upon the operatorâs choice. 6) If operator chooses to use the inherited handler, offer to remember the association for future use. Business case (Partner benefit): openSUSE.org: Waiting for all those dialogue boxes to get and digest their data is a "killer app", especially when somebody asks you "show me this". -- openSUSE Feature: https://features.opensuse.org/311291

1 1

[openFATE 311196] Include brcm80211 driver/firmware into openSUSE 11.4
by fate_noreply＠suse.de 11 Feb '11

11 Feb '11

Feature changed by: Martin Seidler (pistazienfresser) Feature #311196, revision 4 Title: Include brcm80211 driver/firmware into openSUSE 11.4 openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Szymon Kowalczyk (fazerxlo) Partner organization: openSUSE.org Description: Broadcom has released opensource drivers for some of new Wireless cards That could be nice to get those cards working out of box in opensuse 11.4 for snupported bcm/b43 devices I read that this will be included into 2.6.37 but I cannot find it in milestone 6 For more info: http://forums.opensuse.org/english/get-technical-help-here/hardware/447485-… http://wireless.kernel.org/en/users/Drivers/brcm80211 Relations: - Include firmware for wireless broadcom devices (even non-oss) like Microsoft true type fonts installer (feature/id: 311198) + - open firmware for some broadcom wifi cards (feature/id: 306619) -- openSUSE Feature: https://features.opensuse.org/311196

1 0

[openFATE 311196] Include brcm80211 driver/firmware into openSUSE 11.4
by fate_noreply＠suse.de 11 Feb '11

11 Feb '11

Feature changed by: Martin Seidler (pistazienfresser) Feature #311196, revision 3 Title: Include brcm80211 driver/firmware into openSUSE 11.4 openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Szymon Kowalczyk (fazerxlo) Partner organization: openSUSE.org Description: Broadcom has released opensource drivers for some of new Wireless cards That could be nice to get those cards working out of box in opensuse 11.4 for snupported bcm/b43 devices I read that this will be included into 2.6.37 but I cannot find it in milestone 6 For more info: http://forums.opensuse.org/english/get-technical-help-here/hardware/447485-… http://wireless.kernel.org/en/users/Drivers/brcm80211 + Relations: + - Include firmware for wireless broadcom devices (even non-oss) like + Microsoft true type fonts installer (feature/id: 311198) -- openSUSE Feature: https://features.opensuse.org/311196

1 0