- openSUSE Features

[openFate 305591] Define purpose for each project
by fate_noreply＠suse.de 12 Jan '09

12 Jan '09

Feature changed by: Michal Vyskocil <mvyskocil(a)novell.com> Feature #305591, revision 4 Title: Define purpose for each project Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak (prusnak) + Interested: Michal Vyskocil (mvyskocil) Partner organization: openSUSE.org Description: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00056.html * define purpose for each project, like: * add-on package * fresh packages + libraries (eg. games) * bleeding edge packages (eg. zypp:svn) * backports for older distributions (eg. zypp:Backport) * playground (eg. all home projects) - this sets users expectations - purpose could be indicated by naming conventions, or even better by project flags - purpose must be shown in the search result for this method to work -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305591

1 0

[openFate 305534] f-spot should use sqlite3 instead of sqlite2
by fate_noreply＠suse.de 12 Jan '09

12 Jan '09

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #305534, revision 3 Title: f-spot should use sqlite3 instead of sqlite2 - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Juergen Weigert (jnweiger) + Partner organization: openSUSE.org Description: Currently sqlite2 ist installed per default (at least if user runs gnome). It would be much better to require sqlite3 and to phase out sqlite2 to those applications that really need the old-version- compatibility. f-spot was ported to sqlite3 in version 0.4.2, and supports the latest sqlite-3.6 since version 0.5.0.2. f-spot-0.5.0.3 is shipping with e.g. SLED 11 BETA6 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305534

1 0

[openFate 305542] Installation: Detect TabletPC and select TabletPC pattern
by fate_noreply＠suse.de 12 Jan '09

12 Jan '09

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #305542, revision 4 Title: Installation: Detect TabletPC and select TabletPC pattern openSUSE-11.2: Evaluation Priority Requester: Neutral Requested by: Michael Andres (mlandres) + Partner organization: openSUSE.org Description: As it looks yast2 don't select the TabletPC pattern automatically if the install get started on a TabletPC (as it's done for the laptop pattern and it should be easy to detect a tabletPC since HAL tells it via system.formfactor.subtype = 'tabletpc'). References: https://bugzilla.novell.com/show_bug.cgi?id=449770 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305542

1 0

[openFate 305491] package names should also be binary names
by fate_noreply＠suse.de 10 Jan '09

10 Jan '09

Feature changed by: Gerald Pfeifer <gp(a)novell.com> Feature #305491, revision 28 Title: package names should also be binary names openSUSE-11.2: Evaluation Priority Requester: Desirable SLED-11-SP1 SLES-11-SP1 Requested by: Juergen Weigert (jnweiger) + Interested: Federico Lucifredi (flucifredi) Interested: Kai Dupke (kdupke) Interested: Marcus Kraft (marcuskraft) Interested: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: Many packages providing command line applications do so with commands named different than the package Random examples: install cpuset but call cset; install lvm2 but call lvm; install MPlayer but call mplayer, install MozillaFirefox but call firefox, install NetworkManager-kde but call knetworkmanager; install OpenOffice_org but call soffice/ooffice/oowriter I suggest to create one shell script per package, that is named exactly as the package is named, which tells the user how to use the package (unless a binary with that name already exists). This script could point to existing binaries, print documentation, or simply be a symlink to an existing binary if there is one prominent user callable entry point, whatever makes sense. Discussion: #2: Thorsten Kukuk (kukuk) (2008-11-25 05:58:17) Veto. We decided to name RPMs after the name of the upstream package, especially to be in sync with other distributions and don't confuse ISVs and customers completlty. I don't see any benefit for customers, but only disadvantages for everybody. Between, business case for this very cost-intensiv feature is missing. #3: Thorsten Kukuk (kukuk) (2008-11-25 05:59:18) How would you call "pwdutils"? "useradd"? "userdel"? "passwd"? Split them in 100 little RPMs? #10: Thomas Schmidt (digitaltomm) (2008-11-26 12:00:29) This could be added to the command-not-found tool (http://en.opensuse.org/Scout , don't know whether this is available on SLES). When a command is not found, but scout sees a RPM with exactly this name installed it could display a list of the included binaries. This way no packages would need to be changed, it's only an enhancement to command-not-found. #11: Kai Dupke (kdupke) (2008-11-26 12:43:29) (reply to #10) scout is part of the SLES media. Looks like an answer on how to handle this. Not sure if we install this by default. #14: Pavol Rusnak (prusnak) (2009-01-09 15:56:02) (reply to #11) I and mvyskocil are creators and maintainers of scout. All you need to do is to issue (after installing scout of course): $ scout bin firefox repository | binary | path | package --------------------+---------+----------+---------------- zypp (11.1-oss) | firefox | /usr/bin | MozillaFirefox What else needs to be done? #16: Pavol Rusnak (prusnak) (2009-01-09 15:57:33) (reply to #14) I forgot to note that scout is automatically installed in base system in openSUSE 11.1. #17: Juergen Weigert (jnweiger) (2009-01-09 16:43:41) (reply to #11) Hey, thanks for creating scout. This is very helpful. Currently, I can map from binary to package, by using 'scout bin' This feature is about the reverse, mapping from package to binary. Can this be added to scout? Integration with /usr/bin/command-not-found would be very helpful then. E.g. bash$ MPlayer Package MPlayer includes the following binaries: repository | binary | path | package ---------------------------+---------+----------+--------- zypp (Packman Repository) | mplayer | /usr/bin | MPlayer How do we educate our users about the existance of scout? #19: Pavol Rusnak (prusnak) (2009-01-09 17:30:10) (reply to #17) After discussion with Michal, we'll add -p parameter to each module, which will indicate that package name is provided, not search_term. All modules will benefit from that change, not only "bin", so user could also list all java classes from java package and so on. I'm not quite sure about the command-not-found integration. There are some people who don't like the speed of handler and another extra search will add another fractions of seconds. If user wants that feature, he'll just types: $ scout bin -p MPlayer #15: Michael Loeffler (sprudel24) (2009-01-09 15:58:57) (reply to #10) The Scout way sounds like a good solution. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305491

