May 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305301] Central Regulatory Domain Agent (for 802.11)
by fate_noreply＠suse.de 27 May '10

27 May '10

Feature changed by: Stefan Behlert (sbehlert) Feature #305301, revision 42 Title: Central Regulatory Domain Agent (for 802.11) openSUSE-11.2: Rejected by Will Stephenson (cthiel1) reject date: 2009-10-27 16:08:49 reject reason: not done for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory + Projectmanager: Mandatory Requested by: Vladimir Botka (vbotka) Developer: (Novell) 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 Relations: - wpa_supplicant in factory seems to ignore an country=DE setting in its config (novell/bugzilla/id: 537708) https://bugzilla.novell.com/show_bug.cgi?id=537708 - switch nl80211 wpa_supplicant driver in ifup-wireless for WIRELESS_REGULATORY_DOMAIN support (novell/bugzilla/id: 585802) https://bugzilla.novell.com/show_bug.cgi?id=585802 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?) #7: Marius Tomaschewski (mtomaschewski) (2009-06-08 11:27:49) We've already another enhancement bugs for sysconfig/wireless... so let's just add it for 11.2. Helmut, let's speak in the next days about the requirements on the sysconfig side (I guess it is just one optional variable) and add this together with the another enhancements. Michal (yast2 network) requires the sysconfig support to implement it on the yast2 side. #11: Marius Tomaschewski (mtomaschewski) (2009-09-08 15:56:43) (reply to #9) Let's define the sysconfig ifcfg -file variable as: WIRELESS_REGULATORY_DOMAIN='00' The '00' value is the ISO / IEC 3166 alpha2 country code as used in the regdb / wpa_supplicant / iw tool. The _sysconfig_ default is '' , that is empty string. #12: Marius Tomaschewski (mtomaschewski) (2009-09-08 16:39:46) (reply to #11) Hmm... it looks like the reg domain is a global and not a per-interface setting, in iw: reg set <ISO/IEC 3166-1 alpha2> reg get this means it has to go to network/config and not into ifcfg file. Is this correct? #15: Jiri Benc (jbenc) (2009-09-09 13:23:09) (reply to #12) Yes, this is a system-wide setting. On purpose, you don't usually have you computer in two different regulatory zones ;-) I don't see what's the problem with using the timezone setting, though. Yes, it would require a translation table (to map e.g. Europe/Prague to CZ), but other than that, it should provide all the information we need: in what country we are located. #16: Marius Tomaschewski (mtomaschewski) (2009-09-09 13:53:06) (reply to #15) OK, thanks for verifying this! I don't have any problem when yast2 is setting the WIRELESS_REGULATORY_DOMAIN='CZ' value based on the TIMEZONE='Europe/Prague' setting by default / as preselection. But I need the correct, valid and final value for the utilities and don't want to provide any translation table and waste e.g. boot time in sysconfig. It also makes sense to check that the alpha-2 code is in the wireless-regdb and perhaps propose an another value if possible or reject & reset it -- in sysconfig it is too late to do this or ask the user what to do. The package implementing this is in Base:System/sysconfig project and goes to factory today. When iw reg set is used, the value is applied correctly to the crda/kernel. When it is set via wpa_supplicant config, there is no attempt to set it visible in udev -- seems to be a wpa_supplicant bug -> bugzilla. #17: Jiri Benc (jbenc) (2009-09-09 14:01:13) (reply to #16) Yes, all of that makes sense to me. #18: Vladimir Botka (vbotka) (2009-09-09 20:34:24) (reply to #16) Part of the project http://linuxwireless.org/en/developers/Documentation/nl80211 is also an wpa_supplicant with -Dnl80211 which will solves this problem. The yast module can set both the WIRELESS_REGULATORY_DOMAIN in sysconfig and country= in wpa_supplicant.conf. #20: Marius Tomaschewski (mtomaschewski) (2009-09-09 22:40:21) (reply to #18) Stop :-) sysconfg / ifup is not using /etc/.../wpa_supplicant.conf -- it generates one per interface from network/config and network/ifcfg* settings. So just set the WIRELESS_REGULATORY_DOMAIN, ifup-wireless will add the (expanded) "country=$WIRELESS_REGULATORY_DOMAIN" statement to the generated wpa_supplicant config. #19: Vladimir Botka (vbotka) (2009-09-09 21:34:26) (reply to #16) The new nl80211 extension is already available in Factory. # wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -i wlan0 -dd - Dnl80211 Initializing interface 'wlan0' conf '/etc/wpa_supplicant/wpa_supplicant.conf' driver 'nl80211' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant/wpa_supplicant.conf' -> '/etc/wpa_supplicant/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant/wpa_supplicant.conf' country='CZ' #21: Marius Tomaschewski (mtomaschewski) (2009-09-09 22:42:34) (reply to #19) Yes I know already about the new driver. Question is if we can switch to use this driver already. Let's continue with the driver details in bugzilla. #22: Marius Tomaschewski (mtomaschewski) (2009-10-02 08:52:57) FYI: The sysconfig-0.72.4 version in openSUSE:Factory / 11.2 implements this feature. It provides the WIRELESS_REGULATORY_DOMAIN variable and adds it to the per-interface wpa_supplicant.conf as well as sets it via iw command in case of old (iwconfig) setup. It does not change to the new nl80211 driver (or another one supporting it) by default, the user has to set WIRELESS_WPA_DRIVER="nl80211" per interface or wpa_supplicant will ignore it. #25: Jiri Benc (jbenc) (2009-11-04 11:56:30) Opening for 11.3 and setting as mandatory for requester, as without the feature wifi cards are not fully usable outside of the US (and in some cases not even there). #26: Marius Tomaschewski (mtomaschewski) (2010-03-05 15:07:43) (reply to #25) Thanks! I've created bug 585802 to switch to the new nl80211 wpa_supplicant driver as default in ifup-wireless, except in cases where we know that it does not work. #27: Vladimir Botka (vbotka) (2010-05-18 20:22:08) crda and wireless-regdb packages are available and functional in 11.3 . New nl80211 extension must be used to set the country. -- openSUSE Feature: https://features.opensuse.org/305301

