October 2008 - openSUSE Features - openSUSE Mailing Lists

[openFate 301919] Ship nspluginwrapper to better support 32bit Firefox plugins on 64bit systems
by fate_noreply＠suse.de 23 Oct '08

23 Oct '08

Feature changed by: Thorsten Kukuk <kukuk(a)novell.com> Feature #301919, revision 29 Title: Ship nspluginwrapper to better support 32bit Firefox plugins on 64bit systems openSUSE-10.3: Done Priority Requester: Mandatory Projectmanager: Mandatory SLED-11: Done Priority Requester: Mandatory Projectmanager: Important Archs: i386, x86-64 - SLES-11: Candidate + SLES-11: Rejected by Thorsten Kukuk <kukuk(a)novell.com> + reject date: 2008-10-23 14:51:40 + reject reason: No nspluginviewer for SLES Priority Requester: Mandatory Projectmanager: Important Requested by: Klaus Kämpf <kkaempf(a)novell.com> Partner organization: openSUSE.org Description: As of openSUSE 10.2, components of the Mozilla browser suite are building on 64bit. However, plugin compatibility is suffering (e.g. flash-player not working). The nspluginwrapper (available at freshmeat (http://freshmeat.net/projects/nspluginwrapper) fixes these issues nicely References: https://bugzilla.novell.com/show_bug.cgi?id=229257 Discussion: #1: Andreas Jaeger <aj(a)novell.com> (2007-07-27 10:04:18) We're shipping nspluginwrapper now. Unfortunately it does not handle Java yet. #2: Gary Ekker <gekker(a)novell.com> (2008-05-28 20:34:33) Michael, what would it take to finish this off for 11.1 and SLED11? #3: Stefan Behlert <behlert(a)novell.com> (2008-07-01 23:30:58) (reply to #2) Michael? #6: Gary Ekker <gekker(a)novell.com> (2008-09-08 15:30:29) Michael Wolf: It looks like nspluginwrapper itself needs some love in order to get it to support the java plugin reasonably. See http://gwenole.beauchesne.info/en/blog/2008/07/06/nspluginwrapper_1.1.0, a blog entry written about two months ago by nspluginwrapper's maintainer. #8: Stanislav Brabec <sbrabec(a)novell.com> (2008-09-16 15:23:24) Unless you will explicitly request update to development version 1.1.0 (which supports windowless plugin in Flash 10 and restart plugin after crash) or 1.2.0 (not yet written, should support Java plugin), I would consider this feature as done for both 11.1 and SLED11. #10: Stefan Behlert <behlert(a)novell.com> (2008-10-17 16:13:30) (reply to #8) Ok, based on that closed as done. Change if you disagree.. What's with SLES 11? Thorsten, do you want to ship nspluginwrapper? I doubt it, can we reject? + #11: Thorsten Kukuk <kukuk(a)novell.com> (2008-10-23 14:51:24) (reply to + #10) + No nspluginwrapper for SLES. #9: Thorsten Kukuk <kukuk(a)novell.com> (2008-10-09 15:45:55) What is the status here? There is no late feature request and we are past all deadlines. What do you plan to get this fixed? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301919

1 0

[openFate 302919] Improved argument handling for zypper
by fate_noreply＠suse.de 21 Oct '08

21 Oct '08

Feature changed by: Karl Eichwalder <ke(a)novell.com> Feature #302919, revision 13 Title: Improved argument handling for zypper openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Done Priority Requester: Mandatory SLED-11: Done Priority Requester: Mandatory SLES-11: Done Priority Requester: Mandatory Requested by: Klaus Kämpf <kkaempf(a)novell.com> Partner organization: openSUSE.org Description: Please improve argument handling on the zypper command line. zypper install foo should look for a package named foo and, if no such package exist, do an automatic fallback to a capability. The --name qualifier can be used to prevent this fallback (forces a package name. The --capability qualifier can be used to force a capability. - Specifying versions and operators should also be more flexible (Following the motto be generous in what you accept, and strict in what you send ) zypper in foo-1.2-3 should try to install package foo, version 1.2, release 3. zypper in foo-1.2 should try to install package foo, version 1.2, any release. zypper in foo should try to install package foo, any version, any release. When specifying operators, spaces should be accepted, i.e. zypper in foo = 1.2-3 - Forcing a specific repository could be done by prefixing the package name with the repository alias followed by a colon, i.e. zypper in opensuse:foo - To be discussed on opensuse-softwaremgmt and cross-checked with other tools like smart and yum. Documentation Impact: Please, consider this for the documentation update. + +/- ~/! are in for SLE11 and openSUSE 11.2. Discussion: #1: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-23 11:24:48) zypper improvements. #2: Ján Kupec <jkupec(a)novell.com> (2008-04-14 15:02:32) All of the orginal suggestions are implemented, except for per-package forcing of repositories. Can i mark as done? I also thought of install foo@arch postfix to force specific architecture. There is no libzypp API for per-package forcing of repository or architecture but it's doable in zypper the old (forced) way. Would take only few more hours. #3: Ján Kupec <jkupec(a)novell.com> (2008-04-14 14:58:01) BTW, we've got wildcard support, install/remove in one go using +/- ~/! prefix (+maybe more i cannot recall now) as bonus :O) Details will be added to the man page and wiki later. #4: Ján Kupec <jkupec(a)novell.com> (2008-04-21 13:29:15) All done in zypper 0.11.1 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302919

