January 2017 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 313441] Easy Upgrade
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Mário Castanheira (SpeccyMan) Feature #313441, revision 1 Title: Easy Upgrade openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Mário Castanheira (speccyman) Partner organization: openSUSE.org Description: An easy way to allow users to make upgrades (e.g.: changing from version 12.1 to version 12.2) as easy as they can in Ubuntu. Something like one-click, instead of having to deal whit the work of disable and update of the repositories manually. Would be good if all this would be automatic and maybe even integrated it into the new Software Center. Use Case: User gets notified that there's a new version of opensuse available and it is asked if he wishes to upgarde. If he selects "upgrade" the system should ask for permissions and then start upgrading itself. (pretty much like in ubuntu). Nothing else required! Business case (Partner benefit): openSUSE.org: Because it will invite users to keep their distro in it's last version, even if they don't understand much about computers! And because it's something all Ubuntu users keep saying it's one of their loved features. -- openSUSE Feature: https://features.opensuse.org/313441

1 34

[openFATE 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature changed by: Oliver Kurz (okurz) Feature #303532, revision 37 Title: Reduce size of updates for openSUSE Factory Buildservice: Rejected by Lars Vogdt (lrupp) reject date: 2011-04-20 19:16:50 reject reason: We already reduce the size of Factory updates by using build compare. Milestone: 2.5 Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) 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 (adriansuse) 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 Löffler (michl19) 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. References: packages: obs-server + Relations: + - idea for delta-rpm support in openSUSE Tumbleweed (url: + https://progress.opensuse.org/issues/10352) 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. #7: Andreas Jaeger (a_jaeger) (2009-07-14 21:36:57) (reply to #3) What is the status of the Build Service side for this? #8: Adrian Schröter (adriansuse) (2009-09-15 16:42:11) (reply to #7) Partly implemented, the build-compare support exists, delta generation support is currently out of scope (if done on build host, it would need adaptions in backend parts. If done on extra(mirror) host, it would need to resign content, which breaks security concepts). #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) #6: Piotrek Juzwiak (benderbendingrodriguez) (2009-06-17 17:29:42) As an addition to that it would be great if the older package would stay until the second rebuild so that if something breaks we could go back to the previous version and report that something's wrong with the new one. #9: Lars Vogdt (lrupp) (2009-10-01 12:33:06) (reply to #6) Having backups is always a good idea. But as we've just limited space (internally and on our mirrors) I don't think that we can implement this. #10: Stephan Kulow (coolo) (2009-10-01 13:03:18) (reply to #9) download.o.o will keep the old versions alive and the mirrors only get the latest. #11: Ralph Ulrich (ulenrich) (2009-10-01 14:56:11) Why not a more differentiated factory scheme like Debian: - unstable - testing (less frequently changes) Something similar is implemented now using factory snapshots ? -- openSUSE Feature: https://features.opensuse.org/303532

1 0

[New: openFATE 310405] yast2 wagon should be a fully graphic upgrade tool
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Greg Freemyer (gregfreemyer) Feature #310405, revision 1 Title: yast2 wagon should be a fully graphic upgrade tool openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Greg Freemyer (gregfreemyer) Description: I really like it that yast2-wagon exists for users to upgrade from release to release. It effectively does a zypper dup, but via a nicer gui interface. The trouble in my mind is that it still takes way to many seperate steps as is. Quoting just the top level details from http://old-en.opensuse.org/Wagon === 1) Ensure you have yast2-wagon installed 2) As of openSUSE 11.2 Wagon will update the upgrade stack as part of its automated process, so there is no need to ensure you have run zypper up or equivalent 3) Ensure you have the the correct repositories enabled 4) Start YaST2 wagon 5) Follow the dialogs 6) reboot === Taking those steps one at a time: 1) yast2-wagon should be part of the standand yast pattern in my opinion. It currently is not, so it has to be separately installed which makes little sense for a tool designed to simplify the upgrade process. 2) That was a great improvement that went into 11.2, so I'm happy. (Other than the current bugzilla against the yast2-wagon dependencies in the 11.3 release. I wish that would be fixed.) 3) It would be great if yast2-wagon would launch with a user selectable distro to upgrade to. Then once a user selected 11.4 as an example, it would walk the user through upgrading his repos to the 11.4 compatible ones. 4) Once 3) is incorporated it would be great to get a easy to click icon for wagon either within yast itself, or on the system menus. 5) This appears to be an effort to achieve automatic repo updates, but I'm not sure. Unfortunately, the above can be implemented for the 11.3 => 11.4 upgrade but only if the upgraded yast2-wagon is released via online update. That is because it involves updating the repo handling prior to pulling down a new copy of wagon from the 11.4 repos. -- openSUSE Feature: https://features.opensuse.org/310405

1 4

[openFATE 308189] Consolidating terminology: update and upgrade
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Karl Eichwalder (keichwa) Feature #308189, revision 1 Title: Consolidating terminology: update and upgrade openSUSE-11.3: New Priority Requester: Mandatory Requested by: Karl Eichwalder (keichwa) Partner organization: openSUSE.org Description: In the past, we just used the term "update" for all update related things, because we were told "upgrade" is suitable for hardware related upgrades only. With the advent of zypper, the term "upgrade" (dup, dist-upgrade) is back for upgrading the system complete from one version "n" to the next version "n+1" (yes, you can "upgrade" within one version, but that's a special case...). The term is fine and I'd like us to use "upgrade" in YaST and everywhere else where suitable. Business case (Partner benefit): openSUSE.org: Avoid confusion. ATM, I'm force to use different terms in the chapter of the manual, if I describe the same task. -- openSUSE Feature: https://features.opensuse.org/308189

1 13

[New: openFATE 312799] Safer distribution updates
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Duncan Mac-Vicar (dmacvicar) Feature #312799, revision 1 Title: Safer distribution updates openSUSE Distribution: New Priority Requester: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: Michael Elliott (mge) Developer: ma ds (ma) Partner organization: openSUSE.org Description: Currently the documentation says that to do a distribution upgrade you should first update your software stack to the target distribution, then do a zypper dup. The software stack update can already kill your system. zypper could allow an option that makes it first install a miniroot containing the update stack itself, then automatically switch over to the miniroot to do the "zypper dup". Use Case: Bob wants to migrate his server from SLE12 to SLE13. Upgrading the package management stack fails, but he keeps his original system untouched. Business case (Partner benefit): openSUSE.org: Failsafe migrations for SLE -- openSUSE Feature: https://features.opensuse.org/312799

1 18

[openFATE 308147] Simplify "Online update" in Yast
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Birger Kollstrand (MrKane) Feature #308147, revision 1 Title: Simplify "Online update" in Yast openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Birger Kollstrand (mrkane) Description: In 11.2 there are two Online Update applications - one for configuration of online update - one for doing a manual online update I suggest that this is merged to one application which looks mostly like todays "Online update configureation" but has an aditional button on the page that when pushed does an online update. This will simplify the Yast GUI. -- openSUSE Feature: https://features.opensuse.org/308147

1 1

[New: openFATE 316789] Fundamental re-design how to set up the whole printing stuff
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Johannes Meixner (jsmeix) Feature #316789, revision 1 Title: Fundamental re-design how to set up the whole printing stuff Requested by: Johannes Meixner (jsmeix) Partner organization: openSUSE.org Description: The current YaST printer module provides different buttons (i.e. entry points) with different workflows for the different kind of printing setup actions: One via "Add", one via "Printing via Network", one via "Share Printers", and so on. This means the user must know in advance what to choose for his particular kind of printing setup. The software cannot guide the user towards the right entry point according to what the user wants to get in the end. To guide the user towards an actually right solution the initial dialog should show the list of currently available print queues plus one single button to "do whatever can be done" when something is not as expected (e.g. when something is missing) in that list. This means a fundamental re-design of the dialogs and workflows to set up the whole printing stuff is needed. -- openSUSE Feature: https://features.opensuse.org/316789

1 13

[New: openFATE 322318] ake it possible to exclude foreign OS' from the bootloader menu
by fate_noreply＠suse.de 09 Jan '17

09 Jan '17

Feature added by: Richard Bos (rbos) Feature #322318, revision 1 Title: ake it possible to exclude foreign OS' from the bootloader menu openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Richard Bos (rbos) Partner organization: openSUSE.org Description: When a system has many OS' (Linux') installed and probe for 'foreign OS' is enabled, the bootloader menu becomes cluttered with many entries. To prevent a cluttered bootloader menu, functionality to exclude certain partitions is desired. The attached patch (etc_grub2_30_os-prober.patch) to /etc/grub.d/30_os-prober provides this functionality. The 2nd attachment (30_os-prober-exclude) can be used to test the functionality. Now YaST2/bootloader should support this, to make it work. At the bootloader options tab, there should be a possibility to list which partitions are to be excluded from the bootloader menu, for example: Partitions to be excluded from the bootloader menu [ /dev/sda1 /dev/sda4 ] Together with the attached patch, only the desired partitions will be included in the bootloader menu. Even nicer would be to show a list with OS' that can be (un)checked to be excluded from the bootloader menu: [x] Probe foreign OS [x] /dev/sda1:CentOS^release^6.2^(Final):RedHat:linux [x] /dev/sda3:openSUSE^13.1^(x86_64):SUSE:linux [x] /dev/sda4:openSUSE^12.2^(x86_64):SUSE1:linux [x] /dev/sdb6:openSUSE^13.1^(x86_64):SUSE2:linux By default all OS' are selected, and the user can deselect the partitions, he/she does not want to show up in the bootloader menu. Detailed information, including screenshot and possible patch are available in bug report: https://bugzilla.suse.com/show_bug.cgi?id=1017765#c0 Business case (Partner benefit): openSUSE.org: To prevent a clutter boot menu. -- openSUSE Feature: https://features.opensuse.org/322318

1 2

[New: openFATE 322317] Remove /var/run from tmpfs filesystems
by fate_noreply＠suse.de 09 Jan '17

09 Jan '17

Feature added by: Juha Virtanen (jiivee) Feature #322317, revision 1 Title: Remove /var/run from tmpfs filesystems openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Juha Virtanen (jiivee) Partner organization: openSUSE.org Description: Requested feature: Remove /var/run from list of available tmpfs filesystems during installation of Suse family of OSs. Tumbleweed installation allows (like all other Suse versions) to create /tmp, /run, /var/lock and /var/run as separate tmpfs filesystems. Recently (sometime on last November) Tumbleweed behaviour changed so that many things don't work or are very slow, if /run and /var/run are separate. See <https://forums.opensuse.org/showthread.php/521509-X-broke-gt-after-new-inta…> for more info. Solution for experienced problems was to remove entry for /var/run from /etc/fstab and leave bind mounting /var/run to /run for systemd boot process. See also bug 1017683, <https://bugzilla.suse.com/show_bug.cgi?id=1017683>. Business case (Partner benefit): openSUSE.org: /var/run must be a bind mount of /run. At least in Tumbleweed. -- openSUSE Feature: https://features.opensuse.org/322317

1 1

[New: openFATE 321183] Add package Money Manager Ex
by fate_noreply＠suse.de 09 Jan '17

09 Jan '17

Feature added by: Jorge Vallejo (Geoplace1) Feature #321183, revision 1 Title: Add package Money Manager Ex Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Jorge Vallejo (geoplace1) Partner organization: openSUSE.org Description: http://www.moneymanagerex.org/ These is a great open source Finance Manager. Could you make it available to install on opensuse, please? Regards. -- openSUSE Feature: https://features.opensuse.org/321183

1 3