November 2015 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 313233] Get Zypper to remove installed patterns
by fate_noreply＠suse.de 15 Jan '16

15 Jan '16

Feature added by: Drew Adams (Druonysus) Feature #313233, revision 1 Title: Get Zypper to remove installed patterns openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Drew Adams (druonysus) Partner organization: openSUSE.org Description: Get Zypper to remove a pattern. Zypper can install a pattern nut when going to remove that same pattern, Zypper does not remove that pattern... When do a: "zypper rm -t pattern <pattern name>" Zypper, just tells you: "Uninstallation of a pattern is currently not defined and implemented." You CAN remove a pattern in YaST so I would think that there should be a way to remove the pattern with Zypper. "yum groupremove <group name>" works on Fedora/CentOS/RHEL... we should really have this working to keep up with them. Use Case: If I build a bare openSUSE image on SUSE Studio, and I decide not to install yast and only Zypper... I will only be able to install patterns but NO way to remove it. -- openSUSE Feature: https://features.opensuse.org/313233

1 2

[New: openFATE 312293] Option to disable disk check on certian volumes in YaST
by fate_noreply＠suse.de 04 Jan '16

04 Jan '16

Feature added by: Dean Hilkewich (deanjo13) Feature #312293, revision 1 Title: Option to disable disk check on certian volumes in YaST openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Dean Hilkewich (deanjo13) Partner organization: openSUSE.org Description: This is one really really really annoying feature in yast. Here is the scenario, you have a machine with a bunch of storage drives, drives that are normally kept full. Everytime you enter something like package management in YaST it pops up a low disk space warning. This warning should only apply for volumes where YaST utilizes for it's files (such as download cache, home, etc). A HTPC for example often has volumes full to the max. -- openSUSE Feature: https://features.opensuse.org/312293

1 1

[New: openFATE 318082] [Shell][Scripting] Shell-reqs command
by fate_noreply＠suse.de 19 Dec '15

19 Dec '15

Feature added by: Sławomir Lach (Lachu) Feature #318082, revision 1 Title: [Shell][Scripting] Shell-reqs command openSUSE Distribution: Unconfirmed Priority Requester: Neutral Requested by: Sławomir Lach (lachu) Partner organization: openSUSE.org Description: Idea is about creating tool, which checks that given programs are installed. If some program aren't installed then it call special program(dependent on user is working on console and GUI environment), which displays cnf output for missing programs. On program missing return code is not 0, so script can terminate. Idea was proposed by some Red Hat's developers many years ago, but this idea was about to automatically install tools from standard repositories. Use Case: Marek is normal computer user. He decided to download script, but to run correctly script needs some command. This script can looks like this: #!/bin/bash shell-reqs command1 command2 if [ $? -eq 1 ]; then exit fi; command1 parameter1 parameter2 command2 parameter1 parameter2 parameter3 When he run this script, desktop environment reports that command1 and command2 is missing and suggest how to install these commands. Marek will install these commands and rerun script. -- openSUSE Feature: https://features.opensuse.org/318082

1 2

[openFATE 305914] PAC support for 'system wide proxy configuration'
by fate_noreply＠suse.de 05 Dec '15

05 Dec '15

Feature added by: Dominique Leuenberger (dimstar) Feature #305914, revision 1, last change by Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enugh to have the advantage of no longer needing to 'guess' what proxy to use. What is now: - You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234) This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: - Use System Proxy (as configured in yast) - Use proxy configuration (static, same options as in yast) - Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) -- openSUSE Feature: https://features.opensuse.org/305914

1 17

[New: openFATE 319963] Install packages in onion filesystem firstly
by fate_noreply＠suse.de 26 Nov '15

26 Nov '15

Feature added by: Sławomir Lach (Lachu) Feature #319963, revision 1 Title: Install packages in onion filesystem firstly openSUSE Distribution: Unconfirmed Priority Requester: Neutral Requested by: Sławomir Lach (lachu) Partner organization: openSUSE.org Description: Zypper and other tools should use special layered filesystem, which will ship package number/name for each file. One package cannot overwrite existing file if the number/name doesn't match - installing will fail. Also, install process first try to unpack all files on first layer, then executing script will take place on second layer. When some program will create/change file on second layer, which was generated on first layer, then transaction will fail. When on zero layer file was changed, which was changed on second layer, we will retake all changes on second layer. After each install operation is done, we can flush changes to zero layer. Use Case: Martin will install many program. Thanks to this simple change, installing could go in same time. Business case (Partner benefit): openSUSE.org: In my opinion, the could be faster than current mechanism, more secure and allowing to not wait until some program unlock package database. -- openSUSE Feature: https://features.opensuse.org/319963

