June 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305489] default email in email applications
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #305489, revision 15 Title: default email in email applications openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Martin Lasarsch (mlasars) Description: To get more subscriptions to the mailinglists it would be nice to have a "default mail" in the mail clients (evolution, kmail) which points the user to the mailinglists. Every openSUSE user should be subscribed to opensuse-announce at least. A simple reply to this "default mail" should subscribe to the list (so it's opt-in, no one should be forced). Of course there could be more information in it, like other important lists, pointing to the main list page. evolution have already a "default mail", with general information about evolution, kmail afaik not. This might be also useful for OEM customers to have a welcome mail for the customers, pointing to the support pages etc.. So general email "branding" packages which makes it possible to have such special "default mails" for the email clients would be usefull. Discussion: #1: Carlos Lange (cflange) (2009-01-17 19:59:30) There are several parts to this suggestion. 1) "default mail": If you mean "Default" in the sense that when I start a new message the To: field is filled out by default with the mailing- list address, I disagree with your comment. The user should set that and an inexperienced user should find herself/himself subscribing to a mailing-list by mistake, just because they forgot to reset the To: field. Such a user would be rightly upset and feel like they were trapped into doing it. 2) If you mean, however, that the address book in Evolution and Kmail should be pre-populated with relevant addresses, such as the mailing- list and others, in the same way the Firefox bookmarks toolbar comes pre-populated with the SUSE folder, then I would agree that this is a useful suggestion, because the user can freely choose to use those addresses or not. 3) I strongly disagree that every openSUSE user should be subscribed to the opensuse-announce mailing-list. I deal with many different types of users. Only a minority of them would be interested in receiving announcements and they actively subscribe to the mailing-list. The vast majority of them likes the Linux-way of being non-intrusive, without the nags and unsolicited messages from the proprietary world, that tend to be associated with annoying marketing strategies. Please, don't advocate that for openSUSE. The SUSE information box shown at the first login is as much in-your- face direct marketing as one should need to take when using openSUSE. And being beautiful and carefully designed as it is, it contains all information a new user needs to decide how much involved with the operating system they want to be. #2: Joe Brockmeier (jbrockmeier) (2009-01-20 02:05:37) (reply to #1) Perhaps "every" is a bit much, but I feel a lot more people should be subscribed than are currently. I find it's not uncommon to talk to people and see that they're unaware of something happening in the community that has been announced on the mailing list. The percentage of people subscribed to -announce is much less than 1% of openSUSE users, and I feel we could be reaching a lot more people. It's not an "annoying marketing strategy," it's an attempt to keep our community informed. Most of the messages that go to announce are not "marketing" in nature, they're informative. #3: Kevin Dupuy (kdupuy9) (2009-01-20 02:49:32) (reply to #2) I also like the idea of having more users subscribed to the -announce list. Every time there is scheduled downtime, even though it is announced on -announce and openSUSE News, some people come on the opensuse(a)o.o mailinglist "eh, what happened? the servers are down, suse is unreliable!",. so those type of mails I'd like for more users to get. Then again perhaps not every user wants to know when the next project meeting is, so that's a strike against the idea as well. I do think, as with Carlos, that the address book in Kontact and Evolution should have some important email address in there (opensuse(a)o.o, anything else?) #4: Martin Lasarsch (mlasars) (2009-01-20 17:12:09) (reply to #1) 1. no 2. maybe, why not 3. should means as an opt-in ... not forcing With default i meant to have a simple email in the inbox to make it easier to subscribe to the announce list. #5: Stefan Behlert (sbehlert) (2009-03-26 10:58:17) I think the idea of having some addresses in the addressbook is good. I'm not sure which one's are the ideal ones for that, though. Let'S start with a few and add what is found missing later. + #6: Stephan Kulow (coolo) (2009-06-24 11:32:12) (reply to #5) + for opensuse this unfortunately not useful. as the subscription address + is pretty useless in the address book as you only need once. And you + can't post to opensuse(a)opensuse.org without being subscribed. So some + more explanation is needed there - of course in the language of the + user. + #7: Stephan Kulow (coolo) (2009-06-24 11:34:39) + I think there are some issues to be sorted out before we can go + forward, perhaps someone from the marketing team wants to drive this -- openSUSE Feature: https://features.opensuse.org/305489