1 0

[New: openFATE 309593] Build SLEPOS appliance images for branch and admin server
by fate_noreply＠suse.de 25 May '10

25 May '10

Feature added by: Joachim Werner (joachimwerner) Feature #309593, revision 1 Title: Build SLEPOS appliance images for branch and admin server Requested by: Joachim Werner (joachimwerner) Description: Use SUSE Studio to build ready-to-run appliance versions of the SLEPOS branch and admin servers. This is for somebody who would like to learn more about working with SUSE Studio and is looking for real-life useful appliance targets. What makes SLEPOS a bit more challenging than building a plain SLES or SLED appliance is that there's not only clicking the right package selection but also a few configuration steps that should either be pre-configured in the appliance or run automatically the first time the appliance is started. -- openSUSE Feature: https://features.opensuse.org/309593

1 0

[New: openFATE 309351] osc multiple package submit request
by fate_noreply＠suse.de 25 May '10

25 May '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #309351, revision 1 Title: osc multiple package submit request Buildservice: New Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Description: It shall become easy to submit multiple packages within one request with osc. osc may get also a mode to detect all packages with changes in a certain project and creates one request. There is already some first code support in osc for this (osc sr in a project directory). -- openSUSE Feature: https://features.opensuse.org/309351

1 2

[New: openFATE 309580] Push Server
by fate_noreply＠suse.de 25 May '10

25 May '10

