September 2008 - openSUSE Features - openSUSE Mailing Lists

[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

[openFate 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 11 Sep '08

11 Sep '08

Feature changed by: Jiří Suchomel <jsuchome(a)novell.com> Feature #303517, revision 20 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Evaluation Priority Requester: Desirable Projectmanager: Mandatory 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 11 Sep '08

11 Sep '08

Feature changed by: J. Daniel Schmidt <jdsn(a)novell.com> Feature #303517, revision 19 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Evaluation Priority Requester: Desirable Projectmanager: Mandatory 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 303708] [CODE11-GM] Mascot for YaST
by fate_noreply＠suse.de 11 Sep '08

11 Sep '08

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #303708, revision 12 - Title: Mascot for YaST + Title: [CODE11-GM] Mascot for YaST openSUSE-11.1: Candidate Priority Requester: Mandatory Projectmanager: Desirable Requested by: Andreas Jaeger <aj(a)novell.com> Partner organization: openSUSE.org Description: Every successfull product has it's own logo and mascot. We should create and market one for YaST as well, display it prominently on all YaST project pages and also in YaST, e.g. in any About screens or as easter egg. Discussion: #2: Michael Loeffler <michl(a)novell.com> (2008-04-24 12:46:55) I'm fine with that. I think this should come out of the inner YaST circle with some help from design people like Jakub. #3: Michael Loeffler <michl(a)novell.com> (2008-04-24 19:54:31) (reply to #2) And we should inlcude the community on that. Zonker might call for ideas/participation for logo creation on his blog and news.openSUSE. org #4: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-04-25 12:08:16) # zypper moo \\\\\ \\\\\\\__o __\\\\\\\'/_ http://en.wikipedia.org/wiki/Hedgehog -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303708

1 0

[openFate 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 11 Sep '08

11 Sep '08

Feature changed by: Jiri Srain <jsrain(a)novell.com> Feature #303517, revision 18 Title: Configure a cronjob for refreshing repositories - openSUSE-11.1: Candidate + openSUSE-11.1: Evaluation Priority Requester: Desirable Projectmanager: Mandatory 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 11 Sep '08

11 Sep '08

Feature changed by: Jiri Srain <jsrain(a)novell.com> Feature #302119, revision 28 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: Candidate + openSUSE-11.1: Evaluation Priority Requester: Desirable Projectmanager: Important 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 303700] Ability to log all configuration changes done via YaST
by fate_noreply＠suse.de 11 Sep '08

11 Sep '08

Feature changed by: Jiri Srain <jsrain(a)novell.com> Feature #303700, revision 18 Title: Ability to log all configuration changes done via YaST - openSUSE-11.1: Candidate + openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Mandatory - SLED-11: Candidate + SLED-11: Done Priority Requester: Mandatory Projectmanager: Mandatory - SLES-11: Candidate + SLES-11: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Matthias Eckermann <mge(a)novell.com> Partner organization: openSUSE.org Description: Provide the ability to log all configuration changes done via YaST. Additionally, in this mode an admin would be prompted to document what was the nature/purpose of the change as the module is being closed, akin to commit messages in a versioning system. Documentation Impact: The new log file needs to be documentated in admin guide. Discussion: #1: Federico Lucifredi <flucifredi(a)novell.com> (2008-04-30 15:27:04) note fate 303688 related: packaging CFT. I am not sure CFT is the right way to provide this functionality, but a consideration is that an admin using CFT will probably log both manual-editing and YaST-driven conf changes via the same tool. #2: Stanislav Visnovsky <visnov(a)novell.com> (2008-06-03 12:40:41) Duncan, Jiri, this might be an architectural change, please, look into this. Also, we might need to define scope of which changes we are able to track. #3: Jiri Srain <jsrain(a)novell.com> (2008-07-07 10:45:35) Martin, please, have a look at possibilities to record all changes and suggest an infrastructure. Federico, we will hardly be able to make all modules record all the changes they do. Could you, please, give us some priorities for SLE11? #6: Federico Lucifredi <flucifredi(a)novell.com> (2008-07-28 19:58:20) (reply to #3) Sure: network, users+groups would be a start. #4: Martin Vidner <mvidner(a)novell.com> (2008-07-08 11:44:54) This looks like a superset of feature 100386. Note that that one was downgraded because it is large (it requires touching all YaST modules). #5: Stanislav Visnovsky <visnov(a)novell.com> (2008-07-08 12:08:56) (reply to #4) Please, look into enabling of the stuff, not covering all YaST modules. #7: Federico Lucifredi <flucifredi(a)novell.com> (2008-07-28 19:59:34) (reply to #5) Indeed. Look at this architecturally. Also please keep in mind that the maintainer of CFT will help in getting that too to work on SLE (eventually, not for 11 GA timeframe), so please keep in mind these logs could feed into CFT eventually (and we would not want to change too much to make that happen :-) + #8: Jiri Srain <jsrain(a)novell.com> (2008-09-11 09:34:17) + Infrastructure is in, module using it will come later. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303700

1 0

[openFate 100386] Support a verbose logging mode in yast
by fate_noreply＠suse.de 11 Sep '08

11 Sep '08

Feature changed by: Jiri Srain <jsrain(a)novell.com> Feature #100386, revision 31 Title: Support a verbose logging mode in yast openSUSE-10.2: Rejected by Andreas Jaeger <aj(a)novell.com> reject date: 2006-09-30 20:43:33 reject reason: for 10.3. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-08-01 10:24:26 reject reason: Postponing, needs more research. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Federico Lucifredi <flucifredi(a)novell.com> reject date: 2008-06-28 19:27:16 reject reason: fixing my typo. Mandatories in the past don't work (yet). Priority Requester: Important Projectmanager: Important - openSUSE-11.1: Candidate + openSUSE-11.1: Done Priority Requester: Important Projectmanager: Important SL-10.0: Rejected by Andreas Jaeger <aj(a)novell.com> reject date: 2005-12-02 14:56:13 reject reason: not done. Priority Requester: Desirable - SLES-11: Candidate + SLES-11: Done Priority Requester: Important Projectmanager: Important Requested by: Andreas Jaeger <aj(a)novell.com> Partner organization: openSUSE.org Description: Create a verbose logging mode in yast, where any action yast performs is logged. Any file yast touches should be logged (to /var/log/YaST2/y2log AND clean up the structure of that log file, to make it easier to read and interpret) and all changes on the systems configuration. The goal is to make it really transparent what yast does. Documentation Impact: Admin guide needs to contain information about the new log file. Please add it to the Log file section in the troubleshooting chapter Discussion: #1: Edith Parzefall <emap(a)novell.com> (2006-09-28 17:17:54) Can't be done for 10.2. Back to TPMs. #2: Edith Parzefall <emap(a)novell.com> (2007-07-31 16:17:45) Sorry, couldn't be done for 10.3. We need a concept for this. Even within the team different developers have different needs. Improving the logging to give all developers the best possible debugging information will be difficult, but it's definitely something we should attempt in the near future. #3: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-08 10:48:48) Can we get some traction here finally? #4: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-28 10:16:38) Reopening, the YaST transparency is often cited as a problem for users. #6: Federico Lucifredi <flucifredi(a)novell.com> (2008-06-28 17:13:54) I think this has enough user benefit and is trivial enough, we should just get it done. #7: Federico Lucifredi <flucifredi(a)novell.com> (2008-06-28 19:28:04) PM-Priority for product openSUSE-11.0 downgraded from mandatory to : oops. Too many widgets for my tired brain. #8: Stanislav Visnovsky <visnov(a)novell.com> (2008-07-01 16:49:08) (reply to #7) This cannot be done completely - this is non-trivial amount of work. I suggest to start this though, having the YaST infrastructure in place ASAP. Federico, please, downgrade the priority. #9: Federico Lucifredi <flucifredi(a)novell.com> (2008-07-02 14:01:05) PM-Priority for product SLES-11 downgraded from mandatory to important: too much work for a one-off apparently. #10: Federico Lucifredi <flucifredi(a)novell.com> (2008-07-02 14:01:27) PM-Priority for product openSUSE-11.1 downgraded from mandatory to important: too much work for a one-shot. #12: Stanislav Visnovsky <visnov(a)novell.com> (2008-09-10 11:03:50) I've added y2useritem and y2usernote builtins into yast2-core. This might be helpful for this feature. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=100386

1 0

[openFate 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 11 Sep '08

11 Sep '08

Feature changed by: Jiří Suchomel <jsuchome(a)novell.com> Feature #303517, revision 16 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Candidate Priority Requester: Desirable Projectmanager: Mandatory 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 10 Sep '08

10 Sep '08

Feature changed by: Duncan Mac-Vicar <dmacvicar(a)novell.com> Feature #303517, revision 15 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Candidate Priority Requester: Desirable Projectmanager: Mandatory 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 10 Sep '08

10 Sep '08

Feature changed by: J. Daniel Schmidt <jdsn(a)novell.com> Feature #303517, revision 14 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Candidate Priority Requester: Desirable Projectmanager: Mandatory 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 304889] needs_relogin/needs_reboot as a generic flag
by fate_noreply＠suse.de 10 Sep '08

10 Sep '08

Feature changed by: Duncan Mac-Vicar <dmacvicar(a)novell.com> Feature #304889, revision 28 Title: needs_relogin/needs_reboot as a generic flag - openSUSE-11.1: Candidate + openSUSE-11.1: Done Priority Requester: Neutral Projectmanager: Mandatory Requested by: Stanislav Brabec <sbrabec(a)novell.com> Partner organization: openSUSE.org Description: There are situations, where relogin or reboot are needed to activate update: * package updates * proxy settings Now this situation is not done in a consistent way (silently ignoring problem, note in help, abuse of License entry, pop-up...). Providing a common way for setting these flags (via package provides, YaST calls, sysconfig comments) (and maybe comment what will happen ignoring it) would help in user experience (user is notified about need of relogin/reboot in a consistent way and only once) and administration (automatic relogin or reboot during maintenance window). Discussion: #1: Stanislav Visnovsky <visnov(a)novell.com> (2008-06-26 14:15:12) needs_reboot is properly handled by our tools. needs_relogin does not exist. #2: Jiri Srain <jsrain(a)novell.com> (2008-07-07 10:46:59) (reply to #1) We handle reboot only for package management not for anything else (the question is whether it is relevant somewhere else), thus we will need to have a more generic solution. Martin, would you, please, have a look and suggest a generic handler? #3: Stanislav Brabec <sbrabec(a)novell.com> (2008-07-09 15:26:16) needs_relogin would be useful in these situations: * New package, which provides file in /etc/profile.d was installed (or /etc/profile.d was singnificantly modified by the update). Example: ladspa * Packages, that cause that /etc/profile will evaluate environment. Example: Install any KDE application in GNOME only system. /opt/kde3 is not in PATH until next login * Patches, that affect login related programs. Example: security update of ssh-agent or gnome-keyring * YaST settings, that cause environment variable changes. Example: System proxy settings #4: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-08-07 22:06:14) Stefan, how is restart and reboot currently handled in packagekit, what would we need for relogin? #5: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-08-07 22:06:58) (note, ZYpp parts are already done, applications missing ) #6: Stefan Haas <shaas(a)novell.com> (2008-08-08 09:55:52) PackageKit has three different types for reboot/restart: -Restart System -Restart Application -Restart Session #7: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-08-11 17:25:11) Stefan Haas will adapt code from PackageKit to support this flag. #8: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-08-11 17:25:57) Thomas, does the KDE applet handle the relogin needed flag from PackageKit? #10: Thomas Göttlicher <tgoettlicher(a)novell.com> (2008-08-13 14:27:08) (reply to #8) kde4-kupdateapplet listens to PackageKit's restart signal since version 0.8.4. #9: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-08-11 17:26:53) Ladislav, is are the current flags in YaST handled in pkg-bindings? #11: Ladislav Slezak <lslezak(a)novell.com> (2008-08-20 12:16:02) (reply to #9) I just have committed the support for Patch::reloginSuggested() flag in yast SVN. It will be in yast2-pkg-bindings-2.17.8. I guess we also need some support in YCP... Jiri? #12: Jiří Suchomel <jsuchome(a)novell.com> (2008-08-21 15:19:11) Thomas/Stefan: which message does the applet show? I think we should try to show the same one in YaST and zypper. (BTW, zypper should be adapted as well -> Jano) #13: Thomas Göttlicher <tgoettlicher(a)novell.com> (2008-08-21 17:20:24) (reply to #12) kupdateapplet shows "Please reboot your system as soon as possible." or "Please relogin into your system as soon as possible.". If PackageKit provides details, these details are shown too. Please let me know if you prefer other strings. #14: Jiří Suchomel <jsuchome(a)novell.com> (2008-08-22 09:36:44) (reply to #13) Thanks. So I'm going to use this one "At least one of the updates installed requires restart of the session. Relogin into your system as soon as possible." I removed the "Please" intentionally, as such wording should not be used (I assume it can be found is the text style guide) and added kind of explanation sentence (similar is used by YaST in similar situations). #15: Thomas Göttlicher <tgoettlicher(a)novell.com> (2008-08-22 11:16:33) (reply to #14) I've removed the "please", too. Thanks for your hint. #16: Stanislav Brabec <sbrabec(a)novell.com> (2008-08-22 11:21:14) (reply to #14) Please tell me, how could I set this flag in the spec file. Actually, scriptlets are the best place to do it, as there is possible to filter unneeded restarts. Example: If krb5-client package is installed for the first time, relogin is required, but in case of update from new enough version, relogin is not needed, because there is no change in /etc/profile. d/krb5.sh. #18: Jiří Suchomel <jsuchome(a)novell.com> (2008-08-22 11:51:59) (reply to #16) I have no idea if this flag can be used for packages. My understanding is that it is part of patch description. #19: Stanislav Brabec <sbrabec(a)novell.com> (2008-08-22 12:44:15) (reply to #18) Relogin is needed especially for newly installed packages. "As a generic flag" in the FATE was intended as: Generic solution usable in both yast and packages. Packages need most probably a command line utility to set this flag in YaST. #20: Stanislav Visnovsky <visnov(a)novell.com> (2008-09-10 14:11:31) (reply to #19) I'm afraid we have to stick with per-patch flag for openSUSE 11.1. I suggest to have another Fate open for per-package. #17: Jiří Suchomel <jsuchome(a)novell.com> (2008-08-22 11:50:48) (reply to #12) YaST part done in yast2-online-update-2.17.5 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304889

1 0

[openFate 304889] needs_relogin/needs_reboot as a generic flag
by fate_noreply＠suse.de 10 Sep '08

10 Sep '08

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #304889, revision 27 Title: needs_relogin/needs_reboot as a generic flag openSUSE-11.1: Candidate Priority Requester: Neutral Projectmanager: Mandatory Requested by: Stanislav Brabec <sbrabec(a)novell.com> Partner organization: openSUSE.org Description: There are situations, where relogin or reboot are needed to activate update: * package updates * proxy settings Now this situation is not done in a consistent way (silently ignoring problem, note in help, abuse of License entry, pop-up...). Providing a common way for setting these flags (via package provides, YaST calls, sysconfig comments) (and maybe comment what will happen ignoring it) would help in user experience (user is notified about need of relogin/reboot in a consistent way and only once) and administration (automatic relogin or reboot during maintenance window). Discussion: #1: Stanislav Visnovsky <visnov(a)novell.com> (2008-06-26 14:15:12) needs_reboot is properly handled by our tools. needs_relogin does not exist. #2: Jiri Srain <jsrain(a)novell.com> (2008-07-07 10:46:59) (reply to #1) We handle reboot only for package management not for anything else (the question is whether it is relevant somewhere else), thus we will need to have a more generic solution. Martin, would you, please, have a look and suggest a generic handler? #3: Stanislav Brabec <sbrabec(a)novell.com> (2008-07-09 15:26:16) needs_relogin would be useful in these situations: * New package, which provides file in /etc/profile.d was installed (or /etc/profile.d was singnificantly modified by the update). Example: ladspa * Packages, that cause that /etc/profile will evaluate environment. Example: Install any KDE application in GNOME only system. /opt/kde3 is not in PATH until next login * Patches, that affect login related programs. Example: security update of ssh-agent or gnome-keyring * YaST settings, that cause environment variable changes. Example: System proxy settings #4: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-08-07 22:06:14) Stefan, how is restart and reboot currently handled in packagekit, what would we need for relogin? #5: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-08-07 22:06:58) (note, ZYpp parts are already done, applications missing ) #6: Stefan Haas <shaas(a)novell.com> (2008-08-08 09:55:52) PackageKit has three different types for reboot/restart: -Restart System -Restart Application -Restart Session #7: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-08-11 17:25:11) Stefan Haas will adapt code from PackageKit to support this flag. #8: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-08-11 17:25:57) Thomas, does the KDE applet handle the relogin needed flag from PackageKit? #10: Thomas Göttlicher <tgoettlicher(a)novell.com> (2008-08-13 14:27:08) (reply to #8) kde4-kupdateapplet listens to PackageKit's restart signal since version 0.8.4. #9: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-08-11 17:26:53) Ladislav, is are the current flags in YaST handled in pkg-bindings? #11: Ladislav Slezak <lslezak(a)novell.com> (2008-08-20 12:16:02) (reply to #9) I just have committed the support for Patch::reloginSuggested() flag in yast SVN. It will be in yast2-pkg-bindings-2.17.8. I guess we also need some support in YCP... Jiri? #12: Jiří Suchomel <jsuchome(a)novell.com> (2008-08-21 15:19:11) Thomas/Stefan: which message does the applet show? I think we should try to show the same one in YaST and zypper. (BTW, zypper should be adapted as well -> Jano) #13: Thomas Göttlicher <tgoettlicher(a)novell.com> (2008-08-21 17:20:24) (reply to #12) kupdateapplet shows "Please reboot your system as soon as possible." or "Please relogin into your system as soon as possible.". If PackageKit provides details, these details are shown too. Please let me know if you prefer other strings. #14: Jiří Suchomel <jsuchome(a)novell.com> (2008-08-22 09:36:44) (reply to #13) Thanks. So I'm going to use this one "At least one of the updates installed requires restart of the session. Relogin into your system as soon as possible." I removed the "Please" intentionally, as such wording should not be used (I assume it can be found is the text style guide) and added kind of explanation sentence (similar is used by YaST in similar situations). #15: Thomas Göttlicher <tgoettlicher(a)novell.com> (2008-08-22 11:16:33) (reply to #14) I've removed the "please", too. Thanks for your hint. #16: Stanislav Brabec <sbrabec(a)novell.com> (2008-08-22 11:21:14) (reply to #14) Please tell me, how could I set this flag in the spec file. Actually, scriptlets are the best place to do it, as there is possible to filter unneeded restarts. Example: If krb5-client package is installed for the first time, relogin is required, but in case of update from new enough version, relogin is not needed, because there is no change in /etc/profile. d/krb5.sh. #18: Jiří Suchomel <jsuchome(a)novell.com> (2008-08-22 11:51:59) (reply to #16) I have no idea if this flag can be used for packages. My understanding is that it is part of patch description. #19: Stanislav Brabec <sbrabec(a)novell.com> (2008-08-22 12:44:15) (reply to #18) Relogin is needed especially for newly installed packages. "As a generic flag" in the FATE was intended as: Generic solution usable in both yast and packages. Packages need most probably a command line utility to set this flag in YaST. + #20: Stanislav Visnovsky <visnov(a)novell.com> (2008-09-10 14:11:31) + (reply to #19) + I'm afraid we have to stick with per-patch flag for openSUSE 11.1. I + suggest to have another Fate open for per-package. #17: Jiří Suchomel <jsuchome(a)novell.com> (2008-08-22 11:50:48) (reply to #12) YaST part done in yast2-online-update-2.17.5 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304889

1 0

[openFate 305077] Improve support for macbook/pro
by fate_noreply＠suse.de 10 Sep '08

10 Sep '08

Feature added by: Michael Loeffler (michl(a)novell.com) Feature #305077, revision 1 Title: Improve support for macbook/pro openSUSE-11.1: Evaluation Priority Requester: Desirable Requested by: Michael Loeffler (michl(a)novell.com) Partner organization: openSUSE.org Description: The recent ubuntu 7.10 release had really really good macbook pro support. Since it is doable, it would be great to have better support in opensuse 11.0 for the macbook/pro. ie, mouse (trackpad), keyboard, wireless, bluetooth, sound, etc. http://en.opensuse.org/MacBook_Pro_Specials http://en.opensuse.org/Installation_on_MacBook_Pro_Intel_(x86) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305077

1 2

[openFate 100386] Support a verbose logging mode in yast
by fate_noreply＠suse.de 10 Sep '08

10 Sep '08

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #100386, revision 30 Title: Support a verbose logging mode in yast openSUSE-10.2: Rejected by Andreas Jaeger <aj(a)novell.com> reject date: 2006-09-30 20:43:33 reject reason: for 10.3. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-08-01 10:24:26 reject reason: Postponing, needs more research. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Federico Lucifredi <flucifredi(a)novell.com> reject date: 2008-06-28 19:27:16 reject reason: fixing my typo. Mandatories in the past don't work (yet). Priority Requester: Important Projectmanager: Important openSUSE-11.1: Candidate Priority Requester: Important Projectmanager: Important SL-10.0: Rejected by Andreas Jaeger <aj(a)novell.com> reject date: 2005-12-02 14:56:13 reject reason: not done. Priority Requester: Desirable SLES-11: Candidate Priority Requester: Important Projectmanager: Important Requested by: Andreas Jaeger <aj(a)novell.com> Partner organization: openSUSE.org Description: Create a verbose logging mode in yast, where any action yast performs is logged. Any file yast touches should be logged (to /var/log/YaST2/y2log AND clean up the structure of that log file, to make it easier to read and interpret) and all changes on the systems configuration. The goal is to make it really transparent what yast does. Documentation Impact: Admin guide needs to contain information about the new log file. Please add it to the Log file section in the troubleshooting chapter Discussion: #1: Edith Parzefall <emap(a)novell.com> (2006-09-28 17:17:54) Can't be done for 10.2. Back to TPMs. #2: Edith Parzefall <emap(a)novell.com> (2007-07-31 16:17:45) Sorry, couldn't be done for 10.3. We need a concept for this. Even within the team different developers have different needs. Improving the logging to give all developers the best possible debugging information will be difficult, but it's definitely something we should attempt in the near future. #3: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-08 10:48:48) Can we get some traction here finally? #4: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-28 10:16:38) Reopening, the YaST transparency is often cited as a problem for users. #6: Federico Lucifredi <flucifredi(a)novell.com> (2008-06-28 17:13:54) I think this has enough user benefit and is trivial enough, we should just get it done. #7: Federico Lucifredi <flucifredi(a)novell.com> (2008-06-28 19:28:04) PM-Priority for product openSUSE-11.0 downgraded from mandatory to : oops. Too many widgets for my tired brain. #8: Stanislav Visnovsky <visnov(a)novell.com> (2008-07-01 16:49:08) (reply to #7) This cannot be done completely - this is non-trivial amount of work. I suggest to start this though, having the YaST infrastructure in place ASAP. Federico, please, downgrade the priority. #9: Federico Lucifredi <flucifredi(a)novell.com> (2008-07-02 14:01:05) PM-Priority for product SLES-11 downgraded from mandatory to important: too much work for a one-off apparently. #10: Federico Lucifredi <flucifredi(a)novell.com> (2008-07-02 14:01:27) PM-Priority for product openSUSE-11.1 downgraded from mandatory to important: too much work for a one-shot. + #12: Stanislav Visnovsky <visnov(a)novell.com> (2008-09-10 11:03:50) + I've added y2useritem and y2usernote builtins into yast2-core. This + might be helpful for this feature. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=100386

1 0

[openFate 305168] default to relatime
by fate_noreply＠suse.de 10 Sep '08

10 Sep '08

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #305168, revision 5 Title: default to relatime - openSUSE-11.1: New + openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> + reject date: 2008-09-10 10:20:17 + reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory + openSUSE-11.2: New + Priority + Requester: Mandatory Requested by: Michael Meeks <mmeeks(a)novell.com> + Partner organization: openSUSE.org Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305168

1 0

[openFate 304928] LSB build target
by fate_noreply＠suse.de 09 Sep '08

09 Sep '08

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #304928, revision 13 Title: LSB build target Buildservice: Evaluation Priority Requester: Important Requested by: Adrian Schröter <adrian(a)novell.com> Requested by: Michael Loeffler <michl(a)novell.com> Partner organization: openSUSE.org Description: A LSB build target is requested from PM. This does mean we need * A usable base distribution, which avoids to generate binaries with non-LSB requirements. * Additional LSB validation checks packaged. We could integrate these as rpmlint checks for example. Jiri, how can we setup such a distribution, using selected packages from a SUSE distro plus lsb-build-cc as compiler ? Jiri, can you package the lsb validation checks as rpmlint packages or shall we run them in a different way ? Discussion: #1: Jiri Dluhos <jdluhos(a)novell.com> (2008-06-18 13:55:50) The task has two sides: Checking binaries for LSB compliance is relatively easy; I will investigate how the checks could be incorporated into rpmlint. Building in LSB-pure environment is a conceptually different, and significantly more complex task. We have already tried to implement a pure LSB build target for buildservice, but the straightforward strategy failed because LSB-pure environment is too restricted to build essential system binaries (like mount). The Linux Foundation uses a specially crafted host distro for their builds, which is not LSB compliant per se, and then do an additional round of checks and purifications on the built binaries. We can mimic this process. #2: Jiri Dluhos <jdluhos(a)novell.com> (2008-06-18 14:23:32) What we will need is probably the lsbappchk tool from the LSB Application Testkit (downloadable at http://www.linuxfoundation.org/en/Download (http://www.linuxfoundation.org/en/Download) ). I will look at the sources to see if we can easily build it on- site. #3: Jiri Dluhos <jdluhos(a)novell.com> (2008-06-18 15:51:49) For the record (and for the curious :-) ), the database of LSB- compliant interfaces is here: http://bzr.freestandards.org/lsb/devel/specdb (http://bzr.freestandards.org/lsb/devel/specdb) #4: Darren Davis <ddavis(a)novell.com> (2008-06-30 07:55:35) I would also be nice if after they build their LSB Compliant Application in the Build Service, that they could also do the part of submitting the results for the LSB Navigator that the ATK provides. https://www.linuxfoundation.org/dbadmin/commons/welcome.php #5: Gerald Pfeifer <gp(a)novell.com> (2008-06-30 22:53:24) Michl is out right now, so let me play Michl on TV. Important for PM, and on to Adrian. ;-) #6: Martin Mrazik <mmrazik(a)novell.com> (2008-07-01 06:08:50) (reply to #5) Maybe before evaluating this it would be better to split this fate entry into two: * Create a LSB build target * Package ATK and integrate with rpmlint #7: Darren Davis <ddavis(a)novell.com> (2008-07-18 12:35:52) (reply to #6) We could keep this FATE for the build target. I have created FATE 305085 for the ATK. + #8: Michael Loeffler <michl(a)novell.com> (2008-09-09 15:10:31) + Maybe we can combine that with Linux Foundation Application checker, + see http://ldn.linuxfoundation.org/lsb/check-your-app -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304928

1 0

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

08 Sep '08

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

1 0

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

08 Sep '08

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #302119, revision 27 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: Candidate Priority Requester: Desirable Projectmanager: Important 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 301919] Ship nspluginwrapper to better support 32bit Firefox plugins on 64bit systems
by fate_noreply＠suse.de 04 Sep '08

04 Sep '08

Feature changed by: Gary Ekker <gekker(a)novell.com> Feature #301919, revision 22 Title: Ship nspluginwrapper to better support 32bit Firefox plugins on 64bit systems openSUSE-10.3: Done Priority Requester: Mandatory Projectmanager: Mandatory - SLED-11: Evaluation + SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Important Archs: i386, x86-64 - SLES-11: Evaluation + 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? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301919

1 0

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

04 Sep '08

Feature changed by: Gary Ekker <gekker(a)novell.com> Feature #301791, revision 24 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: Evaluation + 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301791

1 0