March 2018 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 981271] New: KTTSMgr cannot use festival 2.4 in 13.1 or 13.2 or 42.1
by bugzilla_noreply＠novell.com 19 Feb '21

19 Feb '21

http://bugzilla.opensuse.org/show_bug.cgi?id=981271 Bug ID: 981271 Summary: KTTSMgr cannot use festival 2.4 in 13.1 or 13.2 or 42.1 Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 URL: http://bugs.pearsoncomputing.net/show_bug.cgi?id=2657 OS: Other Status: NEW Keywords: accessibility Severity: Normal Priority: P5 - None Component: Sound Assignee: tiwai(a)suse.com Reporter: mrmazda(a)earthlink.net QA Contact: qa-bugs(a)suse.de CC: anixx(a)opensuse.org Found By: --- Blocker: --- To reproduce: 1.ensure sound system works reliably 2.install festival and kdeaccessibility3 or trinity-tdeaccessibility from standard repos 3.enable festival with chkconfig (no systemd service for it exists) 4.open a KDE3 or TDE session 5.open KTTSMgr 6.try to add or edit a talker (talker tab) Actual behavior: 1.voice query fails 2.Enable on General tab cannot be selected 3.TTS cannot produce sound Expected behavior: 1.voice query succeeds 2.enabling on General tab is possible 3.TTS works as expected (e.g. speak clipboard) Notes: 1-KDE3's KTTSMgr on 13.1 on host Easystreet made sound until most recent updating, which replaced festival 2.1 with 2.4. Reverting to festival 2.1 from OSS repo restored sound. 2.KDE3' KTTSMgr on 13.2 had never been made to find voices or make sound on host Easystreet. I was only able to make it find voices and make sound after replacing its installed festival 2.4 from KDE3 repo with 2.1 from OSS repo. 3.TDE's KTTSMgr on 42.1 on hosts Easystreet and gx62b would not find voices or make sound until I replaced their festival 2.4 with the 2.1 version from 13.2's OSS repo. 4.TDE's KTTSMgr on Debian stretch on host Easystreet works as expected with its own festival 2.4. Yet to do is figure out why same OS/KTTSMgr/festival on host big41 does not output sound, though it does claim to find voices and appear fully configured to output sound, and other apps do output sound. 5.mailing list thread: http://trinity-users.pearsoncomputing.net/?0::10248 -- You are receiving this mail because: You are on the CC list for the bug.

2 22

[Bug 1049382] New: geany does not produce consistent output
by bugzilla_noreply＠novell.com 19 Feb '21

19 Feb '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1049382 Bug ID: 1049382 Summary: geany does not produce consistent output Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: Development Blocker: --- When the glfw package is built, it calls geany -v -c geany_config -g glfw.c.tags ...c but this produces varying results probably depending on some ordering in the filesystem. Diffing the build logs gave: - In file included from /tmp/tmp_F5J72Y.cpp:2:0: - ./src/wl_platform.h:30:10: fatal error: wayland-client.h: No such file or directory - #include <wayland-client.h> - ^~~~~~~~~~~~~~~~~~ + In file included from ./src/glx_context.c:28:0, + from /tmp/tmp_PQIPOZ.cpp:1: + ./src/internal.h:175:3: error: #error "No supported window creation API selected" + #error "No supported window creation API selected" + ^~~~~ + In file included from /tmp/tmp_PQIPOZ.cpp:6:0: + ./src/egl_context.h:50:3: error: #error "No supported EGL platform selected" + #error "No supported EGL platform selected" + ^~~~~ + In file included from /tmp/tmp_PQIPOZ.cpp:9:0: + ./src/mir_platform.h:34:10: fatal error: mir_toolkit/mir_client_library.h: No such file or directory + #include <mir_toolkit/mir_client_library.h> + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. so it seems, the 'compilation terminated' happens in different places. -- You are receiving this mail because: You are on the CC list for the bug.

2 8

[Bug 1017652] New: tracker-extract process generating core dumps through udev bad system call to socket()
by bugzilla_noreply＠novell.com 19 Feb '21

