January 2015 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 911589] New: argyllcms-1.6.3: calibration is way too slow to be usable
by bugzilla_noreply＠novell.com 03 Jan '15

03 Jan '15

http://bugzilla.opensuse.org/show_bug.cgi?id=911589 Bug ID: 911589 Summary: argyllcms-1.6.3: calibration is way too slow to be usable Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: All OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: Ulrich.Windl(a)rz.uni-regensburg.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I have a Datacolor Spyder 3 USB color sensor suitable for monitor color calibration. When trying to calibrate my LCD monitor from the GNOME's "color" control center, it suggests that an average calibration takes 30 minutes, so I tried a low-quality calibration that takes 15 minutes... Before I continue, let me remark that I also use Datacolor's calibration software that runs under Windows, and that software needs less that 15 minutes for a full recalibration. What it does it a brightness and whitepoint calibration first, then calibration read, green, and blue (ramp from black to full power), then a gray ramp. Finally it applies calibration and re-checks the result for plausibility. Back to openSUSE, I found that the low quality calibration starts playing with the white-point (it seems) and the prgress bar advances for a few pixels, then no visible change could be found (neither color, nor progress bar) for minutes. That's where I cancelled the process! Considering that you should re-calibrate your monitor whenever the lighting conditions change, or after every few weeks, the amount of time needed for calibration is unacceptable (especially when considering the fact that in MS-Windows you can do the same thing much quicker). The obvious deficits are: 1) The calibration takes too long. I can only suspect that the software tries to average the measurement from the sensor over a very long interval; if a sensor is so noisy that it seeds much more than 10 seconds per measurement, it's better no to support such a sensor rather than having to let users wait for minutes for some progress. 2) There is no user-visible feedback during calibration. There could be some timer counting down, or a textual description of what is going on. (I would have liked to report the problem upstream, but they lack a reasonable bug tracker) Inspecting syslog, the application or parts of it may have crashed silently, because I found: org.freedesktop.ColorHelper[2046]: steps were set as [ 3, 97, -1 ] but should have been: [ 5, 95, -1 ] at cd-main.c:475 org.freedesktop.ColorHelper[2046]: *** Error in `/usr/lib/colord-session': double free or corruption (out): 0x00007fbbd0dfc420 *** org.freedesktop.ColorHelper[2046]: ======= Backtrace: ========= org.freedesktop.ColorHelper[2046]: /lib64/libc.so.6(+0x730bf)[0x7fbbcdbf80bf] org.freedesktop.ColorHelper[2046]: /lib64/libc.so.6(+0x7892e)[0x7fbbcdbfd92e] org.freedesktop.ColorHelper[2046]: /lib64/libc.so.6(+0x79636)[0x7fbbcdbfe636] org.freedesktop.ColorHelper[2046]: /usr/lib64/libglib-2.0.so.0(g_string_free+0x3a)[0x7fbbce4b5cea] org.freedesktop.ColorHelper[2046]: /usr/lib/colord-session(cd_state_done_real+0x309)[0x7fbbcf5f3859] org.freedesktop.ColorHelper[2046]: /usr/lib/colord-session(+0x7918)[0x7fbbcf5f4918] org.freedesktop.ColorHelper[2046]: /usr/lib/colord-session(+0x82e6)[0x7fbbcf5f52e6] org.freedesktop.ColorHelper[2046]: /usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x135)[0x7fbbce4968e5] org.freedesktop.ColorHelper[2046]: /usr/lib64/libglib-2.0.so.0(+0x4bc48)[0x7fbbce496c48] org.freedesktop.ColorHelper[2046]: /usr/lib64/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7fbbce496f0a] org.freedesktop.ColorHelper[2046]: /usr/lib/colord-session(main+0x23e)[0x7fbbcf5f23de] org.freedesktop.ColorHelper[2046]: /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fbbcdba6b05] org.freedesktop.ColorHelper[2046]: /usr/lib/colord-session(+0x559f)[0x7fbbcf5f259f] -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 910232] New: buggy SIM pin request
by bugzilla_noreply＠novell.com 03 Jan '15

