[Desktop-packages] [Bug 1845801] Re: [nvidia] Automatic login fails and then all subsequent logins fail. Killing gnome-session-binary fixes it, or just not using automatic login.
The workaround for me was to disable vt_handoff in /etc/grub.d/10_linux* (i.e. set vt_handoff=0 in both places near the top of the file). That resolved the issue completely. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-session in Ubuntu. https://bugs.launchpad.net/bugs/1845801 Title: [nvidia] Automatic login fails and then all subsequent logins fail. Killing gnome-session-binary fixes it, or just not using automatic login. Status in OEM Priority Project: Triaged Status in gdm3 package in Ubuntu: Confirmed Status in gnome-session package in Ubuntu: Confirmed Status in grub2 package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-390 package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-430 package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-435 package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-440 package in Ubuntu: Confirmed Status in gdm3 source package in Eoan: Confirmed Status in gnome-session source package in Eoan: Confirmed Status in nvidia-graphics-drivers-435 source package in Eoan: Confirmed Bug description: [ Impact ] In some platforms with specific Nvidia cards, auto-login will fail due to the old vt-handoff patch in grub2. [ Test Case ] 1. Boot ubuntu into desktop environment. 2. Enabled auto login in System->Users 3. Reboot the system [Expected result] System will boot into desktop environment without the login page. [Actual result] System boots to login page, and can't login to desktop environment with the correct password. [ Regression potential ] Low, the patch just removes vt.handoff part in grub2 package, and I can't find any regression in several runs of stress tests. PPA: https://launchpad.net/~hugh712/+archive/ubuntu/sru-1845801 --- I just updated to the Ubuntu 19.10 beta. After boot, I'm shown the GDM login screen (which I shouldn't; I have auto login enabled), and logging in just takes me back to the same user selection screen even though the password is correct. If I switch to a TTY and run `sudo pkill gnome-session-binary`, logging in through GDM starts working again. I should add that the do-release-upgrade was rocky; I did it in a terminal from within gnome, went away for a while, and when I returned, I just saw an Ubuntu 19.10 in a TTY. I was able to do `sudo dpkg --configure -a` and complete the upgrade, but I don't know if something's still messed up due to that. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.3.0-13.14-generic 5.3.0 Uname: Linux 5.3.0-13-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 435.21 Sun Aug 25 08:17:57 CDT 2019 GCC version: gcc version 9.2.1 20190909 (Ubuntu 9.2.1-8ubuntu1) ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Sat Sep 28 19:55:42 2019 DistUpgraded: 2019-09-28 18:35:15,142 INFO cache.commit() DistroCodename: eoan DistroVariant: ubuntu DkmsStatus: nvidia, 435.21, 5.3.0-13-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GP102 [GeForce GTX 1080 Ti] [1043:85e4] InstallationDate: Installed on 2019-09-14 (13 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) MachineType: MSI MS-7A67 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-13-generic root=UUID=04974c80-e732-49b6-8148-c3dce7c02a25 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display Title: Xorg crash UpgradeStatus: Upgraded to eoan on 2019-09-28 (0 days ago) dmi.bios.date: 01/25/2018 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2.60 dmi.board.asset.tag: Default string dmi.board.name: H270I GAMING PRO AC (MS-7A67) dmi.board.vendor: MSI dmi.board.version: 1.0 dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: MSI dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2.60:bd01/25/2018:svnMSI:pnMS-7A67:pvr1.0:rvnMSI:rnH270IGAMINGPROAC(MS-7A67):rvr1.0:cvnMSI:ct3:cvr1.0: dmi.product.family: Default string dmi.product.name: MS-7A67 dmi.product.sku: Default string dmi.product.version: 1.0 dmi.sys.vendor: MSI version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.99-1ubuntu1
[Desktop-packages] [Bug 1133065] Re: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
This is still happening in Ubuntu 19.10, and I'm all but certain it will continue to happen with 20.04 when I upgrade to it. I'll verify next weekend when I finally have time for the upgrade. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in alsa-driver package in Ubuntu: Expired Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not "leak" out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 741869] Re: Unity/compiz intercepts Super and Alt keypresses from grabbed windows like VMs.
This bug needs to be fixed for those of us that don't use unity and only rely on gnome-shell. The problem seems to have been diagnosed to compiz, and thus the fix should be focused there so that it's not unnecessarily tied to unrelated packages (i.e. unity, as was the fix mentioned above). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/741869 Title: Unity/compiz intercepts Super and Alt keypresses from grabbed windows like VMs. Status in Ayatana Design: Fix Committed Status in Compiz: Triaged Status in Compiz Core: Triaged Status in OEM Priority Project: Won't Fix Status in OEM Priority Project precise series: Won't Fix Status in Unity: Fix Released Status in Unity 7.2 series: Fix Released Status in “compiz” package in Ubuntu: Triaged Status in “unity” package in Ubuntu: Fix Released Status in “compiz” source package in Trusty: Confirmed Status in “unity” source package in Trusty: Fix Released Bug description: [Impact] After upgrading from Maverick to Natty, I can no longer use the Super (windows) key in Virtual Machine Manager. Previously, as long as I had the Virtual Machine Manager console window in the foreground, I could press the Super key and the start menu would pop up. Since upgrading to Natty, this no longer works, and the search box appears in the upper left. Also see bug #934921 [Test Case] (1) Install virtualbox or virt-manager and qemu-system, create and boot a virtual machine (2) while in the virtual machine (and it should grab the keyboard), press the Super key Expected Result: the super key acts inside the VM (check by install unity on it or using xev) Buggy Result: the super key acts in the host and the Unity Dash is displayed [regression Potential]This patch plays with key grabs and ungrabs: the most likely potential for regression is (a) the existing grabs continue and no fix obtains or (2) the grab is not resumed when returning control from the VM and the Super key does not invoke the Unity Dash. To manage notifications about this bug go to: https://bugs.launchpad.net/ayatana-design/+bug/741869/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1155819] Re: Plugging in Logitech G930 USB headset breaks mouse click behaviour
The problem has been narrowed down to when the headset is actually charging - either through to the computer's USB ports or via a wall- socket charger (any micro-USB charger with 0.5A output will suffice). When the headset is unplugged (i.e. fully wireless), everything works fine. But when the headset is plugged in, the symptoms emerge. I will provide further information later today after I make some time to investigate more fully. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xserver-xorg-input-evdev in Ubuntu. https://bugs.launchpad.net/bugs/1155819 Title: Plugging in Logitech G930 USB headset breaks mouse click behaviour Status in “xserver-xorg-input-evdev” package in Ubuntu: Incomplete Bug description: lsb_release -rd: (Note: I get the same behaviour in kubuntu 12.04 and kubuntu 12.10) Description:Ubuntu Raring Ringtail (development branch) - running kubuntu 13.04 Release:13.04 To reproduce: 1) Plug in the USB dongle 2) Wait for the headset to connect As soon as the headset connects (e.g. after connecting the USB dongle) the application which currently has focus will be the only one which receives left mouse click events. This happens in both GNOME3 and KDE4. Alt+(Left,Right)Click + Drag stops moving/resizing windows. Left click does affect keyboard focus. Scrolling the volume wheel on the headset down acts like a middle click and scrolling up like a left click. Synergy also stops being able to move the mouse outside the current screen as soon as you click inside the host screen. The window decorations (including the window which has focus) stop recieving mouse events. (Expected behaviour is unaffected mouse behaviour and headset volume wheel functionality) It is possible to move a window around by doing: 1) Connect the headset with the window active 2) Left click and drag outside of that window 3) The window will be moved as if you were Alt+Left click dragging from inside the window. 4) A second left click will move mouse focus to the window below but will not move that window above the one which previously had focus This person seems to have had a possibly related issue: http://forums.gentoo.org/viewtopic-t-926996-start-0.html dmesg output from unplugging/replugging USB dongle: [ 6848.345037] usb 1-1.1: USB disconnect, device number 25 [ 6851.865274] usb 1-1.1: new full-speed USB device number 26 using ehci-pci [ 6852.580624] usb 1-1.1: New USB device found, idVendor=046d, idProduct=0a1f [ 6852.580629] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6852.580632] usb 1-1.1: Product: Logitech G930 Headset [ 6852.580634] usb 1-1.1: Manufacturer: Logitech [ 6852.589251] input: Logitech Logitech G930 Headset as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.3/input/input101 [ 6852.589453] hid-generic 0003:046D:0A1F.0055: input,hiddev0,hidraw3: USB HID v1.01 Device [Logitech Logitech G930 Headset] on usb-:00:1a.0-1.1/input3 Mouse click behaviour breaks as soon as the headset reconnects. Workaround: Running: modprobe -r usbhid; modprobe usbhid; temporarily fixes mouse click behaviour (but not the volume wheel clicking). The mouse click problem comes back when moving an audio stream to the headset via kmix. dmesg output from reloading usbhid kernel module: [ 6915.812979] usbcore: deregistering interface driver usbhid [ 6915.888438] input: Microsoft Wired Keyboard 600 as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input103 [ 6915.888671] hid-generic 0003:045E:0750.0057: input,hidraw0: USB HID v1.11 Keyboard [Microsoft Wired Keyboard 600] on usb-:00:1a.0-1.4/input0 [ 6915.894333] input: Microsoft Wired Keyboard 600 as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.1/input/input104 [ 6915.894576] hid-generic 0003:045E:0750.0058: input,hidraw1: USB HID v1.11 Device [Microsoft Wired Keyboard 600] on usb-:00:1a.0-1.4/input1 [ 6915.897121] input: USB OPTICAL MOUSE as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input105 [ 6915.897760] hid-generic 0003:093A:2521.0059: input,hidraw2: USB HID v1.11 Mouse [USB OPTICAL MOUSE] on usb-:00:1a.0-1.2/input0 [ 6915.900782] input: Logitech Logitech G930 Headset as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.3/input/input106 [ 6915.901949] hid-generic 0003:046D:0A1F.005A: input,hiddev0,hidraw3: USB HID v1.01 Device [Logitech Logitech G930 Headset] on usb-:00:1a.0-1.1/input3 [ 6915.902002] usbcore: registered new interface driver usbhid [ 6915.902005] usbhid: USB HID core driver Mouse click behaviour returns to normal immediately. Occasionally the headset will start working as expected (volume wheel affects system volume, mouse behaviour is normal) but unfortunately I have not been able to work out how to reproduce this. To manage notifications
[Desktop-packages] [Bug 1175122] Re: Doesn't work with Google 2-Factor Authentication
Still seeing this with gnome-online-accounts-3.8.3-2 on Saucy. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evolution-data-server in Ubuntu. https://bugs.launchpad.net/bugs/1175122 Title: Doesn't work with Google 2-Factor Authentication Status in Evolution Data Server: Fix Released Status in GNOME Online Accounts: Fix Released Status in “evolution-data-server” package in Ubuntu: Fix Released Status in “gnome-online-accounts” package in Ubuntu: Fix Released Status in “evolution-data-server” source package in Raring: Triaged Status in “gnome-online-accounts” source package in Raring: Triaged Status in “evolution-data-server” source package in Saucy: Fix Released Status in “gnome-online-accounts” source package in Saucy: Fix Released Bug description: [Impact] There is no obvious way for users of Google Two-Factor Authentication to add their Google account to GNOME Online Accounts. [Test Case] 1. From GNOME Shell, run System Settings and click Online Accounts (If there are two Online Accounts launchers, click the second one with an icon that looks like two halves of the globe are being plugged into each other). If running Unity, you can also run the GNOME version by running XDG_CURRENT_DESKTOP=GNOME gnome-control-center. 2. Add a Google Account. Use your regular password and then enter the Google Two-Factor Authentication Code verification code when prompted. What happens === The Google account is added but immediately there is a warning Expired credentials. Please log in again. [Regression Potential] Only Google accounts should be affected. The CalDav provider in Evolution Data Server has been ported to also work with OAuth v2. Workaround = 1. Open Password and Keys and type Google in the Filter box. 2. Double-click on the GOA google key. 3. In the Password field, click Show Password and replace only the password part with your application-specific password. See https://support.google.com/accounts/answer/185833 for instructions on generating an application-specific password. Original bug report === Since update to 13.04, using my Googlemail-Account via gnome-online-accounts leads to permant re-authenticating at google. Nearly immediatly after authenticating my Google-Account, gnome- online-accounts asks for re-authenticating. The Dialogs on google show security captchas along the passwort and 2-step-pin entry. Evolution is not able to sync calendar or any mails, even directly after authenticating at google. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: gnome-online-accounts 3.6.2-1ubuntu1 ProcVersionSignature: Ubuntu 3.8.0-19.29-generic 3.8.8 Uname: Linux 3.8.0-19-generic x86_64 ApportVersion: 2.9.2-0ubuntu8 Architecture: amd64 Date: Wed May 1 12:32:58 2013 EcryptfsInUse: Yes InstallationDate: Installed on 2013-04-28 (2 days ago) InstallationMedia: Ubuntu-GNOME 13.04 Raring Ringtail - Release amd64 (20130424) MarkForUpload: True ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: gnome-online-accounts UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/evolution-data-server/+bug/1175122/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1174648] Re: network settings, vpn modules don't load.
Nevermind my last comment. It appears that someone else had replaced the original packages with the ones from the gnome3-team/gnome3 ppa, and those did need the mentioned workaround. The VPN indicator also seems to have been fixed by rolling back the packages and the workaround. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-control-center in Ubuntu. https://bugs.launchpad.net/bugs/1174648 Title: network settings, vpn modules don't load. Status in “gnome-control-center” package in Ubuntu: Confirmed Bug description: gnome-control-center fails to find the Network-managers vpn modules. gnome-control-center is looking for the modules in /usr/lib/x86_64 -linux-gnu/NetworkManager/ However network manager + plugins packages install these modules too, /usr/lib/NetworkManager/. Which was changed due to Bug LP: #985788. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1174648/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1133065] Re: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
No effect for the default volume levels setting, the same behavior continues (tested repeatedly). No idea how to test the other thing you mention, since there's no mention of PCM Capture anywhere in those pulseaudio files. Can you offer up a concrete example of what you'd like me to add, and to which file? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in “alsa-driver” package in Ubuntu: New Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1133065] Re: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
The simplest definition of the bug is that after bootup, the actual state of the emu20k2 hardware is not accurately reflected in the software (alsamixer, alsactl store). The easiest observable effect (in my case) is the PCM Capture switch - it shows off even though it's functioning as if it were on. Other differences between hardware and software may be exist, but I've not detected them (nor have I searched). Toggling the switch on, then off, fixes the issue and syncs between hardware and software. However, using alsactl restore has no effect even if the configuration being restored contains the instructions to set the switch to off, and even if the force parameter is used (which is the default anyway). I wonder if alsactl compares the hardware state to the new state intended and avoids setting the switch value as an optimization... I'm testing your latest now, will report its effects. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in “alsa-driver” package in Ubuntu: New Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1133065] Re: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
Ok...your latest suggestion (pulseaudio analog-input.conf.common modifications) had no effect. The defect is still present. Let me know if you'd like me to test something else. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in “alsa-driver” package in Ubuntu: New Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1133065] Re: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
You lost me - what's the o'clock capture switch? How do I set it? What are the permissible values? It's not documented in the alsactl man page either. If you give me an example I'll be more than happy to test and relay the results. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in “alsa-driver” package in Ubuntu: New Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1133065] [NEW] Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
Public bug reported: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). ** Affects: alsa-driver (Ubuntu) Importance: Undecided Status: New ** Tags: kernel-sound ** Attachment added: Alsa stored state. Even using this state will not cause the EMU20K2 chip to turn off its PCM input automatically. https://bugs.launchpad.net/bugs/1133065/+attachment/3547006/+files/asound.state ** Project changed: launchpad = alsa-driver (Ubuntu) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in “alsa-driver” package in Ubuntu: New Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1133065] Re: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
There would be a simple workaround if any of the command-line utilities for alsa would allow me to change specific mixer settings. A script could easily be devised to simply turn PCM Input on, then off, and that would be that. Sadly, to my knowledge no such utility exists. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in “alsa-driver” package in Ubuntu: New Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1133065] Re: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
-- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in “alsa-driver” package in Ubuntu: New Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1133065] Re: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
-- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in “alsa-driver” package in Ubuntu: New Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1133065] Re: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
As expected, login-logout had no effect. Therefore, it's safe to assume the bug only manifests on a fresh boot. This reinforces the idea that it's either something changing the card's state behind ALSA'S back, or ALSA not properly restoring state to the card. The fact that alsactl restore fails to fix the problem but amixer cset works, seems to suggest that alsactl restore may be where the problem lies. Cheers. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in “alsa-driver” package in Ubuntu: New Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1133065] Re: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled
Yes, precisely. Take this sequence: Start up the machine Boot to Ubuntu Log in Open sound input settings (gnome-control-center sound, input tab) Play some music The input indicator moves with the music clearly denoting that the PCM capture is enabled. However, alsactl store produces an asound.state file in which the PCM switch is turned off. Opening up alsamixer also shows the item as off. Same with amixer cget. Using alsactl to restore a correct asound.state does NOT fix the problem, but if I turn the switch on, then off again (via alsamixer, or amixer, regardless), correct functioning is restored - PCM capture is disabled. However, if I reboot, the problem shows up again. I haven't tested logout-login after fixing the problem (i.e. if it causes the issue or not), but I don't think it does (will test that shortly). The workaround is now to have a script that runs at login, turning the switch on, then off, using amixer (new discovery on my part). However this is only applicable to my case in which I want PCM input to be turned off at the beginning. Other users might want it turned on and/or other input means (microphone, line-in) turned off instead. The issue here is that state isn't being properly restored to where it should - either something is altering the card's state post-alsa initialization and state restore, without alsa's knowledge, or alsa isn't restoring the state properly. Hope this info helps. I'll run the logout-login test shortly and relay the results. Cheers! Thanks for the quick reply! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1133065 Title: Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled Status in “alsa-driver” package in Ubuntu: New Bug description: Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not leak out. This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off. This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1133065/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 994864] Re: Choppy video with Totem in 12.04 Precise Pangolin
Yes, it still occurs with nVidia drivers at 295.49, even 295.53. Videos are also choppy in standalone totem. gst123 works fine, so it would appear that the problem is within totem itself and not the gstreamer libraries. mplayer-based players work fine (except mplayer2). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to totem in Ubuntu. https://bugs.launchpad.net/bugs/994864 Title: Choppy video with Totem in 12.04 Precise Pangolin Status in “totem” package in Ubuntu: Incomplete Bug description: When trying to play MP4 videos captured from my Galaxy Nexus and copied to the local hard drive, video playback in Totem is choppy. VLC has no problem. Videos used to work fine in Totem in Natty and Oneiric. It appears that Totem is maxing out the core upon which it's running (cpu usage just over 25%... between 26% and 28% on a quad-core system). My video setup is dual nVidia GeForce 580 GTX's in SLI (SLI is not active), with dual monitors, using nvidia's driver (NOT nouveau...separate story - it fails miserably and locks up every time). I'm not sure how to gather additional information to help debug the issue, but if you ask, I can definitely try to provide as much information as possible. I've attached a short example video that should suffice to illustrate the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/994864/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 994864] [NEW] Choppy video with Totem in 12.04 Precise Pangolin
Public bug reported: When trying to play MP4 videos captured from my Galaxy Nexus and copied to the local hard drive, video playback in Totem is choppy. VLC has no problem. Videos used to work fine in Totem in Natty and Oneiric. It appears that Totem is maxing out the core upon which it's running (cpu usage just over 25%... between 26% and 28% on a quad-core system). My video setup is dual nVidia GeForce 580 GTX's in SLI (SLI is not active), with dual monitors, using nvidia's driver (NOT nouveau...separate story - it fails miserably and locks up every time). I'm not sure how to gather additional information to help debug the issue, but if you ask, I can definitely try to provide as much information as possible. I've attached a short example video that should suffice to illustrate the issue. ** Affects: totem (Ubuntu) Importance: Undecided Status: New ** Tags: choppy totem video -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to totem in Ubuntu. https://bugs.launchpad.net/bugs/994864 Title: Choppy video with Totem in 12.04 Precise Pangolin Status in “totem” package in Ubuntu: New Bug description: When trying to play MP4 videos captured from my Galaxy Nexus and copied to the local hard drive, video playback in Totem is choppy. VLC has no problem. Videos used to work fine in Totem in Natty and Oneiric. It appears that Totem is maxing out the core upon which it's running (cpu usage just over 25%... between 26% and 28% on a quad-core system). My video setup is dual nVidia GeForce 580 GTX's in SLI (SLI is not active), with dual monitors, using nvidia's driver (NOT nouveau...separate story - it fails miserably and locks up every time). I'm not sure how to gather additional information to help debug the issue, but if you ask, I can definitely try to provide as much information as possible. I've attached a short example video that should suffice to illustrate the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/994864/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 994864] Re: Choppy video with Totem in 12.04 Precise Pangolin
** Attachment added: VID_20120429_171350.mp4 https://bugs.launchpad.net/bugs/994864/+attachment/3130829/+files/VID_20120429_171350.mp4 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to totem in Ubuntu. https://bugs.launchpad.net/bugs/994864 Title: Choppy video with Totem in 12.04 Precise Pangolin Status in “totem” package in Ubuntu: New Bug description: When trying to play MP4 videos captured from my Galaxy Nexus and copied to the local hard drive, video playback in Totem is choppy. VLC has no problem. Videos used to work fine in Totem in Natty and Oneiric. It appears that Totem is maxing out the core upon which it's running (cpu usage just over 25%... between 26% and 28% on a quad-core system). My video setup is dual nVidia GeForce 580 GTX's in SLI (SLI is not active), with dual monitors, using nvidia's driver (NOT nouveau...separate story - it fails miserably and locks up every time). I'm not sure how to gather additional information to help debug the issue, but if you ask, I can definitely try to provide as much information as possible. I've attached a short example video that should suffice to illustrate the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/994864/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 854344] Re: Gwibber 3.0.0.1 incorrectly storing timestamps in SQLite database
I get it - the problem is the message source (Twitter, in this particular case), not Gwibber. Fair enough. So is there an API from the actual service(s) to attempt to get the timezone configured for the account? What I'm thinking is that Gwibber *should* (ideally) store all timestamps relative to UTC if possible. This would make things consistent throughout. Then again, that depends on being able to get the message timestamps in UTC format from the source in the first place or, at least, have the information available to discern that value from the received information. Does this make sense? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gwibber in Ubuntu. https://bugs.launchpad.net/bugs/854344 Title: Gwibber 3.0.0.1 incorrectly storing timestamps in SQLite database Status in Gwibber: New Status in “gwibber” package in Ubuntu: New Bug description: While researching to build a script that would automatically purge messages older than X amount of time from the SQLite database, I found that the from the epoch timestamps being stored in messages.time aren't really from the epoch. As per all definitions, the epoch starts at 1/1/1970 00:00:00.000 GMT (the key point being GMT). Gwibber is storing the correct timestamp, but not taking the active timezone into account. That is to say, it's storing the epoch number into the database as if the local time were in GMT regardless of the truth. Assume a configured system timezone of CST. The current query returns the correct values for the message dates: select time, datetime(time, 'unixepoch') from messages order by time asc; However, clearly this is incorrect as the system is NOT in the GMT timezone. The timestamps stored should be relative GMT. This next query should be the correct one, in order to account for the timezone difference. However, the results are (predictibly) off by 6 hours (in the case of CST, which is the timezone delta): select time, datetime(time, 'unixepoch', 'localtime') from messages order by time asc; The 'localtime' argument instructs SQLite to take that timezone delta into account. (as per instructions from http://www.sqlite.org/lang_datefunc.html) The problem is that now, in order to create my purge script, I have to take into account the timezone that I'm running in, as opposed to simply saying delete the messages older than X hours. While this might appear to be a minor inconvenience, this defect makes it impossible to share the script as a black box solution for other users, since now the script would have to be configured for each user individually, to account for each of their own timezones. Not to mention to account for timezone shifts. To manage notifications about this bug go to: https://bugs.launchpad.net/gwibber/+bug/854344/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 854344] Re: Gwibber 3.0.0.1 incorrectly storing timestamps in SQLite database
To-whit, I found this: https://dev.twitter.com/docs/api/1/get/account/settings The JSON object contains timezone information which can be used to determine which timezone the account is configured to. Thus, it can be used to calculate the UTC time that the message came in under. That's Twitter down... Perhaps you guys know this quicker/better than I: do the other services supported by Gwibber also return the timestamp wrong? If so, then which of them don't provide the ability to determine which timezone the timestamp comes in? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gwibber in Ubuntu. https://bugs.launchpad.net/bugs/854344 Title: Gwibber 3.0.0.1 incorrectly storing timestamps in SQLite database Status in Gwibber: New Status in “gwibber” package in Ubuntu: New Bug description: While researching to build a script that would automatically purge messages older than X amount of time from the SQLite database, I found that the from the epoch timestamps being stored in messages.time aren't really from the epoch. As per all definitions, the epoch starts at 1/1/1970 00:00:00.000 GMT (the key point being GMT). Gwibber is storing the correct timestamp, but not taking the active timezone into account. That is to say, it's storing the epoch number into the database as if the local time were in GMT regardless of the truth. Assume a configured system timezone of CST. The current query returns the correct values for the message dates: select time, datetime(time, 'unixepoch') from messages order by time asc; However, clearly this is incorrect as the system is NOT in the GMT timezone. The timestamps stored should be relative GMT. This next query should be the correct one, in order to account for the timezone difference. However, the results are (predictibly) off by 6 hours (in the case of CST, which is the timezone delta): select time, datetime(time, 'unixepoch', 'localtime') from messages order by time asc; The 'localtime' argument instructs SQLite to take that timezone delta into account. (as per instructions from http://www.sqlite.org/lang_datefunc.html) The problem is that now, in order to create my purge script, I have to take into account the timezone that I'm running in, as opposed to simply saying delete the messages older than X hours. While this might appear to be a minor inconvenience, this defect makes it impossible to share the script as a black box solution for other users, since now the script would have to be configured for each user individually, to account for each of their own timezones. Not to mention to account for timezone shifts. To manage notifications about this bug go to: https://bugs.launchpad.net/gwibber/+bug/854344/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 854344] Re: Gwibber 3.0.0.1 incorrectly storing timestamps in SQLite database
Ditto for Facebook: http://developers.facebook.com/docs/reference/api/user/ I'm almost positive all the others contain this information as well. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gwibber in Ubuntu. https://bugs.launchpad.net/bugs/854344 Title: Gwibber 3.0.0.1 incorrectly storing timestamps in SQLite database Status in Gwibber: New Status in “gwibber” package in Ubuntu: New Bug description: While researching to build a script that would automatically purge messages older than X amount of time from the SQLite database, I found that the from the epoch timestamps being stored in messages.time aren't really from the epoch. As per all definitions, the epoch starts at 1/1/1970 00:00:00.000 GMT (the key point being GMT). Gwibber is storing the correct timestamp, but not taking the active timezone into account. That is to say, it's storing the epoch number into the database as if the local time were in GMT regardless of the truth. Assume a configured system timezone of CST. The current query returns the correct values for the message dates: select time, datetime(time, 'unixepoch') from messages order by time asc; However, clearly this is incorrect as the system is NOT in the GMT timezone. The timestamps stored should be relative GMT. This next query should be the correct one, in order to account for the timezone difference. However, the results are (predictibly) off by 6 hours (in the case of CST, which is the timezone delta): select time, datetime(time, 'unixepoch', 'localtime') from messages order by time asc; The 'localtime' argument instructs SQLite to take that timezone delta into account. (as per instructions from http://www.sqlite.org/lang_datefunc.html) The problem is that now, in order to create my purge script, I have to take into account the timezone that I'm running in, as opposed to simply saying delete the messages older than X hours. While this might appear to be a minor inconvenience, this defect makes it impossible to share the script as a black box solution for other users, since now the script would have to be configured for each user individually, to account for each of their own timezones. Not to mention to account for timezone shifts. To manage notifications about this bug go to: https://bugs.launchpad.net/gwibber/+bug/854344/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 854344] [NEW] Gwibber 3.0.0.1 incorrectly storing timestamps in SQLite database
Public bug reported: While researching to build a script that would automatically purge messages older than X amount of time from the SQLite database, I found that the from the epoch timestamps being stored in messages.time aren't really from the epoch. As per all definitions, the epoch starts at 1/1/1970 00:00:00.000 GMT (the key point being GMT). Gwibber is storing the correct timestamp, but not taking the active timezone into account. That is to say, it's storing the epoch number into the database as if the local time were in GMT regardless of the truth. Assume a configured system timezone of CST. The current query returns the correct values for the message dates: select time, datetime(time, 'unixepoch') from messages order by time asc; However, clearly this is incorrect as the system is NOT in the GMT timezone. The timestamps stored should be relative GMT. This next query should be the correct one, in order to account for the timezone difference. However, the results are (predictibly) off by 6 hours (in the case of CST, which is the timezone delta): select time, datetime(time, 'unixepoch', 'localtime') from messages order by time asc; The 'localtime' argument instructs SQLite to take that timezone delta into account. (as per instructions from http://www.sqlite.org/lang_datefunc.html) The problem is that now, in order to create my purge script, I have to take into account the timezone that I'm running in, as opposed to simply saying delete the messages older than X hours. While this might appear to be a minor inconvenience, this defect makes it impossible to share the script as a black box solution for other users, since now the script would have to be configured for each user individually, to account for each of their own timezones. Not to mention to account for timezone shifts. ** Affects: gwibber Importance: Undecided Status: New ** Affects: gwibber (Ubuntu) Importance: Undecided Status: New ** Also affects: gwibber (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gwibber in Ubuntu. https://bugs.launchpad.net/bugs/854344 Title: Gwibber 3.0.0.1 incorrectly storing timestamps in SQLite database Status in Gwibber: New Status in “gwibber” package in Ubuntu: New Bug description: While researching to build a script that would automatically purge messages older than X amount of time from the SQLite database, I found that the from the epoch timestamps being stored in messages.time aren't really from the epoch. As per all definitions, the epoch starts at 1/1/1970 00:00:00.000 GMT (the key point being GMT). Gwibber is storing the correct timestamp, but not taking the active timezone into account. That is to say, it's storing the epoch number into the database as if the local time were in GMT regardless of the truth. Assume a configured system timezone of CST. The current query returns the correct values for the message dates: select time, datetime(time, 'unixepoch') from messages order by time asc; However, clearly this is incorrect as the system is NOT in the GMT timezone. The timestamps stored should be relative GMT. This next query should be the correct one, in order to account for the timezone difference. However, the results are (predictibly) off by 6 hours (in the case of CST, which is the timezone delta): select time, datetime(time, 'unixepoch', 'localtime') from messages order by time asc; The 'localtime' argument instructs SQLite to take that timezone delta into account. (as per instructions from http://www.sqlite.org/lang_datefunc.html) The problem is that now, in order to create my purge script, I have to take into account the timezone that I'm running in, as opposed to simply saying delete the messages older than X hours. While this might appear to be a minor inconvenience, this defect makes it impossible to share the script as a black box solution for other users, since now the script would have to be configured for each user individually, to account for each of their own timezones. Not to mention to account for timezone shifts. To manage notifications about this bug go to: https://bugs.launchpad.net/gwibber/+bug/854344/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
