November 2016 - openSUSE Features - openSUSE Mailing Lists

[openFATE 322038] cloud-init: add zypp repo support
by fate_noreply＠suse.de 13 Nov '16

13 Nov '16

Feature changed by: Thorsten Kukuk (kukuk) Feature #322038, revision 2 Title: cloud-init: add zypp repo support Requested by: Thorsten Kukuk (kukuk) - Partner organization: SUSE + Partner organization: openSUSE.org Description: If customers don't want to register every system, we need another why to add update repositories to the system. cloud-init can add yum repos, it is quite easy to adopt that for zypp repos. -- openSUSE Feature: https://features.opensuse.org/322038

1 0

[New: openFATE 322039] split cloud-init configuration file from cloud-init package
by fate_noreply＠suse.de 13 Nov '16

13 Nov '16

Feature added by: Thorsten Kukuk (kukuk) Feature #322039, revision 1 Title: split cloud-init configuration file from cloud-init package Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: cloud-init has a /etc/cloud/clould.cfg configuration file, which specifies from where to get the user-data. For different products we have different needs and the current way of overwriting the config file during building the image with kiwi does not work for installations with YaST2. We should move that out into seperate packages for seperate products (like a "branding" package). -- openSUSE Feature: https://features.opensuse.org/322039

1 0

[New: openFATE 322035] libpurple-facebook plugin integegration with kde telepathy
by fate_noreply＠suse.de 12 Nov '16

12 Nov '16

Feature added by: John Shand (jshand2013) Feature #322035, revision 1 Title: libpurple-facebook plugin integegration with kde telepathy Requested by: John Shand (jshand2013) Partner organization: openSUSE.org Description: Ever since the XMPP protocole from facebook has been disable, i have been unable to connect to facebook with kde telepathy. Someone has already made the libpurple-facebook plugin for pidgin and other chat programs. can someone please create a configuration widget for kde telepathy so that facebook chat can be configured. many thanks -- openSUSE Feature: https://features.opensuse.org/322035

1 1

[New: openFATE 322013] Build Cisco Container OVA format
by fate_noreply＠suse.de 08 Nov '16

08 Nov '16

Feature added by: Justin Yaple (yaplej) Feature #322013, revision 1 Title: Build Cisco Container OVA format SUSE Studio: Unconfirmed Priority Requester: Important Requested by: Justin Yaple (yaplej) Partner organization: openSUSE.org Description: Please add the Cisco OVA container as an additional format for a SUSE Studio project. https://cisco.app.box.com/s/9juf2ioenn9ukg69osn3mmky1cecrxqc -- openSUSE Feature: https://features.opensuse.org/322013

1 0

[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