June 2015 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 930340] New: rtl8723be: wifi locks and disconnects on re-keying
by bugzilla_noreply＠novell.com 29 Dec '16

29 Dec '16

http://bugzilla.novell.com/show_bug.cgi?id=930340 Bug ID: 930340 Summary: rtl8723be: wifi locks and disconnects on re-keying Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: psychonaut(a)nothingisreal.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I have a Realtek WLAN controller which uses the rtl8723be driver on the 3.16.7-21-desktop kernel. After connecting to a wireless network, the connection works for about 20 or 30 minutes. The connection then drops, and nothing short of rebooting can get it to connect again. Examining /var/log/wpa_supplicant.log shows that the disconnection always happens after a group rekeying: wlp2s0: WPA: Group rekeying completed with 5c:d9:98:e4:d9:d0 [GTK=TKIP] wlp2s0: WPA: Group rekeying completed with 5c:d9:98:e4:d9:d0 [GTK=TKIP] wlp2s0: WPA: Group rekeying completed with 5c:d9:98:e4:d9:d0 [GTK=TKIP] wlp2s0: WPA: Group rekeying completed with 5c:d9:98:e4:d9:d0 [GTK=TKIP] wlp2s0: CTRL-EVENT-DISCONNECTED bssid=5c:d9:98:e4:d9:d0 reason=2 wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=WORLD wlp2s0: CTRL-EVENT-SCAN-STARTED wlp2s0: SME: Trying to authenticate with 5c:d9:98:e4:d9:d0 (SSID='FrettchenNet' freq=2462 MHz) wlp2s0: CTRL-EVENT-SCAN-STARTED wlp2s0: SME: Trying to authenticate with 5c:d9:98:e4:d9:d0 (SSID='FrettchenNet' freq=2462 MHz) wlp2s0: CTRL-EVENT-SCAN-STARTED wlp2s0: SME: Trying to authenticate with 5c:d9:98:e4:d9:d0 (SSID='FrettchenNet' freq=2462 MHz) wlp2s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="FrettchenNet" auth_failures=1 duration=10 reason=CONN_FAILED This looks to be the upstream bug report: https://github.com/lwfinger/rtlwifi_new/issues/22 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 926006] New: KDE does not display Terminus font anymore
by bugzilla_noreply＠novell.com 26 Dec '16

26 Dec '16

http://bugzilla.opensuse.org/show_bug.cgi?id=926006 Bug ID: 926006 Summary: KDE does not display Terminus font anymore Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Workspace Assignee: kde-maintainers(a)suse.de Reporter: suse(a)bugs.jan.ritzerfeld.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 630042 --> http://bugzilla.opensuse.org/attachment.cgi?id=630042&action=edit This is not xos4 Terminus but Arial with misplaced cursor KDE does not display the xos4 Terminus font anymore. It looks like the update of libfreetype6 last month caused this. Konsole and Yakuake use the fixed font metrics for the cursor but actually display Arial. jan@karl:~> fc-match "xos4 Terminus" ter-112n.pcf: "xos4 Terminus" "Regular" xterm does not want to use Terminus: jan@karl:~> xterm -fa "xos4 Terminus" xterm: Selected font has no non-zero height for ISO-8859-1 encoding -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 929688] New: Critical Problem in Qt Network Stack
by bugzilla_noreply＠novell.com 23 Dec '16

23 Dec '16

http://bugzilla.opensuse.org/show_bug.cgi?id=929688 Bug ID: 929688 Summary: Critical Problem in Qt Network Stack Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Workspace Assignee: kde-maintainers(a)suse.de Reporter: freitag(a)owncloud.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- At ownCloud Inc. we have identified and fixed a severe bug in Qt's network stack which leads to data corruption in rare cases. The corruptions are very hard to even identify for users as the file size remains the same. We provided two patches for both the latest Qt4 and Qt5 packages as described in a mail to the Qt devel mailinglist: http://lists.qt-project.org/pipermail/development/2015-May/021295.html We would like to ask kindly to ship these patches on all supported platforms of openSUSE to avoid users data corruption. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 909824] New: Meld background color of the source view is black when using gtk3-oxygen theme in kde4
by bugzilla_noreply＠novell.com 23 Dec '16