03 Jan '15

http://bugzilla.opensuse.org/show_bug.cgi?id=910232 Bug ID: 910232 Summary: buggy SIM pin request Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Workspace Assignee: kde-maintainers(a)suse.de Reporter: sledz(a)zone42.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 617359 --> http://bugzilla.opensuse.org/attachment.cgi?id=617359&action=edit SIM pin request (screenshot) After distro update from openSUSE 13.1 to 13.2 i've a very annoying behaviour at my Dell LATITUDE E4300 notebook. After login to KDE4 desktop a window pops up requesting the SIM pin for the integrated modem (see screenshot simpin1.png). I've found no place to store this pin persistently. :( But this is the first part of the problem only. In about 50% of the cases I get error messages after entering the SIM pin like "Error unlocking modem: PolicyKit authorization failed: challenge needed for 'org.freedesktop.ModemManager1.Device.Control'" or "Error unlocking modem: PolicyKit authorization error: 'authority not found'" -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 911578] New: Touchpad Left button not worked at all (Lenovo laptops)
by bugzilla_noreply＠novell.com 03 Jan '15

03 Jan '15

http://bugzilla.opensuse.org/show_bug.cgi?id=911578 Bug ID: 911578 Summary: Touchpad Left button not worked at all (Lenovo laptops) Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: 64bit OS: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: berserq0123(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello, Synaptics Touchpad Left button doesnt work on lenovo z5070, b5070, b4070 and maybe in other *70 lenovo laptops Looks like a 3.16 kernel bug. this bug in Ubuntu https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381815 this bug in debian https://lists.debian.org/debian-kernel/2014/11/msg00021.html With 3.17(in Fedora Live) left button works fine attachment for my z5070 xinput list http://pastebin.com/JqMyPMMk cat /proc/bus/input/devices http://pastebin.com/SJRqqFe7 cat /etc/X11/xorg.conf.d/50-synaptics.conf http://pastebin.com/GTFB1wGj -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 911524] New: IPython notebook from community repository does not start - missing Jinja2 dependency
by bugzilla_noreply＠novell.com 03 Jan '15

03 Jan '15

http://bugzilla.opensuse.org/show_bug.cgi?id=911524 Bug ID: 911524 Summary: IPython notebook from community repository does not start - missing Jinja2 dependency Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: don.raboud(a)ualberta.ca QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After installing IPython from the community repository (devel:languages:python) the notebook interface does not start. After installaing Jinja2 from that repository the notebook interface starts as expected, so this seems to be a missing dependency. IPython 2.3.0-74.27 python-Jinja2 2.7.3-62.1 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 908736] wicked breaks usage of Predictable Network Interface Names with kernel-xen+xen
by bugzilla_noreply＠novell.com 03 Jan '15

03 Jan '15

http://bugzilla.opensuse.org/show_bug.cgi?id=908736 Per Jessen <per(a)computer.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |per(a)computer.org -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 911580] New: plymouth-branding-openSUSE (indirectly) calls mkinitrd in %post
by bugzilla_noreply＠novell.com 03 Jan '15

03 Jan '15

http://bugzilla.novell.com/show_bug.cgi?id=911580 Bug ID: 911580 Summary: plymouth-branding-openSUSE (indirectly) calls mkinitrd in %post Classification: openSUSE Product: openSUSE Factory Version: 201412* Hardware: Other OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: RBrownCCB(a)opensuse.org Reporter: suse-beta(a)cboltz.de QA Contact: qa-bugs(a)suse.de Found By: Beta-Customer Blocker: --- plymouth-branding-openSUSE (indirectly) calls mkinitrd in %post: ( 15/353) Installing: plymouth-branding-openSUSE-13.2-10.23 ..........................................................[finished] Additional rpm output: Creating initrd: /boot/initrd-3.17.1-1.g5c4d099-desktop Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force --force-drivers "processor thermal ahci ata_piix ata_generic piix ide_pci_generic fan jbd ext3 md raid1 edd" /boot/initrd-3.17.1-1.g5c4d099-desktop 3.17.1-1.g5c4d099-desktop # rpm -q --scripts plymouth-branding-openSUSE postinstall scriptlet (using /bin/sh): [...] if [ ! -e /.buildenv ]; then /usr/sbin/plymouth-set-default-theme -R openSUSE [...] "-R" means rebuilding the initrd. Please do a separate mkinitrd call in %posttrans to avoid that mkinitrd runs multiple times. (You can probably steal the %post and %posttrans script from the kernel-firmware package ;-) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 880858] bcache symbolic links in /dev/bcache/by-uuid are unstable
by bugzilla_noreply＠novell.com 03 Jan '15

