August 2013 - openSUSE Features - openSUSE Mailing Lists

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

07 Aug '13

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

1 0

[New: openFATE 315964] systemd[1] dependency failed for /windows/G , grub2, no repair tools
by fate_noreply＠suse.de 07 Aug '13

07 Aug '13

Feature added by: Alan H Robinson Jr (alannsandiego) Feature #315964, revision 1 Title: systemd[1] dependency failed for /windows/G , grub2, no repair tools Requested by: Alan H Robinson Jr (alannsandiego) Partner organization: openSUSE.org Description: Thread: systemd[1] dependency failed for /windows/G , grub2, no repair tools http://forums.opensuse.org/english/get-technical-help-here/install-boot-log… Also: https://bugzilla.novell.com/show_bug.cgi?id=824861 alannsandiego Join Date May 2009 Location San Diego CA 92138 Posts 25 Default Re: systemd[1] dependency failed for /windows/G , grub2, no repair tools I noticed no one yet has a good solution to my original problem, except to get the developers to correct the problem ( 7/12/2013, This fix of the boot system is a complex fix and not to be done manually. > This is about asking the developers to build onto OpenSuse a GUI tool If you want to communicate with the developers, you need to open a bug in Bugzilla or a feature request in FATE. OK I see about this. Without an OpenSuse GUI repair tools and admin functions like saving all emails and personal settings, not everyone want to be a Linux expert, or do commands in text lines in Linux to use it. Without better support Linux remains unusable for productions system; it is just very pretty but not useful.) so here it is again: 7/5/2013, Dear Forum, I have backup hardware the same as my desktop, but after a Restore on the backup hardware OpenSuse 12.3 will not boot: Novell missing the fact the Backup Hardware never will be the same as the original system. I only reason the system boot at all is you now ignoring /Dev/by id method and booted /Dev/root Here is more description: last boot mesg: started show plymouth boot screen ---- boot log says this: systemd[1] dependency failed for /windows/G. =================================================== Even though the hardware is the same the device by ID is slightly different and so that method fails and the backup hardware will not start up completely. It boot too the emergency system even though all of OpenSuse is found and only non primary XP partitions are not found. The only reason that OpenSuse 12.3 boot at all is the start up script now ignores Dev/by id and now ignoring /Dev/by id method and booted /Dev/root must do the same thing for the XP C drive, but OpenSuse missed ignoring /Dev/by id method for my two other internal hard drives. Even if I replace my one of my failing drive OpenSuse 12.3 would fail to boot with the Dev/by id method; because the new drive will have a new ID and the only time OpenSuse repairs the boot method now is on an install; so any changes or do a restore to backup hardware and OpenSuse 12.3 can not be easily repair at present. Since there is no Live-CD with repair tools to fix the boot method like ================================================= BTW DO NOT USE THIS TOOL ON OPENSUSE, IT DOES NOT WORK FOR OPENSUSE. How about Novell fix this so that it works for OpenSuse? boot-repair: Simple GUI tool to Repair Grub2 Boot Loader | Handy Tutorial boot-repair-disk - Browse Files at SourceForge.net Home How-To Ubuntu Linux Windows About Us Handy Tutorial boot-repair: Simple GUI tool to Repair Grub2 Boot Loader I tried this tool and it missing one routine "xxxx..." someone commented about it; the routine is not on the disk and so this tool is broken. ================================================================================= The particular bug in Grub2 is that if you change from /Dev/by id to Dev/device this does not change the installation itself; it changes back. And further Grub2 does not present a list of /Dev/by id, or /Dev/device, or /Dev/by label to choose from so that one does not make an error in a long description. ======================================================== OpenSuse 12.3 is a great op system if nothing breaks, but the lack of repair tools on a Live-CD is a great defect. Any suggestion for a non expert? a simple way to fix this problem? ========================================================== It does not matter who owns OpenSuse This is not a backup issue, the backup and restore work very well. This is about asking the developers to build onto OpenSuse a GUI tool like the one above and this comment This entails booting from a live/rescue DVD/CD and doing a chroot Might want to look at this thread https://forums.opensuse.org/english/...-not-boot.html From a live-CD tool you have to use chroot to change the broken system, and of course if you read carefully, this boot does not need to fail at all same method use to find the /dev/root and c for XP can find all the drives with the same partition structure if the fix systemd[1]? Yes, if you can expert you can use the emergency repair system to manual fix the broken system, But why not have a GUI repair tool for this and other repairs? As soon as I replace my week drive OpenSuse 12.3 will not boot because the boot process will not see the new drive with the /Dev/by ID method. Until you fix this I can not use OpenSuse. At the present time on on install do you fix the boot process and that is not good enough to use your system. Business case (Partner benefit): openSUSE.org: If you replace a hard drive on an OpenSuse system at present the system will fail boot because you have no process to fix the boot process by repair GUI. Also after a restore to almost identical hardware the system does not boot even after a restore because your boot process does not see the same partitions on drive with a different /Dev/by ID number There is a simple fix to this problem is to change the systemd[1] script to ignore /Dev/ by ID number and boot to /dev/root and ADD a method to SEE none root partitions as you have already done for /Dev/root and XP root or C: drive. -- openSUSE Feature: https://features.opensuse.org/315964

