August 2015 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 311388] openSUSE Sky
by fate_noreply＠suse.de 15 Nov '16

15 Nov '16

Feature added by: Timo Hoenig (thoenig) Feature #311388, revision 1 Title: openSUSE Sky openSUSE Distribution: Unconfirmed Priority Requester: Important openSUSE Infrastructure: Unconfirmed Priority Requester: Important Requested by: Timo Hoenig (thoenig) Partner organization: openSUSE.org Description: With this feature I am announcing openSUSE Sky. openSUSE Sky will bring our distribution to cloud environments by providing official images for both openSUSE releases and snapshots of current development versions. With openSUSE Sky running the latest and greatest snapshot of openSUSE will be as easy as a mouse click. This gives developers the most efficient way for reproducing bugs on vanilla snapshots. Cloud users will appreciate to have access to trusted built of our distribution without any unknown modifications (e.g. intentional backdoors). Target cloud platforms are Amazon EC2 (using EBS/S3) and Eucalyptus (Walrus). Target audience are cloud users and developers. -- openSUSE Feature: https://features.opensuse.org/311388

1 5

[New: openFATE 316224] Drop dhcpcd from distribution
by fate_noreply＠suse.de 15 Nov '16

15 Nov '16

Feature added by: Peter Varkoly (varkoly) Feature #316224, revision 1 Title: Drop dhcpcd from distribution Requested by: Peter Varkoly (varkoly) Partner organization: openSUSE.org Description: We are going to drop dhcpcd on SLES. There are more reasons: 1. We already have two alternate packages for dhcpcd: dhcp-client and wicked. 2. The actual version will not be maintained by upstream 3. An update to the actual dhcpcd version requires a lot of unneeded work. Stefan Winterfeld was informed and he knows that our initrd must be adapted. -- openSUSE Feature: https://features.opensuse.org/316224

1 6

[New: openFATE 310668] run pulseaudio server with 'flat-volumes=no'
by fate_noreply＠suse.de 02 Nov '16

02 Nov '16

Feature added by: robert spitzenpfeil (robert_spitzenpfeil) Feature #310668, revision 1 Title: run pulseaudio server with 'flat-volumes=no' openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: robert spitzenpfeil (robert_spitzenpfeil) Partner organization: openSUSE.org Description: I listen to music while writing... and every single time I change songs a hilariously loud POP is almost killing my ears. This is annoying and painful. What's also annoying is that with 'flat-volumes = yes' the master volume is changed to the loudest individual stream. If a rogue application should choose to up the volume, my ears get fried (headphones !) Personally I think the purpose of having a master volume slider is to limit the max volume to avoid this kind of crap, which is totally nullified by 'flat-volumes = yes' ! Proposal: use 'flat-volumes = no' as the default in '/etc/pulse/daemon.conf'. I think the user is clever enough to handle the volume sliders himself. And only because Vista or W7 fiddles with the master volume in this _sick_ way, we don't need that as well. Reproducible: Always Steps to Reproduce: 1. play a song 2. increase the volume for the app. using pavucontrol or with the app. itself 3. master volume is pushed up as well Expected Results: The user should be the _only_ one messing with MASTER VOLUME. Business case (Partner benefit): openSUSE.org: With 'flat-volumes=yes' it is possible to get permanent hearing damage if unexpected volume surges are forced into the user's ears! Again with this feature enabled _any_ application that uses pulseaudio can set the master volume to 100%. That might be tolerable with a stereo system with a manual volume knob, but on a laptop + headphones this is close to a criminal assault. -- openSUSE Feature: https://features.opensuse.org/310668

1 16

[New: openFATE 312890] Opensuse 12.1 - provide Blender 2.6 as default install
by fate_noreply＠suse.de 02 Nov '16

02 Nov '16

Feature added by: Jedi Beeftrix (Jedibeeftrix) Feature #312890, revision 1 Title: Opensuse 12.1 - provide Blender 2.6 as default install openSUSE Distribution: Unconfirmed Priority Requester: Important Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Jedi Beeftrix (jedibeeftrix) Partner organization: openSUSE.org Description: Blender 2.6 finally here on Sunday the 16th of October. A huge milestone for Blender, and the best opensource 3D modelling/rendering/animation/editing package available, on linux or otherwise. http://www.blendernation.com/2011/10/14/blender-2-60-rc2-available/ This really should be included on the 12.1 dvd .iso Please! -- openSUSE Feature: https://features.opensuse.org/312890

1 9

[New: openFATE 314707] zypper history
by fate_noreply＠suse.de 02 Nov '16

02 Nov '16

Feature added by: Marcus Moeller (MarcusMoeller) Feature #314707, revision 1 Title: zypper history openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Marcus Moeller (marcusmoeller) Partner organization: openSUSE.org Description: zypper should have something like a history function, similar to yum. With this history function, past installation tasks could be listed, and even undone. example usage: zypper history info: list history -> every step in history has a dedicated number zypper history undo $number: undo the installation This could also be very useful on software testing. If one wants to take a look at the current status of e.g. KDE and uninstall it afterwards. -- openSUSE Feature: https://features.opensuse.org/314707

1 2

[New: openFATE 314853] Remove xterm and icewm from default installation
by fate_noreply＠suse.de 02 Nov '16

02 Nov '16