Feature added by: Alex Chun Yin Lau (allau) Feature #309580, revision 1 Title: Push Server Requested by: Alex Chun Yin Lau (allau) Partner organization: openSUSE.org Description: I've been thinking about this idea for some time now. And there are couple reasons that I like this idea, but instead of telling you the reason why I like it. First of all I need define what I mean by Remote Dbus? As a matter of fact, I don't really know what to call it at the beginning with, I kind of demo it in the GnomeSummit as the future desktop combine with web service. You can call it WebRPC or PushBaseMessaging etc. And here is the definition of it and maybe you can help me naming it. First of all, it can reduce the server bandwidth usage by send information just to the client who is interested and login. By logging in mean you are actually holding a active session in the server. Here is the scenario, our web server want to tell the user that it is going into maintenance mode for an hour. Traditionally you will send out a system wide email to all user and notify them. However, it is kind of like UDP, when the user is not actually using or planning on using within that specific time frame. This email almost act like a spam. And even worst is when the user login to their email account after the fact, this event already expired and it really waste a lot of bandwidth. This specific protocol should allow you to let the server send the message to the client actively interested in this topic ( kind of like twitter) instead of passively subscripted by the client itself. Second key idea is from the client side. This service can send message from the server and no need the client to pull, which fit the need of reduce network traffic and power consumption. It will greatly improve the battery consumption for different handle client. If you compare current technology that mostly fit our desktop nowaday, you will see lot of pulling and no way to let the device / client going to sleep or idle. With a server active pushing message to the client, we can save not only the bandwidth and the power for the client, but the server can also have reduce load by having lesser hit. Third key idea is unlike the web service, there will not be any type checking and interface definition. Client know where to call if they know. What to call if they know and How does it return if they know. Meaning when then client starting a call to the server for a service, the client need know the uri ahead of time, know the interface ahead of time and parameter in/out ready ahead of time. If something go wrong, it just goes wrong. No need for error checking over head. Use Case: You subscript to the push service and when there is information that you interested, server will push to you instead of pulling from the client. Business case (Partner benefit): openSUSE.org: 1) Reduce server side bandwidth 2) Reduce client side pulling 3) Save battery life. -- openSUSE Feature: https://features.opensuse.org/309580

1 1

[New: openFATE 308601] Drop glib/gtk/gnome 1.x stack
by fate_noreply＠suse.de 23 May '10

23 May '10

Feature added by: Vincent Untz (vuntz) Feature #308601, revision 1 Title: Drop glib/gtk/gnome 1.x stack openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Description: We still ship the glib/gtk/gnome 1.x stack, but it's so old that really nothing maintained should still use it. And it's not clear whether we have a good security maintenance for this stack... So let's try to remove this for 11.3. -- openSUSE Feature: https://features.opensuse.org/308601

1 5

[openFATE 308802] History for project and package _meta file changes.
by fate_noreply＠suse.de 21 May '10

21 May '10

Feature changed by: Adrian Schröter (adrianSuSE) Feature #308802, revision 12 Title: History for project and package _meta file changes. - Buildservice: Evaluation + Buildservice: Done Priority Requester: Desirable Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Requested by: Michal Vyskocil (mvyskocil) Developer: (Novell) Description: Changing of a maintainer is completely silent - there is no tracking of changes and no reminder about it (and no possibility of them). When some project maintainer uses a script to mass change something and it has a bug, then we can simply lose the information (the real life example should be in ). So BS as a non reliable source of maintainerhip information. There should be a tracking of changes and notifications about it. In general all metadata changes should be tracked and changes would be notified. Discussion: #1: Michal Vyskocil (mvyskocil) (2010-01-18 09:27:32) The base problem is that we may not lose the internal Novell responsilbe person for maintained packages. So this feature is very close with the FATE#308774 (Ensure that each L3-supported package has a single Novell bugowner) and also FATE#308793 (Versioned History for Roles and Attributes). #2: Adrian Schröter (adriansuse) (2010-01-21 12:29:07) this are acutually two features: * notification via hermes on maintainer change * history for project an package meta data. I choice option two for this feature ;) #3: Dirk Mueller (dirkmueller) (2010-01-21 16:48:51) (reply to #2) I added 308868 for the notification part #4: Adrian Schröter (adriansuse) (2010-02-19 11:01:18) (reply to #2) Marked as important for next (2.0) release. + #5: Adrian Schröter (adriansuse) (2010-05-21 21:54:25) + We have now a history for meta data in the backend. Access via api is + possible, also checkout of old version via osc. We may still need to + improve the history logging. -- openSUSE Feature: https://features.opensuse.org/308802

