February 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 859269] New: logstash unable to upload/query data to embedded Elasticsearch
by bugzilla_noreply＠novell.com 12 Feb '14

12 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=859269 https://bugzilla.novell.com/show_bug.cgi?id=859269#c0 Summary: logstash unable to upload/query data to embedded Elasticsearch Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: tonysu(a)su-networking.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 On VMware 10 Guest(although I don't believe is relevant here) openSUSE 13.1, both "minimal server" and LXDE desktop openjdk 1.7 logstash-1.3.2-flatjar.jar Highly recommend using a Desktop so multiple terminals can be launched easily Logstash tutorial reference http://logstash.net/docs/1.3.2/tutorials/getting-started-simple Example setup: Default 13.1 LXDE install install openjdk 1.7 If running in VMware, I also installed VMware Tools to support Shared Folders Recommend using 3 consoles (terminals) root console to execute the "java -jar logstash" commands user console to execute the curl commands user/root console to run other commands like netstat All tests and configurations work until you reach the step curl -gs -XGET "http://localhost:9200/logstash-*/_search?pretty&q=type:example" Results (stdout) elasticsearch shard configuration instead of data in json format Reproducible: Always Steps to Reproduce: 1.Setup as described in Details 2. Run the tests as described in Details 3. Actual Results: Results in wrong output Expected Results: Should result in json output I have successfully completed the tests in this tutorial in a CentOS Guest. Then I copied the logstash config from the CentOS guest to the openSUSE Guest. Then I deleted the /data folder (in the working logstash directory) to ensure a new test with no old data. Then executed logstash with the known working logstash config file In the user console I ran the problem curl command again. Instead of returning results similar to what I saw on CentOS, I saw the same wrong output on openSUSE. I also ran the java command with "-- web" as described later down the page. It looks like the embedded web module works fine. Bottom line: Looks like an embedded elasticsearch module is properly launched and indices are created. But there is some kind of problem querying for data in elasticsearch. Not fully investigated as of yet: The tutorial only queries an embedded elasticsearch. When I have time I can also try uploading through logstash data to an "installed" elasticsearch and then try querying. This might determine if there is a problem only with the embedded version of ES or if there is a larger problem Speculation: Without knowing whether elasticsearch is making external calls (after all, isn't it running as a jar?) I wonder if it's making calls to expected init services which have been re-written and deployed in systemd. Maybe tests in Fedora and/or earlier openSUSE could circumstantially provide clues. In any case this doesn't seem to affect <all> embedded modules because the web module <seems> to be working properly, although of course not seeing anything except 2 logs (are those data or logstash logs, will need to investigate) So,unknown if could be symptomatic of a more broad problem of a systemd system not supporting systemVinit calls. -- 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 3

[Bug 830571] New: Images in PDF not displayed at all
by bugzilla_noreply＠novell.com 12 Feb '14

12 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=830571 https://bugzilla.novell.com/show_bug.cgi?id=830571#c0 Summary: Images in PDF not displayed at all Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: binli(a)opensuse.org ReportedBy: holgi(a)suse.com QAContact: qa-bugs(a)suse.de CC: coolo(a)suse.com Found By: Component Test Blocker: --- Created an attachment (id=548860) --> (http://bugzilla.novell.com/attachment.cgi?id=548860) scan-example.pdf Using epdfview to display PDF documents I quite often see problems displaying PDF documents with embedded images. While they are displayed correctly if I use a very low scale to view it (e.a. 10-50%) they are not shown at all (just a one pixel hight line below the original place) if I use a higher scale (e.a. 100% or more). To me it looks like PDF pages containing an image for the whole page (e.a. scanned documents like the attached "scan-example.pdf") are quite often showing this problem while small embedded images (like company logs etc.) are displayed correctly in most cases. Please also see attached screenshots) Since epdfview is using poppler to render the PDF documents I assigned the bug report to the maintainer Please tell me if I can help you with any further information. -- 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 12

[Bug 852678] New: Not booting when it's a RAID0
by bugzilla_noreply＠novell.com 12 Feb '14

12 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=852678 https://bugzilla.novell.com/show_bug.cgi?id=852678#c0 Summary: Not booting when it's a RAID0 Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Critical Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jorgeh(a)fsbcomputers.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 Hey guys, I just tried to upgrade/install OpenSUSE 13.1 on a machine that previously had 12.3 working just fine, it did install, but when it restarted to configure the new installation, it never did, instead it went to GRUB rescue stating there was no such device (RAID0), at first I thought it was related to the RAID0, but after trying rebuilding the RAID0 I keep getting the same. I ended up re-installing 12.3 to it and it works just fine, so there must be something weird happening with GRUB and RAID discs. Thanks Reproducible: Always Steps to Reproduce: 1. Configure RAID0 on a computer 2. Install OpenSUSE 13.1 3. Actual Results: When it restarts to configure OpenSUSE, it never does. Expected Results: Continue installation. -- 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 15