1 0

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

24 Jun '09

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

1 0

[openFATE 305877] Popularity contest
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #305877, revision 17 Title: Popularity contest openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Vladimir Nadvornik (nadvornik) Description: We need a feedback about packages that are preferred by users and actively used. Debian already has a tool named Popularity contest (popcon) * reusing popcon will give us results that are directly comparable with Debian and Ubuntu * packagers team can take care of the package * we need a configuration dialog in YaST that is visible enough * we need a server infrastructure on opensuse.org. (There are certain privacy issues, see Debian FAQ for details) References: http://en.opensuse.org/BrainStorming_Prague#We_don.27t_know_which_packages_… http://popcon.debian.org/FAQ http://popcon.debian.org/ http://popcon.ubuntu.com/ Discussion: #1: Michal Vyskocil (mvyskocil) (2009-02-20 12:56:06) The pupularity-contest executable is a simple Perl script, which should be ported to rpm (replacing of dpkg calls by appropiate rpm alternative should be enough). #2: Pavol Rusnak (prusnak) (2009-03-11 15:53:13) (reply to #1) Replacing of dpkg calls with rpm is a no-go, because of the transactions in RPM. I started to work on a rewrite, will post results soon ... #3: Marek Stopka (m4r3k) (2009-03-13 09:28:08) (reply to #2) And here is a result... :-) http://stick.gk2.sk/blog/2009/03/popcorn-popularity-contest-for-rpm/ #4: Jay Mistry (zmdmw52) (2009-03-15 15:36:25) The software equivalent of Smolts Hardware profiler. Results can be uploaded to a dedicated website (such as is for Smolts- http://www.smolts.org/) so that users can see the relative weight/popularity of various commonly-used applications. #5: T. J. Brumfield (enderandrew) (2009-06-13 21:16:54) During install, there can be a simple checkbox such as "Share hardware/software details with openSUSE servers for profiling." + #6: Stephan Kulow (coolo) (2009-06-24 11:29:15) + first we need the package in and someone to maintain the server or + contact debian if they host other distros too. -- openSUSE Feature: https://features.opensuse.org/305877

1 0

[openFATE 306157] vserver for opensuse
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Jean-Daniel Dodin (jdd_sysop) Feature #306157, revision 1, last change by Title: vserver for opensuse openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Jean-Daniel Dodin (jdd_sysop) Description: Include vserver as vitual server in opensuse. It's a very usefull virtualization system for Linux only guest virtualization available for many distros but not yet openSUSE http://linux-vserver.org/Welcome_to_Linux-VServer.org -- openSUSE Feature: https://features.opensuse.org/306157

1 3

[openFATE 305400] kerneloops.org for openSuSE
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #305400, revision 10 Title: kerneloops.org for openSuSE openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Brandon Philips (philipsb) Partner organization: openSUSE.org Description: Desktop integration: Stephan Kulow reported that the kerneloops-applet doesn't work under KDE. I will look into this and fix it. Installer integration: Stanislav Visnovsky suggested that Kerneloops opt-in be done in the same way as the smolt opt-in. I think this is the way to go. References: http://kerneloops.org https://bugzilla.novell.com/show_bug.cgi?id=388570 Business case (Partner benefit): openSUSE.org: Allows us to see trends in kerneloopses in our community releases on kerneloops.org and thereby improve our SLE releases. Eventually we could have the daemon report to an encrypted private internal server so we can get Kernel oops reports from enterprise customers. Discussion: #1: Stephan Kulow (coolo) (2009-03-04 12:03:46) I don't want to see yet another applet for such a specific task. If this is something that does check the log from a cron job and then signals the desktop, I don't mind. But having another applet is a no go - the same for something to start on boot. -- openSUSE Feature: https://features.opensuse.org/305400

