June 2016 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 311697] zypper progress indicator
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: Bryen Yunashko (byunashko) Feature #311697, revision 1 Title: zypper progress indicator openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Bryen Yunashko (byunashko) Partner organization: openSUSE.org Description: Provide an indicator using zypper up or zypper dup to let the user know how far along the process is (preferably by percentage.) Use Case: Especially challenging if you are in the middle of zypper updates and unsure how far along you need to do something else (even possibly come back to the machine. Knowing what percentage of the progress is completed would be useful. I don't think we want some other type of indicator (e.g. how much time left) because there's too many variables. But a percentage should be fairly straightforward. We know how many packages are to be downloaded/installed and how many are completed so far. Business case (Partner benefit): openSUSE.org: Makes use of zypper less intimidating to some users who feel they are at the mercy of a command that doesn't tell them how they are doing. -- openSUSE Feature: https://features.opensuse.org/311697

1 5

[New: openFATE 311696] Auto-disable trackpad when external mouse detected
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: Bryen Yunashko (byunashko) Feature #311696, revision 1 Title: Auto-disable trackpad when external mouse detected openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Bryen Yunashko (byunashko) Partner organization: openSUSE.org Description: Give the user the option to request the system automatically disable the trackpad on laptops when an external mouse (USB, Wireless, etc.) is detected. Use Case: In many cases, having the trackpad (which is usually ill-placed where your hands are supposed to rest) causes the typist to accidentally brush against it and cause typing errors. This is also a problem for some people with accessibility needs who require a different mouse and the trackpad can cause problems. Control Center offers an option to disable the trackpad in GNOME. (Not sure about KDE) but this is a problem if you do not always attach your mouse to your laptop. Then you have a disabled trackpad the next time you boot up. So it's not a very good workaround to this problem. Business case (Partner benefit): openSUSE.org: It would enhance the user experience. I'm told that Windows has this option (though I haven't used Windows in ages.) and I'm also told that other Linux distributions don't seem to have this feature yet either. -- openSUSE Feature: https://features.opensuse.org/311696

1 2

[New: openFATE 311485] "auto" update distribution
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: NIkolai Stoilov (NikolaiSS) Feature #311485, revision 1 Title: "auto" update distribution openFATE: Unconfirmed Priority Requester: Important Requested by: NIkolai Stoilov (nikolaiss) Partner organization: openSUSE.org Description: When we can upgreid distribution as ubuntu? -- openSUSE Feature: https://features.opensuse.org/311485

1 5

[New: openFATE 310229] Add write support for NTFS partitions, using the NTFS-3G.
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: Genix Info (genixinfo) Feature #310229, revision 1 Title: Add write support for NTFS partitions, using the NTFS-3G. openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Genix Info (genixinfo) Description: My suggestion is to add write support on NTFS partitions, being a regular user (not root). -- openSUSE Feature: https://features.opensuse.org/310229

1 18

[New: openFATE 310980] Monthly Qt updates
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: Johannes Obermayr (jobermayr) Feature #310980, revision 1 Title: Monthly Qt updates openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Johannes Obermayr (jobermayr) Partner organization: openSUSE.org Description: KDE has monthly updates and mainly depends on Qt. Qt only has updates from time to time. If you have crashes with KDE apps which are caused by (resolved) Qt bugs (e.g. Â¹Â²) we push them (days/weeks/months/years/decades?) in front of us until a new Qt release. Since a roadmap and/or monthly releases are not relevant for Qt/NokiaÂ³ we should provide own monthly releases of specific current stable branch in KDE:Qt together with KDE in KDE:Distro:Factory (it _link/_aggregate KDE:Qt). May creating additional repositories in KDE:Distro:Factory and KDE:Unstable:SC building against a KDE:QtFactory repository which includes mentioned above "releases" could also do the job ... Â¹ http://bugs.kde.org/show_bug.cgi?id=249373 Â² http://bugreports.qt.nokia.com/browse/QTBUG-15857 Â³ http://bugreports.qt.nokia.com/browse/QTBUG-15975 -- openSUSE Feature: https://features.opensuse.org/310980

1 3

[New: openFATE 314493] Reuse existing Windows EFI System Partition by default
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: Michael Chang (michael-chang) Feature #314493, revision 1 Title: Reuse existing Windows EFI System Partition by default openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Michael Chang (michael-chang) Partner organization: openSUSE.org Description: The current installer will create new EFI System Partition (ESP) if Windows EFI System Parititon exists. The rationale is that we are not sure the consequence about integration an Linux boot into an existing Windows setup. About consideration may not be necessary as ESP is defined in UEFI specification as common places for OS loaders, which differentiate by their own paths. There's no concept that ESP is specific to OS and be exclusive access from it. That would also lead to several issues as two ESP is confusing in general to the firmware and OS tools as they would assume only one single ESP as valid. Here are some of the failure case illustrated. 1. Modify (or repair) Windows boot configuration (BCD) on such system, two system partitions make Windows quite unhappy. It completely ruined boot configuration until hiding (by changing partition type) the one created by SUSE. 2. Boot loader config may be separated from one another as they're potentially placed in different ESP. This would lead to multiboot EFI loader (rEFIt) or any multiboot prober to be able to config the setup correctly. -- openSUSE Feature: https://features.opensuse.org/314493