1 0

[New: openFATE 319865] Support for independent multi-desktop multi-monitor
by fate_noreply＠suse.de 23 Nov '15

23 Nov '15

Feature added by: macias - (truemacias) Feature #319865, revision 1 Title: Support for independent multi-desktop multi-monitor openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: macias - (truemacias) Partner organization: openSUSE.org Description: IMHO this feature would not only be useful but would make OS really different than other distros. I am talking about distro, and not this or that Desktop Manager / Window Manager, because I think it would be a killer feature worth switching from the any liked/used DM/WM. Ok, the feature -- ability to setup multiple desktops and "pin" them down to given monitor. For example -- single monitor, I configure 5 desktops. When I switch desktop 1-5, I can see that desktop on my single monitor. No difference here. Two monitors -- let's say I configure 5 desktops again, but I attach 1-3 desktops to first monitor, and 4-5 to the second one. When the OS starts, it selects the first desktops for each monitor (1, and 4), and now when I switch to say, 5 desktop, the first monitor still displays desktop 1, but second one switches to desktop 5 and gets the focus. Say I switch to desktop 2, the second monitor still displays desktop 5, the first monitor switches to desktop 2 and gets the focus. Possible use cases: * "Monitor" Dual setup -- define N desktops, pin desktop N to second monitor, put there all "monitor" apps, like temperature, weather, HDD space, news :-) and so on, while pin 1-(N-1) desktops to first monitor for regular work. You can define only 1-(N-1) shortcuts for desktop switching -- and you would get pretty neat workstation with constant monitoring, without any conflict between apps * "Viewer" dual setup -- pretty much the same as above, but the second monitor serves as viewer for comparison purposes (some drawing, schematics, book is opened all the time) and thanks to separated desktops it will be visible all the time and it will be unaffected by any conflict (you would have to switch to that desktop to alter how it looks) Currently switching desktops is done in sync, so this would be a major step forward for power users (customization of the workstation). -- openSUSE Feature: https://features.opensuse.org/319865

1 1

[New: openFATE 318203] Let's drop commandline support from Yast
by fate_noreply＠suse.de 20 Nov '15

20 Nov '15

Feature added by: Lukas Ocilka (locilka) Feature #318203, revision 1 Title: Let's drop commandline support from Yast Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: Yast provides some kind of a commandline interface which is based on the same functions provided by standard Yast application (Qt, ncurses). Comandline could be used for scripting, but there are already tools that do it better: AutoYast, Chef, Puppet, SUSE Manager, sed (just to name some). Yast commadline has several drawbacks: * not used, not tested, not maintained, too much of obsolete code - too much maintenance for nothing * architecturally wrong - commandline interface to an app that uses commandline tools (e.g., commandline for Services Manager? This is obviously systemctl) * implemented as kind of a hack What do we lose if we remove it? * Possbility for scripting, but as Yast only builds on other cmdline tools or files, there are replacements Another possibility would be to replace commandline with a static information advicing user which tools to use to configure a particular service manually. Business case (Partner benefit): openSUSE.org: Less unused code to maintain == more time to do something that really matters -- openSUSE Feature: https://features.opensuse.org/318203

1 19

[openFATE 307735] "Publish on Build Success" mode
by fate_noreply＠suse.de 18 Nov '15

18 Nov '15

Feature changed by: Tomas Cech (sleep_walker) Feature #307735, revision 14 Title: "Publish on Build Success" mode Buildservice: Evaluation by engineering manager Priority Requester: Important Projectmanager: Desirable Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: It would be good to have a publishing mode which runs only if all packages of a project have built successful (no fail, no expansion errors, no broken) to prevent syncing out of a likely broken/non- installable state. This would be especially useful for automatic upgraded snapshots with a whole chain of interdepending packages. Discussion: #1: Adrian Schröter (adriansuse) (2010-01-22 16:20:31) Should be a "publish only if no fail/broken/expansion errors exist) #2: Adrian Schröter (adriansuse) (2010-02-20 12:11:31) My suggestion is to make it possible via <publish> <enable condition="noerror"> </disable> </publish> setting. #3: Jan Engelhardt (jengelh) (2010-02-20 20:05:40) At the same time, could we have a tunable that publishes packages "every once in a while" (like, X hours), otherwise I am getting no sync for days with large projects. #4: Adrian Schröter (adriansuse) (2010-05-20 09:09:38) That feature still needs discussion, moving to 2.5. #5: grant k (grantksupport) (2014-06-11 02:44:10) Adrian pointed me here from my own post, https://github.com/openSUSE/open-build-service/issues/702 +1 on this capability to keep critical repos available. #6: Jimmy Berry (boombatower) (2015-11-18 06:52:50) Or even one step further. No packages are in flux (ie building). That can definitely happen with large repositories like KDE updates and such as I used a lot in the past. Not so much with Tumbleweed. Perhaps a pre-publish step that checks that package dependendies can be satisfied which would allow individual packages to require exact versions if they need them and not when they don't. A bit more granular control and should still solve the wait until no errors in the original request. #7: Richard Brown (rbrownsuse) (2015-11-18 10:31:56) (reply to #6) Well in the case of Tumbleweed, we effectively have a 'Publish on Test Success' mode, and given that testing only happens after Building, this feature is unnecessary in the case of Tumbleweed This is one of the reasons why users should consider using Tumbleweed instead of adding too many of their own repositories, and one of the reasons why maintainers should strive to push and maintain as much as they can in Tumbleweed + #8: Tomas Cech (sleep_walker) (2015-11-18 14:18:05) + Isn't it de facto the same as if you just use openSUSE:Factory + repositories? -- openSUSE Feature: https://features.opensuse.org/307735