1 0

[openFATE 305285] dictionary and DoS attack protection based using log scanning and dynamic firewall ban
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #305285, revision 17 Title: dictionary and DoS attack protection based using log scanning and dynamic firewall ban openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) Description: Detailed Description For these attackss, usually the application/service will not allow the attacker to break in, however once a malicious password guess or DoS attack is done, baning the connection for some minutes and then an unban time of several minutes is usually enough to stop a network connection being flooded, as well as reducing the likelihood of a successful dictionary attack. The situation goes this way: - attacker starts a password guess - the system detects Y continuous failed attempts to login in the log file of the service - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again - attacker starts a DoS attack - the system detects Y continuous connections without login - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again Scope To provide an extra option in the firewall which allows to select which services to monitor (usually by looking at patterns in the log file ) and block the ip for a configurable interval once a dictionary attack or DoS is suspected. The option could be as well in the service module (or in both) or even in the specific service configuration module. Usually parameters to configure are the patterns and the actions. Also, YaST should tell the user to install the required packages if this option is enabled. To be defined in the scope is how much configurability is needed. If known services will be protected, or if a generic way to define protection for an arbitrary service is desired. Possible Implementation Fail2Ban provices right now most of the functionality. Provides a service that allows to define jails, a jail is a pattern and an action. A service can have more than one jail. For example the patterns for an ssh DoS attack is different than a dictionary attack on the same service, and the ban times may be different. Fail2Ban provides generic functionality not tied to any specific service and comes with predefined patterns and actions for various popular services as sshd, apache2 http authentication and others. http://en.wikipedia.org/wiki/Fail2ban http://www.fail2ban.org YaST would need to write the configuration about which patterns to use depending on the service to protect, or optionally define patterns for unknown services, same with actions, and start or stop the service depending on this functionality being enabled or not. Test Plan Doing serveral failed attempts on the ssh server should block the user for 3 minutes. Simple testcase. User Experience The functionality should be availabe in a clever location (which can be more than one, for example, firewall, services or the specific module), allowing to turn it on with sane defaults (hopefully provide the defaults fail2ban provides). The user can see the blocked attempts in the logs. Dependencies Using the fail2ban approach would require the fail2ban package, which in turns requires python, available in the openSUSE build service from a community user home project. (home:leonardocf) Contingency Plan None, as the functionality was not available before. Relations: - Preventing Brute Force Attacks With Fail2ban On OpenSUSE 10.3 (url: http://www.howtoforge.com/fail2ban_opensuse10.3) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:50:52) I don't know about the enteprise angle (I need to think), but for the community distro it seems quite a cool feature. #3: Christoph Thiel (cthiel1) (2009-05-26 18:50:09) We won't be able to implement this feature in 11.2 within the YaST teams. Maybe still something for the community? -- openSUSE Feature: https://features.opensuse.org/305285

1 0

[openFate 305146] Use old system network configuration when updating instead of demanding a new one
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305146, revision 1, last change by Title: Use old system network configuration when updating instead of demanding a new one openSUSE-11.2: New Priority Requester: Desirable Requested by: Pacho Ramos <pacho(a)condmat1.ciencias.uniovi.es> Partner organization: openSUSE.org Description: Currently, when I try to update from opensuse 10.3 to 11.0 with DVD and I want to add network repositories, I have to configure again my network for opensuse installer even when it is already configured on my opensuse-10.3 I think that would be much better try to use network configuration from old installation and only ask user if a problem occurs Business case (Partner benefit): openSUSE.org: System update from media: Start installation / Update, select network-based repositories to be used, you will be asked to configure the network. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305146

1 5