1 0

[openFate 305491] package names should also be binary names
by fate_noreply＠suse.de 09 Jan '09

09 Jan '09

Feature changed by: Pavol Rusnak <prusnak(a)novell.com> Feature #305491, revision 26 Title: package names should also be binary names openSUSE-11.2: Evaluation Priority Requester: Desirable SLED-11-SP1 SLES-11-SP1 Requested by: Juergen Weigert (jnweiger) Interested: Kai Dupke (kdupke) Interested: Marcus Kraft (marcuskraft) Interested: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: Many packages providing command line applications do so with commands named different than the package Random examples: install cpuset but call cset; install lvm2 but call lvm; install MPlayer but call mplayer, install MozillaFirefox but call firefox, install NetworkManager-kde but call knetworkmanager; install OpenOffice_org but call soffice/ooffice/oowriter I suggest to create one shell script per package, that is named exactly as the package is named, which tells the user how to use the package (unless a binary with that name already exists). This script could point to existing binaries, print documentation, or simply be a symlink to an existing binary if there is one prominent user callable entry point, whatever makes sense. Discussion: #2: Thorsten Kukuk (kukuk) (2008-11-25 05:58:17) Veto. We decided to name RPMs after the name of the upstream package, especially to be in sync with other distributions and don't confuse ISVs and customers completlty. I don't see any benefit for customers, but only disadvantages for everybody. Between, business case for this very cost-intensiv feature is missing. #3: Thorsten Kukuk (kukuk) (2008-11-25 05:59:18) How would you call "pwdutils"? "useradd"? "userdel"? "passwd"? Split them in 100 little RPMs? #10: Thomas Schmidt (digitaltomm) (2008-11-26 12:00:29) This could be added to the command-not-found tool (http://en.opensuse.org/Scout , don't know whether this is available on SLES). When a command is not found, but scout sees a RPM with exactly this name installed it could display a list of the included binaries. This way no packages would need to be changed, it's only an enhancement to command-not-found. #11: Kai Dupke (kdupke) (2008-11-26 12:43:29) (reply to #10) scout is part of the SLES media. Looks like an answer on how to handle this. Not sure if we install this by default. #14: Pavol Rusnak (prusnak) (2009-01-09 15:56:02) (reply to #11) I and mvyskocil are creators and maintainers of scout. All you need to do is to issue (after installing scout of course): $ scout bin firefox repository | binary | path | package --------------------+---------+----------+---------------- zypp (11.1-oss) | firefox | /usr/bin | MozillaFirefox What else needs to be done? #16: Pavol Rusnak (prusnak) (2009-01-09 15:57:33) (reply to #14) I forgot to note that scout is automatically installed in base system in openSUSE 11.1. #17: Juergen Weigert (jnweiger) (2009-01-09 16:43:41) (reply to #11) Hey, thanks for creating scout. This is very helpful. Currently, I can map from binary to package, by using 'scout bin' This feature is about the reverse, mapping from package to binary. Can this be added to scout? Integration with /usr/bin/command-not-found would be very helpful then. E.g. bash$ MPlayer Package MPlayer includes the following binaries: repository | binary | path | package ---------------------------+---------+----------+--------- zypp (Packman Repository) | mplayer | /usr/bin | MPlayer How do we educate our users about the existance of scout? + #19: Pavol Rusnak (prusnak) (2009-01-09 17:30:10) (reply to #17) + After discussion with Michal, we'll add -p parameter to each module, + which will indicate that package name is provided, not search_term. All + modules will benefit from that change, not only "bin", so user could + also list all java classes from java package and so on. + I'm not quite sure about the command-not-found integration. There are + some people who don't like the speed of handler and another extra + search will add another fractions of seconds. If user wants that + feature, he'll just types: + $ scout bin -p MPlayer #15: Michael Loeffler (sprudel24) (2009-01-09 15:58:57) (reply to #10) The Scout way sounds like a good solution. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305491