1 1

[New: openFATE 315965] Verbatim 96666 driver: Key and Mouse Combo
by fate_noreply＠suse.de 07 Aug '13

07 Aug '13

Feature added by: John Shand (jshand2013) Feature #315965, revision 1 Title: Verbatim 96666 driver: Key and Mouse Combo Requested by: John Shand (jshand2013) Partner organization: openSUSE.org Description: i am unsure what to put here as i don't know which wireless keyboards/mice combos you currently have supported. this key board seems like the top of the line product and it would be good as most people are turning to wireless now. thanks guys for your continuous hard work -- openSUSE Feature: https://features.opensuse.org/315965

1 1

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

07 Aug '13

Feature changed by: Ludwig Nussel (lnussel) Feature #315090, revision 10 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. 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. -- openSUSE Feature: https://features.opensuse.org/315090

1 0

[New: openFATE 314467] virtio-scsi backport the sles10
by fate_noreply＠suse.de 07 Aug '13

07 Aug '13

Feature added by: yi li (liyicybertan123) Feature #314467, revision 1 Title: virtio-scsi backport the sles10 openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: yi li (liyicybertan123) Partner organization: openSUSE.org Description: virtio-scsi driver backport the sles10 -- openSUSE Feature: https://features.opensuse.org/314467

1 4

[New: openFATE 313152] Distribution cleanup (smaller disk footprint)
by fate_noreply＠suse.de 07 Aug '13

07 Aug '13

Feature added by: Andreas Jaeger (a_jaeger) Feature #313152, revision 1 Title: Distribution cleanup (smaller disk footprint) openSUSE Distribution: New Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: We want to have an as small as default base system (default text install) as possible. For this, I suggest to install a base system and investigate then what can be done to decrease the footprint. One idea is to check documentation (in /usr/share/doc/packages) and move them to doc or devel package (with the exception of license files). Also, we can check whether all dependencies (manual requires) are still correct - or in other words: Does every package that's there needs to be in the base install? Business case (Partner benefit): openSUSE.org: A small base system is important especially for appliances and virtual environments. -- openSUSE Feature: https://features.opensuse.org/313152

1 3

[New: openFATE 310310] Installer partition layout to allow "Whole Disk Usage"
by fate_noreply＠suse.de 07 Aug '13

07 Aug '13

Feature added by: Darryl Miles (dlmiles) Feature #310310, revision 1 Title: Installer partition layout to allow "Whole Disk Usage" openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Darryl Miles (dlmiles) Description: Currently the installer doesn't provide any option for Whole Disk Usage for a single purpose (such as rootfs or swap or /home etc...). Whole disk usage means there is no partition table and that file-system or swap is formatted directly. This has use-cases for virtulization where it is easier for the hypervisor to provision two block devices to the guest, one for rootfs and one for swap. These may come from LVM, SAN, etc... it is easier to manage because resizing either is a straight forward event due to the single purpose of each block device. One possible option to shoe-horn it into the UI would be under the Expert.../Advanced... buttons when either a partition or a disk device is selected. More ideas suggested in the bugzilla link further down this comment. Other possible considerations go with the bootloader options for installing GRUB. It would need to be adjusted to disallow/auto-disable MBR when no partition table is present. But the option still remains to install in the rootfs. Also submitted as ENH in Buzilla please read => https://bugzilla.novell.com/show_bug.cgi?id=628056 "installer doesn't support whole-disk usage", since this contain other comments not found here. -- openSUSE Feature: https://features.opensuse.org/310310

1 6

[New: openFATE 310103] wireless bridge configuration support in sysconfig
by fate_noreply＠suse.de 06 Aug '13

06 Aug '13

