[Touch-packages] [Bug 1626651] Re: brightness keys are handled slower in Yakkety than Xenial
In contrast this is what is happening with Xenial, which works perfectly. evtest: Event: time 1475641421.193234, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1 Event: time 1475641421.193234, -- SYN_REPORT Event: time 1475641421.193306, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0 Event: time 1475641421.193306, -- SYN_REPORT udev monitoring in the attachment. ** Attachment added: "udev.xenial.txt" https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/+attachment/4754687/+files/udev.xenial.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/1626651 Title: brightness keys are handled slower in Yakkety than Xenial Status in policykit-1 package in Ubuntu: Triaged Status in unity-settings-daemon package in Ubuntu: Triaged Bug description: I've noticed on Lenovo X220 and X230 laptops that pressing brightness keys on Yakkety seems less responsive and slower than Xenial. I ran forkstat on Xenial and just observed udev being forked off: Xenial: $ sudo forkstat Time Event PID Info Duration Process 17:37:35 fork273 parent /lib/systemd/systemd-udevd 17:37:35 fork 1977 child /lib/systemd/systemd-udevd 17:37:35 exit 1977 00.008 /lib/systemd/systemd-udevd Whereas on Yakkety, there is far more activity: Time Event PID Info Duration Process 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2645 child update-notifier 16:35:34 exec 2645 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 exit 26452560.221 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2646 child update-notifier 16:35:34 exec 2646 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:34 exit 26462560.188 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2647 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2647 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2647 00.008 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2648 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2648 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2648 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2649 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2649 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2649 00.007 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2650 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2650 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2650 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2651 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2651 pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2652 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2653 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 fork 1 parent /sbin/init splash 16:35:36 fork 2654 child /sbin/init splash Time Event PID Info Duration Process 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2655 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2656 child
[Touch-packages] [Bug 1626651] Re: brightness keys are handled slower in Yakkety than Xenial
** Attachment added: "evdtest.txt" https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/+attachment/4754481/+files/evdtest.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/1626651 Title: brightness keys are handled slower in Yakkety than Xenial Status in policykit-1 package in Ubuntu: Triaged Status in unity-settings-daemon package in Ubuntu: Triaged Bug description: I've noticed on Lenovo X220 and X230 laptops that pressing brightness keys on Yakkety seems less responsive and slower than Xenial. I ran forkstat on Xenial and just observed udev being forked off: Xenial: $ sudo forkstat Time Event PID Info Duration Process 17:37:35 fork273 parent /lib/systemd/systemd-udevd 17:37:35 fork 1977 child /lib/systemd/systemd-udevd 17:37:35 exit 1977 00.008 /lib/systemd/systemd-udevd Whereas on Yakkety, there is far more activity: Time Event PID Info Duration Process 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2645 child update-notifier 16:35:34 exec 2645 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 exit 26452560.221 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2646 child update-notifier 16:35:34 exec 2646 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:34 exit 26462560.188 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2647 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2647 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2647 00.008 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2648 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2648 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2648 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2649 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2649 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2649 00.007 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2650 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2650 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2650 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2651 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2651 pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2652 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2653 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 fork 1 parent /sbin/init splash 16:35:36 fork 2654 child /sbin/init splash Time Event PID Info Duration Process 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2655 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2656 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2657 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2658 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2659 child /lib/systemd/systemd-udevd 16:35:36 exit 2659
[Touch-packages] [Bug 1626651] Re: brightness keys are handled slower in Yakkety than Xenial
I have similar problem on Dell XPS 15 (l521x). It is not quick and it seems that for every key-press it's trying to change brightness twice. I'll attach evtest and udev monitor outputs. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/1626651 Title: brightness keys are handled slower in Yakkety than Xenial Status in policykit-1 package in Ubuntu: Triaged Status in unity-settings-daemon package in Ubuntu: Triaged Bug description: I've noticed on Lenovo X220 and X230 laptops that pressing brightness keys on Yakkety seems less responsive and slower than Xenial. I ran forkstat on Xenial and just observed udev being forked off: Xenial: $ sudo forkstat Time Event PID Info Duration Process 17:37:35 fork273 parent /lib/systemd/systemd-udevd 17:37:35 fork 1977 child /lib/systemd/systemd-udevd 17:37:35 exit 1977 00.008 /lib/systemd/systemd-udevd Whereas on Yakkety, there is far more activity: Time Event PID Info Duration Process 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2645 child update-notifier 16:35:34 exec 2645 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 exit 26452560.221 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2646 child update-notifier 16:35:34 exec 2646 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:34 exit 26462560.188 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2647 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2647 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2647 00.008 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2648 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2648 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2648 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2649 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2649 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2649 00.007 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2650 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2650 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2650 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2651 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2651 pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2652 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2653 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 fork 1 parent /sbin/init splash 16:35:36 fork 2654 child /sbin/init splash Time Event PID Info Duration Process 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2655 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2656 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2657 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2658 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2659 child
[Touch-packages] [Bug 1626651] Re: brightness keys are handled slower in Yakkety than Xenial
** Attachment added: "udev.txt" https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/+attachment/4754480/+files/udev.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/1626651 Title: brightness keys are handled slower in Yakkety than Xenial Status in policykit-1 package in Ubuntu: Triaged Status in unity-settings-daemon package in Ubuntu: Triaged Bug description: I've noticed on Lenovo X220 and X230 laptops that pressing brightness keys on Yakkety seems less responsive and slower than Xenial. I ran forkstat on Xenial and just observed udev being forked off: Xenial: $ sudo forkstat Time Event PID Info Duration Process 17:37:35 fork273 parent /lib/systemd/systemd-udevd 17:37:35 fork 1977 child /lib/systemd/systemd-udevd 17:37:35 exit 1977 00.008 /lib/systemd/systemd-udevd Whereas on Yakkety, there is far more activity: Time Event PID Info Duration Process 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2645 child update-notifier 16:35:34 exec 2645 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 exit 26452560.221 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2646 child update-notifier 16:35:34 exec 2646 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:34 exit 26462560.188 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2647 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2647 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2647 00.008 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2648 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2648 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2648 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2649 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2649 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2649 00.007 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2650 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2650 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2650 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2651 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2651 pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2652 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2653 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 fork 1 parent /sbin/init splash 16:35:36 fork 2654 child /sbin/init splash Time Event PID Info Duration Process 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2655 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2656 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2657 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2658 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2659 child /lib/systemd/systemd-udevd 16:35:36 exit 2659 0
[Touch-packages] [Bug 1539513] Re: networkmanager segfaults with 3.2.21-1ubuntu1
Guys, this definately needs a fix, imagine single computer at home + ordinary user (not advanced users like us) = no way of fixing this at all. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnl3 in Ubuntu. https://bugs.launchpad.net/bugs/1539513 Title: networkmanager segfaults with 3.2.21-1ubuntu1 Status in libnl3 package in Ubuntu: Confirmed Bug description: Description:Ubuntu 14.04.3 LTS Release:14.04 After upgrading to 3.2.21-1ubuntu1 network-manager 0.9.8.8-0ubuntu7.2 segfaults: [ 21.367977] init: network-manager main process (1000) killed by SEGV signal [ 21.367989] init: network-manager main process ended, respawning [ 21.424932] init: network-manager main process (1060) killed by SEGV signal [ 21.424943] init: network-manager main process ended, respawning [ 21.451519] init: network-manager main process (1066) killed by SEGV signal [...] xxx@yyy:/tmp/bla# gdb /usr/sbin/NetworkManager CoreDump [...] Reading symbols from /usr/sbin/NetworkManager...(no debugging symbols found)...done. [New LWP 3550] [New LWP 3551] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `NetworkManager'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00469fee in nm_netlink_monitor_attach () To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1539513/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1448555] Re: network-manager does not autoconnect to wifi network after resume from suspend
I'm having kinda the same problem. After suspend at work and resume after one hour at home, NM applet won't show my home networks at all - so no auto connection, of course. If I do enable/disable wifi or try to connect to one of work wifi AP (which of course is not there but is still in the list in NM applet), then NM applet refreshes AP list and I'm able to connect. I have nothing suspicios in pm-suspend log though. It might be nm-applet issue maybe... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1448555 Title: network-manager does not autoconnect to wifi network after resume from suspend Status in network-manager package in Ubuntu: Confirmed Bug description: After upgrading to 15.04 network manager does not reconnect to the wifi network after resuming from a suspend to memory. Workaround: disable and re-enable wireless network - connects immediately ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu15 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 NonfreeKernelModules: nvidia wl ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Sat Apr 25 23:53:54 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2013-05-17 (708 days ago) InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release amd64+mac (20130424) IpRoute: default via 10.1.0.254 dev wlan0 proto static metric 1024 10.0.0.0/8 dev wlan0 proto kernel scope link src 10.1.0.103 169.254.0.0/16 dev wlan0 scope link metric 1000 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: Upgraded to vivid on 2015-04-25 (0 days ago) nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH wlan0 wifi connected /org/freedesktop/NetworkManager/Devices/1 rsb_hs d8793959-2da1-4dc6-85ad-2dcf9e36e64b /org/freedesktop/NetworkManager/ActiveConnection/1 EC:88:92:61:E9:5F btdisconnected /org/freedesktop/NetworkManager/Devices/2 -- -- -- lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/0 -- -- -- nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1448555/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1426851] Re: Power button shuts down computer if a Qt application is running
The same behavior on 14.04 and 15.04 - if QT app is open, all windows for it are closed, like Keepassx, skype, WPS office asks whether to save the contents of documents (this kinda seems like pressing Alt+F4). 14.10, which was troublesome to use for me so I don't use it, didn't have this problem. I'm running Dell, XPS 15 L521X model, can't verify on any other computer. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtbase-opensource-src in Ubuntu. https://bugs.launchpad.net/bugs/1426851 Title: Power button shuts down computer if a Qt application is running Status in qtbase-opensource-src package in Ubuntu: Confirmed Bug description: On Ubuntu 14.04, the usual behavior of the power button is bringing a dialog with options (Lock, Suspend, Restart, Shutdown) and waiting for the user's choice. When a Qt application is running, for instance Qt Creator or Texmaker, (but not VLC, Clementine or Skype) and the power button is pressed, it instantly closes that Qt app (http://qt- project.org/forums/viewthread/47632/), brings the shut down dialog and then shuts down the computer without waiting for the user’s choice. I first asked about this on this forum: http://qt-project.org/forums/viewthread/53243/#222409 and reported it at Qt Creator, thinking it was the only application causing it, where they told me to report it to Canonical: https://bugreports.qt.io/browse/QTCREATORBUG-14030 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1426851/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1451032] Re: keyscript option in crypttab ignored
I was just experimenting with this and about to create a bug, but someone already did, very good :) I set up some home brew logging and it seems passdev is never called, instead systemd is waiting for device which is specified as source for the key, second option in crypttab. When I boot up using upstart, then all is fine and device gets unlocked. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1451032 Title: keyscript option in crypttab ignored Status in systemd package in Ubuntu: Confirmed Status in systemd package in Debian: Confirmed Bug description: The setup for unlocking an encrypted volume during boot using (only) a keyfile (on a detachable USB drive) usually calls for a keyscript to be specified as one of the encrypted volume's options. But with systemd, such encrypted volumes can only be unlocked during boot by typing in a passphrase. Steps to reproduce: 1. Have a LUKS encrypted volume. 2. Have said volume specified in /etc/crypttab, with keyscript= option pointing to your script for outputting the unlocking key. 3. Boot. What I expect to happen: To have the volume unlocked by the script at boot time without manual intervention. What happens instead: Plymouth shows a prompt to enter a valid passphrase for the volume. Workarounds: Apparently the options for unlocking encrypted drives, including keyscript, can also be specified at the kernel command-line, without crypttab, and according to yaantc at Hacker News [1] this can be used to work around the issue. I haven't personally tried this. * [1] https://news.ycombinator.com/item?id=8477913 ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu4 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Sat May 2 15:39:07 2015 InstallationDate: Installed on 2014-10-18 (196 days ago) InstallationMedia: Ubuntu 14.10 Utopic Unicorn - Alpha amd64 (20140923) MachineType: ASUSTeK COMPUTER INC. UX32A ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic.efi.signed root=UUID=2185885c-b860-49a8-973f-fa3b52d3eecf ro quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: Upgraded to vivid on 2015-04-23 (8 days ago) dmi.bios.date: 01/29/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: UX32A.214 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: UX32A dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX32A.214:bd01/29/2013:svnASUSTeKCOMPUTERINC.:pnUX32A:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX32A:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.name: UX32A dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1451032/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1387558] Re: Compiz slows down over time (usually one day is enough)
Hi, recently I tried installing 14.10 on the same machine on different partition and it seems that problem with rotation + slowdown is gone. So as a next step was upgrading my trusty Trysty to Utopic. Right after upgrade (and before login) I deleted monitors.xml file from my working profile (user) and viola problem is gone. So gar so good, I would like to say. So the problem was related to monitors.xml or updates between my last try and this one, or both. Can't say whether slowdown is gone as I'm using the system for just about one day. Will report back with the results. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity in Ubuntu. https://bugs.launchpad.net/bugs/1387558 Title: Compiz slows down over time (usually one day is enough) Status in Compiz: Incomplete Status in Unity: Incomplete Status in unity package in Ubuntu: Incomplete Bug description: I have had this problem for quite a long time tbh. And after each release I hope it will be fixed, but it doesn't happen. A little intro: I'm using Ubuntu for work, I rarely shutdown the computer I rather put it to sleep mode, in worst case it's hibernate. I have loads of apps opened at the same time. I use external monitor as well. Computer is Dell XPS15 L521X, 16Gb RAM, 120GB SSD + 1TB HDD. As a graphics card I'm using builtin intel HD4000, I have GF GT640 as well but it's disabled using bbswitch. Symptoms are that after some time compiz slows down a lot while using it. Usually it's no more than 2 days and it's slow again. When I restart Unity (setsid unity) it's back to full buttersmooth speed with the same apps opened which leads to conclusion that compiz can handle the load very well. Maybe it's mesa, maybe it's compiz or unity itself that slows it down - but I'm no pro to tell. With 14.10 release I observed very interesting behaviour. I have FHD builtin monitor and FHD external monitor rotated counterclockwise. Let's say I started computer yesterday in the morning, it was working smooth with both monitors and single display, I suspended computer got home unsuspended and it seemed sluggish (only graphics part of course). I ran glxgears (I know I know...) and it showed ~ 50FPS which is slow, because running the same before suspend gives near 60FPS (refresh rate). Now I come back to work and run it on single builtin display - ~ 50 FPS, I connect second FHD dispplay and FPS are back to 60 and it's running buttersmooth again. So it seems that mesa/compiz/unity have some strange refresh rate problem detection maybe... 2 FHD displays seems to be twice the job compiz has to do over single display which is strangely slower... Please advise how can I help solving this, do I need to run compiz debug version or what can I exactly help technically (applying a patch, compiling compiz myself, you name it...). I know the standard procedure of logs etc., I'm afraid that won't help much in this situation. I looked at logs and there's nothing suspicious, at least to me. To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1387558/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
