July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306898] Automated Video-Encoding
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature added by: Juergen Weigert (jnweiger) Feature #306898, revision 1 Title: Automated Video-Encoding Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Juergen Weigert (jnweiger) Description: kdeNlive features a batch mode, Its project files are plain XML. We need an application service, that would * take a raw cut DV video file from dvgrab * take number of seconds to trim from begin and end of the DV file * optionally take an additional audio track * configure audio channels mono to stereo, mixdown of additional track * take the text for a title screen * take number of seconds the title screen should be shown (prepended or overlayed) * take a logo graphics (or offer a default openSUSE logo) to be overlayed at the top righthand corner * write out a kdenlive project file, * run kdenlive in batch mode, showing a progress indicator. This could be a simple shell script or a cool web application available on tube.opensuse.org Test Case: The DV video files from LinuxTag still need encoding, so there is plenty material for testing. Use Case: saves us time in post production of our recordings from internal talks and external conferences. Makes the works reproducable, shortens turnaround time. More video coverage gives openSUSE better visibility and transparency. -- openSUSE Feature: https://features.opensuse.org/306898

1 0

[openFATE 305403] Bootloader beep configuration
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305403, revision 16 Title: Bootloader beep configuration + Hackweek IV: Candidate + Priority + Requester: Desirable + Projectmanager: Desirable openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Desirable Requested by: Jiri Srain (jsrain) Description: Allow to configure whether the acoustic signal should be used for installed bootloader. Acoustic signal is valuable for visually impaired people, while it may be disturbing e.g. in libraries. Discussion: #1: Jiri Srain (jsrain) (2008-11-12 15:58:43) Default can be set depending on whether braille display was found or whether text-to-speech in isolinux was used. #2: Stefan Behlert (sbehlert) (2008-11-12 17:15:07) Is this feature meant as 'allow atuomatic setting of'? The beep is afaik already configurable to be 'off'. If not, this would be a bug. #3: Stefan Seyfried (seife) (2008-11-12 18:09:40) Please reject this feature. This is seriously overengineered. The beep now defaults to off int the installed system. If somebody wants to enable it, he can do so with gfxboot --change-config "boot::beep=1" Marco only needs to document that for his customers and everything is fine. Please, no YaST module for that. #4: Jiri Srain (jsrain) (2008-11-13 09:39:44) (reply to #3) It's not about a new module, just about a check box in the bootloader configuration. #5: Jiri Srain (jsrain) (2009-06-01 11:38:11) (reply to #4) Jozo, please, find a reasonable location for the check box. #6: Jozef Uhliarik (juhliarik) (2009-06-25 10:37:14) Steffen how can I obtain info about status of "beep" from gfxboot? I know how to switch on/off option but I need also status. Please let me know. #7: Steffen Winterfeldt (snwint) (2009-06-25 11:40:48) (reply to #6) You can't. If you have an INF file parser, you can run 'gfxboot --show- config' and get the value from there. -- openSUSE Feature: https://features.opensuse.org/305403

1 0

[openFATE 304500] Make storage failures non-fatal
by fate_noreply＠suse.de 15 Jul '09

15 Jul '09

Feature changed by: Greg Riedesel (Gracal) Feature #304500, revision 26 Title: Make storage failures non-fatal openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-29 13:04:58 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:34:12 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Arvin Schnell (aschnell) Description: Currently all storage failures (during step "Prepare Harddisk") are fatal. E.g. if a partition cannot be mounted the installation is aborted. Some failures do not really harm, e.g. if mounting of a Windows partition fails that is not used for the installation. For other failures an really experienced user might fix the problem manually on the console. So for all failures the user should be asked whether the installation should continue. References: https://bugzilla.novell.com/show_bug.cgi?id=382765#c1 https://bugzilla.novell.com/show_bug.cgi?id=397156 https://bugzilla.novell.com/show_bug.cgi?id=402812 https://bugzilla.novell.com/show_bug.cgi?id=438660 https://bugzilla.novell.com/show_bug.cgi?id=520902 Relations: - Installation aborts after error message that NTFS partition can't be mounted (novell/bugzilla/id: 309074) https://bugzilla.novell.com/show_bug.cgi?id=309074 Discussion: #2: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:33:20) Please reject for SLE11/11.1. All resources allocated with mandatory features already. + #6: Greg Riedesel (gracal) (2009-07-15 21:49:09) + When installng openSUSE on a latop with a hybernated Windows parition, + the current behavior will hard-stop the install. In some instances, if + there was a prior openSUSE install, the boot files may have already + been scrubbed when the mount-failure occurs that hard-stops the + install. In this case, the laptop will become unbootable. The only way + around it is to complete the openSUSE install, and explicitly remove + the Windows parititions from fstab as part of the disk-parititioning + dialog. That way the Windows partitions are not mounted during + installation and won't throw an error. -- openSUSE Feature: https://features.opensuse.org/304500

1 0

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

15 Jul '09

