December 2013 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 316827] Descriptions of rules in yast2-firewall
by fate_noreply＠suse.de 19 Dec '13

19 Dec '13

Feature added by: Namor Barcode (z1trus) Feature #316827, revision 1 Title: Descriptions of rules in yast2-firewall openFATE: Unconfirmed Priority Requester: Neutral Requested by: Namor Barcode (z1trus) Partner organization: openSUSE.org Description: Add descriptions of rules to "Custom rules" section in yast2-firewall. Business case (Partner benefit): openSUSE.org: If add a lot of custom rules with random ports (for example, change default sshd server port, vnc, mpd, torrent etc.) then difficult to maintain this list. If these rules have descriptions, then we don't need remember why we opened these ports. -- openSUSE Feature: https://features.opensuse.org/316827

1 1

[New: openFATE 313567] option to osc results shown transposed
by fate_noreply＠suse.de 17 Dec '13

17 Dec '13

Feature added by: Tomas Cech (sleep_walker) Feature #313567, revision 1 Title: option to osc results shown transposed Buildservice: Unconfirmed Priority Requester: Important Requested by: Tomas Cech (sleep_walker) Partner organization: openSUSE.org Description: Allow to see project results with switched axis. For bigger projects there is bigger number of packages than number of repositories being compiled against. For such case it would be more readable to show on X axis repositories and Y (easier to scroll) to show packages. As benefit from this there is a way smaller probability that the result table will be split. openSUSE_12.1 i586 | openSUSE_12.1 x86_64 . . some_package F . another_package s % more_package f . distinct_package . . hand_package It would be also much easier to see per distribution results. -- openSUSE Feature: https://features.opensuse.org/313567

1 3

[New: openFATE 312822] Get Enlightenment 17 into openSUSE
by fate_noreply＠suse.de 17 Dec '13

17 Dec '13

Feature added by: Tomas Cech (sleep_walker) Feature #312822, revision 1 Title: Get Enlightenment 17 into openSUSE Hackweek VII: Unconfirmed Priority Requester: Desirable Requested by: Tomas Cech (sleep_walker) Partner organization: openSUSE.org Description: Enlightenment 17 is good looking, but resource friendly, very well usable desktop environment. Unfortunately it's not present in openSUSE distribution and current state of X11:Enlightenment is awful. As a result, there were several home projects with these packages and no effort to fix current state. I created X11:Enlightenment:Staging project as future replacement of old X11:Enlightenment. I'd like to improve quality of spec files and have better cross distribution coverage. After that I'd like to post result into openSUSE Factory. -- openSUSE Feature: https://features.opensuse.org/312822

1 12

[New: openFATE 316810] Dont lock the whole package manager
by fate_noreply＠suse.de 15 Dec '13

15 Dec '13

Feature added by: Immanuel H. (FrankyBoy1234) Feature #316810, revision 1 Title: Dont lock the whole package manager openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Immanuel H. (frankyboy1234) Partner organization: openSUSE.org Description: Hi! It is extremely annoying that the package-manager locks itself out completely eg. when doing updates (which can take some time). Esp. it seems to me (with my limited understanding of the topic) to be a quite needlessly vast impact considering the only reason for doing so it to not update the same packages from two different locations. A more desirable solution would be to a) only lock the packages that are currently worked on / will be worked on in the scope of the task or b) instead of doing all changes "in sync" just put everything in a queue and have a worker thread go through the entries. In this case locking may still be required for the time that the user writes to the worker thread, but as soon as the change is enqueued the package manager should know enough to make the right queuing choices or restrictions to the user (as it knows current state and enqueued changes). Additionally to that it would be great if download and install would not be treated as one (as dl for the next package(s) can happen already when current one is installing), but thats another story. Thx and regards, ... Use Case: Step 1: fresh install of OpenSUSE -> package manager will start updating, which can take some time Step 2: try doing anything during that time that requires the package manager, like installing codecs, programs or whatever (as typical for a new system when user first configures it) Current: PM tells you that it is locked and if it should ask the updater to stop ... which fails Proposed (a/b according to above solutions): PM starts, and a) updates the required packages directly or tells the user in case of collision he will have to wait (which should be extremely rare if the locking could be reduced to eg. only packages which still require work) b) enqeues the new packages (preferably with higher priority than the updater, or near the head of the queue) and shows the user a waiting symbol (with some message like "3 packages ahead of us" - "applying" - "done"). -- openSUSE Feature: https://features.opensuse.org/316810

1 0

