July 2014 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 317808] OBS support for adding external repositories (Packman and such) for dependencies
by fate_noreply＠suse.de 24 Jul '14

24 Jul '14

Feature added by: Sergey Kondakov (X0F) Feature #317808, revision 1 Title: OBS support for adding external repositories (Packman and such) for dependencies Buildservice: Unconfirmed Priority Requester: Important Requested by: Sergey Kondakov (x0f) Partner organization: openSUSE.org Description: OBS must allow the addition of repositories from other OBS instances into a project, similarly to the usual way (https://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#Adding_multi…) of adding its "local" repos. "Just registering" on those OBS instances, like Packman, isn't really much of an option because of their weird trial-to-sing-up lunacy (which, i'm sure, isn't the end of it but just the beginning). Things like that really make one regret ever trying to create packages for binary distributions. Use Case: You want to make a package of perfectly free and open source software (like goldendict or ppsspp) that depends on other perfectly free and open source software, which SUSE discriminates against, (like ffmpeg) but can't, because SUSE admins silently delete it from your repos and OBS doesn't allow adding external (from other OBS instances) repos (like Packman) to accommodate for such dependencies. Business case (Partner benefit): openSUSE.org: To not to discriminate against perfectly good free and open source software (some of which is so important that even on non-free OSes it holds primacy in its category) because of legalized extortion in some countries that doesn't even apply to many of us. -- openSUSE Feature: https://features.opensuse.org/317808

1 1

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

24 Jul '14

Feature changed by: Jeffrey Cheung (Jeffreycheung) Feature #315090, revision 56 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 + 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 + 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 -- openSUSE Feature: https://features.opensuse.org/315090

1 0

[openFATE 307255] Less scary yast conflict dialogs
by fate_noreply＠suse.de 22 Jul '14

22 Jul '14

Feature added by: Martin Schlander (cb400f) Feature #307255, revision 1 Title: Less scary yast conflict dialogs openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Martin Schlander (cb400f) Description: The YaST2 sw_single dialog for conflicts, vendor change, architecture change etc. is very scary for many users. The dialog asks the user to select one of usually three offered solutions for each problem without giving much help. This is a cause for many complaints, and contributes to myths of RPM dependency hell still existing today. Zypper on the other hand, does things differently. Zypper will select an action for the user, then informs the user of the changes that will be made, and asks a Yes or No question whether the user wishes to proceed or not. I suggest to implement behaviour similar to zypper in the YaST dialog. However, the old functionality of letting the user select a solution manually for each individual problem should probably be kept, as a "hidden" expert/advanced option in the dialog. -- openSUSE Feature: https://features.opensuse.org/307255

1 10

[New: openFATE 317804] Add a revert changes button on the package manager (Yast Software Management)
by fate_noreply＠suse.de 22 Jul '14

22 Jul '14

Feature added by: Kyle Agronick (agronick) Feature #317804, revision 1 Title: Add a revert changes button on the package manager (Yast Software Management) Requested by: Kyle Agronick (agronick) Partner organization: openSUSE.org Description: Currently to get a clean slate in the package manager you need to close the application and open it again. It would be nice if you could simply revert all changes. Especially after choosing a conflict resolution and you decide to cancel it or choose a different option. Business case (Partner benefit): openSUSE.org: So you don't need to close the application and restart it to reset the program. -- openSUSE Feature: https://features.opensuse.org/317804

1 0

[openFate 305249] Remove agfa-fonts from openSUSE 11.1
by fate_noreply＠suse.de 22 Jul '14

22 Jul '14

Feature added by: Michael Loeffler <michl(a)novell.com> Feature #305249, revision 1, last change by Title: Remove agfa-fonts from openSUSE 11.1 openSUSE-11.1: Evaluation Priority Requester: Important Requested by: Michael Loeffler <michl(a)novell.com> Partner organization: openSUSE.org Description: As Liberation fonts looking really good meanwhile I propose to replace the proprietary agfa-fonts with the open source fonts for openSUSE 11.1 and future versions. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305249

1 17

[New: openFATE 308528] Yast options to replicate Ldap server
by fate_noreply＠suse.de 18 Jul '14

18 Jul '14

Feature added by: Eduardo Sotomayor (Easgs) Feature #308528, revision 1 Title: Yast options to replicate Ldap server openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Eduardo Sotomayor (easgs) Description: In opensuse 11.x it is possible to setup an ldap server easily, but it would be nice to have the option to setup the server in graphical mode as an ldap provider or ldap costumer, in case you need redundancy in your environment, this is especially useful when creating a samba BDC that is possible to setup using yast. -- openSUSE Feature: https://features.opensuse.org/308528

