January 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 120340] Run download and install in parallel
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Ruchir Brahmbhatt (Ruchir) Feature #120340, revision 41 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf <kkaempf(a)novell.com> reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Interested: Ján Kupec (jkupec) Interested: Lukas Ocilka (locilka) Interested: Robert Davies (robopensuse) + Interested: Ruchir Brahmbhatt (ruchir) Interested: Stephan Binner (beineri) Partner organization: openSUSE.org Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=120340

1 0

[openFate 120326] Resume download
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Ruchir Brahmbhatt (Ruchir) Feature #120326, revision 34 Title: Resume download openSUSE-10.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2006-09-21 09:56:17 reject reason: Not enough resources to implement in time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-25 15:20:32 reject reason: Out of time. Postponing. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-03-28 13:51:03 reject reason: Out of resources for 11.0. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-01 11:34:46 reject reason: Postponing, needs downloading refactor. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Interested: Andreas Jaeger (a_jaeger) Interested: Ján Kupec (jkupec) + Interested: Ruchir Brahmbhatt (ruchir) Partner organization: openSUSE.org Description: YaST/YOU times out too easy when downloading large packages like kde- base (14 MB) over a single ISDN connection. Please cache the half downloaded package so I don't have to start from the beginning again. See http://bugzilla.suse.de/show_bug.cgi?id=9740 (http://bugzilla.suse.de/show_bug.cgi?id=9740) http://bugzilla.suse.de/show_bug.cgi?id=278507 (http://bugzilla.suse.de/show_bug.cgi?id=9740) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-30 17:40:31) Klaus, do you now whether this is still an issue? #2: Klaus Kämpf (kwk) (2006-06-30 18:38:23) We still have very large packages (kernel, OpenOffice_org) which might not download completely in one go. #7: Stanislav Visnovsky (visnov) (2007-11-23 10:32:46) Related to commit-refactoring. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:21:33) Klaus, are you still running ISDN? just kidding :-) Stano, please your opinion on workload - is this easily achievable? if not, there are hgher priorities. #10: Stanislav Visnovsky (visnov) (2008-06-20 13:10:21) (reply to #9) Jiri, could we get estimate for this? #11: Jiri Srain (jsrain) (2008-08-04 08:59:34) (reply to #10) Since curl itself does support resuming download, then this feature should not be hard to be implemented. + #12: Ruchir Brahmbhatt (ruchir) (2009-01-17 12:07:25) + I also vote for this feature. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=120326

1 0