23 Dec '16

http://bugzilla.opensuse.org/show_bug.cgi?id=909824 Bug ID: 909824 Summary: Meld background color of the source view is black when using gtk3-oxygen theme in kde4 Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Workspace Assignee: kde-maintainers(a)suse.de Reporter: thomasbilk(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- There is a resolving bug on the GNOME/meld Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=741287 When you use meld with the gtk3-oxygen theme in kde4 the background of the source view is black and so nothing is readable. It seems like they fixed it. So it would be nice to see the patch in openSuse 13.2. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 911693] New: request systemd build bump to current BaseSystem repo instance
by bugzilla_noreply＠novell.com 23 Dec '16

23 Dec '16

http://bugzilla.opensuse.org/show_bug.cgi?id=911693 Bug ID: 911693 Summary: request systemd build bump to current BaseSystem repo instance Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: grantksupport(a)operamail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- informed that BaseSystem repo is *not* for Opensuse 13.2 use https://bugzilla.opensuse.org/show_bug.cgi?id=911245#c1 there are some significant, production-needed updates (naming- & udev- related) in systemd available in BaseSystem's instance, rpm -qa systemd systemd-210-905.1.x86_64 but not in the official OS update rpm -qa systemd systemd-210-25.8.1.x86_64 requesting to sync official OS update channel to current BaseSystem instance -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 584970] New: Yast gives error -4017 when trying to partition using LVM
by bugzilla_noreply＠novell.com 22 Dec '16

22 Dec '16

http://bugzilla.novell.com/show_bug.cgi?id=584970 http://bugzilla.novell.com/show_bug.cgi?id=584970#c0 Summary: Yast gives error -4017 when trying to partition using LVM Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: HP OS/Version: openSUSE 11.2 Status: NEW Severity: Major Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: p.c.manning(a)swansea.ac.uk QAContact: jsrain(a)novell.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.89 Safari/532.5 Hardware: HP ML115 with E200 SmartArray card. 4 250GB drives built as raid 5. Use OpenSUSE DVD installer, select LVM partitioning scheme, installation dies when preparing disks with error -4017 Reproducible: Always Steps to Reproduce: 1.Use OpenSUSE 11.2 DVD 64bit to Install OS 2.Get to partitioning scheme - select LVM 3.Continue through installation, installation dies at preparing disks stage Actual Results: Retried this with text mode installer which enabled me to switch to a working shell console, I could see that the installer had created a boot partition, an LVM partition and an LVM group. But had failed to create any logical volumes Expected Results: A properly partitioned disk! http://forums.opensuse.org/install-boot-login/433990-yast-partitioning-erro… Workround was to partition manually via a shell console. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 4

[Bug 910713] New: Microsoft Sculpt mouse needs regular re-pairing
by bugzilla_noreply＠novell.com 22 Dec '16

22 Dec '16

