July 2014 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 310516] YaST2 DNSSEC
by fate_noreply＠suse.de 02 Oct '14

02 Oct '14

Feature added by: Peter Bowen (pzb) Feature #310516, revision 1 Title: YaST2 DNSSEC openSUSE-11.4: New Priority Requester: Important Requested by: Peter Bowen (pzb) Description: With the root zone now being signed, DNSSEC is finally seeing adoption. It would be really nice for YaST to be able to generate a signed zone. -- openSUSE Feature: https://features.opensuse.org/310516

1 8

[New: openFATE 315590] Support non-numeric names for md/raid devices.
by fate_noreply＠suse.de 30 Sep '14

30 Sep '14

Feature added by: Neil Brown (neilbrown) Feature #315590, revision 1 Title: Support non-numeric names for md/raid devices. Requested by: Neil Brown (neilbrown) Partner organization: openSUSE.org Description: mdadm-3.3 (due to be released July 2013) will support md device named like "md_home" as well as the traditional "md4". However these names are likely to confuses installers and other system managers so they are disabled by default. To get full benefit from these we need to: 1) Make sure initrd scripts in mdadm package handle these names. 2) teach yast-storage to be able to use non-numeric names and not to be confused by them 3) update any system administration documentation 4) check any system monitoring tools to ensure they won't get confused. Business case (Partner benefit): openSUSE.org: More friendly device names make for an improved user experience. -- openSUSE Feature: https://features.opensuse.org/315590

1 13

[New: openFATE 317700] Drop GRUB1 support from yast2-bootloader
by fate_noreply＠suse.de 08 Sep '14

08 Sep '14

Feature added by: Josef Reidinger (jreidinger) Feature #317700, revision 1 Title: Drop GRUB1 support from yast2-bootloader Requested by: Josef Reidinger (jreidinger) Partner organization: openSUSE.org Description: Drop grub1 support from yast2-bootloader. It will still allow to manually use grub1. Just it will drop support from installer and also configuration using yast2 bootloader module. Business case (Partner benefit): openSUSE.org: GRUB1 and GRUB2 is configured completely differently and result is that to allow yast2-bootloader support both, code contain many work-arounds and nasty code. It also allows us to focus on one supported bootloader that works for newbies. Expert can use what they need, but yast2 bootloader is focused to help new users to not be scared by bootloader and have their machine boot without problems. -- openSUSE Feature: https://features.opensuse.org/317700

1 1

[New: openFATE 314594] Drop ISDN support
by fate_noreply＠suse.de 03 Sep '14

03 Sep '14

Feature added by: Thorsten Kukuk (kukuk) Feature #314594, revision 1 Title: Drop ISDN support Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: ISDN package still depends on SuSEconfig, there is nobody who is able to adjust the code, ISDN is getting less and less important. -- openSUSE Feature: https://features.opensuse.org/314594

1 14

[New: openFATE 314945] No ABI extension in glibc
by fate_noreply＠suse.de 03 Sep '14

03 Sep '14

Feature added by: Andreas Jaeger (a_jaeger) Feature #314945, revision 1 Title: No ABI extension in glibc openSUSE Distribution: New Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: Currently we have the crypt-blowfish patches in glibc that add new symbol versions to it. I consider that addition wrong and propose to find a solution (might be getting the support in upstream, or using a separate library,...) that does not extend the ABI at all. The goal should be that our glibc exports exactly the same symbols as upstream glibc does. -- openSUSE Feature: https://features.opensuse.org/314945

1 8

[New: openFATE 315589] Deprecate bind-mount configuration with NFSv4 export
by fate_noreply＠suse.de 02 Sep '14

02 Sep '14

Feature added by: Neil Brown (neilbrown) Feature #315589, revision 1 Title: Deprecate bind-mount configuration with NFSv4 export Requested by: Neil Brown (neilbrown) Partner organization: openSUSE.org Description: When NFSv4 was introduced it was not possible to export filesystems to NFSv4 the same way as for NFSv3. The "bind=" syntax was added to /etc/exports to help bridge the gaps. With current kernel and nfs-utils this is no longer an issue. By default any filesystem that is exported is exported equally to NFSv2, v3, and v4. So we should deprecate the "bind=" syntax and eventually remove it. This means: 1) yasts nfs-server module should remove knowledge of "Bindmount targets". The "bind=..." option should just be treated like any other option. 2) yasts nfs-server module should not encourage the "fsid=0" export option. Like "bind=" it must still be permitted, but it should be considered and exception rather than normal. 3) Yasts nfs-server help screens should remove mention of "bind=" and "fsid=0". 4) Any documentation that mentioned nfs export, such as http://doc.opensuse.org/documentation/html/openSUSE/opensuse-reference/cha.… should be changed to remove mention of bind= and fsid=, and should not make any distinciton between NFSv4 and NFSv3. Business case (Partner benefit): openSUSE.org: Simplifies administration, reduces possible confusion, remove unnecessary difference between SUSE and other distros. -- openSUSE Feature: https://features.opensuse.org/315589

1 10

