July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 03 Jul '09

03 Jul '09

Feature changed by: Marcus Meissner (msmeissn) Feature #305503, revision 17 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) Also, i noticed in 11.1 updates repository, that many bugs have a CVE, but it's only in the description, not in the 'reference' metadata. Only bugzilla is in 'reference'. Do we want to address this? + #10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9) + we are not emitting it yet. this also needs to be done :/ #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 03 Jul '09

03 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305503, revision 16 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? + #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) + Also, i noticed in 11.1 updates repository, that many bugs have a CVE, + but it's only in the description, not in the 'reference' metadata. Only + bugzilla is in 'reference'. Do we want to address this? #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 03 Jul '09

03 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305503, revision 15 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? + #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) + Suggestion how the commands could look like: + $ zypper fix --search [string] + $ zypper fix --bugzilla <#> + $ zypper fix --cve <#> -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 03 Jul '09

03 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305503, revision 14 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: + - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. + #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) + Thanx! I have a question about the reference types. What types do we + support? in updateinfo.rnc (see references) i only see bugzilla and + cve + Do we want separate options for all supported types, like yum has? -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 306640] Enhancing po-mode (Emacs Add-On)
by fate_noreply＠suse.de 03 Jul '09

03 Jul '09

Feature added by: Karl Eichwalder (keichwa) Feature #306640, revision 1 Title: Enhancing po-mode (Emacs Add-On) Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Karl Eichwalder (keichwa) Description: This is part of "Make Emacs a Better Translation Tool" started during the hack week in June 2007. For more information, see http://idea.opensuse.org/content/ideas/make-emacs-a-better-translation-tool… -- openSUSE Feature: https://features.opensuse.org/306640

1 0

[openFATE 306620] Possibility to skip filesystem check at startup
by fate_noreply＠suse.de 02 Jul '09

02 Jul '09

Feature added by: Dominik Grafenhofer (dgrafenhofer) Feature #306620, revision 1 Title: Possibility to skip filesystem check at startup openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dominik Grafenhofer (dgrafenhofer) Description: Periodic filesystem checks at startup are important, but take a lot of time. For desktop users it is sometimes importent to startup their computer really fast (e.g. when giving a presentation). It is a nuissance, that these filesystem checks cannot be easily skipped (and postponed for the next startup) like under Ubuntu. Analogous to Ubuntu Linux I therefore propose to have a mechanism in place to stop a (periodic) filesystem check at startup when the escape key is pressed during the check. -- openSUSE Feature: https://features.opensuse.org/306620

1 1

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

01 Jul '09

Feature changed by: Jared Allen (jpallen) Feature #305623, revision 10 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. Discussion: #5: Jiri Srain (jsrain) (2009-06-02 11:43:54) The only dependency I found is the yast2-control-center-gnome package; Jared, can you handle it? + #6: Jared Allen (jpallen) (2009-07-01 17:09:54) (reply to #5) + Yes, we'll need to look into an alternative. I'm not sure that + PolicyKit itself is enough to replace the functionality of gnomesu. + I'll ask Gabriel to look into this. -- openSUSE Feature: https://features.opensuse.org/305623

1 0

[openFATE 305299] Port kio_fuse to KDE4
by fate_noreply＠suse.de 01 Jul '09

01 Jul '09

Feature changed by: Todd R (TheBlackCat) Feature #305299, revision 7 Title: Port kio_fuse to KDE4 openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Desirable Requested by: JP Rosevear (jproseve) Description: Enable kio mounted file systems to be exposed via fuse by getting kio_fuse to work on KDE4. Relations: - Integrate fuse based permanent mounting (feature/id: 300613) Discussion: #1: Michael Löffler (michl19) (2009-06-05 14:34:38) JP, what would be the benefit? Please add to the description. + #2: Todd R (theblackcat) (2009-07-01 23:31:24) + I think the main benefit would be that applications that do not support + kio (most non-KDE apps) would still be able to see the + files. Presently this is not possible. -- openSUSE Feature: https://features.opensuse.org/305299

1 0

[openFATE 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 01 Jul '09

01 Jul '09

Feature changed by: Stephan Binner (Beineri) Feature #304879, revision 81 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Use Case: I will find this is really usefull. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 KDE4 integration done by the kubuntu boys + #13: Stephan Binner (beineri) (2009-07-01 20:17:03) (reply to #12) + An early OpenOffice_org-kde4 package exists in Factory so this should + be change to Candidate. -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 303394] arptables support
by fate_noreply＠suse.de 01 Jul '09

01 Jul '09

Feature changed by: Marcus Meissner (msmeissn) Feature #303394, revision 14 Title: arptables support openSUSE-11.1: Done Priority Requester: Desirable Projectmanager: Desirable Requested by: Matthias Eckermann (mge1512) Description: The kernel supports ARP firewalling (firewalling based on ARP addresses and mangling of ARP addresses) for hosts and bridges since quite some time. But we don't have a package for the arptables package to configure it on the command line. ARP firewalling would be a nice feature for SLES11. I actually think we used to have one in 10.1 (http://www.novell.com/products/linuxpackages/suselinux/arptables.html) but 10.3 has it dropped. http://ebtables.sourceforge.net/ Discussion: #6: Marius Tomaschewski (mtomaschewski) (2008-09-05 16:31:51) Packaged arptables_jf 0.0.8 as arptables in BETA. Requested "undrop" in pdb. + #7: Marcus Meissner (msmeissn) (2009-07-01 19:40:55) + reopened for community screening ... seems not done? -- openSUSE Feature: https://features.opensuse.org/303394

1 0