[Bug 863065] New: build failure of ndiswrapper rpm on 32-bit PC
by bugzilla_noreply＠novell.com 12 Feb '14

12 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=863065 https://bugzilla.novell.com/show_bug.cgi?id=863065#c0 Summary: build failure of ndiswrapper rpm on 32-bit PC Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: i686 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: comes(a)naic.edu QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 I try to build on my PC the ndiswrapper rpm. I unpack the src.rpm and run: build ndiswrapper.spec On 64-bit the build process completes without error. On 32-bit (or on 64-bit using the command: linux32 build ndiswrapper.spec) it fails with the error message: [ 3s] expansion error [ 3s] nothing provides kernel-desktop-devel needed by kernel-syms [ 3s] nothing provides kernel-pae-devel needed by kernel-syms [ 3s] nothing provides kernel-xen-devel needed by kernel-syms I was able to go further in the build process using the command line: build --arch i686 ndiswrapper.spec but the build process fails anyway: [ 7s] now finalizing build dir... [ 8s] ----------------------------------------------------------------- [ 8s] ----- building ndiswrapper.spec (user abuild) [ 8s] ----------------------------------------------------------------- [ 8s] ----------------------------------------------------------------- [ 8s] + exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --nosignature /home/abuild/rpmbuild/SOURCES/ndiswrapper.spec [ 8s] warning: Macro %flavors_to_build needs whitespace before body [ 8s] error: line 39: Unknown tag: %internal_kmp_error Reproducible: Always Steps to Reproduce: 1.build ndiswrapper rpm on 32-bit 2. 3. Actual Results: build fails Expected Results: build is successful -- 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 1

[Bug 862581] New: networkmanager,ipv6,privoxy does not start
by bugzilla_noreply＠novell.com 12 Feb '14

12 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=862581 https://bugzilla.novell.com/show_bug.cgi?id=862581#c0 Summary: networkmanager,ipv6,privoxy does not start Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: epistemepromeneur(a)free.fr QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=577463) --> (http://bugzilla.novell.com/attachment.cgi?id=577463) errror messages when trying to start privoxy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 opensuse 13.1 x86_64 , kde 4.12.2 , networkmanager 0.9.8 , privoxy 3.0.21 privoxy is a proxy if ipv6 is managed by yast network manager then privoxy service starts and i can use without any pb if ipv6 is managed by networkmanager (method "automatic") then privoxy service does not starts see the screenshot see the answer of networkmanager team https://bugzilla.gnome.org/show_bug.cgi?id=723756#c2 it seems it is a bad integration by opensuse Reproducible: Always Steps to Reproduce: 1. 2. 3. -- 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 863444] New: Firefox opening takes ages, when checking on terminal give an error message about glibc
by bugzilla_noreply＠novell.com 12 Feb '14

12 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=863444 https://bugzilla.novell.com/show_bug.cgi?id=863444#c0 Summary: Firefox opening takes ages, when checking on terminal give an error message about glibc Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Critical Priority: P5 - None Component: Firefox AssignedTo: bnc-team-mozilla(a)forge.provo.novell.com ReportedBy: stakanov(a)freenet.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 When I try to open Firefox 27.0 it takes ages. When I checked in terminal it throws and error message (long before finally opening): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed Firefox seems to have problems also to open links in the selection window of this site (click right with open in new tab works but direct clicks no). Reproducible: Always Steps to Reproduce: 1.open firefox 2.wait an eternity 3.opens but problems with links Actual Results: takes ages to open give an error message: GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed when opened in terminal system load is high. Temperature is rising. Shutdown due to overheat and heat throttle occurs since the problems manifests. There seems to go on something with dns resolution too. Pages load with difficulty. Using the tor browser bundle pages load well and browser opens fast. No problems with anything. Expected Results: Firefox should be reliable and do what a browser does. Open fast and work. Theme: varies through the account. All the account have the same problem. -- 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 0

[Bug 861731] New: nm-connection-editor and GNOME system status out of sync
by bugzilla_noreply＠novell.com 12 Feb '14