1 6

[openFATE 313811] Configurable multi-spec file package build mode
by fate_noreply＠suse.de 15 Jul '14

15 Jul '14

Feature changed by: Adrian Schröter (adrianSuSE) Feature #313811, revision 6 Title: Configurable multi-spec file package build mode Buildservice: Evaluation by engineering manager - Milestone: 2.6 + Milestone: 2.7 Priority Requester: Mandatory Projectmanager: Important Requested by: Dr. Werner Fink (wernerfink) Partner organization: openSUSE.org Description: We want to have a functionality to enable multiple spec file builds from one source without the need to create _link's. This should be configurable project wide and per package. Additionally it would be nice to offer an option to build all of them in same build root sequential or even in parallel (Would obsolete texlive-specs-? meta packages). Discussion: #1: Adrian Schröter (adriansuse) (2012-09-07 10:16:43) This can also be used for product building, so we can turn productconverter into a source service. -- openSUSE Feature: https://features.opensuse.org/313811

1 0

[New: openFATE 309058] Support patterns a build dependencies
by fate_noreply＠suse.de 07 Jul '14

07 Jul '14

Feature added by: Adrian Schröter (adrianSuSE) Feature #309058, revision 1 Title: Support patterns a build dependencies Buildservice: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Adrian Schröter (adriansuse) Description: Esp. for kiwi image builds we need to support also patterns as build dependencies. This may be done together with fate #309057 (Generate patterns out of product descriptions), but we could also already support it with current pattern support of OBS. That would mean we need to generate the patterns from past products also as OBS pattern. -- openSUSE Feature: https://features.opensuse.org/309058

1 5

[openFATE 306193] Provide download statistics in OBS
by fate_noreply＠suse.de 07 Jul '14

07 Jul '14

Feature added by: Carsten Hoeger (choeger) Feature #306193, revision 1, last change by Title: Provide download statistics in OBS Buildservice: Unconfirmed Priority Requester: Important Requested by: Carsten Hoeger (choeger) Description: It would be great to see how popular the packages are. That's an important feature especially for management people. Use Case: Manager John would like to see whether the investment in providing packages for the community did show any results. Is the community interested at all? Did the last press announcement result in increased download numbers? -- openSUSE Feature: https://features.opensuse.org/306193

1 9

[New: openFATE 317744] YaST PKGBUILD
by fate_noreply＠suse.de 01 Jul '14

01 Jul '14

Feature added by: Aidan Collier (WokSearedBacon) Feature #317744, revision 1 Title: YaST PKGBUILD openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Aidan Collier (woksearedbacon) Partner organization: openSUSE.org Description: As part of YaSt, there would be a program which would help users to build their openSUSE packages from source, and easily expedite the process of packaging linux programs for the openSUSE distribution. Use Case: To given an example, say a project had put out a linux program in the form of a source tarball, and the program has not yet been built specifically for RPM (or zypper). The YaST packager would make building this program into an openSUSE package much easier to do for most any user, and with Build Service integration, allow users to add new packages to the RPM repositories. Business case (Partner benefit): openSUSE.org: To allow users to easily build new packages for openSUSE, and allow more packages to be contributed to the Build service or another openSUSE repository. -- openSUSE Feature: https://features.opensuse.org/317744

1 0

[New: openFATE 317727] automatic daily fstrim for SSD
by fate_noreply＠suse.de 01 Jul '14

01 Jul '14

Feature added by: Matthias Eckermann (mge1512) Feature #317727, revision 1 Title: automatic daily fstrim for SSD Requested by: Matthias Eckermann (mge1512) Partner organization: openSUSE.org Description: As SSD are becoming more affordable they are also becoming more widespread on laptop and desktop computer. Modern SSD supports the TRIM functionality. This functionality delays costly erase operation to speed up performance ; these erase operations are then executed by batch (this is SSD equivalent to defragmentation). SSD can only run at their full potential if this functionality is also supported by kernel and/or userland on the OS. Sadly TRIM support by kernel is not optimal yet. Erase operation are not launched automaticaly and this impacts overall SSD performance. A cron script written at setup phase could launch fstrim program each night; this program performs the erase operation needed not to struggle the SSD. Relations: - automatic daily fstrim for SSD (feature/copiedfrom: 312476) -- openSUSE Feature: https://features.opensuse.org/317727

1 2