[openFATE 304937] Wireless dynamic WEP connection with 802.1x authentication in Yast/sysconfig
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #304937, revision 12 Title: Wireless dynamic WEP connection with 802.1x authentication in Yast/sysconfig openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-29 15:43:08 reject reason: This cannot be done in time for openSUSE 11.1. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Helmut Schaa (hschaa) Description: Yast/sysconfig does already support WPA-EAP wireless connections but is missing support for dynamic WEP connections using 802.1x authentication. wpa_supplicant is able to start such a connection with a network block which uses key_mgmt=IEEE8021X instead of key_mgmt=WPA- EAP. Example: network={ ssid=xxx key_mgmt=IEEE8021X eap=TTLS identity=xxx password=xxx ... } Based on bug #380671 comment #16 and #19. Discussion: #2: Helmut Schaa (hschaa) (2008-07-09 13:34:35) (reply to #1) This request is about dynamic WEP, not static WEP keys (which is already supported). The 802.1x authentication is used to derive dynamic WEP keys repeatedly. It is much more secure then plain static WEP (although not as secure as WPA of course) and still widely used. #3: Stephan Kulow (coolo) (2009-04-16 14:53:06) looking for community volunteers -- openSUSE Feature: https://features.opensuse.org/304937

1 0

[openFATE 304911] Import all GPG keys at once before downloading the metadata from new repositories
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #304911, revision 24 Title: Import all GPG keys at once before downloading the metadata from new repositories openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-09 07:54:32 reject reason: Cannot be done in time. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Ladislav Slezak (lslezak) Description: If e.g. 10 different repositories are added yast asks to import the GPG key for each repository so the user cannot leave the computer while the metadata are downloaded. References: https://bugzilla.novell.com/show_bug.cgi?id=399253 Discussion: #2: Federico Lucifredi (flucifredi) (2008-07-08 19:41:45) (reply to #1) cute. It is a nice idea indeed. #3: Dmitry Mittov (michael_knight) (2009-02-23 11:03:50) It is not a good idea to add gpg keys for all repos all over the world. What do you want to do with new repos on BuildService? They can be created after release of new Suse version. All repos signed with SuSE Package Signing Key are guaranteed. When you add other repos you should confirm you trust them. But special option for 'zypper ar'. Something like '--trust-key' will solve you problem. #4: Stephan Kulow (coolo) (2009-04-16 14:41:15) (reply to #3) you haven't see the community repos list yet? #5: Stephan Kulow (coolo) (2009-04-16 14:41:42) looking for community volunteers #6: Stanley Miller (stan_qaz) (2009-04-30 04:10:50) Would it be possible to do a quick check to see which repositories do not have the keys already downloaded and do the dialog box for all of them before starting the metadata download? That avoids the issue of just accepting the keys blindly and the issue of having the download process stop and wait for user input when a missing key is found. #7: T. J. Brumfield (enderandrew) (2009-06-13 02:14:59) You have to go out of your way to add the repo in the first place. Can someone please explain a scenario where you would go out of your way to add the repo, and then reject the GPG key? -- openSUSE Feature: https://features.opensuse.org/304911

1 0

[openFATE 303517] Automatically refreshing repositories at recurring intervals
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #303517, revision 30 Title: Automatically refreshing repositories at recurring intervals openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-12 14:12:10 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Ladislav Slezak (lslezak) 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) (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) (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) (2008-07-07 12:34:19) (reply to #2) We have a concept in the automatic online update configuration. #4: Jiri Srain (jsrain) (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) (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) (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) (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) (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) (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) (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) (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) (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) (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) (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) (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. #19: Robert Davies (robopensuse) (2009-01-16 16:30:40) As when I go into Software Repository management, I am offered check boxes like "autorefresh", it would seem when those boxes are checked, that I expect this to happen without knowing about it. Being made to wait, when I choose to run Online Update, or Software Management, seems to defeat purpose of auto-refresh feature, though it is understandable if no refresh was done for days. Some kind of cron job, ought to just handle this. Why should the user be asked more questions than "autorefresh" tick box? #20: Stephan Kulow (coolo) (2009-04-16 13:47:23) looking for community volunteers -- openSUSE Feature: https://features.opensuse.org/303517

1 0