http://bugzilla.opensuse.org/show_bug.cgi?id=910713 Bug ID: 910713 Summary: Microsoft Sculpt mouse needs regular re-pairing Classification: openSUSE Product: openSUSE Factory Version: 201412* Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Workspace Assignee: kde-maintainers(a)suse.de Reporter: ingham(a)i-pi.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- OpenSUSE Tumbleweed on x86_64. POssibly relevant software: $ rpm -qa | grep -i blue pulseaudio-module-bluetooth-5.0-9.1.x86_64 libgnome-bluetooth13-3.14.0-1.1.x86_64 libbluedevil2-2.0~rc1-3.1.x86_64 bluez-5.25-1.1.x86_64 typelib-1_0-GnomeBluetooth-1_0-3.14.0-1.1.x86_64 libbluetooth3-5.25-1.1.x86_64 bluedevil-2.0~rc1-5.1.x86_64 bluedevil-lang-2.0~rc1-5.1.noarch gnome-bluetooth-3.14.0-1.1.x86_64 I am using KDE. $ ps ax | grep -i blue 1379 ? Ss 0:00 /usr/lib/bluetooth/bluetoothd 1933 ? S 0:00 /usr/lib/bluetooth/obexd 2091 ? Sl 0:00 /usr/bin/bluedevil-monolithic 14162 ? S 0:00 /usr/bin/kcmshell4 bluedevildevices bluedeviltransfer bluedeviladapters 14191 pts/2 S+ 0:00 grep --color=auto -i blue I have a Microsoft Sculpt bluetooth mouse. I had it working under 13.1, but I unfortunately do not know what I did to get it working properly. The OUI for this mouse is: 28:18:78 I can pair the mouse successfully, and it works fine. However, when it is not moved for a while, the mouse goes into a power-save mode and the result is that it disconnects from my system. When I move the mouse, I can see it try to re-connect; the bluetooth icon in the system tray blinks. If I have the bluetooth configuration page up, I can see the entry for the mouse change for a moment; the rightmost "ball" turns green and then back to gray. If the mouse is selected in the bluetooth configuration, after this, it is no longer selected. I can resolve the problem until the mouse goes to sleep again by putting the mouse into pairing mode and then select "Connect" from the bluetootk configuration page. This might the same bug from Ubuntu: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1094744 https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/1158462 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 833235] New: security:OpenVAS:UNSTABLE:v6: Bug
by bugzilla_noreply＠novell.com 19 Dec '16

19 Dec '16

https://bugzilla.novell.com/show_bug.cgi?id=833235 https://bugzilla.novell.com/show_bug.cgi?id=833235#c0 Summary: security:OpenVAS:UNSTABLE:v6: Bug Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software AssignedTo: johann.luce(a)wanadoo.fr ReportedBy: chrisfischer81(a)gmx.de QAContact: opensuse-communityscreening(a)forge.provo.novell.com Found By: --- Blocker: --- Hi, the current OpenVAS v6 packages on OBS for Debian 7 (i don't know the status of other packages) are missing some files for running the openvas-certdata-sync script: /usr/sbin/openvas-certdata-sync: 185: /usr/sbin/openvas-certdata-sync: cannot open /usr/share/openvas/cert/cert_db_init.sql: No such file Error: no such table: dfn_cert_advs Error: no such table: meta Error: Inconsistent data. Resetting CERT database. [i] Updating /var/lib/openvas/cert-data/dfn-cert-2008.xml warning: failed to load external entity "/usr/share/openvas/cert/dfn_cert_update.xsl" Because of this the openvas-manager failed to start: /etc/init.d/openvas-manager start Starting OpenVAS Manager: ERROR. because of this log entry: md main:WARNING:2013-08-03 13h21.04 utc:7559: sql_x: sqlite3_prepare faile d: no such table: main.meta -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 2

[Bug 924830] New: Apparmor service fails to start on boot
by bugzilla_noreply＠novell.com 19 Dec '16

19 Dec '16