1 0

[New: openFATE 312747] Backport fix for Okular printing in KDE4 for KDE 4.7
by fate_noreply＠suse.de 18 Nov '15

18 Nov '15

Feature added by: Mindaugas Baranauskas (embar-) Feature #312747, revision 1 Title: Backport fix for Okular printing in KDE4 for KDE 4.7 openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Mindaugas Baranauskas (embar-) Partner organization: openSUSE.org Description: Please include this patch http://commits.kde.org/okular/e001fbab55aceef62ad9ca2bb87a170dacfe3fdd Kevin Kofler 2011-07-27 23:50:46 wrote: I forgot to put in a FIXED-IN tag, so let's make it clear: This fix will be in 4.8.0. 4.7.0 has already been released, and the fix requires new APIs in the Okular core, so I'm probably not supposed to backport it for 4.7.x. See https://bugs.kde.org/show_bug.cgi?id=181290#c118 -- openSUSE Feature: https://features.opensuse.org/312747

1 6

[openFATE 307735] "Publish on Build Success" mode
by fate_noreply＠suse.de 18 Nov '15

18 Nov '15

Feature changed by: Richard Brown (RBrownSUSE) Feature #307735, revision 12 Title: "Publish on Build Success" mode Buildservice: Evaluation by engineering manager Priority Requester: Important Projectmanager: Desirable Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: It would be good to have a publishing mode which runs only if all packages of a project have built successful (no fail, no expansion errors, no broken) to prevent syncing out of a likely broken/non- installable state. This would be especially useful for automatic upgraded snapshots with a whole chain of interdepending packages. Discussion: #1: Adrian Schröter (adriansuse) (2010-01-22 16:20:31) Should be a "publish only if no fail/broken/expansion errors exist) #2: Adrian Schröter (adriansuse) (2010-02-20 12:11:31) My suggestion is to make it possible via <publish> <enable condition="noerror"> </disable> </publish> setting. #3: Jan Engelhardt (jengelh) (2010-02-20 20:05:40) At the same time, could we have a tunable that publishes packages "every once in a while" (like, X hours), otherwise I am getting no sync for days with large projects. #4: Adrian Schröter (adriansuse) (2010-05-20 09:09:38) That feature still needs discussion, moving to 2.5. #5: grant k (grantksupport) (2014-06-11 02:44:10) Adrian pointed me here from my own post, https://github.com/openSUSE/open-build-service/issues/702 +1 on this capability to keep critical repos available. #6: Jimmy Berry (boombatower) (2015-11-18 06:52:50) Or even one step further. No packages are in flux (ie building). That can definitely happen with large repositories like KDE updates and such as I used a lot in the past. Not so much with Tumbleweed. Perhaps a pre-publish step that checks that package dependendies can be satisfied which would allow individual packages to require exact versions if they need them and not when they don't. A bit more granular control and should still solve the wait until no errors in the original request. + #7: Richard Brown (rbrownsuse) (2015-11-18 10:31:56) (reply to #6) + Well in the case of Tumbleweed, we effectively have a 'Publish on Test + Success' mode, and given that testing only happens after Building, this + feature is unnecessary in the case of Tumbleweed + This is one of the reasons why users should consider using Tumbleweed + instead of adding too many of their own repositories, and one of the + reasons why maintainers should strive to push and maintain as much as + they can in Tumbleweed -- openSUSE Feature: https://features.opensuse.org/307735

1 0