1 3

[New: openFATE 318181] updates
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: Peter Høgstedt (hoegstedt) Feature #318181, revision 1 Title: updates openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Peter Høgstedt (hoegstedt) Partner organization: openSUSE.org Description: I uninstalled SUSE because updating is impossible. In theory it might Work, but in practice I am 'unable to connect ...' then trying Again later etc. etc. I believe the servers (and yes I did try different ones)are too slow or too crowded but maybe something else is wrong. At any rate I finally switched to Debian for that one and only reason - here updates do Work. Even if I am doing something 'wrong' it still means that SUSE really should do something to address the problem. The abilyty to update is of cause essential. SUSE has many other good features so I am kind of sorry that I switched - but now you know the reason. It is of cause utterly irrelevant if I am the only person having this problem - but this is very unlikely. If it is a hidden policy of SUSE that updates should really not be available then tell it openly - that way a lot of people would waste al lot less time. -- openSUSE Feature: https://features.opensuse.org/318181

1 3

[New: openFATE 314818] Life cycle for OpenSUSE
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: Juraj Václavík (juvi) Feature #314818, revision 1 Title: Life cycle for OpenSUSE openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Juraj Václavík (juvi) Partner organization: openSUSE.org Description:  Although this theme has been here many times, I return it again. The reason is discussion in Ubuntu and Fedora communities, that reflects the same problems, as exists in OpenSUSE.. I think, that today's concept is not good and limiting the spreading this, I think, very good distribution into population. Today's concept generates every 8 (or another number) months a quite new distribution. That distribution includes the newest features â but it is suitable for only a small group of users, as these features significantly decreases the platform stability. I think, that surely exists good concepts, that can solve it. I think, that only determining a some period is not a solution, as, of course, every quite new system must have a lot of bugs. To get a good and stable distribution this distribution must have a time for consolidation. I also think, that OpenSUSE has a good tools that is very suitable for solving problems, that my concept require: good work with repositories, rolling update â thumbleweed and alternatively evergreen. I think, that we can search solution easy by: 1) Prolongation the life cycle â the new major version distribution can start every approximately 18 â 24 months. 2) structure the life cycle â development stage, stabilization stage, production stage, maintenance stage, (evergreen stage?) 3) generating production distributions from âthe actual state of the artâ - every 6 months The period of stages let is a theme for discussion. I think, that developing stage can take about 6 months. This stage finished by generating the âzeroâ minor number distribution â that is not for production use. It follows stabilization stage â ~3 months, that includes minor number 1 and 2. The minor number 2 started the stable stage, that continues by releasing minor number every 6 month (3, 4, 5). During this stage can be accepted new version of applications, but only repaired and actualized version of desktop environment, compiler and libraries. Maybe some exceptions for last minor version? What about new version of kernel â it is theme for discussion. Every minor number releases since 2 have own maintenance stage â I suggest 9-12 months and last (minor number 5) 18 months; this concept expects massive using rolling update between minor version of distributions. It would be interesting to have extra stage for last version (5) â evergreen. Probably it is necessary to synchronize OpenSUSE development cycle with SLES/SLED, but it concerns only duration of stages â I can imagine, that minor version 2 can be a base of this commercial distributions and (last) version can be base for âservice packâ and it is also reason for some exception and more extensively updating. -- openSUSE Feature: https://features.opensuse.org/314818

1 7

[New: openFATE 315095] I want a special version of openSUSE,like Ubuntu Studio and Fedora Design Suite.
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: huang sr (huangsr2012) Feature #315095, revision 1 Title: I want a special version of openSUSE,like Ubuntu Studio and Fedora Design Suite. openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: huang sr (huangsr2012) Partner organization: openSUSE.org Description: Ubuntu Studio is an official flavor of Ubuntu, and the most widely used multimedia orientated GNU/Linux distribution in the world. It comes preinstalled with a selection of the most common free multimedia applications available, and is configured for best performance for the Ubuntu Studio defined workflows: Audio, Graphics, Video, Photography and Publishing. Fedora Spins are alternate version of Fedora, tailored for various types of users via hand-picked application sets and other customizations. -- openSUSE Feature: https://features.opensuse.org/315095

1 2

[New: openFATE 316462] new release cycle idea
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: Jörg Stephan (johest) Feature #316462, revision 1 Title: new release cycle idea openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Jörg Stephan (johest) Partner organization: openSUSE.org Description: As seen at http://amelinux.blogspot.de/2013/08/opensuse-new-idea.html I really would like to discuss the current release circle. I know it was a community discussion which lead to this 8 month timeline. But i guess it would be best to change this again. In my mind it would be best to support tumbleweed more and release a stable evergreen like distribution with 2 years release cycle and minor changes from tumbleweed upstream. The release should include: * A Desktop system like we already have * A server system (kernel, software) * Proffesional "forks" like terminal server, small business The new release cycle (like seen in the picture): For example called openSUSE 14 Every two years, the tumbleweed will be freezed for evergreen release. Every 6 month any minor change of software will be pushed to 14.n+1 until the release of the next major openSUSE release -- openSUSE Feature: https://features.opensuse.org/316462

1 2