http://bugzilla.opensuse.org/show_bug.cgi?id=924830 Bug ID: 924830 Summary: Apparmor service fails to start on boot Classification: openSUSE Product: openSUSE Factory Version: 201503* Hardware: All OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: ushamim(a)linux.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The apparmor service fails to start on boot but will work normally if I start it manually afterwards (systemctl start apparmor). ---------------------------------------------------------------------------- linux-jyg:~ # systemctl status apparmor -l ● apparmor.service - LSB: AppArmor initialization Loaded: loaded (/etc/init.d/boot.apparmor) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) Mar 29 12:22:46 linux-2jim systemd[1]: Job apparmor.service/start deleted to break ordering cycle starting with sysinit.target/start Mar 29 12:22:46 linux-2jim systemd[1]: Job apparmor.service/start deleted to break ordering cycle starting with basic.target/start Mar 29 12:22:46 linux-2jim systemd[1]: Job apparmor.service/start deleted to break ordering cycle starting with sysinit.target/start Mar 29 12:29:14 linux-jyg systemd[1]: Stopped LSB: AppArmor initialization. ---------------------------------------------------------------------------- linux-jyg:~ # systemctl show apparmor.service Type=forking Restart=no NotifyAccess=none RestartUSec=100ms TimeoutStartUSec=5min TimeoutStopUSec=5min WatchdogUSec=0 WatchdogTimestampMonotonic=0 StartLimitInterval=10000000 StartLimitBurst=5 StartLimitAction=none FailureAction=none PermissionsStartOnly=no RootDirectoryStartOnly=no RemainAfterExit=yes GuessMainPID=no MainPID=0 ControlPID=0 FileDescriptorStoreMax=0 StatusErrno=0 Result=success ExecMainStartTimestampMonotonic=0 ExecMainExitTimestampMonotonic=0 ExecMainPID=0 ExecMainCode=0 ExecMainStatus=0 ExecStart={ path=/etc/init.d/boot.apparmor ; argv[]=/etc/init.d/boot.apparmor start ; ignore_errors=no ; start_time=[Sun 2015-03-29 12:34:25 EDT] ; stop_time=[Sun 2015-03-29 12:34:26 EDT] ; pid=3876 ; code=exited ; status=0 } ExecReload={ path=/etc/init.d/boot.apparmor ; argv[]=/etc/init.d/boot.apparmor reload ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 } ExecStop={ path=/etc/init.d/boot.apparmor ; argv[]=/etc/init.d/boot.apparmor stop ; ignore_errors=no ; start_time=[Sun 2015-03-29 12:34:43 EDT] ; stop_time=[Sun 2015-03-29 12:34:43 EDT] ; pid=4084 ; code=exited ; status=0 } Slice=system.slice MemoryCurrent=18446744073709551615 Delegate=no CPUAccounting=no CPUShares=18446744073709551615 StartupCPUShares=18446744073709551615 CPUQuotaPerSecUSec=infinity BlockIOAccounting=no BlockIOWeight=18446744073709551615 StartupBlockIOWeight=18446744073709551615 MemoryAccounting=no MemoryLimit=18446744073709551615 DevicePolicy=auto UMask=0022 LimitCPU=18446744073709551615 LimitFSIZE=18446744073709551615 LimitDATA=18446744073709551615 LimitSTACK=18446744073709551615 LimitCORE=18446744073709551615 LimitRSS=18446744073709551615 LimitNOFILE=4096 LimitAS=18446744073709551615 LimitNPROC=31291 LimitMEMLOCK=65536 LimitLOCKS=18446744073709551615 LimitSIGPENDING=31291 LimitMSGQUEUE=819200 LimitNICE=0 LimitRTPRIO=0 LimitRTTIME=18446744073709551615 OOMScoreAdjust=0 Nice=0 IOScheduling=0 CPUSchedulingPolicy=0 CPUSchedulingPriority=0 TimerSlackNSec=50000 CPUSchedulingResetOnFork=no NonBlocking=no StandardInput=null StandardOutput=journal StandardError=inherit TTYReset=no TTYVHangup=no TTYVTDisallocate=no SyslogPriority=30 SyslogLevelPrefix=yes SecureBits=0 CapabilityBoundingSet=18446744073709551615 MountFlags=0 PrivateTmp=no PrivateNetwork=no PrivateDevices=no ProtectHome=no ProtectSystem=no SameProcessGroup=no IgnoreSIGPIPE=no NoNewPrivileges=no SystemCallErrorNumber=0 RuntimeDirectoryMode=0755 KillMode=process KillSignal=15 SendSIGKILL=yes SendSIGHUP=no Id=apparmor.service Names=apparmor.service Requires=basic.target Wants=system.slice WantedBy=sysinit.target Conflicts=shutdown.target Before=shutdown.target libvirtd.service sysinit.target YaST2-Second-Stage.service YaST2-Firstboot.service After=cleanup.service basic.target system.slice systemd-journald.socket Documentation=man:systemd-sysv-generator(8) Description=LSB: AppArmor initialization LoadState=loaded ActiveState=inactive SubState=dead FragmentPath=/run/systemd/generator.late/apparmor.service SourcePath=/etc/init.d/boot.apparmor UnitFilePreset=disabled InactiveExitTimestamp=Sun 2015-03-29 12:34:25 EDT InactiveExitTimestampMonotonic=703223225 ActiveEnterTimestamp=Sun 2015-03-29 12:34:26 EDT ActiveEnterTimestampMonotonic=704613755 ActiveExitTimestamp=Sun 2015-03-29 12:34:43 EDT ActiveExitTimestampMonotonic=720971923 InactiveEnterTimestamp=Sun 2015-03-29 12:34:43 EDT InactiveEnterTimestampMonotonic=721002152 CanStart=yes CanStop=yes CanReload=yes CanIsolate=no StopWhenUnneeded=no RefuseManualStart=no RefuseManualStop=no AllowIsolate=no DefaultDependencies=yes OnFailureJobMode=replace IgnoreOnIsolate=no IgnoreOnSnapshot=no NeedDaemonReload=no JobTimeoutUSec=0 JobTimeoutAction=none ConditionResult=yes AssertResult=yes ConditionTimestamp=Sun 2015-03-29 12:34:25 EDT ConditionTimestampMonotonic=703221450 AssertTimestamp=Sun 2015-03-29 12:34:25 EDT AssertTimestampMonotonic=703221451 Transient=no ---------------------------------------------------------------------------- More info: http://lists.opensuse.org/opensuse-factory/2015-03/msg00390.html -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 888446] New: dead_caron + u should produce uring for czech locale xim
by bugzilla_noreply＠novell.com 18 Dec '16