Feature added by: Jared Meidal (kahu) Feature #314853, revision 1 Title: Remove xterm and icewm from default installation openFATE: Unconfirmed Priority Requester: Important Requested by: Jared Meidal (kahu) Partner organization: openSUSE.org Description: xterm and icewm are great alternatives, but seem redundant when always bundled with default installations of Gnome or KDE's terminal (gnome-terminal, konsole). Also, having the icewm session is a great fallback and useful for emergency access but really necessary by default? I have found that if I remove xterm is removed the bundle with icewm, but also xorg-X11 and other packages. When this happens GDM will not launch after a reboot without CLI commands. This does not feel intuitive for a smooth default system, or helpful for a user who is wanting to clean up their packages or menu items they do not use. -- openSUSE Feature: https://features.opensuse.org/314853

1 5

[New: openFATE 314883] /root symlinked to /home/root
by fate_noreply＠suse.de 02 Nov '16

02 Nov '16

Feature added by: Kalenz . (Kalenz) Feature #314883, revision 1 Title: /root symlinked to /home/root openSUSE Distribution: Unconfirmed Priority Requester: Neutral Requested by: Kalenz . (kalenz) Partner organization: openSUSE.org Description: I might be saying something stupid here, in which case just shout me down. But: by default openSUSE installs with a separate /home partition, and for a typical user the most obvious benefits are: - ability to format/reinstall without erasing /home; - ability to share /home with different installs/distros; - (less sexy: keep root partition small, for efficiency.) Based on the first two arguments, I think we would be doing most users a favour by placing /root on the /home folder. Arguments for: (1) It is the home folder of the root user, so surely /home is a sensible place to keep it; (2) /root typically contains credential files, config scripts and so on, which you probably don't want to lose if you format / (and not /home). Arguments against: (3) I can imagine this to be problematic if you encrypt /, but not /home. What do others think? -- openSUSE Feature: https://features.opensuse.org/314883

1 4

[New: openFATE 318921] YaST should log time like dmesg and journalctl
by fate_noreply＠suse.de 01 Nov '16

01 Nov '16

Feature added by: Arvin Schnell (aschnell) Feature #318921, revision 1 Title: YaST should log time like dmesg and journalctl Requested by: Arvin Schnell (aschnell) Partner organization: openSUSE.org Description: YaST should log the time in its log-file like 'dmesg' and 'journalctl --output short-monotonic' so that times in the various logs can be compared and events can be synchronized. Business case (Partner benefit): openSUSE.org: Easier to analyse logs in bug reports. -- openSUSE Feature: https://features.opensuse.org/318921

1 4

[New: openFATE 308401] Opensuse netbook edition
by fate_noreply＠suse.de 25 Oct '16

25 Oct '16

Feature added by: Agustin Chavarria (dj_ubun_1) Feature #308401, revision 1 Title: Opensuse netbook edition openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Agustin Chavarria (dj_ubun_1) Description: The growing demand for netbooks, has made several distributions of Linux, to create a specific version for these computers. The creation of a version with moblin, with gnome, and kde would be a big step. and also enter a specific kernel for these computers, including drivers and kernel patches to improve stability of the distribution. This would include a change in the interface in both gnome and kde, and both of these projects have packages to improve the interface little displays -- openSUSE Feature: https://features.opensuse.org/308401

1 21

[openFATE 306896] Zypp-proxy - A proxy cache server for zypper updates
by fate_noreply＠suse.de 15 Oct '16

15 Oct '16

Feature added by: Alex Tsariounov (tsariounov) Feature #306896, revision 1 Title: Zypp-proxy - A proxy cache server for zypper updates Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Alex Tsariounov (tsariounov) Description: This project will create zypp-proxy which is a server proxy used for caching update packages that are used by machines on the local network on a locally designated host machine that acts as a proxy to the openSUSE updates repositories. The project is similar in function and requirements to the Debian project apt-proxy, details of which can be found here: http://apt-proxy.sourceforge.net/ This project is useful for those who run many local (both physical and virtual) openSUSE machines and like to keep them up to date with updates; however, they do not wish to waste bandwidth for downloading the same updates over and over to all local machines whether when keeping exisiting machines up to date, or building new machines and having to re-download all updates yet again. For some people, simply mirroring the entire openSUSE updates repository is sufficient to provide local network updates; however, for most, since they do not use near as many packages as that repository provides, doing this simply wastes disk space. These people will find zypp-proxy most useful. Both server and client setup will be quite simple. The server will use the public openSUSE updates repositories to check for updates. The clients will point to the local server (the proxy) machine for updates rather than the public servers. When a client requests an update, the zypp-proxy server first checks if the public server has a more up to date package that what it has cached locally. If the public server doesn't, then zypp-proxy serves the locally cached package. If the public server does have a more up to date package, then zypp-proxy first downloads it to its local cache and then serves it to the client. How many old versions of packages to keep will be a configurable. The first implementation will support openSUSE 11.1 only, with support for other openSUSE releases following suit. -- openSUSE Feature: https://features.opensuse.org/306896

1 17

[New: openFATE 309540] Create Saxon9 Package
by fate_noreply＠suse.de 05 Oct '16

05 Oct '16

Feature added by: Thomas Schraitle (thomas-schraitle) Feature #309540, revision 1 Title: Create Saxon9 Package Package Wishlist: New Priority Requester: Important Requested by: Thomas Schraitle (thomas-schraitle) Description: Currently we have only Saxon 6.x and Saxon 8.8. It would be useful, if we could add this package as it is under Mozilla licence. The latest version brings some bug fixing and some other improvements. Relations: - The XSLT and XQuery Processor (url: http://saxon.sourceforge.net/) -- openSUSE Feature: https://features.opensuse.org/309540