[openFate 305586] Desktop independent global notification framework
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Ruchir Brahmbhatt (Ruchir) Feature #305586, revision 9 Title: Desktop independent global notification framework openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stefan Assmann (assmannst) Interested: Alexander Graf (algraf) Interested: Garrett LeSage (glesage) Interested: Guy Lunardi (glunardi) Interested: Jared Allen (jpallen) Interested: Matthias Eckermann (mge1512) + Interested: Ruchir Brahmbhatt (ruchir) Interested: Siegfried Olschner (sdolschn) Interested: Stefan Fent (sfent) Interested: Tejun Heo (teheo) Partner organization: openSUSE.org Description: Our current desktop environments lack a good, configurable notification framework like Growl on Mac OS X. With D-BUS in place we could develop/integrate a framework that is desktop independent and could serve both KDE and GNOME applications the same way. This provides one step towards integrating both desktops more closely, thus making the user experience smoother. One such notification system is already in development. It's called mumbles (http://www.mumbles-project.org/) and provides lots of features similar to Growl. * It's customizable * Has theming support * Has plugin support * Desktop independent * Can use compiz for smooth display Using such a framework, more than just integrating desktops could be achieved: * Local notifications on hardware events * Remote notifications on login/hardware events * Easy scriptability for custom notifications Steps necessary to implement such a framework in openSUSE/SLE: * Install and configure framework by default * Integrate framework configuration in desktop environment * Make framework interactive so the user can react on events (optional) * Make applications D-Bus/Notification aware, so they send events, already available: Firefox, Thunderbird, Pidgin, several others Business case (Partner benefit): openSUSE.org: Such a framework would be a huge win for the general user experience, as it makes the desktop look more integrated and smooth. It's even a good idea for SLES, so administrators can be easily notified when events occur, without the hassle to set up syslog forwarding+parsing+notifying. Discussion: #2: Guy Lunardi (glunardi) (2008-12-18 08:32:18) I agree this is an important part of the desktop platform. How is this different from the libnotify solution which I believe we use for this purpose today? It is my PM understanding it does most everything you are describing including a CLI (notify-send). Applications such as NetworkManager, PowerManager, Pidgin and Banshee. Reading their FAQ, the reason for not using libnotify is that the author wanted to put more Python dependent software on their system :- ). Is this proposal about switching from libnotify to mumbles? (honestly asking, I have no opinion) #3: Stefan Assmann (assmannst) (2008-12-18 15:46:19) (reply to #2) Honestly I have not much insighted into libnotify myself. Talking to Alex Graf about this, we came up with the idea to teach the libnotify daemon how to forward messages to mumbles. It turns out that libnotify has support for theming, so it should be possible to create a theme that forwards all events to mumbles. Then we would not have to make a decision what we should use and could just switch and see what suits us best. This way we don't lose any functionality. In my opinion mumbles looks a lot smoother than the current libnotify messages. However I guess everything possible with mumbles could be tought to libnotify as well. Frankly said I don't want to make a decision here, what I care for is that the functionality described in this fate will be integrated into our products. #4: Stefan Assmann (assmannst) (2008-12-18 16:15:56) (reply to #3) Update: Talking to the developers I just learned that mumbles will intercept libnotify messages and handle them. There's a plugin for mumbles that does that. #5: Tejun Heo (teheo) (2008-12-22 13:28:54) I think that having the notion of what a "notification" is and how the user can take "action"s to it is quite important. There are multiple classes of notifications - some are ephemeral while others must get acknowledgement from the user. For example, download complete from firefox, new driver or codec installation suggestion and smartd reporting imminent disk failures can and probably should use the same notification mechanism but they need to be handled differently. For ephemeral notifications, I think what libnotify has been doing is fine but for anything else, we at least need a way for the user to ack or take actions accordingly and review and search unacked and acked notifications. I think having such notification mechanism will help us a lot as a distro as it will enable us to suggest things in not-too-intrusive yet friendly way. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305586

1 0