[New: openFATE 310623] Please bring SCPM back to Suse
by fate_noreply＠suse.de 15 Dec '13

15 Dec '13

Feature added by: Hawke Robinson (kmleon) Feature #310623, revision 1 Title: Please bring SCPM back to Suse openSUSE-11.4: Unconfirmed Priority Requester: Important Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Hawke Robinson (kmleon) Partner organization: openSUSE.org Description: SCPM is one of the major components (among others) for why I prefer to use Suse over other distros. I use SCPM for changing many configuration values for hardware and software cleanly, through one tool, instead of dozens, between when plugged into very different docking stations between work and home, when at home undocked, when roaming at coffee shops, when locked down for work or client sites, when broadcasting live shows at various locations, or when setting up different hardware profiles with different components connected and keeping the configuration consistent for that profile, printers, firewall rules, etc. Networkmanager only handles the networking aspect (and poorly at that, especially for devices that require using if-up mode, and not network manager (driver bugs)). Other tools only handle the configuration values for their own domains of responsibilty, and do not keep a single profile with all the many variables, easily in one place, and easily switched either on the fly or at boot time. This tool has been a huge boon to being far more productive over other distros. Please consider adding this back to 11.3, and keeping it for future releases. I am even willing to become a maintainer for this package if no one more qualified steps up to do so. I will try the information for the 11.2 repo kludge, but please advise on how the suse decision makers can be encouraged to bring scpm back. Thanks! Use Case: Mobile user (laptop, portable device, or full PC that is moved to different locations) with one kind of docking station or port replicator at home, and a completely different docking-station or port replicator at work, beign able to easily switch all the hardware, network, firewall, monitor(s), printers, and other software and hardware values at boot time between home and work. Mobile user that has very different security settings and hardware settings between home setup, work setup, and different clients when on-site. variables include network, firewall, antivirus, fileshares, sound cards, external video cards, monitor(s), printers, virtual machine configurations, DNS, hosts files, email server settings, sshd settings, ftpd settings, the list of variables served through one profile tool is extremely extensive. Business case (Partner benefit): openSUSE.org: The wonderful flexibility of so many variables being able to be easily tracked on the fly from one utility is extremely valuable for mobile use. Networkmanager only handles the networking aspect (and poorly at that, especially for devices that require using if-up mode, and not network manager (driver bugs)). Other tools only handle the configuration values for their own domains of responsibilty, and do not keep a single profile with all the many variables, easily in one place, and easily switched either on the fly or at boot time. This tool has been a huge boon to being far more productive over other distros. Without SCPM support, Suse becomes that much more "just another same/similiar Linux distro", and looses another distinctive benefit over other distros for me, and for all my clients. -- openSUSE Feature: https://features.opensuse.org/310623

1 4

[openFATE 315090] Upgrade to Bluez 5
by fate_noreply＠suse.de 13 Dec '13

13 Dec '13