19 Feb '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1017652 Bug ID: 1017652 Summary: tracker-extract process generating core dumps through udev bad system call to socket() Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: bwilson3013(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build Identifier: After updating openSUSE Tumbleweed yesterday (12/29), I discovered that the tracker-extract process was cyclically failing and causing core dumps to be generated through systemd-coredump. The issue does not start until I log into the GNOME desktop (Wayland and/or X.org), and is not present if I log into the IceWM desktop. When I log into the GNOME desktop, I quickly hear my laptop fans kick into high gear, and I can see several (6-8) systemd-coredump processes running to generate the core dump files. I can see the new core-dump files being actively created in /var/lib/systemd/coredump/ When I first noticed this issue, I was using the packman-essentials repo for codes. I disabled the packman-essentials repo and reverted to the official Tumbleweed versions, and the issue is still present. I did a little debugging with the systemd coredumpctl utility, and the error seems to be caused by a bad system call in glibc socket(). Here's the gdb output and backtrace: Core was generated by `/usr/lib/tracker-extract'. Program terminated with signal SIGSYS, Bad system call. #0 0x00007f34356a1587 in socket () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. [Current thread is 1 (Thread 0x7f3413b15700 (LWP 2777))] (gdb) bt #0 0x00007f34356a1587 in socket () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f342fb0d304 in udev_monitor_new_from_netlink_fd (udev=0x7f340c379be0, name=<optimized out>, fd=-1) at src/libudev/libudev-monitor.c:207 #2 0x00007f343178a3a2 in () at /usr/lib64/libgudev-1.0.so.0 #3 0x00007f3435e9f0d7 in () at /usr/lib64/libgobject-2.0.so.0 #4 0x00007f3435ea0a6e in g_object_new_valist () at /usr/lib64/libgobject-2.0.so.0 #5 0x00007f3435ea0d11 in g_object_new () at /usr/lib64/libgobject-2.0.so.0 #6 0x00007f343178a537 in g_udev_client_new () at /usr/lib64/libgudev-1.0.so.0 #7 0x00007f33fe030d3a in () at /usr/lib64/gstreamer-1.0/libgstvideo4linux2.so #8 0x00007f33fe00ea53 in () at /usr/lib64/gstreamer-1.0/libgstvideo4linux2.so #9 0x00007f34207d10f7 in () at /usr/lib64/libgstreamer-1.0.so.0 #10 0x00007f34207d3068 in () at /usr/lib64/libgstreamer-1.0.so.0 #11 0x00007f34207dfc0e in () at /usr/lib64/libgstreamer-1.0.so.0 #12 0x00007f34207e0d01 in () at /usr/lib64/libgstreamer-1.0.so.0 #13 0x00007f34207e0ed6 in () at /usr/lib64/libgstreamer-1.0.so.0 #14 0x00007f34207e2b24 in gst_update_registry () at /usr/lib64/libgstreamer-1.0.so.0 #15 0x00007f342077d41e in () at /usr/lib64/libgstreamer-1.0.so.0 #16 0x00007f3435bcc988 in g_option_context_parse () at /usr/lib64/libglib-2.0.so.0 #17 0x00007f342077ddef in gst_init_check () at /usr/lib64/libgstreamer-1.0.so.0 #18 0x00007f342077de44 in gst_init () at /usr/lib64/libgstreamer-1.0.so.0 #19 0x00007f342110434b in tracker_extract_gstreamer (uri=uri@entry=0x7f340c007930 "file:///home/bwilson3013/Music/moe_/Sticks%20and%20Stones/02%20Sticks%20and%20Stones.m4a", info=info@entry=0x7f3418003060, type=type@entry=EXTRACT_MIME_AUDIO) at tracker-extract-gstreamer.c:1341 #20 0x00007f3421105b59 in tracker_extract_get_metadata (info=0x7f3418003060) at tracker-extract-gstreamer.c:1470 #21 0x000000000040ba86 in get_file_metadata (task=task@entry=0x17ad590, info_out=info_out@entry=0x7f3413b14d10) at tracker-extract.c:326 #22 0x000000000040bb53 in get_metadata (task=0x17ad590) at tracker-extract.c:510 #23 0x000000000040bbb0 in single_thread_get_metadata (queue=0x1932510) at tracker-extract.c:538 #24 0x00007f3435be81c5 in () at /usr/lib64/libglib-2.0.so.0 #25 0x00007f343595d454 in start_thread (arg=0x7f3413b15700) at pthread_create.c:333 #26 0x00007f34356a037f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Reproducible: Always Steps to Reproduce: 1. Turn on computer 2. Log into GNOME 3. See systemd-coredump processes running Actual Results: New core dump files for /usr/lib/tracker-extract appear in /var/lib/systemd/coredump/ Expected Results: GNOME tracker (or udev) should not be generating core dumps -- You are receiving this mail because: You are on the CC list for the bug.

2 68

[Bug 1084758] New: seccheck fails to cleanup some temporary files created during daily and weekly run
by bugzilla_noreply＠novell.com 14 Feb '21

14 Feb '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1084758 Bug ID: 1084758 Summary: seccheck fails to cleanup some temporary files created during daily and weekly run Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: d_werner(a)gmx.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build Identifier: During each run of the daily or weekly cron jobs of seccheck afterwards temporary files are left. Specifically these files are daily: created by the pattern specia_files_owner.XXXX in security_daily_helper.inc e.g. /tmp/specia_files_owner.Jx25 weekly: created by the pattern rpm-md5.XXXX in helper.inc e.g. /tmp/rpm-md5.AYWm This is observed with the rpm seccheck-3.0-lp150.2.3.noarch.rpm from Leap 15.0 Build 153.1 Reproducible: Always Steps to Reproduce: 1.have the seccheck rpm installed (and ensure the START_SECCHK="yes" which is the default) 2.let the time pass when the cron job triggers or tweak it to run "soon" 3.check if the files /tmp/rpm-md5.* or /tmp/specia_files_owner.* exist after the cronjob is finished dependent whether the daily or the weekly cron job was executed. Note: the weekly job can run for several minutes. Actual Results: Temporary files created by the cron job are left after the cron job completes. /tmp/specia_files_owner.???? /tmp/rpm-md5.???? Expected Results: seccheck should not leave temporary files after it finishes successfully. I do not consider this bug is not an actual security problem, it is just in a security related component. As far as I remember it even was already once fixed but crept in again. Note: this is not a new problem, AFAIK it also exists in Leap 42.3 and Tumbleweed, but maybe now is a good time to fix it and the fix is simple. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 912059] New: networkmanager plasmoid shows nearly everybody connected (although it seems that only one wpa2 is correctly connected
by bugzilla_noreply＠novell.com 11 Feb '21

11 Feb '21

http://bugzilla.opensuse.org/show_bug.cgi?id=912059 Bug ID: 912059 Summary: networkmanager plasmoid shows nearly everybody connected (although it seems that only one wpa2 is correctly connected Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Minor Priority: P5 - None Component: KDE4 Applications Assignee: kde-maintainers(a)suse.de Reporter: stakanov(a)freenet.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 618858 --> http://bugzilla.opensuse.org/attachment.cgi?id=618858&action=edit wrong connection info of networkmanager plugin Create several users. Create in user A a connection with wpa2 encryption, choose: only this user can connect. Save and connect. Look at the list of the plasmoid: it shows all available wlan as not connected and the one you created as connected. Now change to user B or C. As you are still up with user A and you are connected, now in user B or C it should show the same as in user A. Only it should not be possible to end simply this connection or to start it. But you will be able to use it. What happens: in B or C respectively, the list of all available stations shows up as "connected". So in theory you are connected to all wireless of the area. All? No, some do show up correctly as "not connected" but the list here is so long that I can show only the beginning of the screen-shot. The output of ifconfig and netstat seem normal. So this seems to be more an apparent than a real bug. I join a screenshot. What should have done the program: show the correct connection information. Screen-shot: the only "real" connection iw the one with the button disconnect. The other ssids are from the neighborhood. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 980313] New: /usr/lib/zypp/plugins/commit/susemanager should be moved to susemanager related package and not be part of base salt-minion
by bugzilla_noreply＠novell.com 08 Feb '21

08 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=980313 Bug ID: 980313 Summary: /usr/lib/zypp/plugins/commit/susemanager should be moved to susemanager related package and not be part of base salt-minion Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: mrueckert(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- seen with salt-minion-2015.8.8-68.1.x86_64 from systemsmanagement:saltstack the salt setup on the machine was turned off atm and this noticably slows down all zypp operations. if this plugin is mostly for susemanager it shouldnt be part of the normal salt-minion package. if it is meant to be used with normal salt, i would recommend renaming it. -- You are receiving this mail because: You are on the CC list for the bug.

2 25

[Bug 978833] New: systemsmanagement:saltstack/salt broken pkgrepo.managed priority atribute
by bugzilla_noreply＠novell.com 08 Feb '21

08 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=978833 Bug ID: 978833 Summary: systemsmanagement:saltstack/salt broken pkgrepo.managed priority atribute Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bmaryniuk(a)suse.com Reporter: tchatzimichos(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- pkgrepo.managed priority attribute shows the following error: Failed to configure repo 'NON_Public:Infrastructure': zypper command failed: Invalid priority ''102''. Use a positive integer number. The greater the number, the lower the priority. -- You are receiving this mail because: You are on the CC list for the bug.

2 10

[Bug 1032452] New: salt-cloud package misses deployment scripts
by bugzilla_noreply＠novell.com 08 Feb '21

08 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1032452 Bug ID: 1032452 Summary: salt-cloud package misses deployment scripts Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: openSUSE 42.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: dkarakasilis(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build Identifier: There is a number of scripts that salt-cloud uses in order to "saltify" (aka bootstrap) the minions: https://github.com/saltstack/salt/tree/develop/salt/cloud/deploy One of them (bootstrap-salt.sh) is the default when no specific (or custom) script is specified in configuration. None of our packages (salt, salt-cloud) provide that script. As a result, when a machine is started on some public cloud (only tried ec2 driver), the machine doesn't get salt-master or salt-minion services installed or run. The bootstrap process is completely ignored. After copying the bootstrap-salt.sh script from the github repo in "/usr/lib/python2.7/site-packages/salt/cloud/deploy" directory, the machines gets saltified. One thing to keep in mind though, if we are going to package those files, is that there is a "salt-cloud -u" command that fetches the latest versions from i-dont-know-where. That might mean, our users will use versions of those scripts that weren't packaged (or tested) by us. The 'salt-cloud -u' command doesn't fetch anything in my case, I don't know if this is because of the files missing in the first place or some other problem. Reproducible: Always Steps to Reproduce: 1. In OpenSUSE LEAP 42.2 install the packages salt-cloud and salt 2. Create ec2 provider and profile configuration 3. Try to create a saltified machine. E.g. "salt-cloud -p my_ec2_profile my_machine_name" Actual Results: The machine is created but there is no salt related package installed and no salt service running. We should get at least salt-minion running. Expected Results: Depending on configuration we should get "salt-minion" services installed and running. If we set "make_master: True" in our configuration we should also get salt-master service installed and running. below are an ec2 provider and profile examples. Replace placeholders with something working. > cat /etc/salt/cloud.providers.d/my-ec2.provider.conf my-ec2-provider: id: your_id_here key: 'your_key_here' keyname: your_key_name_as_it_appears_in_aws_console subnetid: comment_out_if_no_subnet_is_used private_key: your_pem_key_path # Make sure it is owned by whatever user salt is run as driver: ec2 ssh_interface: public_ips > cat /etc/salt/cloud.profiles.d/base_ec2.conf base_ec2: provider: my-ec2-provider # Opensuse image image: ami-eada30fc size: t2.micro make_master: True ssh_username: ec2-user -- You are receiving this mail because: You are on the CC list for the bug.

2 28

[Bug 1020831] New: All salt commands hang and cause salt-master to crash soon after
by bugzilla_noreply＠novell.com 08 Feb '21

08 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1020831 Bug ID: 1020831 Summary: All salt commands hang and cause salt-master to crash soon after Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: hguo(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 710818 --> http://bugzilla.suse.com/attachment.cgi?id=710818&action=edit master journal I started 3 fresh instances of Leap 42.2 on EC2, then proceed to install all updates and salt. Two minions can successfully join the master, but then all salt commands issued by master hang and cause salt-master to crash soon after a python error is raised. See attached log files. -- You are receiving this mail because: You are on the CC list for the bug.

2 41

[Bug 1058115] New: ORC tracker
by bugzilla_noreply＠novell.com 05 Feb '21

05 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1058115 Bug ID: 1058115 Summary: ORC tracker Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jslaby(a)suse.com Reporter: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This is a tracker for ORC patches. -- You are receiving this mail because: You are on the CC list for the bug.

2 102