1 0

[openFate 303527] Resolve dependencies after ignoring package download failure
by fate_noreply＠suse.de 21 Oct '08

21 Oct '08

Feature changed by: Karl Eichwalder <ke(a)novell.com> Feature #303527, revision 18 Title: Resolve dependencies after ignoring package download failure openSUSE-11.1: Done Priority Requester: Desirable Projectmanager: Desirable Requested by: Ján Kupec <jkupec(a)novell.com> Partner organization: openSUSE.org Description: YaST and Zypper should run the solver before resuming installation if download of a package fails and the user chooses to ignore that package. Currently YaST continues withough solving which makes the ignore button useful only if the user knows how the missing package will affect the system. References: https://bugzilla.novell.com/show_bug.cgi?id=340345#c4 http://lists.opensuse.org/zypp-devel/2008-03/msg00025.html Documentation Impact: Check whether this has documentation impact + Thus far not even the ignore button is documented, because we are not + writing reference documentation, but procedure docs. Thus I think we + can drop documentation for this feature. Discussion: #1: Federico Lucifredi <flucifredi(a)novell.com> (2008-06-13 15:13:41) bit of a corner case. #2: Ján Kupec <jkupec(a)novell.com> (2008-06-16 11:44:24) Well, yes. An idea to cover it easily to some extent: let's advice users to run 'zypper verify' (or the YaST equivalent) in such case, after the installation is finished. This will fix hard dependencies. #3: Stanislav Visnovsky <visnov(a)novell.com> (2008-06-24 15:32:30) (reply to #2) Yes, I would just suggest to add a message with instructions for the user. #4: Jiri Srain <jsrain(a)novell.com> (2008-07-11 10:22:19) (reply to #3) That should be pretty simple. #5: Ján Kupec <jkupec(a)novell.com> (2008-09-12 11:09:55) done in zypper, handing over to Lada for YaST #6: Ladislav Slezak <lslezak(a)novell.com> (2008-09-12 16:00:59) (reply to #5) Implemented in yast2-2.17.23. After pressing [Ignore] user is advised to run the Software Management module (sw_single) to verify the system later. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303527

1 0

[openFate 301919] Ship nspluginwrapper to better support 32bit Firefox plugins on 64bit systems
by fate_noreply＠suse.de 17 Oct '08

17 Oct '08

Feature changed by: Stefan Behlert <behlert(a)novell.com> Feature #301919, revision 28 Title: Ship nspluginwrapper to better support 32bit Firefox plugins on 64bit systems openSUSE-10.3: Done Priority Requester: Mandatory Projectmanager: Mandatory - SLED-11: Candidate + SLED-11: Done Priority Requester: Mandatory Projectmanager: Important Archs: i386, x86-64 SLES-11: Candidate Priority Requester: Mandatory Projectmanager: Important Requested by: Klaus Kämpf <kkaempf(a)novell.com> Partner organization: openSUSE.org Description: As of openSUSE 10.2, components of the Mozilla browser suite are building on 64bit. However, plugin compatibility is suffering (e.g. flash-player not working). The nspluginwrapper (available at freshmeat (http://freshmeat.net/projects/nspluginwrapper) fixes these issues nicely References: https://bugzilla.novell.com/show_bug.cgi?id=229257 Discussion: #1: Andreas Jaeger <aj(a)novell.com> (2007-07-27 10:04:18) We're shipping nspluginwrapper now. Unfortunately it does not handle Java yet. #2: Gary Ekker <gekker(a)novell.com> (2008-05-28 20:34:33) Michael, what would it take to finish this off for 11.1 and SLED11? #3: Stefan Behlert <behlert(a)novell.com> (2008-07-01 23:30:58) (reply to #2) Michael? #6: Gary Ekker <gekker(a)novell.com> (2008-09-08 15:30:29) Michael Wolf: It looks like nspluginwrapper itself needs some love in order to get it to support the java plugin reasonably. See http://gwenole.beauchesne.info/en/blog/2008/07/06/nspluginwrapper_1.1.0, a blog entry written about two months ago by nspluginwrapper's maintainer. #8: Stanislav Brabec <sbrabec(a)novell.com> (2008-09-16 15:23:24) Unless you will explicitly request update to development version 1.1.0 (which supports windowless plugin in Flash 10 and restart plugin after crash) or 1.2.0 (not yet written, should support Java plugin), I would consider this feature as done for both 11.1 and SLED11. + #10: Stefan Behlert <behlert(a)novell.com> (2008-10-17 16:13:30) (reply + to #8) + Ok, based on that closed as done. Change if you disagree.. + What's with SLES 11? Thorsten, do you want to ship nspluginwrapper? I + doubt it, can we reject? #9: Thorsten Kukuk <kukuk(a)novell.com> (2008-10-09 15:45:55) What is the status here? There is no late feature request and we are past all deadlines. What do you plan to get this fixed? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301919

