[Touch-packages] [Bug 1759950] Re: Lid-close suspend: blank screen when switching to user session

2020-08-22 Thread Elliot
This issue does not seem to occur when compiling XFCE Settings Mnaager
without UPower as per my findings here:
https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/222

** Bug watch added: gitlab.xfce.org/xfce/xfce4-settings/-/issues #222
   https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/222

-- 
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/1759950

Title:
  Lid-close suspend: blank screen when switching to user session

Status in Light-Locker:
  New
Status in Xfce4 Power Manager:
  Confirmed
Status in light-locker package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Confirmed
Status in xfce4-power-manager package in Ubuntu:
  Confirmed
Status in xfce4-settings package in Ubuntu:
  Confirmed
Status in xubuntu-default-settings package in Ubuntu:
  Confirmed

Bug description:
  I'm currently testing Xubuntu 18.04 after a do-release-upgrade from
  16.04.

  I discovered a very weird issue. When doing S3 sleep via closing the
  lid, on resume the lock screen appears, I authenticate, but as soon as
  it switches to the user session the screen goes blank - not even a
  backlight.

  Switching to other ttys works and they display correctly but the GUI
  user session remains blank.

  If the system is manually suspended (not using the lid), then resumed
  either by opening the lid or pressing the power button, the GUI user
  session is fine.

  I narrowed it down to xfce4-power-manager and discovered disabling the
  lock-screen cured the issue.

  I cloned the repository and reviewed commits between 1.7 and 1.8.
  Fortunately there aren't many. Looking at 6365683 "Proper exit status
  for light-locker-command" I suspected the change in the SetActive
  return value, and reverted it.

  After a build/install cycle I've found the system now behaves
  correctly so I think the change should be reverted.

  I've created an issue upstream for this at

  https://github.com/the-cavalry/light-locker/issues/108

To manage notifications about this bug go to:
https://bugs.launchpad.net/light-locker/+bug/1759950/+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 1858336] [NEW] Login loops with GNOME Boxes on Xorg

2020-01-05 Thread Elliot
Public bug reported:

After doing a normal installation with erasing the disk in GNOME Boxes,
I cannot log into the Ubuntu Xorg session. Wayland works fine, but this
still isn't a workaround if the user wants to use Xorg for any given
reason.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xorg 1:7.7+19ubuntu12
ProcVersionSignature: Ubuntu 5.3.0-24.26-generic 5.3.10
Uname: Linux 5.3.0-24-generic x86_64
ApportVersion: 2.20.11-0ubuntu15
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Sun Jan  5 10:21:36 2020
DistUpgraded: Fresh install
DistroCodename: focal
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 04) (prog-if 00 
[VGA controller])
   Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
InstallationDate: Installed on 2020-01-05 (0 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200104)
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 002 Device 002: ID 08e6:4433 Gemalto (was Gemplus) GemPC433-Swap
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Lsusb-t:
 /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
 /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
 /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
 |__ Port 1: Dev 2, If 0, Class=Chip/SmartCard, Driver=, 12M
 /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-24-generic 
root=UUID=3faaad6a-d32e-4d07-877f-3ef17831e142 ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/01/2014
dmi.bios.vendor: SeaBIOS
dmi.bios.version: ?-20191223_100556-anatol
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-q35-4.2
dmi.modalias: 
dmi:bvnSeaBIOS:bvr?-20191223_100556-anatol:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2:
dmi.product.name: Standard PC (Q35 + ICH9, 2009)
dmi.product.version: pc-q35-4.2
dmi.sys.vendor: QEMU
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.100-4
version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.4-1ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20190815-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

** Affects: xorg (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug focal regression reproducible ubuntu wayland-session

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1858336

Title:
  Login loops with GNOME Boxes on Xorg

Status in xorg package in Ubuntu:
  New

Bug description:
  After doing a normal installation with erasing the disk in GNOME
  Boxes, I cannot log into the Ubuntu Xorg session. Wayland works fine,
  but this still isn't a workaround if the user wants to use Xorg for
  any given reason.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.3.0-24.26-generic 5.3.10
  Uname: Linux 5.3.0-24-generic x86_64
  ApportVersion: 2.20.11-0ubuntu15
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Jan  5 10:21:36 2020
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 04) (prog-if 00 
[VGA controller])
 Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
  InstallationDate: Installed on 2020-01-05 (0 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200104)
  Lsusb:
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 002 Device 002: ID 08e6:4433 Gemalto (was Gemplus) GemPC433-Swap
   Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  Lsusb-t:
   /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
   /:  Bus 03.Port 1: Dev 