[New: openFATE 309036] Add checkbox to yast2-dns-server whether to use NETCONFIG_DNS_FORWARDER="bind" or not
by fate_noreply＠suse.de 02 Sep '14

02 Sep '14

Feature added by: Marius Tomaschewski (mtomaschewski) Feature #309036, revision 1 Title: Add checkbox to yast2-dns-server whether to use NETCONFIG_DNS_FORWARDER="bind" or not openSUSE-11.3: New Priority Requester: Desirable Requested by: Marius Tomaschewski (mtomaschewski) Description: Currently, yast2-dns-server always enables and makes use of the netconfig NETCONFIG_DNS_FORWARDER="bind" feature and writes the recursive forwarder name servers specified by the user to NETCONFIG_DNS_STATIC_SERVERS (same nameserver list as in yast2-dns). This configures, that the locally running bind is used as forwarder for the system (glibc) and the bind is using the specified name servers as forwarders and allows netconfig (by default, but it depends on NETCONFIG_DNS_POLICY) to update the forwarders list via netconfig with dynamic settings, e.g. from DHCP or PPP. This behavior is usually OK, and the user can disable the updates with the DHCP/PPP/... nameservers by NETCONFIG_DNS_POLICY="STATIC" instead of "auto". But currently, yast2-dns-server does not allow to configure forwarders for e.g. non-recursive, (authorative only) name server serving some zones, without to act as forwarder/recursive name server for the local system (glibc, /etc/resolv.conf), that may use another forwarders (netconfig). To allow above configuraion, it would be required to add a checkbox to disable the current behavior and instead: * Set NETCONFIG_DNS_FORWARDER="resolver" * Write the forwardes list directly into the /etc/named.d/forwarders.conf * Call "netconfig update -m dns" (when it fails, ask the user whether to force and call "netconfig update -m dns -f") To enable current behavior again: * Reset/truncate the /etc/named.d/forwarders.conf ("cp /dev/null forwarders.conf") * Set NETCONFIG_DNS_FORWARDER="bind" * Write the forwardes list to NETCONFIG_DNS_STATIC_SERVERS * Call "netconfig update -m dns" (when it fails, ask the user whether to force and call "netconfig update -m dns -f") Relations: - Bug 576759 - yast dns vs. dns-server is poorly designed (feature/id: 576759) -- openSUSE Feature: https://features.opensuse.org/309036

1 17

[New: openFATE 308902] Configure SSSD via Yast
by fate_noreply＠suse.de 02 Sep '14

02 Sep '14

Feature added by: David Alston (dalston) Feature #308902, revision 1 Title: Configure SSSD via Yast openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: David Alston (dalston) Description: It would be great if we could configure the SSSD package (http://fedoraproject.org/wiki/Features/SSSD) for local user/password sync with either LDAP or Kerberos for offline authentication with Yast. This is related to https://features.opensuse.org/308900 This is important if OpenSUSE is interested in being a significant presence in Enterprise environments. -- openSUSE Feature: https://features.opensuse.org/308902

1 35

[New: openFATE 308523] Firefox address bar should respect ctrl+backspace
by fate_noreply＠suse.de 20 Aug '14

20 Aug '14

Feature added by: Alex Richardson (alerich) Feature #308523, revision 1 Title: Firefox address bar should respect ctrl+backspace openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Alex Richardson (alerich) Description: To achieve consistency with the rest of the desktop (KDE or GNOME, don't know about XFCE), layout.word_select.stop_at_punctuation in about:config should be set to true by default. -- openSUSE Feature: https://features.opensuse.org/308523

1 4

[openFATE 315090] Upgrade to Bluez 5
by fate_noreply＠suse.de 28 Jul '14

28 Jul '14

Feature changed by: Karl Eichwalder (keichwa) Feature #315090, revision 57 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,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? #34: Al Cho (acho-novell) (2014-01-24 10:26:47) Done. Already supported on Factory. - Release Notes: Support Bluez 5 + Release Notes: Bluetooth Implementation BlueZ 5 Challenge: - BlueZ 5 come with numerous new features, API simplifications and other - improvements such as Low Energy profiles support. The new major version - of the Bluetooth handling daemon and utilities. - In facts, BlueZ 4 is no longer maintained upstream; thus upgrade to - BlueZ 5 ensures that we can get all the latest upstream bug fixes and + BlueZ 4 is no longer maintained upstream. Thus upgrading to BlueZ 5 + ensures that you will get all the latest upstream bug fixes and enhancements. - The BlueZ version in SUSE Linux Enterprise 11 SP3 is BlueZ 4.99 which - mean that regardless of new features, and improvements, we have to - upgrade definitely . Solution: - To develop SUSE Linux Enterprise 12 as BlueZ 5.0 compatable + BlueZ 5 comes with numerous new features, API simplification and other + improvements such as Low Energy support. It is new major version of the + Bluetooth handling daemon and utilities. + Note: The new major version indicates that the API is not backwards + compatible with BlueZ 4, which means that all applications, agents, + etc. must be updated. -- openSUSE Feature: https://features.opensuse.org/315090

1 0