Feature added by: Marius Tomaschewski (mtomaschewski) Feature #310103, revision 1 Title: wireless bridge configuration support in sysconfig openSUSE-11.4: New Priority Requester: Important Requested by: Casual J. Programmer (casualprogrammer) Developer: (Novell) Developer: (Novell) Description: Wireless interfaces currently can not be bridged. In Windows XP it is quite easy to create and operate a bridge, saving one to setup and maintain all sorts of route information. It would make sense to support the bridged configuration in sysconfig when hostap implements 802.11c. Relations: - network bridge fails to integrate wlan (ipw3945) with WPA (novell/bugzilla/id: 541817) https://bugzilla.novell.com/show_bug.cgi?id=541817 - Bridge FAQ: I still don't understand!! (url: http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#I_s…) - Bridge FAQ: It doesn't work with my Wireless card! (url: http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#It_…) -- openSUSE Feature: https://features.opensuse.org/310103

1 3

[openFATE 313143] YaST LDAP client refactor/cleanup
by fate_noreply＠suse.de 05 Aug '13

05 Aug '13

Feature changed by: Ralf Haferkamp (rhafer) Feature #313143, revision 14 Title: YaST LDAP client refactor/cleanup openSUSE Distribution: Unconfirmed Priority Requester: Mandatory Requested by: Ralf Haferkamp (rhafer) Partner organization: openSUSE.org Description: Jiri (jsuchome) an I recently discussed some cleanup work we'd like to see in the YaST ldap-client module. This feature lists the main items we'd like to see reworked to improve the Module: Remove no longer needed UI elements Candidates are: * The TLS/SSL checkbox (sssd has a hard requirement for SSL/TLS) * The "LDAP Version 2" checkbox in the advanced settings. (there is AFAIK no LDAPv2-only Server implementation left) * The "Use LDAP but Disable Login" Radio Button Restrict the UI to handle only really LDAP client related things Currently the UI contains quite some settings which are not strictly related to LDAP client (nss/pam) setup. Over the year ldap-client became a bit of a disposal site for all kinds of LDAP related things, which made the UI a bit hard to understand. We should move some things to YaST modules where make a better fit. This is mostly about the settings currently available in the "Administration Settings" Tab (in "Advanced Configuration") * The Password Policies settings seem to fit better into the ldap- server module which already contains some of this functionality * Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. When a specific service still requires those configuration objects the YaST module for that service should be able to handle those objects it self (we could still offer utils API for that in yast2-ldap/ldap-client). E.g. the user management related object should be configured from inside the yast2-users module. yast2- ldap-server could offer to create default objects during the initial LDAP server setup. * The Home Directories on This Machine checkbox seems to be better suite in the Users module as well. * The rest of the values which go to /etc/sysconfig/ldap could be written by yast2-ldap-servers. We still need to figure out how to setup /etc/sysconfig/ldap on machines which to not run the LDAP Server but need access to those settings. (yast2-mail, -dns-server, -dhcp-server) * Adapt the API: move the LDAP* functions from ldap-client (impact on other modules!) Relations: - related feature (feature/id: 313142) Discussion: #1: Jiří Suchomel (jsuchome) (2012-01-19 10:15:11) 1. Removing TLS/SSL is based on assumption that we configure SSSD only, which is feature 313142. 2. About The "Use LDAP but Disable Login" Radio Button: did we agree on some replacement of it? I cannot remember... #2: Jiří Suchomel (jsuchome) (2012-01-23 16:25:33) Added attachment proposal for simplified first screen (ldap-client- redesign2.png) #3: Jiří Suchomel (jsuchome) (2012-02-21 09:26:08) yast2-ldap-client-2.22.3 only offers SSSD configuration in UI, and the option to turn off TLS/SSL was removed. #5: Jiří Suchomel (jsuchome) (2012-02-21 11:37:45) (reply to #3) yast2-ldap-client-2.22.4 has the password policy configuration removed. Some parts were moved to yast2-ldap-server code (just svn), some other parts need to be added there. I've created a bug report to track it, see bnc#748004. #4: Jiří Suchomel (jsuchome) (2012-02-21 10:26:39) Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. Ralf, do you have any idea where it could/should be removed? Who can decide it? #6: Jiří Suchomel (jsuchome) (2012-04-19 08:52:07) OK, I've made most of the required changes in yast2-ldap-client, yast2- users and yast2-ldap-server. Ralf, could you take a look at current (Factory) versions of these and comment what else should be done? I mean mostly UI-wise, that API transition was not done. #7: Lukas Ocilka (locilka) (2013-07-30 14:38:43) (reply to #6) Ralf: ping + #8: Ralf Haferkamp (rhafer) (2013-08-05 10:43:08) (reply to #7) + Peter, could you take a look a this. I don't have any time left for + this currently. -- openSUSE Feature: https://features.opensuse.org/313143

1 0

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

05 Aug '13

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

1 0