[Touch-packages] [Bug 1853709] Re: lightdm does not greet or present login prompt when resuming from laptop suspend

2019-12-19 Thread Elliot
Happens with the Dell XPS 9570 (Intel-Nvidia) as well on a fresh
install.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1853709

Title:
  lightdm does not greet or present login prompt when resuming from
  laptop suspend

Status in lightdm package in Ubuntu:
  Confirmed

Bug description:
  Expected result: when opening laptop lid the lock screen presents
  itself so I can unlock my session

  Actual result: the contents of my desktop are visible (windows, etc)
  and I can move my mouse cursor around but I cannot interact with the
  desktop session at all. Hovering over UI elements or clicking them has
  no effect.

  In order to get the login prompt I have to ctrl+alt+f1, login at the
  console, and run sudo systemctl restart lightdm, then I can login
  normally and resume whatever I was doing from before I closed the
  laptop lid.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: lightdm 1.30.0-0ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
  Uname: Linux 5.3.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Sat Nov 23 09:08:32 2019
  InstallationDate: Installed on 2019-11-09 (14 days ago)
  InstallationMedia: Xubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: lightdm
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1853709/+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 1854588] Re: Clicking 'Install' on gdebi-gtk makes it vanish ONLY when .deb opened from Chrome/Firefox

2019-12-01 Thread Elliot
No issue on Ubuntu MATE 19.10! This was tested with Firefox 70.0.1 and
the Minecraft deb package.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdebi in Ubuntu.
https://bugs.launchpad.net/bugs/1854588

Title:
  Clicking 'Install' on gdebi-gtk makes it vanish ONLY when .deb opened
  from Chrome/Firefox

Status in Ubuntu MATE:
  New
Status in gdebi package in Ubuntu:
  New

Bug description:
  Before anyone says this bug already exists... it doesn't (at least as
  far as I can see).  It's just that a lot of similar bugs do/did exist
  where people have also experienced the same symptoms (of gdebi-gtk
  vanishing upon clicking 'Install').

  So yes this is the same symptoms, but it must be a different cause as
  the circumstances are different and doesn't have the same resolution.

  The meat of it...

  Basically on a fresh install of Ubuntu MATE 18.04.3 amd64... with Firefox (or 
with Chrome if you installed that) go to any site that offers a .deb package 
and either...
  a) choose to open it directly from the browser (rather than saving it to 
'Downloads' folder)
  b) or... save the file (e.g. to the 'Downloads' folder), BUT!.. open that 
file from within the browser itself.

  You should find that gdebi-gtk appears but vanishes the moment you
  click 'Install' without a prompt for a password, an explanation or the
  package actually getting installed.

  This bug has existed since the beginning of Ubuntu 18.04 however it's
  been largely confused with other similar bugs.  I've had it on half a
  dozen machines and confirmed it exists with IRC users on #ubuntu-mate
  of freenode.

  However with *this* bug (compared to others) gdebi-gtk works perfectly
  fine if you run it from the terminal or just double click the .deb
  package from your file manager.

  It's the kind of bug which if you're a hardened desktop Linux user,
  you'd just work around it...

  But if you're a novice and you can't get a simple thing like
  Teamviewer installed (which is a .deb, and a thing I might ask someone
  to do over the phone to try to help them) you likely get fed up and
  re-install Windows :S

  Any input on this would be brilliant as I can't seem to get any
  logs/output.

  ~lantizia

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-mate/+bug/1854588/+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 1405232] Re: ping reports wrong IP responding under certain conditions

2016-02-15 Thread Elliot Dronebarger
Can confirm - I tested in 15.10 and this bug no longer exists in the
current iputils package, but this should be backported to 14.04 IMHO

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iputils in Ubuntu.
https://bugs.launchpad.net/bugs/1405232

Title:
  ping reports wrong IP responding under certain conditions

Status in iputils package in Ubuntu:
  Confirmed