12 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=861731 https://bugzilla.novell.com/show_bug.cgi?id=861731#c0 Summary: nm-connection-editor and GNOME system status out of sync Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: gp(a)suse.com QAContact: qa-bugs(a)suse.de CC: fcrozat(a)suse.com Found By: Product Management Blocker: --- nm-connection-editor and the GNOME system status (upper right corner) interact in interesting ways. 1. It seems new connections added via nm-connection-editor show up in system status right away. 2. When I rename such a new connection, that is NOT synced. 3. When I delete that connection, that seems to be synced. 4. However, when I restart the network (service network restart), then out of a sudden the renamed and later removed connection appears in system status -- for the very first time. And, yes, I verified it did not show up in nm-connection-editor. -- 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 1

[Bug 861145] New: Collectd Feature Request - Configure $PATH automatically
by bugzilla_noreply＠novell.com 12 Feb '14

12 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=861145 https://bugzilla.novell.com/show_bug.cgi?id=861145#c0 Summary: Collectd Feature Request - Configure $PATH automatically Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: All OS/Version: openSUSE 13.1 Status: NEW Severity: Enhancement Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: tonysu(a)su-networking.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; Touch) Original request to collectd https://github.com/collectd/collectd/issues/527 IMO all the reasons for declining setting the collectd path in that request do not apply to openSUSE at all. As noted, existing code already reads the relevant paths to the collectd binary (required) and the collectd config files (optional), so it's likely that creating a file /etc/profile.d/collectd which contains the command to add the collectd path should be easy. AFAIK there is no reason for any future collectd package to install to a non-default location, so it's possible to simply hardcode "export PATH=$PATH:/opt/collectd/sbin:/opt/collectd/etc" but of course that risks breaking the PATH if for some reason the binary location should change. As unlikely as it would be that the binary location might change, an easy decision would be to just hardcode the path, otherwise the code could be inspected for the variable that is already used holding the PATH and just use that. Reproducible: Always Steps to Reproduce: 1. Install collectd package 2. export PATH=$PATH:/opt/collectd/sbin:/opt/collectd/etc Actual Results: Without setting the $PATH, the User has to find (eg locate) the binary to execute Alternatively, although it might not be obvious, a systemd Unit has been created which works. Expected Results: After collectd package installation, there should be some clue what was installed, now to invoke. This is a minor feature request. There is a more serious problem I will submit in a separate bug that makes collectd unconfigurable on openSUSE -- 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 1

[Bug 863418] New: osc results -w won't quit if publishing is disabled.
by bugzilla_noreply＠novell.com 12 Feb '14

12 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=863418 https://bugzilla.novell.com/show_bug.cgi?id=863418#c0 Summary: osc results -w won't quit if publishing is disabled. Classification: Internal Novell Products Product: openSUSE Build Service Version: 2.4 Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: osc AssignedTo: adrian(a)suse.com ReportedBy: joseph(a)mulloy.me QAContact: adrian(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36 I'm not sure if this is intended behavior or not, but when using the "osc results -w" command it won't actually quit until all packages have either failed or are published. If you have publishing disabled it will never return. This makes it impossible to use in a script to wait for a build to finish. Of course if you're script is waiting for the RPM to be published you would want it to behave as it does now. In my case, however I don't, I just want to wait until the builds are done. The best solution would be another option to specify whether you want to wait for build completion or publish completion. Reproducible: Always Steps to Reproduce: 1. Run "osc results -w" on a package where publishing is disabled on at least one OS/Architeture Actual Results: osc command never quits, even when all builds have finished Expected Results: osc quits once all the builds have completed This is the code causing the issue. If the packages are unpublished the waiting variable is set to true and the loop is never broken. /usr/lib/python2.7/site-packages/osc/core.py lines 5049-5054 elif res['code'] in ('succeeded') and res['repostate'] != "published": waiting = True if verbose: res['status'] += '(unpublished)' else: res['status'] += '*' -- 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 0

[Bug 863380] New: No energy in Battery Monitor
by bugzilla_noreply＠novell.com 11 Feb '14

11 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=863380 https://bugzilla.novell.com/show_bug.cgi?id=863380#c0 Summary: No energy in Battery Monitor Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Workspace AssignedTo: kde-maintainers(a)suse.de ReportedBy: smartinds(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=578147) --> (http://bugzilla.novell.com/attachment.cgi?id=578147) Hardware Info User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 When tha laptop is off (for some hours), if you turn on and write your password quickly (in KDM), in KDE the "Battery Monitor" is zero. So, if you reboot the laptop, the "Battery Monitor" is OK. Reproducible: Always Steps to Reproduce: 1. Turn on the laptop 2. Write your password quickly in KDM Actual Results: In KDE, the "Battery Monitor" is Zero Expected Results: In KDE, the "Battery Monitor" is OK. (100% or 98%, etc) SONY VAIO Fit-15 Kernel: Linux 3.11.10-7-desktop S.O: openSUSE 13.1 (Bottle) (x86_64) KDE: 4.11.5 -- 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 0