Feature changed by: Frederic Crozat (fcrozat) Feature #315090, revision 50 Title: Upgrade to Bluez 5 Requested by: Jeffrey Cheung (jeffreycheung) Partner organization: openSUSE.org Description: BlueZ 5 come with numerous new features, API simplifications and other improvements. With this release BlueZ only supports the new Bluetooth Management kernel interface that was introduced in Linux 3.4, so essentially this is the minimum kernel requirement for BlueZ 5. For Low Energy support at least kernel version 3.5 is needed. The new major version indicates that the API is not backwards compatible with BlueZ 4, which means that any applications, agents, etc will need to be updated. The BlueZ internal test scripts and tools have naturally already been updated to support the new API. The BlueZ version in SLE11 SP3 is BlueZ 4.99 which mean that regardless of new features, and improvements, we have to upgrade definitely. References: - Packages: ofono + Packages: ?ofono,bluez,obex-data-server,openobex,-obexd,-obexftp Documentation Impact: RN Discussion: #1: Frederic Crozat (fcrozat) (2013-06-25 16:26:22) Bluez 5 can be installed in parallel with Bluez4, allowing applications not ported to BlueZ 5 API to work properly #2: Frederic Crozat (fcrozat) (2013-07-02 16:53:42) (reply to #1) it looks like I was a bit optimistic. You can only have one BlueZ installed (4 or 5) and they aren't API compatible, which requires having all BT applications moved to BlueZ 5.. #3: Jeffrey Cheung (jeffreycheung) (2013-08-05 12:06:33) So, can this fate proceed ? #4: Ludwig Nussel (lnussel) (2013-08-07 10:34:47) (reply to #3) We are past feature freeze with Milestone 4 now. I suppose this will affect the desktops so please evaluate the potential fallout and discuss on the Factory mailinglist whether it's still possible to fix the affected packages. #5: Jeffrey Cheung (jeffreycheung) (2013-08-07 11:15:59) (reply to #4) Hi Ludwig Nussel, Thanks of reminder. I already send email to factory mailing list. The current status is that RD finished the x86-64 part but i386 not yet. #6: Stefan Seyfried (seife) (2013-08-07 17:00:41) Also note that the bluez library is deprecated with bluez5, so if we want to do it "right", we should not pass --enable-library to configure. The consequence if this is that almost everything that uses bluez will break, though :-) #7: Jeffrey Cheung (jeffreycheung) (2013-08-08 15:39:18) (reply to #6) Thanks and RD acknowledged your comment. We may miss upgrade at openSUSE 13.1 and wait for 13.2 next year. However, we will keep working for SLE12. #12: Petr Tesařík (ptesarik) (2013-08-20 14:03:06) FWIW the Bluetooth stack is currently broken in Factory. At least I cannot get my BT headset to work. We would have to make our own patch to fix this bug (backporting from upstream is hard because of API changes). I'm afraid the maintenance cost in SLE12 lifetime is prohibitively high, not even daring to think about security monitoring. #16: Al Cho (acho-novell) (2013-08-21 15:02:41) (reply to #12) Hi Petr, Thanks for your comment. and Would you file a bug to me about your headset doesn't work ? ( or the bug is already there? ) I would fix it. Thanks, AL #20: Petr Tesařík (ptesarik) (2013-08-23 12:46:13) (reply to #16) The failure seems to be somewhat related to the HCI hardware, not to the bluez version. I only wanted to mention it as an example, but it wasn't a good one after all. Nevertheless, I still believe that providing L3 support for an outdated bluez version for years is too much effort. Moreover, this would be wasted effort, while helping to update dependent packages (in upstream) pays off. #13: Ondrej Holecek (oholecek) (2013-08-20 15:05:24) Note that current PulseAudio (4.0) does not support Bluez5. PulseAudio 5.0 with initial Bluez5 support was planned to release around upcoming GNOME 3.10 (end of September AFAIK) but freeze was postponed so this target was missed. #14: Petr Tesařík (ptesarik) (2013-08-21 11:50:56) (reply to #13) This is sweet. So, the same Lennart who repeatedly introduced incompatible changes in the infrastructure and asked everybody to adapt, has been unable for over a year to adapt his fine software to a similar change in the infrastructure he's using... Why am I surprized? *sigh* #18: Joey Lee (joeyli) (2013-08-23 07:06:48) Thanks for the comments from Petr, Ondrej and Scott. Per Scott's comment, looks Gnome will move to support BlueZ 5. If there doesn't have KDE in SLE-12, then I think move to BlueZ 5 in SLE-12 is make sense. This FATE highly dependent to the development progress of desktop UI(e. g. Gname, KDE) but not just replace the BlueZ package and take care the bluetooth driver in kernel. So, I suggest add desktop engineering leader and Gnome experts to this FATE to collaborative work. #19: Jeffrey Cheung (jeffreycheung) (2013-08-23 15:42:17) Very well, AL, please watch closely the gnome development. Hi Scott, can you provide your member which AL can cowork with. #25: Scott Reeves (sreeves1) (2013-08-30 17:26:23) (reply to #19) For now just directly to me. #21: Jeffrey Cheung (jeffreycheung) (2013-08-25 23:28:54) Add Some current mail thread from openSUSE factory mailing list (1) From Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> Jeffrey, looking at where GNOME 3.10 is heading, we discuss as much as there is need for: but in the end, GNOME 3.10 will depend on BlueZ5; As such, it's much better for us to switch sooner than later; and Raymond is doing the best job there is to get KDE in line with these requirements as well. So, I would really recommend that we bite the bullet and push BlueZ5 to Factory ASAP! The good thing: we won't be alone with this: Fedora 20 will have the same setup. So we can surely profit from each other there. If we stay with Bluez4, then we have to be aware that for GNOME this might or might not work; surely, upstream support will not be given in this case. If you're planning to such tricks for SLE, I urge you to rethink such a plan. Again, for openSUSE: BlueZ5 is mainly ready, the 'legacy API' needs to be enabled (which is done by Seife) and the stuff relying on the DBUS interface needs to be made aware of the new interface (not backwards compatible). It's a one-time pain we have to take now; or we split the pain over two releases. Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> -------------------------------------------------------------------------------- (2) From Stefan Seyfried <stefan.seyfried(a)googlemail.com> Hi Jeffrey, I was the one objecting the update. But then I did not know that there is already software using (even depending on) bluez5. My impression was that there is "no need to rush" for 13.1. And when I had looked last, there was no sign of fedora using bluez5 "soon". Now that these things have changed (GNOME 3.10 depends on bluez5, KDE will most likely be able to use it) and we won't be the first and only users of bluez5, I agree with Dominique's assessment that it probably is best to switch to the newer version and not mess around with the old stuff. If only GNOME would have kept the standalone bluetooth-applet, this would be a total non-brainer since everyone could use it, but they are really trying to create vendor lock-in to their platform :-( For SLES12 anything less than bluez5 is probably a bad ide :-) Best regards, and sorry for any confusion I might have caused with my previous rejection. Stefan -- Stefan Seyfried Linux Consultant & Developer -- GPG Key: 0x731B665B #22: Al Cho (acho-novell) (2013-08-28 10:26:11) Hi All, we also need a new package "ofono" (https://ofono.org/about) if we choose move to bluez 5. Because bluez remove internal support for telephony (HFP and HSP) profiles. They should be implemented using the new Profile interface preferably by the telephony subsystem of choice ( oFono which already supports this). Cheers, AL #23: Jeffrey Cheung (jeffreycheung) (2013-08-29 11:14:27) (reply to #22) Hi Stefan, per Al, we need the new package "ofono", can we just add the package directly ? #24: Stefan Behlert (sbehlert) (2013-08-29 08:48:19) (reply to #23) Sure, if the license is ok (seems to be GPL2 if I did not misread) and there's a maintainer. I assume it will be in Factory soon? Iexpect we will notice it is required due to dependencies when we start with the SLE 12 images? -- openSUSE Feature: https://features.opensuse.org/315090