1 7

[openFATE 306234] allow to resize unformatted partitions and logical volume
by fate_noreply＠suse.de 03 Oct '16

03 Oct '16

Feature added by: Arvin Schnell (aschnell) Feature #306234, revision 1, last change by Title: allow to resize unformatted partitions and logical volume openSUSE-11.2: New Priority Requester: Important Requested by: Thomas Wouters (twouters) Description: Allow to resize unformatted partitions and logical volume with YaST. Relations: - Unable to resize unformatted logical volume (novell/bugzilla/id: 479561) https://bugzilla.novell.com/show_bug.cgi?id=479561 -- openSUSE Feature: https://features.opensuse.org/306234

1 9

[New: openFATE 309642] Hacking NetwotkManagement plasma applet
by fate_noreply＠suse.de 12 Aug '16

12 Aug '16

Feature added by: Alexander Naumov (Alexander_Naumov) Feature #309642, revision 1 Title: Hacking NetwotkManagement plasma applet Requested by: Alexander Naumov (alexander_naumov) Description: Trying to create a better support for wifi in NetworkManagement ;) -- openSUSE Feature: https://features.opensuse.org/309642

1 5

[New: openFATE 313139] One letter usernames
by fate_noreply＠suse.de 07 Aug '16

07 Aug '16

Feature added by: Mats Söderström (mazu) Feature #313139, revision 1 Title: One letter usernames openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Mats Söderström (mazu) Partner organization: openSUSE.org Description: The minimum allowed username length is two letters, I see no reason why this can't be changed to one. Business case (Partner benefit): openSUSE.org: To save hassle configuring ssh, nfs, etc. -- openSUSE Feature: https://features.opensuse.org/313139

1 2

[New: openFATE 317762] git mirror integration
by fate_noreply＠suse.de 05 Jul '16

05 Jul '16

Feature added by: Adrian Schröter (adrianSuSE) Feature #317762, revision 1 Title: git mirror integration Buildservice: New Milestone: 2.7 Priority Requester: Mandatory Requested by: Adrian Schröter (adriansuse) Partner organization: openSUSE.org Description: OBS can already roll tar balls from git (or other SCM systems) on code change, however, this has two disadvantages: * source server needs to store new tar ball for each change * using files as build descriptions is only working via workarounds. A full git (and only git, not svn,..) support would allow to mirror an entire git tree on the source server and fetch only updates. This means we need to * build tar balls at build time (since package systems like rpm rely on it) * ensure that a rewritten git history can not drop sources of former builds. * allow mirroring of either * * package sources only * * entirely on package level, including .spec files -- openSUSE Feature: https://features.opensuse.org/317762

1 6

[New: openFATE 316517] 32bit version of padsp in 64bit openSUSE
by fate_noreply＠suse.de 27 Jun '16

27 Jun '16

Feature added by: Mircea Kitsune (MirceaKitsune) Feature #316517, revision 1 Title: 32bit version of padsp in 64bit openSUSE openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Mircea Kitsune (mirceakitsune) Partner organization: openSUSE.org Description: I've been trying to fix a Linux game for which sound wasn't working. After some searching, I found that I must run it with the "padsp" command. However, the game is 32 bit and I run 64 bit openSUSE, so "padsp ./game_binary" wouldn't work. I searched for a padsp32 command and even tried to replicate the padsp script, but the library for the x32 version doesn't exist in the x64 repositories. Eventually I got it working by extracting libpulsedsp.so from the x32 openSUSE repos, and manually launching the binary with a LD_PRELOAD pointing to it. This is a workaround and maintaining it can become problematic. The existing library can be found in /usr/lib64/pulseaudio/libpulsedsp.so and the script in /usr/bin/padsp. Basically, I'm asking for x32 bit versions of these in the x64 variant of openSUSE, so any 32bit program can benefit from them too. Business case (Partner benefit): openSUSE.org: Only the 64bit version of padsp is included. Therefore, only 64bit programs can make use of it. Including the 32bit variant in the 32bit pulseaudio package for 64bit openSUSE would solve this problem. -- openSUSE Feature: https://features.opensuse.org/316517

1 2

[New: openFATE 314963] Manage battery threshold
by fate_noreply＠suse.de 19 Jun '16

19 Jun '16

Feature added by: Marc collin (collinm) Feature #314963, revision 1 Title: Manage battery threshold openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Marc collin (collinm) Partner organization: openSUSE.org Description: Some laptop have tool in windows to decide when laptop stop to chargin battery. This feature allow to increate life battery. This is a tool to manage lenovo battery threshold. some laptops are supported by this project tpacpi-bat https://github.com/teleshoes/tpacpi-bat some laptops are managed by this one and have more features https://github.com/evgeni/tp_smapi theses need acpi_call https://github.com/mkottman/acpi_call -- openSUSE Feature: https://features.opensuse.org/314963

1 6

[New: openFATE 315140] Kernel: CONFIG_TCP_MD5SIG needed for quagga
by fate_noreply＠suse.de 14 Jun '16

14 Jun '16