1 0

[New: openFATE 308844] rcs: not an RCS ...
by fate_noreply＠suse.de 21 May '10

21 May '10

Feature added by: Michael Meeks (michael_meeks) Feature #308844, revision 1 Title: rcs: not an RCS ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. -- openSUSE Feature: https://features.opensuse.org/308844

1 9

[New: openFATE 308757] Build Cycle Dependencies must be accessable in api and webui
by fate_noreply＠suse.de 21 May '10

21 May '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #308757, revision 1 Title: Build Cycle Dependencies must be accessable in api and webui Buildservice: New Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Description: The build dependency cycles of packages are not stored to disk and requestable via api atm. -- openSUSE Feature: https://features.opensuse.org/308757

1 4

[New: openFATE 309578] Better maintenance of src.rpm changes
by fate_noreply＠suse.de 21 May '10

21 May '10

Feature added by: Michal Vyskocil (mvyskocil) Feature #309578, revision 1 Title: Better maintenance of src.rpm changes Requested by: Michal Vyskocil (mvyskocil) Partner organization: openSUSE.org Description: During a SUSE development, we are often using upstream source rpms. The most notable example is jpackage.org - a source of almost every of our Java package. But importing of jpackage.org src.rpm we create a fork of this package and it is not possible to maintain our and future upstream changes. Everything needs to be done manually, which is horribly slow and also error prone apporach. There is a better solution based on patch queues - SUSE changes are considered as a set of patches on top of the upstream sources. This method has many advantages - like sharing of our changes with upstream is piece of cake, updating to the new upstream version is simple - just pop all patches and try to recreate them to newest version. upg is the tool try to smoothly intergrate three different systems into one - osc, git and stg to make this concept easy to use. It manages patches using stg, it is well integrated into BuildService using osc and comes with a few interesting concepts, which will make work with patches more reasonable: * scratches - patches created by simple script - they are never "popped", simply recreated again, so they never failed * heuristics - sometimes patches fails only because PatchXY: number is changed in new upstream version, so upg would be able to fix that * changes - it's a pain for each versioning system, but upg deal with it and try to have them in a good state What is done: upg already exists in very raw version with a basic concept implemented, tested and working (netbeans 6.8 update has been done using this tool). What needs to be done: A public release, implemented configuration system, more heuristics and add more tests than now - yes and also some documentation will be necessary Business case (Partner benefit): openSUSE.org: Why do we want this? Well the most probable user is me - I'll use it for a big automation of my work with a jpackage.org. But this tool can also change a concept of rpm packaging as it is done today. Nowadays we maintain a lot of packages in different code streams and projects, because every one have their own processes, needs and requirements. Using this approach we might be able to reuse an effort of some other projects and be up-to-date with them. Also will be able to share our improvements more easily. The second big use case of this system is an ability of maintain our own forks (or branches) of packages improved for specific purposes. -- openSUSE Feature: https://features.opensuse.org/309578

1 2

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 21 May '10

21 May '10

