September 2008 - openSUSE Features - openSUSE Mailing Lists

[openFate 305131] connecting an unpartitioned disk should bring up a partitioner
by fate_noreply＠suse.de 25 Sep '08

25 Sep '08

Feature changed by: Danny Kukawka <dkukawka(a)novell.com> Feature #305131, revision 5 Title: connecting an unpartitioned disk should bring up a partitioner openSUSE-11.1: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Juergen Weigert <jw(a)novell.com> Partner organization: openSUSE.org Description: USB or Firewire disks can be easily connected at runtime. For a newly bought disk, nothing happens, when it is connected for the first time. Unlike e.g. a USB-Memory-stick, which immediatly opens a filebrowser, when first connected. The technical difference is, disks come unformatted, USB-sticks come formatted. We should recognize this difference and pop up an easy to use partitioner. Discussion: #1: Stefan Behlert <behlert(a)novell.com> (2008-08-18 12:52:42) Christian, would it be possible to use HAL or something like that to pop-up the Yast-partitioner? I don't think we will get a stripped down partitioner at the moment for 11.1. + #2: Danny Kukawka <dkukawka(a)novell.com> (2008-09-25 18:48:47) (reply to + #1) + No, HAL can't and shouldn't popup anything. It's up to the desktop (e.g. + suse-plugger) to check the HAL events if a device get added to the + machine and react on this. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305131

1 0

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

16 Sep '08

Feature changed by: Stanislav Brabec <sbrabec(a)novell.com> Feature #301919, revision 26 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301919

1 0

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

12 Sep '08

Feature changed by: Ladislav Slezak <lslezak(a)novell.com> Feature #303527, revision 17 Title: Resolve dependencies after ignoring package download failure - openSUSE-11.1: Candidate + 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 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 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 12 Sep '08

12 Sep '08

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #302119, revision 30 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: Evaluation + 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 + Priority + Requester: Desirable Requested by: Stefan Hundhammer <sh(a)novell.com> 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(a)novell.com> (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(a)novell.com> (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(a)novell.com> (2007-04-16 14:47:02) (reply to #3) Agreed. Reopening for ncurses and possibly gtk+. #5: Jiri Srain <jsrain(a)novell.com> (2007-06-13 13:54:26) JP, both Qt and NCurses are done, but GTK is still missing. #6: Stefan Hundhammer <sh(a)novell.com> (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(a)novell.com> (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(a)novell.com> (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(a)novell.com> (2007-11-08 11:38:22) (reply to #9) Please, follow up on this. #11: Martin Vidner <mvidner(a)novell.com> (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(a)novell.com> (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 <jpr(a)novell.com> (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(a)novell.com> (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 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 12 Sep '08