1 0

[openFATE 306476] Install boot entry configurable in kernel git file
by fate_noreply＠suse.de 11 Dec '13

11 Dec '13

Feature changed by: Thomas Renninger (trenn) Feature #306476, revision 22 Title: Install boot entry configurable in kernel git file openSUSE-11.2: Rejected by Stefan Dirsch (sndirsch) reject date: 2010-01-10 10:12:41 reject reason: Obviously this has not been implemented for 11.2. Priority Requester: Important Projectmanager: Important - openSUSE-11.3: Evaluation by engineering manager + openSUSE-11.3: Rejected by Thomas Renninger (trenn) + reject reason: This product is out for long -> setting rejected so that + this feature does not show up in search requests anymore. Priority Requester: Important Projectmanager: Important Requested by: Thomas Renninger (trenn) Partner organization: openSUSE.org Description: Provide a file in the kernel git which describes an installation boot entry including: - help/description - specific boot parameters - active on which arch The installation image (e.g. DVD) will then provide these specific boot entries to make it easy for: - kernel developers to add critical boot parameters required for specific HW for booting - users by providing a meaningful help at boot loader start up Currently most important settings that are coming to my mind are: - apic=bigsmp (for i386 machines with a lot cores might require that) - disable Kernel Mode Settings -> disable kernel graphics parts which won't work on all HW if set by default soon The idea originally comes from Bernhard Walle. Steffen and myself discussed that already and agreed that it makes sense to do that. On longterm it would be great to get rid of the "Failsafe" Yast boot loader functionality. This would not be necessary anymore then. This currently totally useless and outdated anyway. With the new approach, soon as one successfully booted an entry from the installation image, these boot options will be the default forever (or manually adjusted). Discussion: #1: Stefan Dirsch (sndirsch) (2009-06-22 10:09:05) I think the X' team' would like to get involved here WRT KMS. Also I believe we still want to have a possibility to detect that the user wants to start the Xserver from installation (usually fbdev driver) instead of the apparently broken native X driver. This was boot param 'x11failsafe' in the past. #2: Thomas Renninger (trenn) (2009-06-22 14:27:39) Yeah, in this case we probably need some advise from the X guys which boot params have to be passed, eventually other extra quirks are needed for KMS, no idea. But in general the responsibility and possibilty to generate/modify extra boot entries and with them passing extra kernel boot parameters and a description when to use them should rely in the kernel teams hands and thus the config file should lie in the kernel repo. Coolo, can you set this fate entry a project manager state, so that we can finally work on that at some time, thanks. #3: Stefan Dirsch (sndirsch) (2009-06-22 14:52:39) Probably the modeset option needs to be used for all relevant KMS capable DRM modules, like i915, radeon. Possibily also radeonhd (still to be implemented) and nouveau (in case it's installed, we don't ship it). So something like this: i915.modeset=0, radeon.modeset=0, radeonhd. modeset=0, nouveau.modeset=0. #5: Andreas Jaeger (a_jaeger) (2009-07-10 11:47:39) I'm a bit confused what you want to do here. What advantage will this bring us? #6: Andreas Jaeger (a_jaeger) (2009-07-14 15:13:04) (reply to #5) Just talked with Thomas: The idea is to safe the information about kernel-parameters as part of the kernel package and let the installation get this information from there - instead of hardcoding it in the installation workflow. Also the kernel would provide different options that the developers think make sense. #8: Michal Marek (michal-m) (2009-09-04 13:05:51) Adding such file(s) to git and packaging them in the binary rpms is not a problem, I think this is mainly a feature for installation images build to get the configuration from the kernels and use it when generating the menu. Steffen, what do you think? #9: Thomas Renninger (trenn) (2009-09-04 13:47:04) Yep. Steffen and I already fiddled out a config file format. It's mainly on me to add an example file to our git repo. Steffen then can implement the installation image part. I just did not found the time (and wanted to poke graphics guys about sane KMS kernel boot params to provide which should be most important for 11.2). #10: Stefan Dirsch (sndirsch) (2009-12-12 07:14:04) About KMS integration for openSUSE 11.3 and SLE11-SP1, please see Bug #560438. #11: Stefan Dirsch (sndirsch) (2010-04-03 11:47:31) Not sure if this one is still interesting for X developers. KMS integration is now fully done in SLE11-SP1 and openSUSE 11.3. #12: Stefan Dirsch (sndirsch) (2010-04-24 16:20:47) (reply to #11) I believe it isn't. -- openSUSE Feature: https://features.opensuse.org/306476