Bug description:
  Description:  Ubuntu 14.04.1 LTS
  Release:  14.04
  iputils-ping:
  Installed: 3:20121221-4ubuntu1.1
  Candidate: 3:20121221-4ubuntu1.1

  ping will report the incorrect reply IP address under certain,
  specific conditions, and is repeatable. This is how to re-create the
  issue:

  1. Start pinging an IP where you get an ICMP error message from some
  other device (RFC792 lists errors). For instance: Destination IP is
  offline and the last-hop router reports message type "Destination
  Unreachable". I assume this would work for any ICMP error, though.

  2. When the device comes back online, ping reports replies from the
  "other" device, when it should report replies from the device that is
  sending the "Echo Reply" messages.

  3. If the ping is stopped and restarted after the device is up, it
  reports the correct IP address again. Other ping utilities do not
  exhibit this behavior.

  Example output (Destination that was pinged was 172.21.56.50, last hop router 
was 172.21.25.103):
  circle@circle:~$ /bin/ping 172.21.56.50
  PING 172.21.56.50 (172.21.56.50) 56(84) bytes of data.
  From 172.21.25.103 icmp_seq=1 Destination Host Unreachable
  From 172.21.25.103 icmp_seq=2 Destination Host Unreachable
  From 172.21.25.103 icmp_seq=3 Destination Host Unreachable
  From 172.21.25.103 icmp_seq=4 Destination Host Unreachable
  From 172.21.25.103 icmp_seq=5 Destination Host Unreachable
  From 172.21.25.103 icmp_seq=6 Destination Host Unreachable
  64 bytes from 172.21.25.103: icmp_seq=7 ttl=63 time=0.689 ms
  64 bytes from 172.21.25.103: icmp_seq=8 ttl=63 time=0.635 ms
  64 bytes from 172.21.25.103: icmp_seq=9 ttl=63 time=0.656 ms
  64 bytes from 172.21.25.103: icmp_seq=10 ttl=63 time=0.822 ms
  64 bytes from 172.21.25.103: icmp_seq=11 ttl=63 time=0.785 ms
  ^C
  --- 172.21.56.50 ping statistics ---
  11 packets transmitted, 5 received, +6 errors, 54% packet loss, time 10023ms
  rtt min/avg/max/mdev = 0.635/0.717/0.822/0.077 ms, pipe 3
  circle@circle:~$ /bin/ping 172.21.56.50
  PING 172.21.56.50 (172.21.56.50) 56(84) bytes of data.
  64 bytes from 172.21.56.50: icmp_seq=1 ttl=63 time=0.737 ms
  64 bytes from 172.21.56.50: icmp_seq=2 ttl=63 time=0.646 ms
  64 bytes from 172.21.56.50: icmp_seq=3 ttl=63 time=0.626 ms
  ^C
  --- 172.21.56.50 ping statistics ---
  3 packets transmitted, 3 received, 0% packet loss, time 1998ms
  rtt min/avg/max/mdev = 0.626/0.669/0.737/0.056 ms

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: iputils-ping 3:20121221-4ubuntu1.1
  ProcVersionSignature: Ubuntu 3.13.0-43.72-generic 3.13.11.11
  Uname: Linux 3.13.0-43-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.6
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Tue Dec 23 10:50:35 2014
  InstallationDate: Installed on 2014-10-08 (76 days ago)
  InstallationMedia: Xubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140723)
  SourcePackage: iputils
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1405232/+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 1405232] [NEW] ping reports wrong IP responding under certain conditions

2014-12-23 Thread Elliot Dronebarger
Public bug reported:

Description:Ubuntu 14.04.1 LTS
Release:14.04
iputils-ping:
Installed: 3:20121221-4ubuntu1.1
Candidate: 3:20121221-4ubuntu1.1

ping will report the incorrect reply IP address under certain, specific
conditions, and is repeatable. This is how to re-create the issue:

1. Start pinging an IP where you get an ICMP error message from some
other device (RFC792 lists errors). For instance: Destination IP is
offline and the last-hop router reports message type Destination
Unreachable. I assume this would work for any ICMP error, though.

2. When the device comes back online, ping reports replies from the
other device, when it should report replies from the device that is
sending the Echo Reply messages.

3. If the ping is stopped and restarted after the device is up, it
reports the correct IP address again. Other ping utilities do not
exhibit this behavior.