Feature added by: Marc Langer (marclanger) Feature #315140, revision 1 Title: Kernel: CONFIG_TCP_MD5SIG needed for quagga openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Marc Langer (marclanger) Partner organization: openSUSE.org Description: Quagga bgpd allows the configuration of MD5 protected BGP sessions, but the kernel does not have this activated. Business case (Partner benefit): openSUSE.org: Our BGP peers require MD5 but the SuSE Kernel is compiled without CONFIG_TCP_MD5SIG. It takes a long time to find this issue because in the default configuration quagga is not logging properly that this option is missing in the kernel. Each time we have to compile an own kernel. Please activate this in future versions. -- openSUSE Feature: https://features.opensuse.org/315140

1 1

[openFATE 307884] Yafaray instead of Yafray for Blender
by fate_noreply＠suse.de 07 Jun '16

07 Jun '16

Feature added by: Rene Bernhard (rebe) Feature #307884, revision 1 Title: Yafaray instead of Yafray for Blender Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Rene Bernhard (rebe) Description: Hello. As the Yafray render engine for Blender is not longer developed I apreciate if you would replace it with the Yafaray render engine in one of the next openSUSE versions. Or maybe it is possible to make a package for the repositories to download. Thank you very much for your efforts. Best regards rebe -- openSUSE Feature: https://features.opensuse.org/307884

1 4

[New: openFATE 312491] Explicit IPv6 support for YaST printer module
by fate_noreply＠suse.de 11 May '16

11 May '16

Feature added by: Johannes Meixner (jsmeix) Feature #312491, revision 1 Title: Explicit IPv6 support for YaST printer module openSUSE Distribution: Unconfirmed Priority Requester: Mandatory Requested by: Johannes Meixner (jsmeix) Partner organization: openSUSE.org Description: Currently there is not any kind of special IPv6 support in yast2-printer. Currently IPv6 works only where it is compatible to IPv4 but there are cases where IPv6 needs special handling: For example the tests whether or not a remote host is accessible run "ping <IP-address or hostname>" which fails if IP-address is an IPv6 address because for IPv6 ping6 must be used. See https://bugzilla.novell.com/show_bug.cgi?id=697833 Unfortunately ping6 cannot be used for IPv4 addresses so that yast2-printer needs to implement special distinction of cases in particular if a hostname is given depending on whether or not this hostname has an IPv4 or IPv6 address or both. Probably there are some more special distinction of cases needed to distinguish between IPv4 and IPv6 stuff. -- openSUSE Feature: https://features.opensuse.org/312491

1 20

[New: openFATE 314657] Add setting to not create Failsafe entries in grub menu
by fate_noreply＠suse.de 18 Apr '16

18 Apr '16

Feature added by: Michal Marek (michal-m) Feature #314657, revision 1 Title: Add setting to not create Failsafe entries in grub menu openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Michal Marek (michal-m) Partner organization: openSUSE.org Description: When testing multiple kernels, the grub menu quickly becomes a mess, because every kernel is listed twice. I would love to have a setting in /etc/sysconfig/bootloader, that would allow to tell perl-Bootloader to stop generating the Failsafe entries. -- openSUSE Feature: https://features.opensuse.org/314657

1 1

[New: openFATE 308839] performance: prompt early on failure ...
by fate_noreply＠suse.de 05 Apr '16

05 Apr '16

Feature added by: Michael Meeks (michael_meeks) Feature #308839, revision 1 Title: performance: prompt early on failure ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: For local builds, osc has an unfortunate habit of doing a large amount of work, before failing very late. For slow building or leaf packages this can be excessively painful - wasting an "overnight" build slot eg. Many of the checks that we currently do in the middle, should be moved to the beginning (or perhaps just duplicated there). Some examples I have fallen over: * prompt-user-to-re-build-jail - this currently happens after any new packages are downloaded - a process that can take as long as the building. We can know that a jail was dirty before we start & warn then; if we even need dirty jails [cf. fate#308837# ] * simple RPM syntax problems - could be linted ahead of time, currently done after jail construction. + we should catch in particular: missing / mis-named files + mis-applied / not-applied patches + anything else obvious that we can catch Doing this early - while the human is watching is likely to hide long pipeline stalls, and context switching overhead for packagers. -- openSUSE Feature: https://features.opensuse.org/308839

1 3

[New: openFATE 313077] New PAM modules must not be deployed unnoticed by sec team
by fate_noreply＠suse.de 05 Apr '16

05 Apr '16

Feature added by: Sebastian Krahmer (krahmer) Feature #313077, revision 1 Title: New PAM modules must not be deployed unnoticed by sec team openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Sebastian Krahmer (krahmer) Partner organization: openSUSE.org Description: New PAM modules should be reviewed by security team. Just like any suid/daemon/DBUS service. In particular if they are installed by default. -- openSUSE Feature: https://features.opensuse.org/313077

1 4

[New: openFATE 311163] packaging firefox add-ons
by fate_noreply＠suse.de 05 Apr '16

05 Apr '16

Feature added by: Ludwig Nussel (lnussel) Feature #311163, revision 1 Title: packaging firefox add-ons Hackweek VI: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: We lack a way to be able to easily package firefox add-ons as rpm. Packages of add-ons are useful both for the distro vendor and for admins. Distro (or appliance) vendors may install some add-ons by default. Admins want all users to have certain add-ons by default. Moreover some add-ons are not noarch (like bonjourfoxy) and need to be compiled specifically for each distro so a package is unavoidable. To make all of that possible the firefox package needs to provide rpm macros so spec files for add-ons become really simple. By creating a script that downloads version, description etc from addons.mozilla.org and automatically creates spec files the task of packaging add-ons becomes a piece of cake. See home:lnussel:firefox for current status. -- openSUSE Feature: https://features.opensuse.org/311163