Feature changed by: Jan Holesovsky (kendysan) Feature #304879, revision 89 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 + openSUSE-11.2: Candidate 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. #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) Jan, can you comment on #9. As this feature is one of the highest rated ones we should start implementation better sooner than later. #15: Jan Holesovsky (kendysan) (2009-07-14 15:15:21) (reply to #14) We now have a proof of concept KDE4 integration in ooo-build, it will be a part of OOo 3.1.1. So far the theming and the file dialog were ported; also the Oxygen icons for OOo were provided - everything as a community effort. For more information please see the comments 11, 12, 13. #16: Michael Löffler (michl19) (2009-07-15 13:55:55) (reply to #15) Jan, so it looks like we can change the status of this feature into implementation, right? #17: Jan Holesovsky (kendysan) (2009-07-15 14:10:00) (reply to #16) I suppose so, so I changed the state to implementation. Let's evaluate the quality of this later in the beta phase, and reject for SP1 if the quality is poor - as I say, it is still purely community effort. #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 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 15 Jul '09

15 Jul '09

Feature changed by: Jan Holesovsky (kendysan) Feature #304879, revision 88 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. #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) Jan, can you comment on #9. As this feature is one of the highest rated ones we should start implementation better sooner than later. #15: Jan Holesovsky (kendysan) (2009-07-14 15:15:21) (reply to #14) We now have a proof of concept KDE4 integration in ooo-build, it will be a part of OOo 3.1.1. So far the theming and the file dialog were ported; also the Oxygen icons for OOo were provided - everything as a community effort. For more information please see the comments 11, 12, 13. #16: Michael Löffler (michl19) (2009-07-15 13:55:55) (reply to #15) Jan, so it looks like we can change the status of this feature into implementation, right? + #17: Jan Holesovsky (kendysan) (2009-07-15 14:10:00) (reply to #16) + I suppose so, so I changed the state to implementation. Let's evaluate + the quality of this later in the beta phase, and reject for SP1 if the + quality is poor - as I say, it is still purely community effort. #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 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 15 Jul '09

15 Jul '09

Feature changed by: Michael Löffler (michl19) Feature #304879, revision 87 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. #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) Jan, can you comment on #9. As this feature is one of the highest rated ones we should start implementation better sooner than later. #15: Jan Holesovsky (kendysan) (2009-07-14 15:15:21) (reply to #14) We now have a proof of concept KDE4 integration in ooo-build, it will be a part of OOo 3.1.1. So far the theming and the file dialog were ported; also the Oxygen icons for OOo were provided - everything as a community effort. For more information please see the comments 11, 12, 13. + #16: Michael Löffler (michl19) (2009-07-15 13:55:55) (reply to #15) + Jan, so it looks like we can change the status of this feature into + implementation, right? #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 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 15 Jul '09

15 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305503, revision 27 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 <#> #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? + #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? -- openSUSE Feature: https://features.opensuse.org/305503

1 0

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

15 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305503, revision 26 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 <#> #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? -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #303532, revision 27 Title: Reduce size of updates for openSUSE Factory Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter (adriansuse) reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Löffler (michl19) Description: Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant. Discussion: #1: Stephan Kulow (coolo) (2008-03-27 16:48:43) According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them. So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors. #2: Duncan Mac-Vicar (dmacvicar) (2008-04-22 13:28:56) This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today. #3: Duncan Mac-Vicar (dmacvicar) (2008-05-26 17:09:31) ZYpp side is done. The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly. + #7: Andreas Jaeger (a_jaeger) (2009-07-14 21:36:57) (reply to #3) + What is the status of the Build Service side for this? #4: Gerald Pfeifer (geraldpfeifer) (2009-01-03 14:54:00) Opening this up for openSUSE.org. #5: Stephan Kulow (coolo) (2009-01-16 08:24:42) ok, we discussed this a bit further. We plan to throw away builds that are equal to the previous build and publish deltas generated by the build clients if they are not equal. If a build is equal is to be defined, for now it's a shell script that checks various properties - and works acceptable for now. I rebuild a good portion of 11.1 without further changes and get 7345 binary rpms (including all subpackages). 5666 are considered equal by my current script (based on work by Michael Matz). And many of other packages are possible to fix, so they are equal too. So this gives for uneffected rebuilds a huge reduction of updates. The kernels and kmps are currently seen as !equal after an uneffected rebuild as they put the %release (rebuild counter) in many places. Not sure how much the script should work around such cases. But even for those the download size would reduce: kernel-default.i586 (with base and extra): 25.7MB to download deltas of it: 6.7MB (I think the kernel puts a lot of "rebuild on" info in the code) #6: Piotrek Juzwiak (benderbendingrodriguez) (2009-06-17 17:29:42) As an addition to that it would be great if the older package would stay until the second rebuild so that if something breaks we could go back to the previous version and report that something's wrong with the new one. -- openSUSE Feature: https://features.opensuse.org/303532

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository exists
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 18 Title: zypper: dist upgrade could error out if more than one repository exists - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). + #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) + OK, so this should not be too much work. So to sum it up: + * zypper: show a warning in 'dup' if there are multiple base repos with + different CPEids enabled. + * metadata: check/include the CPEid in product metadata (who should do + this?) -- openSUSE Feature: https://features.opensuse.org/305553

1 0