1 0

[openFate 302186] zypper needs ability to specify version of package to be manipulated.
by fate_noreply＠suse.de 14 Oct '08

14 Oct '08

Feature changed by: Ján Kupec <jkupec(a)novell.com> Feature #302186, revision 13 Title: zypper needs ability to specify version of package to be manipulated. openSUSE-10.3: Done Priority Requester: Important Projectmanager: Mandatory Requested by: Ján Kupec <jkupec(a)novell.com> + Partner organization: openSUSE.org Description: zypper needs to be able to install/update/remove a specific version of a package, e.g.: $ zypper install libcurl4 =7.16.1-13 Exact syntax needs to be discussed. References: https://bugzilla.novell.com/show_bug.cgi?id=247320 Discussion: #1: Jiri Srain <jsrain(a)novell.com> (2007-05-22 10:34:30) Stano, is the suggested syntax OK with you? For me it sounds good. #2: Ján Kupec <jkupec(a)novell.com> (2007-05-22 11:27:11) A complete syntax of version specification then would be something like: zypper [global-options] < command > [command-options] [resolvable-name [version-specification]] for command: install | remove | update(?) | info | patch-info | search | $the_other_unimplemented version-specification: [relation-op]< version > relation-op: = | > | < | >= | <= (default: =) #3: Stanislav Visnovsky <visnov(a)novell.com> (2007-05-22 11:35:30) (reply to #2) Is this syntax compatible with rug? #4: Ján Kupec <jkupec(a)novell.com> (2007-05-22 12:38:47) (reply to #3) The rug manual doesn't say, so asking rug maintainer to provide the info. #5: Jiri Srain <jsrain(a)novell.com> (2007-06-12 15:48:29) (reply to #4) Answer from Duncan on how ZLM is specifying the version: IIRC you jsut specify something like package-1.0-2 in the cmd line. At least something like that worked when we implemented "best package" feature for ZLM. #6: Jiri Srain <jsrain(a)novell.com> (2007-06-12 15:49:07) (reply to #2) IMO if you want to specify a version to install, you specify exact version and not the version range. #8: Martin Vidner <mvidner(a)novell.com> (2007-07-27 19:45:03) I have implemented (in zypper r 6273) installing by capabilities (Feature 301956), which includes almost what is wanted here, namely zypper {in,rm} 'NAME [OP EDITION]' . I decided not to use NAME-VERSION so far because it seems it would misbehave on packages like dbus-1-x11and java-1_4_2-gcj-compat. #9: Ján Kupec <jkupec(a)novell.com> (2007-08-06 18:36:37) Based on discussion on zypp-devel, I've changed the syntax to NAME[OP (EDITION)] (without spaces) as zypper 0.8.9. Marking as done. NAME-EDITION syntax is not yet implemented, but we should consider that as a rug compatibility feature (covered by FATE #302148) , thus we have time to implement that for SLE-11. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302186

1 0

[openFate 301791] "Report a bug" a-la-Safari for Mozilla Firefox
by fate_noreply＠suse.de 14 Oct '08

14 Oct '08

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

1 0

[openFate 301919] Ship nspluginwrapper to better support 32bit Firefox plugins on 64bit systems
by fate_noreply＠suse.de 09 Oct '08

09 Oct '08