1 6

[New: openFATE 316562] Add fs.protected_hardlinks=1
by fate_noreply＠suse.de 15 Mar '16

15 Mar '16

Feature added by: Sebastian Krahmer (krahmer) Feature #316562, revision 1 Title: Add fs.protected_hardlinks=1 Requested by: Sebastian Krahmer (krahmer) Partner organization: openSUSE.org Description: In order to disallow hard linking to suid files etc we should enable hardlink protection: fs.protected_hardlinks=1 or via apropriate /proc entry. -- openSUSE Feature: https://features.opensuse.org/316562

1 9

[New: openFATE 309362] Re-implement Download on Demand (DoD) feature
by fate_noreply＠suse.de 01 Mar '16

01 Mar '16

Feature added by: Adrian Schröter (adrianSuSE) Feature #309362, revision 1 Title: Re-implement Download on Demand (DoD) feature Buildservice: Done Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Description: The DoD features was dropped for 1.7. LinuxFoundation has re-implemented it in a cleaner way for 1.8 release. -- openSUSE Feature: https://features.opensuse.org/309362

1 8

[openFATE 305838] Integrate ReviewBoard in Buildservice
by fate_noreply＠suse.de 12 Feb '16

12 Feb '16

Feature added by: Klaas Freitag (kfreitag) Feature #305838, revision 1, last change by Title: Integrate ReviewBoard in Buildservice Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Klaas Freitag (kfreitag) Description: ReviewBoard is a code change review system. It should be considered to integrate it to the openSUSE Buildservice infrastructure to ease collaboration. It might be an option that submit requests to packages can be handled in the review board. -- openSUSE Feature: https://features.opensuse.org/305838

1 4

[New: openFATE 318951] YaST should log time like dmesg and journalctl
by fate_noreply＠suse.de 09 Feb '16

09 Feb '16

Feature added by: Joachim Werner (joachimwerner) Feature #318951, revision 1 Title: YaST should log time like dmesg and journalctl Requested by: Arvin Schnell (aschnell) Partner organization: openSUSE.org Description: YaST should log the time in its log-file like 'dmesg' and 'journalctl --output short-monotonic' so that times in the various logs can be compared and events can be synchronized. Relations: - YaST should log time like dmesg and journalctl (feature/copiedfrom: 318921) Business case (Partner benefit): openSUSE.org: Easier to analyse logs in bug reports. -- openSUSE Feature: https://features.opensuse.org/318951

1 4