1 0

[openFate 305491] package names should also be binary names
by fate_noreply＠suse.de 09 Jan '09

09 Jan '09

Feature changed by: Juergen Weigert <jw(a)novell.com> Feature #305491, revision 24 Title: package names should also be binary names openSUSE-11.2: Evaluation Priority Requester: Desirable SLED-11-SP1 SLES-11-SP1 Requested by: Juergen Weigert (jnweiger) Interested: Kai Dupke (kdupke) Interested: Marcus Kraft (marcuskraft) Interested: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: Many packages providing command line applications do so with commands named different than the package Random examples: install cpuset but call cset; install lvm2 but call lvm; install MPlayer but call mplayer, install MozillaFirefox but call firefox, install NetworkManager-kde but call knetworkmanager; install OpenOffice_org but call soffice/ooffice/oowriter I suggest to create one shell script per package, that is named exactly as the package is named, which tells the user how to use the package (unless a binary with that name already exists). This script could point to existing binaries, print documentation, or simply be a symlink to an existing binary if there is one prominent user callable entry point, whatever makes sense. Discussion: #2: Thorsten Kukuk (kukuk) (2008-11-25 05:58:17) Veto. We decided to name RPMs after the name of the upstream package, especially to be in sync with other distributions and don't confuse ISVs and customers completlty. I don't see any benefit for customers, but only disadvantages for everybody. Between, business case for this very cost-intensiv feature is missing. #3: Thorsten Kukuk (kukuk) (2008-11-25 05:59:18) How would you call "pwdutils"? "useradd"? "userdel"? "passwd"? Split them in 100 little RPMs? #10: Thomas Schmidt (digitaltomm) (2008-11-26 12:00:29) This could be added to the command-not-found tool (http://en.opensuse.org/Scout , don't know whether this is available on SLES). When a command is not found, but scout sees a RPM with exactly this name installed it could display a list of the included binaries. This way no packages would need to be changed, it's only an enhancement to command-not-found. #11: Kai Dupke (kdupke) (2008-11-26 12:43:29) (reply to #10) scout is part of the SLES media. Looks like an answer on how to handle this. Not sure if we install this by default. #14: Pavol Rusnak (prusnak) (2009-01-09 15:56:02) (reply to #11) I and mvyskocil are creators and maintainers of scout. All you need to do is to issue (after installing scout of course): $ scout bin firefox repository | binary | path | package --------------------+---------+----------+---------------- zypp (11.1-oss) | firefox | /usr/bin | MozillaFirefox What else needs to be done? #16: Pavol Rusnak (prusnak) (2009-01-09 15:57:33) (reply to #14) I forgot to note that scout is automatically installed in base system in openSUSE 11.1. #17: Juergen Weigert (jnweiger) (2009-01-09 16:43:41) (reply to #11) Hey, thanks for creating scout. This is very helpful. - Currently, I can map from binary to package, by using 'scout bin' This - feature is about the reverse, mapping from package to binary. Can this - be added to scout? + Currently, I can map from binary to package, by using 'scout bin' + This feature is about the reverse, mapping from package to binary. Can + this be added to scout? Integration with /usr/bin/command-not-found would be very helpful then. E.g. - bash$ MPlayer Package MPlayer includes the following binaries: - repository | binary | path | package --------------------------- - +---------+----------+--------- zypp (Packman Repository) | mplayer | - /usr/bin | MPlayer + bash$ MPlayer + Package MPlayer includes the following binaries: + repository | binary | path | package + ---------------------------+---------+----------+--------- + zypp (Packman Repository) | mplayer | /usr/bin | MPlayer How do we educate our users about the existance of scout? #15: Michael Loeffler (sprudel24) (2009-01-09 15:58:57) (reply to #10) The Scout way sounds like a good solution. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305491