1 0

[New: openFATE 316780] Search for application by description
by fate_noreply＠suse.de 08 Dec '13

08 Dec '13

Feature added by: Philipp Bielefeldt (pbiel) Feature #316780, revision 1 Title: Search for application by description Buildservice: Unconfirmed Priority Requester: Desirable openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Philipp Bielefeldt (pbiel) Partner organization: openSUSE.org Description: Installing programs on openSuSE already offers the best experience in the Linux world. Yet, finding applications you need can be a little too complicated, as you'll usually have to know what program you're looking for. I'll give an example: On my new openSuSE machine, I intended to install a twitter client, so I went to software.opensuse.org and typed "twitter client". It found 0 results. The Software Manager came up with turpial at least (because it contains "Twitter Client" in it's description). Nevertheless, Gwibber, Hotot, Tweetdeck, Choqok and many others are available for openSuSE. It would help if a search for a specific use case could give me all information necessary to find a well-suited program for my needs. -- openSUSE Feature: https://features.opensuse.org/316780

1 1

[New: openFATE 316759] option to supress return of i#86 packages on x86_64 systems for zypper se -s
by fate_noreply＠suse.de 08 Dec '13

08 Dec '13

Feature added by: Felix Miata (mrmazda) Feature #316759, revision 1 Title: option to supress return of i#86 packages on x86_64 systems for zypper se -s Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Felix Miata (mrmazda) Partner organization: openSUSE.org Description: Feature should be configurable and on by default. Zypper se -s on 64 bit systems typically returns nearly twice as many hits as on 32 bit systems. This pointless nuisance makes me want to not bother using 64 bit arch on 64 bit capable machines. Virtually every 64 bit search requires extending cmdline to include "| egrep -v '586|686'" to minimize loss of hits above the scrollback buffer and tire the eyes less from the virtual replication. -- openSUSE Feature: https://features.opensuse.org/316759

1 2

[New: openFATE 310151] YAST Software Manager-Search also in openSUSE Build Service
by fate_noreply＠suse.de 05 Dec '13

05 Dec '13

Feature added by: m s (miki100) Feature #310151, revision 1 Title: YAST Software Manager-Search also in openSUSE Build Service openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: m s (miki100) Description: It would be really helpful if Software Manager could find packages that aren't in any repo added. For example: a new user wants to install VLC Media Player. He search for it, but he doesn't have any repos added. Instead of an empty list Software Manager could search for it in openSUSE Build Service. After selecting an app to install and clicking "Apply" a question could appear with choice to keep or not that repository after install. It would be much easier for new users. -- openSUSE Feature: https://features.opensuse.org/310151

1 3