Example output (Destination that was pinged was 172.21.56.50, last hop router 
was 172.21.25.103):
circle@circle:~$ /bin/ping 172.21.56.50
PING 172.21.56.50 (172.21.56.50) 56(84) bytes of data.
From 172.21.25.103 icmp_seq=1 Destination Host Unreachable
From 172.21.25.103 icmp_seq=2 Destination Host Unreachable
From 172.21.25.103 icmp_seq=3 Destination Host Unreachable
From 172.21.25.103 icmp_seq=4 Destination Host Unreachable
From 172.21.25.103 icmp_seq=5 Destination Host Unreachable
From 172.21.25.103 icmp_seq=6 Destination Host Unreachable
64 bytes from 172.21.25.103: icmp_seq=7 ttl=63 time=0.689 ms
64 bytes from 172.21.25.103: icmp_seq=8 ttl=63 time=0.635 ms
64 bytes from 172.21.25.103: icmp_seq=9 ttl=63 time=0.656 ms
64 bytes from 172.21.25.103: icmp_seq=10 ttl=63 time=0.822 ms
64 bytes from 172.21.25.103: icmp_seq=11 ttl=63 time=0.785 ms
^C
--- 172.21.56.50 ping statistics ---
11 packets transmitted, 5 received, +6 errors, 54% packet loss, time 10023ms
rtt min/avg/max/mdev = 0.635/0.717/0.822/0.077 ms, pipe 3
circle@circle:~$ /bin/ping 172.21.56.50
PING 172.21.56.50 (172.21.56.50) 56(84) bytes of data.
64 bytes from 172.21.56.50: icmp_seq=1 ttl=63 time=0.737 ms
64 bytes from 172.21.56.50: icmp_seq=2 ttl=63 time=0.646 ms
64 bytes from 172.21.56.50: icmp_seq=3 ttl=63 time=0.626 ms
^C
--- 172.21.56.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.626/0.669/0.737/0.056 ms

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: iputils-ping 3:20121221-4ubuntu1.1
ProcVersionSignature: Ubuntu 3.13.0-43.72-generic 3.13.11.11
Uname: Linux 3.13.0-43-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.6
Architecture: amd64
CurrentDesktop: XFCE
Date: Tue Dec 23 10:50:35 2014
InstallationDate: Installed on 2014-10-08 (76 days ago)
InstallationMedia: Xubuntu 14.04.1 LTS Trusty Tahr - Release amd64 (20140723)
SourcePackage: iputils
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: iputils (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iputils in Ubuntu.
https://bugs.launchpad.net/bugs/1405232

Title:
  ping reports wrong IP responding under certain conditions

Status in iputils package in Ubuntu:
  New

Bug description:
  Description:  Ubuntu 14.04.1 LTS
  Release:  14.04
  iputils-ping:
  Installed: 3:20121221-4ubuntu1.1
  Candidate: 3:20121221-4ubuntu1.1

  ping will report the incorrect reply IP address under certain,
  specific conditions, and is repeatable. This is how to re-create the
  issue:

  1. Start pinging an IP where you get an ICMP error message from some
  other device (RFC792 lists errors). For instance: Destination IP is
  offline and the last-hop router reports message type Destination
  Unreachable. I assume this would work for any ICMP error, though.

  2. When the device comes back online, ping reports replies from the
  other device, when it should report replies from the device that is
  sending the Echo Reply messages.

  3. If the ping is stopped and restarted after the device is up, it
  reports the correct IP address again. Other ping utilities do not
  exhibit this behavior.

  Example output (Destination that was pinged was 172.21.56.50, last hop router 
was 172.21.25.103):
  circle@circle:~$ /bin/ping 172.21.56.50
  PING 172.21.56.50 (172.21.56.50) 56(84) bytes of data.
  From 172.21.25.103 icmp_seq=1 Destination Host Unreachable
  From 172.21.25.103 icmp_seq=2 Destination Host Unreachable
  From 172.21.25.103 icmp_seq=3 Destination Host Unreachable
  From 172.21.25.103 icmp_seq=4 Destination Host Unreachable
  From 172.21.25.103 icmp_seq=5 Destination Host Unreachable
  From 172.21.25.103 icmp_seq=6 Destination Host Unreachable
  64 bytes from 172.21.25.103: icmp_seq=7 ttl=63 time=0.689 ms
  64 bytes from 172.21.25.103: icmp_seq=8 ttl=63 time=0.635 ms
  64 bytes from 172.21.25.103: icmp_seq=9 ttl=63 time=0.656 ms
  64 bytes from 172.21.25.103: icmp_seq=10