1 0

[openFate 303555] Create a home-user-readable partitioning summary
by fate_noreply＠suse.de 09 Jan '09

09 Jan '09

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #303555, revision 7 Title: Create a home-user-readable partitioning summary openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-08 15:38:07 reject reason: Postponing. More important stuff to do. Priority Requester: Important - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Jiri Srain (jsrain) Interested: Arvin Schnell (aschnell) Interested: Katarina Machalkova (kmachalkova) + Partner organization: openSUSE.org Description: The partitoiner installation summary contains all detailed information about the disk changes, however, for home users it is not easily understandable. If we have a workflow prior the partitioning proposal, it will not be that important to contain all detailed information in the proposal. Discussion: #1: Arvin Schnell (aschnell) (2008-03-28 16:27:43) I don't understand the reasoning: If the user doesn't understand the summary in the installation proposal neither can he understand the proposal in the workflow before. If that is the case we have to change both. #2: Jiri Srain (jsrain) (2008-03-31 13:39:55) (reply to #1) You are right, that with current workflow anything that contains less information is bad. However, for 11.1, we should improve the workflow and afterwards we can also simplify the summary. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303555

1 0

[openFate 305491] package names should also be binary names
by fate_noreply＠suse.de 09 Jan '09

09 Jan '09

Feature changed by: Juergen Weigert <jw(a)novell.com> Feature #305491, revision 22 Title: package names should also be binary names openSUSE-11.2: Evaluation Priority Requester: Desirable SLED-11-SP1 SLES-11-SP1 Requested by: Juergen Weigert (jnweiger) Interested: Kai Dupke (kdupke) Interested: Marcus Kraft (marcuskraft) Interested: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: Many packages providing command line applications do so with commands named different than the package Random examples: install cpuset but call cset; install lvm2 but call lvm; install MPlayer but call mplayer, install MozillaFirefox but call firefox, install NetworkManager-kde but call knetworkmanager; install OpenOffice_org but call soffice/ooffice/oowriter I suggest to create one shell script per package, that is named exactly as the package is named, which tells the user how to use the package (unless a binary with that name already exists). This script could point to existing binaries, print documentation, or simply be a symlink to an existing binary if there is one prominent user callable entry point, whatever makes sense. Discussion: #2: Thorsten Kukuk (kukuk) (2008-11-25 05:58:17) Veto. We decided to name RPMs after the name of the upstream package, especially to be in sync with other distributions and don't confuse ISVs and customers completlty. I don't see any benefit for customers, but only disadvantages for everybody. Between, business case for this very cost-intensiv feature is missing. #3: Thorsten Kukuk (kukuk) (2008-11-25 05:59:18) How would you call "pwdutils"? "useradd"? "userdel"? "passwd"? Split them in 100 little RPMs? #10: Thomas Schmidt (digitaltomm) (2008-11-26 12:00:29) This could be added to the command-not-found tool (http://en.opensuse.org/Scout , don't know whether this is available on SLES). When a command is not found, but scout sees a RPM with exactly this name installed it could display a list of the included binaries. This way no packages would need to be changed, it's only an enhancement to command-not-found. #11: Kai Dupke (kdupke) (2008-11-26 12:43:29) (reply to #10) scout is part of the SLES media. Looks like an answer on how to handle this. Not sure if we install this by default. #14: Pavol Rusnak (prusnak) (2009-01-09 15:56:02) (reply to #11) I and mvyskocil are creators and maintainers of scout. All you need to do is to issue (after installing scout of course): $ scout bin firefox repository | binary | path | package --------------------+---------+----------+---------------- zypp (11.1-oss) | firefox | /usr/bin | MozillaFirefox What else needs to be done? #16: Pavol Rusnak (prusnak) (2009-01-09 15:57:33) (reply to #14) I forgot to note that scout is automatically installed in base system in openSUSE 11.1. + #17: Juergen Weigert (jnweiger) (2009-01-09 16:43:41) (reply to #11) + Hey, thanks for creating scout. This is very helpful. + Currently, I can map from binary to package, by using 'scout bin' This + feature is about the reverse, mapping from package to binary. Can this + be added to scout? + Integration with /usr/bin/command-not-found would be very helpful then. + E.g. + bash$ MPlayer Package MPlayer includes the following binaries: + repository | binary | path | package --------------------------- + +---------+----------+--------- zypp (Packman Repository) | mplayer | + /usr/bin | MPlayer + How do we educate our users about the existance of scout? #15: Michael Loeffler (sprudel24) (2009-01-09 15:58:57) (reply to #10) The Scout way sounds like a good solution. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305491