12 Sep '08

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #303517, revision 22 Title: Configure a cronjob for refreshing repositories - openSUSE-11.1: Evaluation + openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> + reject date: 2008-09-12 14:12:10 + reject reason: Postponing. Priority Requester: Desirable - Projectmanager: Mandatory + Projectmanager: Important + openSUSE-11.2: New + Priority + Requester: Desirable Requested by: Ladislav Slezak <lslezak(a)novell.com> Partner organization: openSUSE.org Description: Autorefresh configured repositories at certain times, this could be on certain days, or time of day, etc. A mockup and more details are in https://bugzilla.novell.com/show_bug.cgi?id=346966 Discussion: #1: Federico Lucifredi <flucifredi(a)novell.com> (2008-06-13 15:12:52) there are some caveats I can think of requiring silent fail (for instance, a laptop), or requiring randomization (not hitting NCC with a volley all at the same time), but I think the idea is good. #2: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-07-07 11:13:37) If you think you can make it work in a reliable way, please present a concept. Right now PackageKit and updater applets do refresh often before checking for updates so the system repos _are_ refreshed. So I don't see much value in this feature (unless a concept is presented). #3: Stanislav Visnovsky <visnov(a)novell.com> (2008-07-07 12:34:19) (reply to #2) We have a concept in the automatic online update configuration. #4: Jiri Srain <jsrain(a)novell.com> (2008-07-07 12:58:59) (reply to #3) You mean running online update from cron? It should involve metadata refresh, but I do not see any reason for a separate metadata download from cron. #5: Ladislav Slezak <lslezak(a)novell.com> (2008-07-09 10:30:09) (reply to #4) The feature should allow to disable "autorefresh" flag for all repositories so the package management can be started quickly without connecting to network. The cronjob would keep the metadata uptodate. Of course, there might be a problem when metadata are changed too often on the server, but in my opinion that's not a usual case in the real world. #6: Jiri Srain <jsrain(a)novell.com> (2008-07-10 12:16:08) Let's extend the "automatic online update" module so that it offers whether to do real automatic online update, or just refresh the metadata (via one check box) #8: J. Daniel Schmidt <jdsn(a)novell.com> (2008-07-18 18:13:38) (reply to #6) This would hide the feature in an update related module. But the feature does not restrict this only to update repositories. Build-Service Repos might need a refresh as well or think of Factory. The right place for this feature is the Repository Manager. It has no relation to the update process or a configuration concerning updates. #7: Jiří Suchomel <jsuchome(a)novell.com> (2008-07-14 14:46:01) Daniel, what's the status of the plan to merge "online update configuration" into registration module? #9: J. Daniel Schmidt <jdsn(a)novell.com> (2008-07-18 18:15:46) (reply to #7) Currently I plan to merge it into a new module together with "Online Update Configuration" related settings. Please do not extend it with this unrelated repo refreshing dialog. #10: J. Daniel Schmidt <jdsn(a)novell.com> (2008-09-10 19:48:24) Why am I listed as the only developer here? I just said that I will merge the modules "automatic online update setup" and "online update setup". This feature is requesting something completely different. #11: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-09-10 22:21:17) (reply to #10) Don't worry, this feature will be dropped as because the OnStar work. It is just abandoned. #13: Jiří Suchomel <jsuchome(a)novell.com> (2008-09-11 08:20:55) (reply to #11) Really? I don't think so.This feature is aimed for opensuse (it wants to extend the current "online update setup"), while OnStar is for SLE. #12: Jiří Suchomel <jsuchome(a)novell.com> (2008-09-11 08:22:02) (reply to #10) Because the requested feature would be part of what is currently "online update setup". And after the merge, I assumed you should mainain the merged parts. #15: J. Daniel Schmidt <jdsn(a)novell.com> (2008-09-11 12:37:19) (reply to #12) No the requested feature will not be part of the successor of "online update setup". Maybe you want it to be. But IMHO this has nothing to do with anything that is called "online update *something*". This feature is about a general refresh of repositories - not just the update repo. Software repositories are handled in the "Software repositories" module. And thats the place where this feature is asking for enhancement. Just look at the linked bug (bnc#346966). It even has a mockup (yes, I added one as well, but just look at the original one). And this is now quite the same I already wrote in comment #8. #16: Jiří Suchomel <jsuchome(a)novell.com> (2008-09-11 12:44:53) (reply to #15) Ah, sorry. Looks like I have some other feature in mind while commenting this one. This one really is not online-update specific. + #17: Stanislav Visnovsky <visnov(a)novell.com> (2008-09-12 14:12:02) + PM-Priority for product openSUSE-11.1 downgraded from mandatory to + important: + Aurora ECO approved. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 303559] @opensuse.org mail forward support in users.opensuse.org
by fate_noreply＠suse.de 12 Sep '08

12 Sep '08

Feature changed by: Ruediger Oertel <ro(a)novell.com> Feature #303559, revision 4 Title: @opensuse.org mail forward support in users.opensuse.org - Buildservice: New + Buildservice: Done Priority Requester: Mandatory Requested by: Adrian Schröter <adrian(a)novell.com> Partner organization: openSUSE.org Description: We have the request to support the membership management of opensuse. org via users.opensuse.org. This require the following: * Admin (can be defined via hard coded list for now) can enable a "Membership Flag" for dedicated users. * Users with Membership Flag can enter an email forwarding adress. * Regular export of forwarding adresses for Boetti to support the new forwarders. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303559

1 0

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

12 Sep '08

Feature changed by: Ján Kupec <jkupec(a)novell.com> Feature #303527, revision 15 Title: Resolve dependencies after ignoring package download failure openSUSE-11.1: Candidate 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 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 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303527

1 0

[openFate 303367] Better Beagle Acceptance
by fate_noreply＠suse.de 12 Sep '08

12 Sep '08