03 Jan '15

http://bugzilla.opensuse.org/show_bug.cgi?id=880858 --- Comment #1 from Olav Reinert <seroton10(a)gmail.com> --- Rewritten final paragraph of "Expected Results": This bug becomes a real problem if multiple bcaches are in use, because it becomes impossible to define stable fstab entries for mounting bcached devices. The /dev/bcache[0-9] device names can't be used because they are assigned arbitrarily. Instead, the symlinks in /dev/bcache/by-uuid/ should be used, but that doesn't work either due to this bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 897855] scanning (at least via skanlite) no longer works
by bugzilla_noreply＠novell.com 03 Jan '15

03 Jan '15

http://bugzilla.opensuse.org/show_bug.cgi?id=897855 Bernhard Wiedemann <bwiedemann(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bnc-team-screening(a)forge.pr |jsmeix(a)suse.com |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 911497] New: Downloads from download.opensuse.org and mirrors open to man-in-the-middle attacks
by bugzilla_noreply＠novell.com 03 Jan '15

03 Jan '15

http://bugzilla.opensuse.org/show_bug.cgi?id=911497 Bug ID: 911497 Summary: Downloads from download.opensuse.org and mirrors open to man-in-the-middle attacks Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: All OS: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: cschroedl(a)usgs.gov QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 Build Identifier: The checksums for the iso downloads of openSUSE 13.2 are not available over https. Checksums should be delivered over https in order to ensure the authenticity of the the download. Currently when a user attempts to download a file from download.opensuse.org, any man in the middle can serve a maliciously constructed iso with whatever software they want, and also serve a valid checksum of their malicious file. Without serving openSUSE checksums over https, users have no guarantee that they are installing secure software. Currently, the 13.2 download page (https://software.opensuse.org/132/en) only provides links to the checksums over http: http://download.opensuse.org/distribution/13.2/iso/openSUSE-13.2-DVD-x86_64… http://download.opensuse.org/distribution/13.2/iso/openSUSE-13.2-DVD-x86_64… http://download.opensuse.org/distribution/13.2/iso/openSUSE-13.2-DVD-x86_64… Switching the protocol on the links from http to https yields timeout errors. In fact, it does not seem possible to access anything via https on download.opensuse.org, or on the mirrors. I discovered this vulnerability in the context of openSUSE 13.2, but it is probable that the problem is more widespread. To enable secure retrieval of openSUSE software, it must be possible (and perhaps mandatory) for checksums to be retrieved via https. It is not necessary to deliver the actual large download files over https as long as the checksums are delivered securely. Reproducible: Always Steps to Reproduce: 1.For example, access: https://download.opensuse.org/distribution/13.2/iso/openSUSE-13.2-DVD-x86_6… Actual Results: The connection times out Expected Results: Securely download the checksum This is a problem throughout the software industry. A brief survey of the problem is here: http://www.elvey.com/insecure/ -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 889754] please provide https - support for all buildservice repositories at download.opensuse.org
by bugzilla_noreply＠novell.com 03 Jan '15

03 Jan '15

http://bugzilla.opensuse.org/show_bug.cgi?id=889754 Bernhard Wiedemann <bwiedemann(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cschroedl(a)usgs.gov --- Comment #7 from Bernhard Wiedemann <bwiedemann(a)suse.com> --- *** Bug 911497 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0