[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 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

[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

[New: openFATE 310712] Constantly usable Factory
by fate_noreply＠suse.de 18 Nov '15

18 Nov '15

Feature added by: Christoph Obexer (cobexer) Feature #310712, revision 1 Title: Constantly usable Factory openSUSE-11.4: Unconfirmed Priority Requester: Mandatory Requested by: Christoph Obexer (cobexer) Partner organization: openSUSE.org Description: I recently read about the Debain CUT project, ( http://cut.debian.net/ (http://cut.debian.net/) , http://kitenet.net/~joey/code/debian/cut/ (http://kitenet.net/~joey/code/debian/cut/) ) looking at the current situation with openSuSE Factory i see that it is dangerous to use, unstable alpha or beta packages come into Factory all the time, while other packages become out of date. The result is a system that is pretty much unusable. Only allowing stable packages to enter Factory would make that a lot better, and if one finds bugs chances are that those bugs aren't already fixed in a newer svn/git snapshot, but are real bugs. This would save a lot of time for testers and developers in dealing with "invalid", or "temporary" bugs. I think that a robust, "stable" Factory would lead to more people using it full time and thus a better quality of the next openSuSE version. I see that this would have negative aspects as well, but i think most devel projects have unstable/testing repositories set up already and those could still contain the snapshots of upcoming versions, testers of those specific projects could use tose repositories then. Doing a release of openSuSE would be easier then too, simply snapshot Factory, and declare it as openSuSE $VERSION. The transition from the current state to a "constantly usable Factory" would be smooth too. And it's also in line with the openSuSE vision, stable rather than bleeding edge. Business case (Partner benefit): openSUSE.org: More users using Factory -> better stability of Factory -> better stability of openSuSE $VERSION -> openSuSE back where it should be - the Linux for professionals. -- openSUSE Feature: https://features.opensuse.org/310712

1 4

[New: openFATE 309700] Advanced uninstall/Rollback support in package management, zypper
by fate_noreply＠suse.de 30 Oct '15

30 Oct '15

Feature added by: Nikanth K (nikanth) Feature #309700, revision 1 Title: Advanced uninstall/Rollback support in package management, zypper openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Nikanth K (nikanth) Description: # Zypper install evolution This will install say 13 packages, evolution and its dependencies including evolution-data-server etc.... #zypper remove evolution This will remove only evolution. Leaving the dependencies installed. The 12 packages are left installed. Instead provide an easy way to rollback/uninstall all those packages using say a transaction-id from the history. So that, say we have foo.rpm which needs bar.rpm #zypper install foo #zypper remove foo will not leave bar installed in the system. -- openSUSE Feature: https://features.opensuse.org/309700

1 4

[New: openFATE 309070] Allow auth
by fate_noreply＠suse.de 27 Oct '15

27 Oct '15

Feature added by: Adrian Schröter (adrianSuSE) Feature #309070, revision 1 Title: Allow auth Buildservice: Evaluation Priority Requester: Important Projectmanager: Desirable Requested by: Adrian Schröter (adriansuse) Description: Implement authentification plugin for api which allows authentification against remote http web server. This may need changes in session handling. We want to use this plugin and setup for opensuse.org and connect api.o.o and build.o.o directly to internet without iChain proxy. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-23 12:06:04) Tom, we need your expertise here, what is possible with rails and what makes sense. -- openSUSE Feature: https://features.opensuse.org/309070

1 7

[New: openFATE 310233] skip repo update when installing packages with zypper
by fate_noreply＠suse.de 24 Sep '15

24 Sep '15

Feature added by: Denny Beyer (lumnis) Feature #310233, revision 1 Title: skip repo update when installing packages with zypper openFATE: Unconfirmed Priority Requester: Important Requested by: Denny Beyer (lumnis) Description: When installing a new package with zypper etc. everytime you run zypper, repos get updated and the user has to wait. Because a general user needs several extra repos, this waiting time always seems to be too long. Why not running 'zypper ref' as a low priority task after startup/time intervall has passed and give the used immidiate access to install a software package? -- openSUSE Feature: https://features.opensuse.org/310233

1 18

[New: openFATE 318306] Systemd service to catch crashed X, try to auto repair it and restart
by fate_noreply＠suse.de 08 Sep '15

08 Sep '15

Feature added by: Mindaugas Baranauskas (embar-) Feature #318306, revision 1 Title: Systemd service to catch crashed X, try to auto repair it and restart openSUSE Distribution: Unconfirmed Priority Requester: Important SUSE Studio: Unconfirmed Priority Requester: Important Requested by: Mindaugas Baranauskas (embar-) Partner organization: openSUSE.org Description: We could have solution automatically detect, if X.Org X Server terminated with error. Then we could try repair X configuration and restart X server. Test Case: That case encouraged me to write systemd service and script, which temporaly is named as check-x-failed. You can download it as systemd-check-x-failed-service RPM package: http://software.opensuse.org/download.html?project=home%3Aembar-%3ALietukas… Source is here: https://build.opensuse.org/package/show/home:embar-:Lietukas/systemd-check-… This is included in openSUSE based appliance âLietukasâ ( https://susestudio.com/a/CttYWz/lietukas-13-2-64-bit ) Use Case: This is very important now as we swithed to system and much system modules are included in initrd. This my cose much problems, e.g. then we we boot from LiveCD/LiveUSB. One problematic case described here: http://suse-studio-users.1598176.n2.nabble.com/Tesdrive-OK-but-does-not-dir… -- openSUSE Feature: https://features.opensuse.org/318306

1 5

[New: openFATE 312852] Hack your windows with sticky notes
by fate_noreply＠suse.de 25 Aug '15

25 Aug '15

Feature added by: Christopher De Nicolo (dec16180) Feature #312852, revision 1 Title: Hack your windows with sticky notes Hackweek VII: Unconfirmed Priority Requester: Desirable Requested by: Christopher De Nicolo (dec16180) Partner organization: openSUSE.org Description: What geeks really need: http://www.geekosystem.com/french-post-it-note-war/ -- openSUSE Feature: https://features.opensuse.org/312852

1 5

[New: openFATE 312810] Build a wireless lan access point
by fate_noreply＠suse.de 25 Aug '15

25 Aug '15

Feature added by: Juergen Weigert (jnweiger) Feature #312810, revision 1 Title: Build a wireless lan access point openSUSE.org: Unconfirmed Priority Requester: Important Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: Use hostap mode to turn a laptop into a full featured access point. (not just ad-hoc). Find out which hardware is suitable. I have an USB-Wlan-dongle with rt73 chipset, whichis reported to support AP-mode. -- openSUSE Feature: https://features.opensuse.org/312810

1 3

[New: openFATE 319359] Wicked Internet Connection Tool
by fate_noreply＠suse.de 22 Aug '15

22 Aug '15

Feature added by: Norman Gorlt (norgo70) Feature #319359, revision 1 Title: Wicked Internet Connection Tool openFATE: Unconfirmed Priority Requester: Important Requested by: Norman Gorlt (norgo70) Partner organization: openSUSE.org Description: Up to openSUSE 13.1 we had the option to use ifup alternatively to Networkmanager. Internet connection via ifup was easy to use because we had smpppd and qinternet e.g. Now ifup is replaced by wicked and smpppd and qinternet aren't available anymore. For desktop computer with a fixed internet connection it's quite silly to use Networkmanager in my opinion. In this case wicked would be a good choice. But, unfortunately there don't exist a simple connection tool for easy useability. Connecting or disconnecting of internet connection via command line is not userfriendly. I would wish a simple icon in the taskbar similar we had in qinternet. Fist click onto icon establish the connection, 2nd click disconnect network connection. Maybe right click to show up/down load data rate. -- openSUSE Feature: https://features.opensuse.org/319359

1 1

[New: openFATE 319369] add Svdvorak to supported keyboard layouts
by fate_noreply＠suse.de 21 Aug '15

21 Aug '15

Feature added by: August Lindberg (aggelito) Feature #319369, revision 1 Title: add Svdvorak to supported keyboard layouts openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: August Lindberg (aggelito) Partner organization: openSUSE.org Description: Right now there are no alternatives for swedish dvorak layouts in the system keyboard layouts. Having the Svdvorak layout as a supported layout would be a nice addition. -- openSUSE Feature: https://features.opensuse.org/319369

1 1

[New: openFATE 314922] Amazon EC2
by fate_noreply＠suse.de 14 Aug '15

14 Aug '15

Feature added by: Paulo Andrade (bugsoftware) Feature #314922, revision 1 Title: Amazon EC2 SUSE Studio: Unconfirmed Priority Requester: Important Requested by: Paulo Andrade (bugsoftware) Partner organization: openSUSE.org Description: I would like Amazon EC2 support for Opensuse 12.3 -- openSUSE Feature: https://features.opensuse.org/314922

1 2

[New: openFATE 311401] Live CD templates
by fate_noreply＠suse.de 14 Aug '15

14 Aug '15

Feature added by: Mustafa Hadi (mustafa1987) Feature #311401, revision 1 Title: Live CD templates SUSE Studio: Unconfirmed Priority Requester: Desirable Requested by: Mustafa Hadi (mustafa1987) Partner organization: openSUSE.org Description: Add a template with their default package selection is all the software available on the live CDs (KDE Live CD and Gnome Live CD) and the software automatically selected on the first yast software manager run, adding these templates is not hard to do (they are just package selection lists) an its benifits will be great. Business case (Partner benefit): openSUSE.org: To provide a complete operating system that can be then extended with additional software, the KDE4 template is just not enough. -- openSUSE Feature: https://features.opensuse.org/311401

1 3

[openFATE 305015] support noarch via own scheduler in Build Service
by fate_noreply＠suse.de 14 Aug '15

14 Aug '15

Feature changed by: Adrian Schröter (adrianSuSE) Feature #305015, revision 13 Title: support noarch via own scheduler in Build Service Buildservice: Evaluation by engineering manager Priority Requester: Desirable Projectmanager: Desirable Requested by: Adrian Schröter (adriansuse) Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: We would like to build noarch packages only once to avoid multiple builds and wasted space on the server. This can be reached by building noarch packages only via an dedicated scheduler. However, we need to avoid that have a horrible project configuration, where all BuildRequired noarch packages needs to get submitted into all other architecture repository :full trees. + The biggest problem is that build cycle detection is not working + accross schedulers. We would have endless builds easily with the + current code. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:48:58) Theoretically already possible, still questionable if we want this. -> keep it in evaluation #2: Greg Freemyer (gregfreemyer) (2012-03-30 20:14:05) I can think of of at least 3 ways to accomplish the goal: 1) Allow noarch builds of just one arch to be accepted to factory. Then encourage people to just enable one arch. Hopefully randomly to spread the load around. 2) Create a new "noarch" architecture and scheduler. Have that feed whatever actual scheduler has the lightest load at schedule time. That way even non-Intel machines could build the noarch packages. 3) Enforce in all schedulers but one, that they ignore noarch packages. Then document that so everyone knows they can only build noarch on i586 (as an example). idea 1) seems relatively doable for a modest effort. idea 2) would require changes lots of places I assume, so it is not trivial. idea 3) seems like the least work by far, and it sheds work load from one of the schedulers. I don't know if that would benefit the overall OBS load or not. And I'm sure there are other ways. === The question is if the wasted build resources is worth the R&D to bother with fixing this. #3: Claudio Freire (klaussfreire) (2012-03-30 20:30:05) (reply to #2) 3) Enforce in all schedulers but one, that they ignore noarch packages. Then document that so everyone knows they can only build noarch on i586 (as an example). I think this is the best option. For one, making sure noarch packages are built in the same architecture every time will help avoid spurious deltas: if a package builds differently on different architectures, but the packager decided that the difference is inconsequential. For instance, arm zlib needs not produce the same output as x86 zlib. For two, i586 and x86_64, AFAIK, use the same hosts. Right? So spreading the load among those two is useless. But there are quite a few caveats. One, people should not care about which arch is enabled, if there is any enabled archs for a noarch package, it should be built by "the noarch" scheduler (say, the x86_64 scheduler). If there are many archs enabled, only one build should be scheduled, and build results should be replicated. This might need some doing. 2) Create a new "noarch" architecture and scheduler. Have that feed whatever actual scheduler has the lightest load at schedule time. That way even non-Intel machines could build the noarch packages. So, more to-the-point would be option 2, but it still doesn't completely convince me, because it would be quite confusing in the UI. There also option 1, which I guess would work for factory (but not other projects). It's already common practice in OBS to only enable one arch for big noarch packages, so it should be rather easy to do - just fix factory-auto's validation script to account for noarch packages. About the benefits, I have a few projects that build hundred-MB noarch rpms with game data. Those take a lot of I/O resources to build, so the inefficiency (in that case) is significant. I'm not sure about how many projects are found in that situation, though. I would vote to get option 1 implemented ASAP - it should be easy and immediate. If I wanted to patch it... where should I go to find the factory-auto script? #5: Jan Engelhardt (jengelh) (2015-08-14 00:06:13) (reply to #2) >[3.] Then document that so everyone knows they can only build noarch on i586 And if you have no x86? Like, a PPC-only pool. Suggestion [2] doing a round-robin seems preferable. #4: Stefan Brüns (stefanbruens) (2015-07-20 17:10:51) I think this should be reevaluated - ARM builds are really slow, and e. g kernel-docs takes a full day to rebuild. -- openSUSE Feature: https://features.opensuse.org/305015

1 0

[openFATE 305015] support noarch via own scheduler in Build Service
by fate_noreply＠suse.de 13 Aug '15

13 Aug '15

Feature changed by: Jan Engelhardt (jengelh) Feature #305015, revision 12 Title: support noarch via own scheduler in Build Service Buildservice: Evaluation by engineering manager Priority Requester: Desirable Projectmanager: Desirable Requested by: Adrian Schröter (adriansuse) Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: We would like to build noarch packages only once to avoid multiple builds and wasted space on the server. This can be reached by building noarch packages only via an dedicated scheduler. However, we need to avoid that have a horrible project configuration, where all BuildRequired noarch packages needs to get submitted into all other architecture repository :full trees. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:48:58) Theoretically already possible, still questionable if we want this. -> keep it in evaluation #2: Greg Freemyer (gregfreemyer) (2012-03-30 20:14:05) I can think of of at least 3 ways to accomplish the goal: 1) Allow noarch builds of just one arch to be accepted to factory. Then encourage people to just enable one arch. Hopefully randomly to spread the load around. 2) Create a new "noarch" architecture and scheduler. Have that feed whatever actual scheduler has the lightest load at schedule time. That way even non-Intel machines could build the noarch packages. 3) Enforce in all schedulers but one, that they ignore noarch packages. Then document that so everyone knows they can only build noarch on i586 (as an example). idea 1) seems relatively doable for a modest effort. idea 2) would require changes lots of places I assume, so it is not trivial. idea 3) seems like the least work by far, and it sheds work load from one of the schedulers. I don't know if that would benefit the overall OBS load or not. And I'm sure there are other ways. === The question is if the wasted build resources is worth the R&D to bother with fixing this. #3: Claudio Freire (klaussfreire) (2012-03-30 20:30:05) (reply to #2) 3) Enforce in all schedulers but one, that they ignore noarch packages. Then document that so everyone knows they can only build noarch on i586 (as an example). I think this is the best option. For one, making sure noarch packages are built in the same architecture every time will help avoid spurious deltas: if a package builds differently on different architectures, but the packager decided that the difference is inconsequential. For instance, arm zlib needs not produce the same output as x86 zlib. For two, i586 and x86_64, AFAIK, use the same hosts. Right? So spreading the load among those two is useless. But there are quite a few caveats. One, people should not care about which arch is enabled, if there is any enabled archs for a noarch package, it should be built by "the noarch" scheduler (say, the x86_64 scheduler). If there are many archs enabled, only one build should be scheduled, and build results should be replicated. This might need some doing. 2) Create a new "noarch" architecture and scheduler. Have that feed whatever actual scheduler has the lightest load at schedule time. That way even non-Intel machines could build the noarch packages. So, more to-the-point would be option 2, but it still doesn't completely convince me, because it would be quite confusing in the UI. There also option 1, which I guess would work for factory (but not other projects). It's already common practice in OBS to only enable one arch for big noarch packages, so it should be rather easy to do - just fix factory-auto's validation script to account for noarch packages. About the benefits, I have a few projects that build hundred-MB noarch rpms with game data. Those take a lot of I/O resources to build, so the inefficiency (in that case) is significant. I'm not sure about how many projects are found in that situation, though. I would vote to get option 1 implemented ASAP - it should be easy and immediate. If I wanted to patch it... where should I go to find the factory-auto script? + #5: Jan Engelhardt (jengelh) (2015-08-14 00:06:13) (reply to #2) + >[3.] Then document that so everyone knows they can only build noarch + on i586 And if you have no x86? Like, a PPC-only pool. + Suggestion [2] doing a round-robin seems preferable. #4: Stefan Brüns (stefanbruens) (2015-07-20 17:10:51) I think this should be reevaluated - ARM builds are really slow, and e. g kernel-docs takes a full day to rebuild. -- openSUSE Feature: https://features.opensuse.org/305015

1 0

[New: openFATE 318204] Drop Yast LXC (replaced by libvirt / docker)
by fate_noreply＠suse.de 05 Aug '15

05 Aug '15

Feature added by: Lukas Ocilka (locilka) Feature #318204, revision 1 Title: Drop Yast LXC (replaced by libvirt / docker) Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: Yast LXC is not needed anymore, libvirt-lxc already covers that. Additionally, docker with Yast Docker module seem to be a good replacement for LXC. Business case (Partner benefit): openSUSE.org: Less code to maintain, less bugs. Yast doesn't need to provide functionality that already exists and is maintained elsewhere. -- openSUSE Feature: https://features.opensuse.org/318204

1 6

[New: openFATE 319299] require libvirt-images subvolume creation at install time
by fate_noreply＠suse.de 03 Aug '15

03 Aug '15

Feature added by: Chris Murphy (cmurf) Feature #319299, revision 1 Title: require libvirt-images subvolume creation at install time Requested by: Chris Murphy (cmurf) Partner organization: openSUSE.org Description: Similar to https://features.opensuse.org/319287 Create a subvolume in the top level of the file system for libvirt images, and add it to fstab to mount at /var/lib/libvirt/images/ Without this, any rollback will be missing virt-manager VM images. -- openSUSE Feature: https://features.opensuse.org/319299

1 4