Feature changed by: Ján Kupec (jkupec) Feature #305503, revision 40 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Done Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Developer: (Novell) Developer: (Novell) 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 <#> #11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8) Please re-think about introducing another term ( fix ), we already have * update * upgrade * patch #12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11) What i try to achieve is to have a way to install the patches fixing the issues and a way to list them (issue number & patch name & (patch) description), search in them. The other alternatives i considered were: $ zypper patch [--bugzilla #] [--cve #] $ zypper list-patches --issues [string] The first command looks nice, but i don't know what to use to list/search the issues - the list-patches command does not seem right to me - looks more like it deserved a new command. $ zypper install [--bugzilla #] [--cve #] $ zypper search --issues [string] In this case, like in the 'list-patches --issues' case, the search command would either need to radically change its output, or user would need to call 'zypper patch-info the_found_patch' to get the patch description. Any other ideas? Why is having a new command a bad thing (esp. compared to having new options in the existing commands)? BTW: (We don't have 'upgrade' :O) #13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12) Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article? * http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ (http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/) * http://linux.die.net/man/8/yum-security (http://linux.die.net/man/8/yum-security) #14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13) 'zypper update' does not work with patches. 'zypper patch' looks to me like better candidate for new --bz or --cve options. yum does not make difference between these two. The yum plugin also adds a new command (list-sec), which was Klaus' objection. #15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14) Well, my objection is the new term 'fix' besides 'update' and 'patch' and will confuse people. It should be an option to "list" or "list-patches" imho #16: Ján Kupec (jkupec) (2009-07-07 16:16:12) (reply to #15) OK, so far the following looks like a candidate (taken yum into account as well): # to install a fix $ zypper patch [--bz #] [--cve #] [--any-other #] # to list available needed fixes (issue-number, patchname-version, category, description) # all $ zypper list-patches --issues # matching a substring ("CVE", number, or any) $ zypper list-patches --issues foo # only CVEs/bugzillas $ zypper list-patches [--cve] [--bz] #17: Ján Kupec (jkupec) (2009-07-15 09:24:34) Done in zypper. You can fetch zypper 1.2.2 from home:jkupec:Factory to try and let me know what you think. New options in lp and patch commands: $ zypper help lp -b, --bugzilla[=#] List needed patches for Bugzilla issues. --cve[=#] List needed patches for CVE issues. --issues[=string] Look for issues matching the specified string. -a, --all List all patches, not only the needed ones. $ zypper help patch patch [options] -b, --bugzilla # Install patch fixing the specified bugzilla issue. --cve # Install patch fixing the specified CVE issue. --bz works, too. Can this feature be closed, or we'll close it after the repo metadata have the CVE references? #25: brodie brodie (brodie31k) (2010-04-16 20:11:58) (reply to #17) The listing packages by issues is great, but why is there no coredsponding --issue option for the for zypper update? Does not seem to make sense that you can list packages by issue, but not then update then by issue. + #26: Ján Kupec (jkupec) (2010-05-21 12:51:47) (reply to #25) + Look at c#17 more closely: it's 'list-patches' to list them and 'patch' + to install them. 'list-updates' and 'update' is a different approach to + updating. You can find more info in zypper's man page and wiki. #18: Ján Kupec (jkupec) (2009-07-15 09:30:38) One more thing that crossed my mind when looking at the yum article http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ They seem to be able to associate issue numbers with spcecific packages. I'm not sure if this is because they just avoid issuing updates with plenty of packages in single <update> tags, like we often do? #19: Christoph Thiel (cthiel1) (2009-07-16 11:33:39) (reply to #18) Rudi, is autobuild planning to adding additional information to the metadata? #20: Ruediger Oertel (oertel) (2009-08-26 12:12:41) (reply to #19) Not as the driving element. But we usually implement these extensions when maintenance and zypp development request them. #21: Ján Kupec (jkupec) (2009-09-21 10:58:06) (reply to #20) Well, we would like CVEs in the patches :O) So i repeat my question: Can this feature be closed, or we'll close it after the repo metadata have the CVE references? #22: Ruediger Oertel (oertel) (2009-11-18 16:27:31) I just need the URL to enter as CVE reference to complete my side. #23: Ruediger Oertel (oertel) (2009-11-18 17:19:01) (reply to #22) got the url from dirk in bnc#556293. my side is implemented now. #24: Ján Kupec (jkupec) (2009-11-19 12:58:35) (reply to #23) So we have it in zypper, we have it in metadata. Done. -- openSUSE Feature: https://features.opensuse.org/305503

1 0