[openFate 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Ruchir Brahmbhatt (Ruchir) Feature #304879, revision 19 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important Requested by: Stephan Binner (beineri) Interested: Markus K (kamikazow) Interested: Maxi Schimmel (maxxs) + Interested: Ruchir Brahmbhatt (ruchir) Interested: Stephan Kulow (coolo) Partner organization: openSUSE.org Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304879

1 0

[openFate 303311] Include Pidgin and the Conferencing Plugin for Pidgin
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Ruchir Brahmbhatt (Ruchir) Feature #303311, revision 14 Title: Include Pidgin and the Conferencing Plugin for Pidgin Requested by: Gary Ekker (gekker) + Developer: Michael Wolf (maw) + Interested: Ruchir Brahmbhatt (ruchir) Interested: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: The Teaming + Conferencing product team from the workgroup BU would like us to include pidgin and the conferencing plugin for pidgin in SLED10-SP2. Discussion: #1: Gary Ekker (gekker) (2008-02-15 13:37:24) Pidgin was added. We were unable to add the zon-plugin and libicecore as there are still some packaging issues to be worked out for libicecore. libicecore is also not yet ready for x86_64. #3: Stefan Behlert (sbehlert) (2008-10-23 16:40:14) Gary, Michael, any news on zon-plugin? #4: Stefan Behlert (sbehlert) (2008-11-13 23:49:29) No progress here. I'm rejecting this now. Let's see if we want this for SP1 or if we have EMpathy there anda differen tsolution. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303311

1 0

[openFate 120340] Run download and install in parallel
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Robert Davies (robopensuse) Feature #120340, revision 40 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf <kkaempf(a)novell.com> reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Interested: Ján Kupec (jkupec) Interested: Lukas Ocilka (locilka) + Interested: Robert Davies (robopensuse) Interested: Stephan Binner (beineri) Partner organization: openSUSE.org Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=120340

1 0

[openFate 303517] Automatically refreshing repositories at recurring intervals
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Robert Davies (robopensuse) Feature #303517, revision 26 Title: Automatically refreshing repositories at recurring intervals openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-12 14:12:10 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Interested: J. Daniel Schmidt (jdsn) Interested: Jiri Srain (jsrain) Interested: Jiří Suchomel (jsuchome) + Interested: Robert Davies (robopensuse) 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) (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? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Bruno Friedmann (bruno_friedmann) Feature #305634, revision 22 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) + Interested: Bruno Friedmann (bruno_friedmann) Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Mario Carrion (mariocarrion) Interested: Markus K (kamikazow) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

[openFate 300689] TabletPC: Support Touchscreen and Wacom decives during installation
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Mario Carrion (MarioCarrion) Feature #300689, revision 24 Title: TabletPC: Support Touchscreen and Wacom decives during installation openSUSE-10.3: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2007-08-03 09:39:40 reject reason: installation is frozen Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-16 09:02:38 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stefan Behlert (sbehlert) Interested: Christian Zoz (zoz) Interested: Danny Kukawka (dkukawka) Interested: Gary Ekker (gekker) + Interested: Mario Carrion (mariocarrion) Interested: Philip Oswald (poswald) Partner organization: openSUSE.org Description: Tablet PCs are normally produced in two kinds of flavours: Convertibles, which have a keyboard, and Slates, which have none (only pens or touchscreens). If a user installs a Slate, he has no keyboard and no (pohysical) mouse device, only the touchscreen. We should on TabletPCs automatically recognize that it is a TabletPC and configure the Wacom or other Touchscreen device where possible. Thus would enhance the usability of the product on TabletPCs. Discussion: #1: Gary Ekker (gekker) (2007-07-17 11:24:05) Stefan, do you see this as work that your team would do, something that needs to be done by the YaST installer, or both? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300689

1 0

[openFate 300688] Show virtual keyboard on TabletPC during installation
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Mario Carrion (MarioCarrion) Feature #300688, revision 39 Title: Show virtual keyboard on TabletPC during installation openSUSE-10.2: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2006-09-25 14:06:21 reject reason: Not enough resources. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Edith Parzefall <emapedl@please-enter-an-email-address> reject date: 2007-07-24 14:21:32 reject reason: Sorry, not doable for 10.3. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Michael Loeffler <michl(a)novell.com> reject date: 2008-01-11 16:39:04 reject reason: out of scope for openSUSE Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Stefan Behlert (sbehlert) Interested: Gary Ekker (gekker) Interested: Jiri Srain (jsrain) + Interested: Mario Carrion (mariocarrion) Interested: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: Tablet PCs are normally produced in two kinds of flavours: Convertibles, which have a keyboard, and Slates, which have none (only pens or touchscreens). If a user installs a Slate, he has to press e.g. buttons without having a keyboard to do it. Additionally he has no mouse device (except his pen) to press buttons. To do so, two ways are possible: Either using some kind of graffiti scribbling, which makes entering e. g. the password an adventure, or by providing a virtual keyboard where the user can select the characters. The second possibility is far superior and also used by Windows. It should be simply to blend xvkbd into the screen. Only possible problems: If a 800x600 resolution is used, the display is really small for both Yast and the keyboard. Discussion: #3: Edith Parzefall (emapedl) (2006-09-20 17:04:28) Jiri, do you see any chance to have it done in your team? Otherwise, I'd reject it. #6: Stephan Kulow (coolo) (2008-01-11 13:50:29) I would think that such devices are out of context for openSUSE 11.0, but asking Michl. How would this look like? Would the xvkbd always be visible and yast screen reduced accordingly? #7: Michael Loeffler (sprudel24) (2008-01-11 16:38:08) As long as this is not required by SLED this is out of scope for openSUSE. #10: Guy Lunardi (glunardi) (2008-01-18 17:34:09) Gartner projects 5% to 20% market penetration for Tablet PCs in the Healthcare. It is positioned as: "Tablet PCs meet all the criteria for a notebook PC and are equipped with a pen and an on-screen digitizer". "The tablet PC is solid and mature for vertical applications where it solves a specific problem. Of course there are 2 kinds of tablets, with physical keyboard and without (slab). I had to install openSUSE 10.3 on a slab myself and must admit that on-screen would have been nice. Is there an engineering effort estimate that could be looked at before we reject it for SLED11? #11: Stefan Behlert (sbehlert) (2008-05-21 21:39:58) (reply to #10) Duncan, any effort estimation? #13: Guy Lunardi (glunardi) (2008-06-23 11:44:51) (reply to #11) As we discussed, support for tablet is primarly critical at runtime. if we can add support for the install, that would be great even for accessibility reasons. I think we should focus our resources on making sure that tablets work well once the system is installed. #14: Duncan Mac-Vicar (dmacvicar) (2008-11-18 13:38:12) (reply to #13) Sure, but this was rejected because there are no resources to do it. So what did we had to drop in order to make it? Without reprioritization there is nothing we can do. I will provide an effort estimation for a next cycle. Estimating the effort here means basically prototyping it, and that just can't be done. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300688

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 17 Jan '09

17 Jan '09

Feature changed by: Mario Carrion (MarioCarrion) Feature #305634, revision 21 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) + Interested: Mario Carrion (mariocarrion) Interested: Markus K (kamikazow) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Markus K (KAMiKAZOW) Feature #305634, revision 20 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) + Interested: Markus K (kamikazow) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

[openFate 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Markus K (KAMiKAZOW) Feature #304879, revision 18 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important Requested by: Stephan Binner (beineri) + Interested: Markus K (kamikazow) Interested: Maxi Schimmel (maxxs) Interested: Stephan Kulow (coolo) Partner organization: openSUSE.org Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304879

1 0

[openFate 303736] yast and libzypp should respect the disk space reserved for root
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: robermann79 robermann79 (robermann79) Feature #303736, revision 6 Title: yast and libzypp should respect the disk space reserved for root openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-08 12:18:47 reject reason: Postponing. This is nice to have. Priority Requester: Desirable openSUSE-11.2: New Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) + Interested: robermann79 robermann79 (robermann79) Partner organization: openSUSE.org Description: If e.g. root partition has 70MB free user space and 500MB free space reserved for root user yast reports 570MB total free space. But installation of a package which is greater than 70MB fails: installing package kdelibs3-devel-doc-3.5.5-45 needs 335MB on the / filesystem Yast should display the non-root free space (70MB in this case). It seems that it is valid only for ext2/ext3 filesystems (XFS and ReiserFS seem to not support root space). Default reserved space for ext2/ext3 is 5%. References: https://bugzilla.novell.com/show_bug.cgi?id=237309 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303736

1 0

[openFate 303527] Resolve dependencies after ignoring package download failure
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: robermann79 robermann79 (robermann79) Feature #303527, revision 19 Title: Resolve dependencies after ignoring package download failure openSUSE-11.1: Done Priority Requester: Desirable Projectmanager: Desirable Requested by: Ján Kupec (jkupec) Interested: Josef Reidinger (jreidinger) + Interested: robermann79 robermann79 (robermann79) Partner organization: openSUSE.org Description: YaST and Zypper should run the solver before resuming installation if download of a package fails and the user chooses to ignore that package. Currently YaST continues withough solving which makes the ignore button useful only if the user knows how the missing package will affect the system. References: https://bugzilla.novell.com/show_bug.cgi?id=340345#c4 http://lists.opensuse.org/zypp-devel/2008-03/msg00025.html Documentation Impact: Check whether this has documentation impact Thus far not even the ignore button is documented, because we are not writing reference documentation, but procedure docs. Thus I think we can drop documentation for this feature. Discussion: #1: Federico Lucifredi (flucifredi) (2008-06-13 15:13:41) bit of a corner case. #2: Ján Kupec (jkupec) (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) (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) (2008-07-11 10:22:19) (reply to #3) That should be pretty simple. #5: Ján Kupec (jkupec) (2008-09-12 11:09:55) done in zypper, handing over to Lada for YaST #6: Ladislav Slezak (lslezak) (2008-09-12 16:00:59) (reply to #5) Implemented in yast2-2.17.23. After pressing [Ignore] user is advised to run the Software Management module (sw_single) to verify the system later. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303527

1 0

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

16 Jan '09

Feature changed by: Luuk de Waal Malefijt (Tails9) Feature #304911, revision 10 Title: Import all GPG keys at once before downloading the metadata from new repositories openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> 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 Requested by: Ladislav Slezak (lslezak) Interested: Guy Lunardi (glunardi) Interested: Klaus Kämpf (kwk) + Interested: Luuk de Waal Malefijt (tails9) Interested: Marcus Kraft (marcuskraft) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) Interested: Security Team (secteam) Partner organization: openSUSE.org 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: -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304911

1 0

[openFate 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Maxi Schimmel (maxxs) Feature #304879, revision 17 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important Requested by: Stephan Binner (beineri) + Interested: Maxi Schimmel (maxxs) Interested: Stephan Kulow (coolo) Partner organization: openSUSE.org Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304879

1 0

[openFate 303678] New yast module - LIRC configuration
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Maxi Schimmel (maxxs) Feature #303678, revision 10 Title: New yast module - LIRC configuration openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-06-24 15:31:30 reject reason: More urgent stuff to cover. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) + Interested: Maxi Schimmel (maxxs) Partner organization: openSUSE.org Description: Create a new Yast module for configuring IR receivers and remote controls. * irrecord support * ir-kbd-i2c, ir-kbd-gpio support as in tv module already * reading users' config to find out what buttons were defined (only if /home partition left from last installation) * support for lirc's options in /etc/sysconfig See bug https://bugzilla.novell.com/show_bug.cgi?id=381641 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303678

1 0

[openFate 301207] Support encrypted partitions in mediamanager
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Maxi Schimmel (maxxs) Feature #301207, revision 35 Title: Support encrypted partitions in mediamanager openSUSE-10.2: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2006-10-25 12:10:25 reject reason: no time left Priority Requester: Important Projectmanager: Important openSUSE-10.3: Rejected by Jared Allen <jpallen(a)novell.com> reject date: 2007-08-13 19:01:49 reject reason: Didn't make it. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Dirk Mueller <dmueller(a)novell.com> reject date: 2008-04-11 16:44:11 reject reason: out of time due to KDE4 switch Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-07-16 15:48:12 reject reason: The common encrypted partition cases are handled already and there is a lack of time before feature freeze. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stephan Kulow (coolo) Interested: JP Rosevear (jproseve) + Interested: Maxi Schimmel (maxxs) Interested: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: KDE's mediamanager currently only supports volumes from HAL, which excludes encrypted partitions only listed in fstab. This needs integrated support including new strings to indicate it's encrypted. Discussion: #1: Stephan Kulow (coolo) (2007-11-16 11:40:04) encrypted partitions become more and more popular, so we should get forward here. We support encryption for removable media now thanks to Daniel's work, but partitions are still out from media:/ #2: Dirk Mueller (dirkmueller) (2008-03-25 11:28:48) there is a improved solution for KDE3 thanks to Tom Patzig. This needs forward port to KDE4 however for 11.0, which will be a non-trivial amount of work. I would say it is 2-3 weeks to get it done properly, including learning solid. #3: Dirk Mueller (dirkmueller) (2008-04-11 16:43:37) the time is not available, beta1 is imminent and there are too many other things to fix. #4: Guy Lunardi (glunardi) (2008-06-03 22:34:50) (reply to #3) Should this be re-prioritize for openSUSE 11.1? Sounds like an important feature. #7: Dirk Mueller (dirkmueller) (2008-06-13 15:06:01) (reply to #4) I'm not sure.. the typical use case of encrypted non-hotpluggable media is to have an encrypted home partition, and you have to mount that on boot, otherwise you can't login. I don't know what the use case or the customer value for this feature is. #9: Daniel Gollub (dgollub) (2008-06-13 15:42:54) (reply to #7) This is already implemented: # cryptconfig make-ehd luks image per user in /home/ + pam_mount #10: Dirk Mueller (dirkmueller) (2008-06-13 15:58:52) (reply to #9) yep, I guess this feature is however about other custom mounts, that shouldn't be mounted via pam_mount (??) #5: JP Rosevear (jproseve) (2008-06-13 08:18:02) Dirk, whats the upstream status of this now? #6: Dirk Mueller (dirkmueller) (2008-06-13 15:01:56) KDE4 (upstream and openSUSE) supports encryted hotpluggable media (usb sticks etc) just fine, but this particular feature, the manually to /etc/fstab added feature is not there afaik. #8: Dirk Mueller (dirkmueller) (2008-06-13 15:09:54) (reply to #6) I'll have to check if my understanding is correct, hence still needinfo #11: Dirk Mueller (dirkmueller) (2008-06-23 10:44:56) (reply to #8) support for fstab-only is not upstream #12: Andreas Jaeger (a_jaeger) (2008-07-07 13:03:21) (reply to #11) OK, so let's evaluate what needs to be done for this - and whether we should move it to 11.2. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301207

1 0

[openFate 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Maxi Schimmel (maxxs) Feature #303532, revision 16 Title: Reduce size of updates for openSUSE Factory Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter <adrian(a)novell.com> reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Loeffler (sprudel24) Interested: Duncan Mac-Vicar (dmacvicar) Interested: Gerald Pfeifer (geraldpfeifer) Interested: Klaas Freitag (kfreitag) Interested: Lukas Lipavsky (llipavsky) + Interested: Maxi Schimmel (maxxs) Interested: Michal Marek (michal-m) Interested: Peter Poeml (poeml) Interested: Ruediger Oertel (oertel) Interested: Stephan Kulow (coolo) Interested: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant. Discussion: #1: Stephan Kulow (coolo) (2008-03-27 16:48:43) According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them. So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors. #2: Duncan Mac-Vicar (dmacvicar) (2008-04-22 13:28:56) This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today. #3: Duncan Mac-Vicar (dmacvicar) (2008-05-26 17:09:31) ZYpp side is done. The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly. #4: Gerald Pfeifer (geraldpfeifer) (2009-01-03 14:54:00) Opening this up for openSUSE.org. #5: Stephan Kulow (coolo) (2009-01-16 08:24:42) ok, we discussed this a bit further. We plan to throw away builds that are equal to the previous build and publish deltas generated by the build clients if they are not equal. If a build is equal is to be defined, for now it's a shell script that checks various properties - and works acceptable for now. I rebuild a good portion of 11.1 without further changes and get 7345 binary rpms (including all subpackages). 5666 are considered equal by my current script (based on work by Michael Matz). And many of other packages are possible to fix, so they are equal too. So this gives for uneffected rebuilds a huge reduction of updates. The kernels and kmps are currently seen as !equal after an uneffected rebuild as they put the %release (rebuild counter) in many places. Not sure how much the script should work around such cases. But even for those the download size would reduce: kernel-default.i586 (with base and extra): 25.7MB to download deltas of it: 6.7MB (I think the kernel puts a lot of "rebuild on" info in the code) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303532

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Maxi Schimmel (maxxs) Feature #305634, revision 19 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Matthias Eckermann (mge1512) + Interested: Maxi Schimmel (maxxs) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

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

16 Jan '09

Feature changed by: Maxi Schimmel (maxxs) Feature #304911, revision 9 Title: Import all GPG keys at once before downloading the metadata from new repositories openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> 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 Requested by: Ladislav Slezak (lslezak) Interested: Guy Lunardi (glunardi) Interested: Klaus Kämpf (kwk) Interested: Marcus Kraft (marcuskraft) Interested: Matthias Eckermann (mge1512) + Interested: Maxi Schimmel (maxxs) Interested: Security Team (secteam) Partner organization: openSUSE.org 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: -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304911

1 0

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

16 Jan '09

Feature changed by: Marcus Meissner (msmeissn) Feature #304911, revision 8 Title: Import all GPG keys at once before downloading the metadata from new repositories openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> 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 Requested by: Ladislav Slezak (lslezak) Interested: Guy Lunardi (glunardi) Interested: Klaus Kämpf (kwk) Interested: Marcus Kraft (marcuskraft) Interested: Matthias Eckermann (mge1512) + Interested: Security Team (secteam) Partner organization: openSUSE.org 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: -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304911

1 0

[openFate 303517] Automatically refreshing repositories at recurring intervals
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Robert Davies (robopensuse) Feature #303517, revision 25 Title: Automatically refreshing repositories at recurring intervals openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-12 14:12:10 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Interested: J. Daniel Schmidt (jdsn) Interested: Jiri Srain (jsrain) Interested: Jiří Suchomel (jsuchome) 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) (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? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 305168] default to relatime
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Robert Davies (robopensuse) Feature #305168, revision 7 Title: default to relatime 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 (michael_meeks) Interested: Guy Lunardi (glunardi) Interested: Jan Kara (jankara) Interested: Marcus Meissner (msmeissn) + Interested: Robert Davies (robopensuse) 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. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 + Discussion: + #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) + Bug #461829 is not requesting breaking POSIX semantics by default! + relatime should replace noatime option in the mount options part of + partioner tool, especially now it has been improved to update atime on + file access if it's older than 24 hours. + Standards are important, and LRU file caches cannot be relied on if + noatime usage is common, or if poor backup software touches atimes, + when reading files. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305168

1 0