Feature changed by: Thorsten Kukuk <kukuk(a)novell.com> Feature #301919, revision 27 Title: Ship nspluginwrapper to better support 32bit Firefox plugins on 64bit systems openSUSE-10.3: Done Priority Requester: Mandatory Projectmanager: Mandatory SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Important Archs: i386, x86-64 SLES-11: Candidate Priority Requester: Mandatory Projectmanager: Important Requested by: Klaus Kämpf <kkaempf(a)novell.com> Partner organization: openSUSE.org Description: As of openSUSE 10.2, components of the Mozilla browser suite are building on 64bit. However, plugin compatibility is suffering (e.g. flash-player not working). The nspluginwrapper (available at freshmeat (http://freshmeat.net/projects/nspluginwrapper) fixes these issues nicely References: https://bugzilla.novell.com/show_bug.cgi?id=229257 Discussion: #1: Andreas Jaeger <aj(a)novell.com> (2007-07-27 10:04:18) We're shipping nspluginwrapper now. Unfortunately it does not handle Java yet. #2: Gary Ekker <gekker(a)novell.com> (2008-05-28 20:34:33) Michael, what would it take to finish this off for 11.1 and SLED11? #3: Stefan Behlert <behlert(a)novell.com> (2008-07-01 23:30:58) (reply to #2) Michael? #6: Gary Ekker <gekker(a)novell.com> (2008-09-08 15:30:29) Michael Wolf: It looks like nspluginwrapper itself needs some love in order to get it to support the java plugin reasonably. See http://gwenole.beauchesne.info/en/blog/2008/07/06/nspluginwrapper_1.1.0, a blog entry written about two months ago by nspluginwrapper's maintainer. #8: Stanislav Brabec <sbrabec(a)novell.com> (2008-09-16 15:23:24) Unless you will explicitly request update to development version 1.1.0 (which supports windowless plugin in Flash 10 and restart plugin after crash) or 1.2.0 (not yet written, should support Java plugin), I would consider this feature as done for both 11.1 and SLED11. + #9: Thorsten Kukuk <kukuk(a)novell.com> (2008-10-09 15:45:55) + What is the status here? There is no late feature request and we are + past all deadlines. What do you plan to get this fixed? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301919

1 0

[openFate 302923] handle redirection to mirrors robustly
by fate_noreply＠suse.de 01 Oct '08

01 Oct '08

Feature changed by: Peter Poeml <poeml(a)novell.com> Feature #302923, revision 13 Title: handle redirection to mirrors robustly openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-28 15:42:20 reject reason: Out of scope for 11.0 Priority Requester: Neutral openSUSE-11.1: Rejected by Matthias Eckermann <mge(a)novell.com> reject date: 2008-07-22 23:04:50 reject reason: Postponing, will not be ready. Priority Requester: Neutral openSUSE-11.2: New Priority Requester: Neutral SLED-11: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-08 12:13:52 reject reason: Postponing, will not be ready. Priority Requester: Neutral SLES-11: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-08 12:13:49 reject reason: Postponing, will not be ready. Priority Requester: Neutral Requested by: Ján Kupec <jkupec(a)novell.com> Partner organization: openSUSE.org Description: The proposal is to try other mirrors from a mirror list (from the redirector?) if an error occurs on some of the mirrors while providing a file from http/ftp repository. See the references for more details. References: https://bugzilla.novell.com/show_bug.cgi?id=337410 http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00170.html http://en.opensuse.org/Libzypp/Failover http://code.google.com/soc/2008/suse/appinfo.html?csaid=6F1844AB23B67E06 Discussion: #1: Stephan Kulow <coolo(a)novell.com> (2007-11-20 11:15:49) I would be strictly against having an own mirror list. The decision was to go with the redirector (or NCC for SLE) and be done with mirrors. If that does not work, then we have to do this whole thing again, not adding untested work arounds to the product. #2: Stephan Kulow <coolo(a)novell.com> (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag <freitag(a)novell.com> (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag <freitag(a)novell.com> (2008-06-12 10:06:42) I have to revert my statement that I made before in comment #3, this problem is more serious than realised in the first look. First, it should be noted that we do not control mirrors nor we do have the chance to really influence them. That means that if a mirrors decides to not longer mirror or to switch off or whatever, we have to live with it. However if a customer is sticky to a mirror that is not longer available he would not get any packages from it and thus installation or update fails. The worst thing about that is that this seems to happen regularly but we do not realise that because we're not involved. A solution would be to have a list of possible mirrors that is used by the software installation stack to find a working mirror. Peter knows much more here. But I am not sure at the moment if not Yast/zypper already has this functionality in 11.0? + #5: Peter Poeml <poeml(a)novell.com> (2008-10-01 11:58:38) + YaST/zypper in 11.1 will have preliminary support for this. The + essential part of http://en.opensuse.org/Libzypp/Failover has been + implemented during a GSoC project this year. See + http://lists.opensuse.org/zypp-devel/2008-09/msg00142.html for the + status. + There is a number of things left to do, like + * making it the default + * better debuggability - show what it does + * better progress report + * testing + * integration into the install system so it is available during + installation + Further features from the proposal (mirror preference, simultaneous + downloads) are not tackled yet. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302923

1 0