1 0

[openFate 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 09 Jan '09

09 Jan '09

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #302119, revision 31 Title: Load package selector and libzypp only when needed openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-08-01 16:40:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-04-28 13:42:30 reject reason: Did not make it, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-12 14:13:58 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Stefan Hundhammer (sh-sh-sh) Interested: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: The YaST2 UI should load the code for the package selector and libzypp only when needed. Not all applications / YaST2 modules need package selection code, yet for all of them the respective code from the YaST2 UI and libzypp is loaded. Discussion: #1: Stefan Hundhammer (sh-sh-sh) (2007-04-13 18:13:44) In the YaST2 Qt the package management related code is now moved to a separate plugin that is loaded upon demand only if the calling YCP application actually requests a PackageSelector widget. This reduces the memory footprint from 20 MB VmRSS minimum (HelloWorld. ycp) to 18 MB minimum (PackageSelector-empty.ycp). #3: Katarina Machalkova (kmachalkova) (2007-04-16 14:41:35) Stano, do we want this for curses UI as well? If yes, than it's not 'done' ... #4: Stanislav Visnovsky (visnov) (2007-04-16 14:47:02) (reply to #3) Agreed. Reopening for ncurses and possibly gtk+. #5: Jiri Srain (jsrain) (2007-06-13 13:54:26) JP, both Qt and NCurses are done, but GTK is still missing. #6: Stefan Hundhammer (sh-sh-sh) (2007-06-13 15:08:58) Looks like yast2-pkg-bindings are also loaded unconditionally. It shouldn't be too hard to do that with "lazy initialization" like UI built-ins: Postpone loading the Y2Component until it's really needed. #7: Stanislav Visnovsky (visnov) (2007-06-19 15:01:54) (reply to #6) Jiri, if Pkg bindings problem is not addressed, it does not make sense to fix Gtk UI. #8: Jiri Srain (jsrain) (2007-07-18 13:59:50) (reply to #7) Sorry for missing this. Martin, please, solve this for the Pkg bindings. #10: Stanislav Visnovsky (visnov) (2007-11-08 11:38:22) (reply to #9) Please, follow up on this. #11: Martin Vidner (mvidner) (2008-04-10 15:23:51) yast2-perl-bindings-2.16.6 no longer links to libzypp, which means libzypp will not be loaded at the very start of yast (perl still will be loaded, but that is relatively cheap). That helps in some cases, but mostly it only delays loading of libzypp, which occurs as soon as Pkg (or Package) is imported. Now I need to make Pkg lazy. #12: Martin Vidner (mvidner) (2008-04-21 15:32:09) I have it almost working, but got stopped by bug 381917 (https://bugzilla.novell.com/show_bug.cgi?id=381917) : problems with destructors of static objects #13: JP Rosevear (jproseve) (2008-07-21 13:59:18) (reply to #12) Martin, what's the status here? Will we need to do anything explicit in packagekit to get this functionality? #14: Stanislav Visnovsky (visnov) (2008-09-08 16:44:06) (reply to #13) There is nothing regarding packagekit for this feature. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302119

1 0

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

09 Jan '09

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #301791, revision 32 Title: "Report a bug" a-la-Safari for Mozilla Firefox 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 openSUSE-11.1: Rejected by Stefan Behlert <behlert(a)novell.com> reject date: 2008-12-03 14:23:26 reject reason: Nothing done for 11.1 Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Mandatory SLED-11 SLED-11-SP1 Requested by: Guy Lunardi (glunardi) Developer: Michael Wolf (maw) Interested: Federico Lucifredi (flucifredi) Interested: Stanislav Visnovsky (visnov) 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 (jproseve) (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) (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) (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) (2008-05-30 18:27:09) (reply to #3) Not sure yet, but I'll look into it. #6: Gary Ekker (gekker) (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) (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 (sbehlert) (2008-10-14 10:34:08) What's the status here? #9: Stefan Behlert (sbehlert) (2008-10-24 17:23:17) (reply to #8) Gary, Michael? #10: Stefan Behlert (sbehlert) (2008-11-13 23:46:50) Guy, we need to reject this as there was no progress. Gary, could you provide an ECO for that? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301791

1 0