Feature changed by: JP Rosevear <jpr(a)novell.com> Feature #303367, revision 12 Title: Better Beagle Acceptance openSUSE-11.0: Rejected by Gary Ekker <gekker(a)novell.com> reject date: 2008-05-27 09:03:27 reject reason: Not done for 11.0. Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.1: Candidate + openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Important - SLED-11: Candidate + SLED-11: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Andreas Jaeger <aj(a)novell.com> Partner organization: openSUSE.org Description: There have been several discussions on the public openSUSE mailing lists, e.g. http://lists.opensuse.org/opensuse-factory/2008-01/msg00157.html where people complain about resource usage or garbage from beagle. I suggest that we analyze the current situation and check where are real problems and consider solutions. One option would be to make it easier for users to not enable beagle on their systems. Note: The feature request is about getting a better acceptance by our users of our indexing technology - and therefore let's figure out what are the problems they are hitting in real life. References: https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Andreas Jaeger <aj(a)novell.com> (2008-01-20 11:12:58) See also bug 282678. #2: Andreas Jaeger <aj(a)novell.com> (2008-01-23 16:23:51) Note: powertop advises "Suggestion: Disable or remove 'beagle' from your system. Beagle is the program that indexes for easy desktop search, however it's not very efficient and costs a significant amount of battery life.". #3: JP Rosevear <jpr(a)novell.com> (2008-01-23 10:38:58) (reply to #2) Yes, this is well known and was covered extensively last year and caused by polling for battery status in some cases. 0.3.2 uses hal to detect battery status: http://www.mail-archive.com/dashboard-hackers@gnome.org/msg03464.html #4: JP Rosevear <jpr(a)novell.com> (2008-01-23 10:41:35) (reply to #3) Also part of it was a mono issue: http://www.nabble.com/Beagle-indexing-when-running-on-batteries-td13842939.… -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303367

1 0

[openFate 302220] Automatic Language Subpackage Generation and Collection
by fate_noreply＠suse.de 12 Sep '08

12 Sep '08

Feature changed by: Gary Ekker <gekker(a)novell.com> Feature #302220, revision 15 Title: Automatic Language Subpackage Generation and Collection openSUSE-10.3: Done Priority Requester: Mandatory Projectmanager: Mandatory - SLED-11: Candidate + SLED-11: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Andreas Jaeger <aj(a)novell.com> Partner organization: openSUSE.org Description: To decrease size of installed packages, we want to create language subpackages similar to yast2-trans-$lang and kde-i18n-$lang for other areas. This feature is needed for one CD installations and helps also with thin-client. The idea is to add to spec file of packages a new rpm macro so that subpackages are created and then related subpackages are repacked for each language in our build system. This way we would get e.g. basesystem-$lang and gnome-$lang packages and those can then be installed. Discussion: #1: Stephan Kulow <coolo(a)novell.com> (2007-05-14 13:30:09) Technically it's not a problem. The tools are there, but we need to change ~500 packages to split translations out. Suggestions? Letting them fail or submit them in masses? #2: Andreas Jaeger <aj(a)novell.com> (2007-06-15 16:34:23) (reply to #1) Please discuss on dist mailing list. #3: Stephan Kulow <coolo(a)novell.com> (2007-07-30 09:48:08) we've done it for KDE and saved about 8MB for the english only CD. But the potential for GNOME / Base is still big. #4: Jared Allen <jpallen(a)novell.com> (2007-08-05 21:41:40) Micheal can you take a look at what Stephan did for KDE and see what can be done for GNOME. #5: Stephan Kulow <coolo(a)novell.com> (2007-10-01 12:00:15) done for 10.3, to be reevaluated if enterprise compatible for 11.0 - Thorsten had his doubts. + #7: Gary Ekker <gekker(a)novell.com> (2008-09-11 19:03:07) + Proxied from Michael. + Already done for GNOME (and Firefox) as of 10.3, and all new GNOME + packages are being created with -lang subpackages (where + possible/relevant). I blogged about it, even :) See + http://nachosetcrayons.blogspot.com/2007/08/think-small.html. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302220

1 0

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

12 Sep '08

Feature changed by: Gary Ekker <gekker(a)novell.com> Feature #301791, revision 25 Title: "Report a bug" a-la-Safari for Mozilla Firefox openSUSE-11.0: Evaluation 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301791

1 0