18 Dec '16

https://bugzilla.novell.com/show_bug.cgi?id=888446 https://bugzilla.novell.com/show_bug.cgi?id=888446#c0 Summary: dead_caron + u should produce uring for czech locale xim Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: i686 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: X.Org AssignedTo: bnc-team-xorg-bugs(a)forge.provo.novell.com ReportedBy: vlmarek(a)volny.cz QAContact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 My .profile contains: export GTK_IM_MODULE=xim export QT_IM_MODULE=xim export LC_ALL=cs_CZ.UTF-8 Now if I press dead_caron + u, I get ǔ, but I should get ů. The same for capital letters - I get Ǔ but I should get Ů. The workaround I use is to set ~/.XCompose to include "%S/en_US.UTF-8/Compose" <dead_caron> <u> : "ů" U016F # LATIN SMALL LETTER U WITH RING ABOVE <dead_caron> <U> : "Ů" U016E # LATIN CAPITAL LETTER U WITH RING ABOVE This is already defined in /usr/share/X11/locale/iso8859-2/Compose , but one would have to use iso8859-2 instead of UTF-8: <dead_caron> <U> : "\331" Uring <dead_caron> <u> : "\371" uring (of course the binary value for Uring is different in iso8859-2 and UTF-8, so it can't be fixed by straight copy/paste) I don't understand the xkb too well, but I guess that there should be new directory and file /usr/share/X11/locale/cs_CZ.UTF-8/Compose which would contain something similar to what I have in ~/.XCompose Please note that it does not seem to be logical to use dead_caron for ring above u, but since we don't use ring above any other letter, and ǔ does not exist in czech, it's very convenient to have it print ů. This way it works on czech keyboards since ever. It's interesting that I have hard time finding evidence that it should be set this way. For example https://ufal.mff.cuni.cz/pdt/Support/czech-info.html The ring accent can occur only above an "u" where, in contrary, no caron can occur. That is why many keyboards use the sequence "dead caron" - "u"/"U" to enter an "u" with ring above. However, other keyboards (including Microsoft Windows, I guess) alocate a "dead ring" key elsewhere, often to shifted semicolon, replacing the U.S. key for tilde. https://lists.debian.org/debian-gtk-gnome/2003/11/msg00235.html Thank you __ Vlad Reproducible: Always Steps to Reproduce: 1. Enable XIM input method by putting this into your .profile: export GTK_IM_MODULE=xim export QT_IM_MODULE=xim export LC_ALL=cs_CZ.UTF-8 2. restart X so that the options take effect 2.5 start xterm 3. set czech keyboard map setxkbmap "us,cz(qwerty)" -option grp:shifts_toggle -option ctrl:swapcaps 4. switch into czech map by pressing both shifts together 5. Press dead_caron (shift + key "=" which should normally produce character "+") 6. Press letter "u" 7. ǔ appears, but I should see ů Actual Results: ǔ appears Expected Results: I should see ů -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 4