[Touch-packages] [Bug 1833719] Re: UFW 2nd interface incorrectly working

[Launchpad Bug Tracker]

[Expired for ufw (Ubuntu) because there has been no activity for 60
days.]

** Changed in: ufw (Ubuntu)
   Status: Incomplete => Expired

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

Title:
  UFW 2nd interface incorrectly working

Status in ufw package in Ubuntu:
  Expired

Bug description:
  ufw --version  = ufw 0.36

  Server has two interfaces ens160 and ens192

  looking at the logs to understand why ufw is blocking requests from an
  interface, the log show the correct ip address and the incorrect
  interface.

  ip address 192.168.1.4 is on ens160 
  ip address 192.168.1.46 is on ens192 

  Correct
  when visiting address 192.168.1.4 i am blocked an logs correctly identify 
that i am using IN=ens160

  Incorrect 
  when visiting address 192.168.1.46 i am also blocked even though rule has 
been added "sudo ufw allow in on ens192 to any from 192.168.0.0/16" 

  Logs from /var/log/ufw.log show that DST=192.168.1.46 is blocked witn
  IN=ens160

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1833719/+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 1849666] Re: can not see hdmi

[Daniel van Vugt]

You have installed packages from the 'oibaf' PPA, which is unsupported
and frequently broken:

version.libdrm2: libdrm2 2.4.100+git1910210630.c69c9c~oibaf~b
version.libgl1-mesa-dri: libgl1-mesa-dri 19.3~git1910240730.196165~oibaf~b
version.libgl1-mesa-glx: libgl1-mesa-glx 19.3~git1910240730.196165~oibaf~b
version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 
1:19.1.0+git1910151930.b9bd80~oibaf~b
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git1910071930.bff5ec~oibaf~b
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.16+git1906080730.ec2b45~oibaf~b

Please uninstall the PPA from your machine and then open a new bug if
you still have trouble.

** Tags added: nvidia

** Package changed: xorg (Ubuntu) => ubuntu

** Changed in: ubuntu
   Status: New => Invalid

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

Title:
  can not see hdmi

Status in Ubuntu:
  Invalid

Bug description:
  i can not see hdmi, and i don't know why?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 5.0.0-32.34~18.04.2-generic 5.0.21
  Uname: Linux 5.0.0-32-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Oct 24 15:27:11 2019
  DistUpgraded: Fresh install
  DistroCodename: bionic
  DistroVariant: ubuntu
  DkmsStatus: nvidia, 430.50, 5.0.0-32-generic, x86_64: installed
  GraphicsCard:
   Intel Corporation Device [8086:3e9b] (prog-if 00 [VGA controller])
 Subsystem: Lenovo Device [17aa:39fe]
   NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1) 
(prog-if 00 [VGA controller])
 Subsystem: Lenovo GP107M [GeForce GTX 1050 Mobile] [17aa:39fe]
  InstallationDate: Installed on 2019-10-22 (2 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 04ca:7070 Lite-On Technology Corp. 
   Bus 001 Device 002: ID 145f:01e7 Trust 
   Bus 001 Device 004: ID 0bda:b023 Realtek Semiconductor Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: LENOVO 81FV
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic 
root=UUID=6747b4a8-5274-45de-a7f5-f774e2c086d9 ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/02/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 8JCN48WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0R33126 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo Legion Y530-15ICH
  dmi.modalias: 
dmi:bvnLENOVO:bvr8JCN48WW:bd11/02/2018:svnLENOVO:pn81FV:pvrLenovoLegionY530-15ICH:rvnLENOVO:rnLNVNB161216:rvrSDK0R33126WIN:cvnLENOVO:ct10:cvrLenovoLegionY530-15ICH:
  dmi.product.family: Legion Y530-15ICH
  dmi.product.name: 81FV
  dmi.product.sku: LENOVO_MT_81FV_BU_idea_FM_Legion Y530-15ICH
  dmi.product.version: Lenovo Legion Y530-15ICH
  dmi.sys.vendor: LENOVO
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.100+git1910210630.c69c9c~oibaf~b
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.3~git1910240730.196165~oibaf~b
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.3~git1910240730.196165~oibaf~b
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 
1:19.1.0+git1910151930.b9bd80~oibaf~b
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git1910071930.bff5ec~oibaf~b
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.16+git1906080730.ec2b45~oibaf~b

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1849666/+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 1849711] Re: Only GRUB2 have MAX BRIGHTNESS in 19.04 and 19.10

[Daniel van Vugt]

I think Ubuntu 19.10 is better at remembering your previous brightness
values and yes indeed that will change after grub2. So I don't think
this is a bug. Unless you're saying it's the wrong brightness value
being remembered?

See also (probably unrelated) bug 1848360

** Package changed: xorg (Ubuntu) => linux (Ubuntu)

** Changed in: linux (Ubuntu)
   Status: New => Incomplete

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

Title:
  Only GRUB2 have MAX BRIGHTNESS  in 19.04 and 19.10

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  whenever I boot into Ubuntu the grub 2 boot loader have maximum brightness 
but after selecting Ubuntu OS, system return to its normal brightness value , 
previously my Ubuntu version is 19.04 and this problem exists but after 
upgrading to 19.10 this issue still there and nothing works by upgrading 
system, grub remains at high brightness value (even function keys not working 
at that time). Every time i reboot the system the grub 2 have max brightness 
and it returns to normal brightness after reaching to log on screen and then 
everything works fine even functions keys also working.
  laptop specs:
  AMD reyzen 3 2200u
  AMD Radeon Vega 3
  HP g7 245

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.0.0-32.34-generic 5.0.21
  Uname: Linux 5.0.0-32-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Oct 24 21:52:44 2019
  DistUpgraded: Fresh install
  DistroCodename: eoan
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / 
Radeon Vega Mobile Series] [1002:15dd] (rev c5) (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Raven Ridge [Radeon Vega Series / 
Radeon Vega Mobile Series] [103c:8562]
  MachineType: Hewlett-Packard HP 245 G7 Notebook PC
  ProcEnviron:
   LANGUAGE=en_IN:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IN
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic 
root=UUID=380079ae-40a6-4aed-8280-2b263a41cf1e ro quiet splash 
acpi_backlight=vendor quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/03/2019
  dmi.bios.vendor: AMI
  dmi.bios.version: F.42
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: 8562
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: 84.24
  dmi.chassis.asset.tag: 5CG9212QLP
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnAMI:bvrF.42:bd07/03/2019:svnHewlett-Packard:pnHP245G7NotebookPC:pvr:rvnHewlett-Packard:rn8562:rvr84.24:cvnHewlett-Packard:ct10:cvrChassisVersion:
  dmi.product.family: 103C_5336AN HP 200
  dmi.product.name: HP 245 G7 Notebook PC
  dmi.product.sku: 6JM93PA#ACJ
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.99-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-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.0.1-1ubuntu1
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849711/+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 1849751] [NEW] vulkan support on intel broken after 19.10 upgrade

[Tessa]

Public bug reported:

after upgrading to ubuntu 19.10, vulkan support when using the intel
card in my laptop is broken. running any of my example vulkan apps shows
the following error:

$ vkcube
vkcube: 
/build/vulkan-tools-IZAxVX/vulkan-tools-1.1.114.0+dfsg1/cube/cube.c:3175: 
demo_init_vk: Assertion `!err' failed.
Aborted (core dumped)

note that since the update I can no longer boot my system at all without
adding "nomodeset" the kernel params, something is broken in the intel
modeset driver since 19.04. so this may very well be related.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: mesa-vulkan-drivers 19.2.1-1ubuntu1
ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
Uname: Linux 5.3.0-19-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu8
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Thu Oct 24 20:04:54 2019
DistUpgraded: 2019-10-23 18:54:04,373 DEBUG Running PostInstallScript: 
'./xorg_fix_proprietary.py'
DistroCodename: eoan
DistroVariant: ubuntu
DkmsStatus: zfs, 0.8.1, 5.3.0-19-generic, x86_64: installed
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation HD Graphics 630 [8086:591b] (rev 04) (prog-if 00 [VGA 
controller])
   Subsystem: CLEVO/KAPOK Computer HD Graphics 630 [1558:65a1]
 NVIDIA Corporation GP104BM [GeForce GTX 1070 Mobile] [10de:1be1] (rev a1) 
(prog-if 00 [VGA controller])
   Subsystem: CLEVO/KAPOK Computer GP104BM [GeForce GTX 1070 Mobile] [1558:65a3]
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 004: ID 04f2:b5a7 Chicony Electronics Co., Ltd Chicony USB 2.0 
Camera
 Bus 001 Device 003: ID 8087:0a2b Intel Corp. 
 Bus 001 Device 002: ID 1c7a:0603 LighTuning Technology Inc. EgisTec_ES603
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: System76 Oryx Pro
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-19-generic root=ZFS=rpool/root ro 
root=ZFS=rpool/root quiet nomodeset
SourcePackage: mesa
UpgradeStatus: Upgraded to eoan on 2019-10-23 (1 days ago)
dmi.bios.date: 02/20/2017
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.05.02dRSA2
dmi.board.asset.tag: Tag 12345
dmi.board.name: Oryx Pro
dmi.board.vendor: System76
dmi.board.version: oryp3-ess
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: System76
dmi.chassis.version: N/A
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.05.02dRSA2:bd02/20/2017:svnSystem76:pnOryxPro:pvroryp3-ess:rvnSystem76:rnOryxPro:rvroryp3-ess:cvnSystem76:ct10:cvrN/A:
dmi.product.family: Not Applicable
dmi.product.name: Oryx Pro
dmi.product.sku: Not Applicable
dmi.product.version: oryp3-ess
dmi.sys.vendor: System76
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.99-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.1-1ubuntu1
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.0.1-1ubuntu1
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: mesa (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug eoan ubuntu

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

Title:
  vulkan support on intel broken after 19.10 upgrade

Status in mesa package in Ubuntu:
  New

Bug description:
  after upgrading to ubuntu 19.10, vulkan support when using the intel
  card in my laptop is broken. running any of my example vulkan apps
  shows the following error:

  $ vkcube
  vkcube: 
/build/vulkan-tools-IZAxVX/vulkan-tools-1.1.114.0+dfsg1/cube/cube.c:3175: 
demo_init_vk: Assertion `!err' failed.
  Aborted (core dumped)

  note that since the update I can no longer boot my system at all
  without adding "nomodeset" the kernel params, something is broken in
  the intel modeset driver since 19.04. so this may very well be
  related.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: mesa-vulkan-drivers 19.2.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Oct 24 20:04:54 2019
  DistUpgraded: 2019-10-23 18:54:04,373 DEBUG Running PostInstallScript: 
'./xorg_fix_proprietary.py'
  DistroCodename: eoan
  DistroVariant: ubuntu
  DkmsStatus: zfs, 0.8.1, 5.3.0-19-generic, x86_64: installed
  

[Touch-packages] [Bug 1739948] Re: Missing French-Belgian keyboard layout

[Gunnar Hjalmarsson]

Hmm.. This conversation seems to be about a confusion about the Settings
GUI, not an IBus bug, and since the problem seems to be resolved, I
closed it.

As regards documentation of extra layouts, it's there on this page:

https://help.ubuntu.com/stable/ubuntu-help/keyboard-layouts.html

** Package changed: ibus (Ubuntu) => gnome-control-center (Ubuntu)

** Changed in: gnome-control-center (Ubuntu)
   Status: New => Invalid

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

Title:
  Missing French-Belgian keyboard layout

Status in gnome-control-center package in Ubuntu:
  Invalid

Bug description:
  Description:  Ubuntu 17.10
  Release:  17.10

  ibus:
Installed: 1.5.14-2ubuntu1
Candidate: 1.5.14-2ubuntu1
Version table:
   *** 1.5.14-2ubuntu1 500
  500 http://be.archive.ubuntu.com/ubuntu artful/main amd64 Packages
  100 /var/lib/dpkg/status

  After my update on 17.10 I couldn't get a french Belgian keyboard in the 
input sources.
  During install time I have tried to find my keyboard layout by using the 
"Type this key process" without success.
  I have also tried all the French keyboard but none of them allow me to type 
"@" or "-"... sut to mention main missing keys.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1739948/+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 1849714] Re: failure to install repos for raspberry pi

[Kenneth Zadeck]

I still get the failure.From the prompt in your run, it looks like
you are running the arm64 version, i am running the armhf version.
That seems unlikely to be significant difference, but there are at least
some major differences since the arm64 cannot use the usb ports on the
pi 4b with 4GB and that is what I have.

i do have outside connectivity.

shire:~(20) ping www.ubuntu.com
PING www.ubuntu.com (91.189.89.115) 56(84) bytes of data.
64 bytes from www-ubuntu-com.privet.canonical.com (91.189.89.115): icmp_seq=1 
ttl=56 time=85.1 ms
64 bytes from www-ubuntu-com.privet.canonical.com (91.189.89.115): icmp_seq=2 
ttl=56 time=78.5 ms
64 bytes from www-ubuntu-com.privet.canonical.com (91.189.89.115): icmp_seq=3 
ttl=56 time=79.2 ms
^C

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

Title:
  failure to install repos for raspberry pi

Status in software-properties package in Ubuntu:
  Incomplete

Bug description:
  following the directions about 1/5 down the page of
  https://wiki.ubuntu.com/ARM/RaspberryPi

  sudo add-apt-repository ppa:ubuntu-raspi2/ppa
  Cannot add PPA: 'ppa:~ubuntu-raspi2/ubuntu/ppa'.
  ERROR: '~ubuntu-raspi2' user or team does not exist.

  This seems like a failure to me.

  shire:~(13) lsb_release -rd
  Description:  Ubuntu 19.10
  Release:  19.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1849714/+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 1487534] Re: Unable to set Alt+Shift for switching keyboard layout

[Gunnar Hjalmarsson]

Which desktop environment are you using?

** Changed in: ibus (Ubuntu)
   Status: New => Incomplete

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

Title:
  Unable to set Alt+Shift for switching keyboard layout

Status in Ubuntu Studio:
  Won't Fix
Status in ibus package in Ubuntu:
  Incomplete

Bug description:
  I used to Alt+Shift combination for switching keyboard layouts. but I
  can't find where to do this. Right clicking on language indicator and
  choosing Preferences open IBus configuration window. But when I set
  Alt+Shift, it just hangs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntustudio/+bug/1487534/+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 1449250] Re: Keyboard Layout "Portuguese (Brazil, nativo for US keyboards)" doesn't respect US keyboard layout.

[Gunnar Hjalmarsson]

This is not an IBus issue - changing affected package.

With that said, it's easy to set it up to meet your expectations:

* Pick the English (US) layout

* Go to Settings -> Region & Language and change either Language (i.e.
the display language) or Formats to a Portuguese option. That will bring
you '+c => ç.

With that said, this is an upstream issue, and it would be great if some
affected users could work together with the upstream maintainer to make
more sense of the Portuguese (Brazil) keyboard layout options. An
upstream issue can be filed here:

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues

This is the file which seems to need some love:

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-
config/blob/master/symbols/br

** Package changed: ibus (Ubuntu) => xkeyboard-config (Ubuntu)

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

Title:
  Keyboard Layout "Portuguese (Brazil, nativo for US keyboards)" doesn't
  respect US keyboard layout.

Status in xkeyboard-config package in Ubuntu:
  Confirmed

Bug description:
  When setting up the keyboard layout to my bluetooth keyboard on my machine I 
saw the option to add a layout specific to Portuguese with the promise it would 
work with USA keyboards.
  But many letters are assigned to the wrong codes.

  1. I'm using Ubuntu 14.04
  2. I don't know the package responsible for this behaviour
  3. I expected a behaviour similar to English USA International layout, but 
with cedilla when you press ' + C instead of the "ć" it currently generates.

  Pressing all characters keys on a USA keyboard should give the following 
result(with spaces between them and enter after each row of keys):
  ` 1 2 3 4 5 6 7 8 9 0 - =
  q w e r t y u i o p [ ] \
  a s d f g h j k l ; '
  z x c v b n m , . /

  4. While using "Portuguese (Brazil, nativo for USA keyboards)" layout it gives
  = 1 2 3 4 5 6 7 8 9 0 [ ]
  / , . h x w l t c p ~ - '
  i e a o u m d s r n '
  y ; j b k q v g f z

  If you look at the keyboard layout chart, you'll see it has nothing to
  do with USA keyboards and specially nothing like to what is sold here
  in Brazil.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1449250/+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 1540587] Re: No UK keyboard support

[Gunnar Hjalmarsson]

*** This bug is a duplicate of bug 1835541 ***
https://bugs.launchpad.net/bugs/1835541

Thanks for your report!

This issue is upstream in nature, and it would be great if you could
submit an upstream issue:

https://github.com/ibus/ibus/issues/

There is another bug about the same topic, so I marked this bug as a
duplicate of the other one. Please submit possible follow-up comment on
the other bug.

** This bug has been marked a duplicate of bug 1835541
   ibus only provides non-standard UK keyboard layouts

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

Title:
  No UK keyboard support

Status in ibus package in Ubuntu:
  Confirmed

Bug description:
  UK keyboard is NOT available as an input method in uBuntu 14.04 LTS
  ibus (1.5.5-1ubuntu3) input method selection.

  Please can someone fix this omission by adding the appropriate info to
  /usr/share/ibus/component/simple.xml as having the system incorrectly
  default to a US keyboard is a real pain - you can't put anything in
  quotes or pipe output from one command into another. It makes a UK
  keyboard system unusable.

  My simple solution is to add the 'gb' keyboard as follows:


xkb:gb::eng
eng
GPL
gb
English (UK)
English (UK)
  ibus-keyboard
99


  A better solution would be to process files in
  /usr/share/X11/xkb/symbols and add ALL available xkb keyboards to
  simple.xml as a post installation operation. Doing this would help
  people see the advantages of ibus instead of fighting it to try and
  get a usable system.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1540587/+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 1835541] Re: ibus only provides non-standard UK keyboard layouts

[Gunnar Hjalmarsson]

ibus-setup only makes a selection of XKB layouts available, and the
basic UK layout is not one of those.

The XKB layouts available are hard coded in the file
/usr/share/ibus/component/simple.xml, and a workaround would be to edit
that file and simply add the layout you are missing.

This issue is upstream in nature, and it would be great if you could
submit an upstream issue:

https://github.com/ibus/ibus/issues/

I don't know which criteria they used for the selection, and such an
upstream issue would be a way to shed some light on the thoughts behind
that file.

I recently saw a Debian bug about this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942245

** Bug watch added: Debian Bug tracker #942245
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942245

** Changed in: ibus (Ubuntu)
   Status: New => Confirmed

** Also affects: ibus (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942245
   Importance: Unknown
   Status: Unknown

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

Title:
  ibus only provides non-standard UK keyboard layouts

Status in ibus package in Ubuntu:
  Confirmed
Status in ibus package in Debian:
  Unknown

Bug description:
  When I attempt to add my standard UK keyboard to the layouts ibus
  knows about, I cannot do so.

  (See the attached image for the list of available layouts.)

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: ibus 1.5.19-4ubuntu1
  ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8
  Uname: Linux 5.0.0-20-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu3
  Architecture: amd64
  CurrentDesktop: i3
  Date: Fri Jul  5 10:07:41 2019
  InstallationDate: Installed on 2019-05-07 (58 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  SourcePackage: ibus
  UpgradeStatus: Upgraded to eoan on 2019-05-08 (57 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1835541/+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 1849714] Re: failure to install repos for raspberry pi

[Brian Murray]

Was this perhaps a temporary issue? I'm not able to recreate this right
now.

bdmurray@clean-eoan-amd64:~$ sudo add-apt-repository ppa:ubuntu-raspi2/ppa
[sudo] password for bdmurray: 
 https://wiki.ubuntu.com/ARM/RaspberryPi

Optional PPA for Raspberry Pi 2/3 installations.
 More info: https://launchpad.net/~ubuntu-raspi2/+archive/ubuntu/ppa
Press [ENTER] to continue or Ctrl-c to cancel adding it.
^C


** Package changed: ubuntu => software-properties (Ubuntu)

** Changed in: software-properties (Ubuntu)
   Status: New => Incomplete

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

Title:
  failure to install repos for raspberry pi

Status in software-properties package in Ubuntu:
  Incomplete

Bug description:
  following the directions about 1/5 down the page of
  https://wiki.ubuntu.com/ARM/RaspberryPi

  sudo add-apt-repository ppa:ubuntu-raspi2/ppa
  Cannot add PPA: 'ppa:~ubuntu-raspi2/ubuntu/ppa'.
  ERROR: '~ubuntu-raspi2' user or team does not exist.

  This seems like a failure to me.

  shire:~(13) lsb_release -rd
  Description:  Ubuntu 19.10
  Release:  19.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1849714/+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 1849714] [NEW] failure to install repos for raspberry pi

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

following the directions about 1/5 down the page of
https://wiki.ubuntu.com/ARM/RaspberryPi

sudo add-apt-repository ppa:ubuntu-raspi2/ppa
Cannot add PPA: 'ppa:~ubuntu-raspi2/ubuntu/ppa'.
ERROR: '~ubuntu-raspi2' user or team does not exist.

This seems like a failure to me.

shire:~(13) lsb_release -rd
Description:Ubuntu 19.10
Release:19.10

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: Incomplete


** Tags: 4b 4gb armhf bot-comment eoan pi raspberry
-- 
failure to install repos for raspberry pi
https://bugs.launchpad.net/bugs/1849714
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to software-properties in Ubuntu.

-- 
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 1191895] Re: networking eventually brought down due to inactivity

[Tom Reynolds]

Is this something which could be supported by now?

gnome-control-center -> power seems to offer a setting to manage wi-fi
power saving but in the end this is just a wi-fi on/off switch which
immediately brings the device down/up (bug 1751954).

Looking through the details of an existing NM wireless configuration profile 
there are no related (power saving) features exposed on the GUI. "nmcli 
connection show $UUID" lists a 
   802-11-wireless.powersave (default: 0)
setting.

https://developer.gnome.org/NetworkManager/stable/settings-802-11-wireless.html

Is this what brings the interface down after some ~ 10 minutes of user
input inactivity / ~ 5 minutes of blank screen? If so, could this be
exposed on the GUI?

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

Title:
  networking eventually brought down due to inactivity

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  For various reasons, I like to be able to ssh in to my nexus 4. I have
  noticed with current saucy (and raring before it), after some time of
  inactivity the screen goes blank (fine), but then occasionally after
  some more time after that, networking is brought down (wifi) if there
  is no network activity. If I continuously ping the device, networking
  stays up. If I keep the screen from blanking, networking stays up. The
  current behavior is different than the behavior on android, where I
  can get various notifications for facebook, email, etc when the screen
  is blank.

  HARDWARE=mako
  JENKINS_BUILD=saucy-11
  UBUNTU=ubuntu-touch-saucy-armhf
  ubuntu/platform-api=:68
  hybris=0.1.0+git20130606+c5d897a-0ubuntu2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1191895/+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 1849733] Re: resolved incorrectly limits TCP reply to edns0 payload

[Dan Streetman]

** Changed in: systemd (Ubuntu)
   Status: New => Fix Released

** Tags added: bionic ddstreet disco eoan systemd

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

Title:
  resolved incorrectly limits TCP reply to edns0 payload

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its
  payload limit to 1200.  When the response is larger than 1200,
  resolved will limit the response and set the truncate flag.  This
  causes getaddrinfo() to switch to TCP and request again, but glibc
  incorrectly keeps the EDNS0 RR opt, with the same 1200 payload limit.
  Most dns nameservers ignore EDNS0 payload limit for TCP, since per RFC
  it applies only to UDP, but resolved does not and again marks the
  response as truncated.  This prevents getaddrinfo() from being able to
  resolve any records with a response over 1200 bytes.

  [test case]

  use ping or telnet, which use getaddrinfo(), to lookup an A record
  with a lot of results, like toomany100.ddstreet.org

  $ telnet toomany100.ddstreet.org
  telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure 
in name resolution

  [regression potential]

  any regression would likely result in failure to correctly lookup a
  hostname or to provide the correct response to a local client.

  [other info]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849733/+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 1849733] [NEW] resolved incorrectly limits TCP reply to edns0 payload

[Dan Streetman]

Public bug reported:

[impact]

glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its
payload limit to 1200.  When the response is larger than 1200, resolved
will limit the response and set the truncate flag.  This causes
getaddrinfo() to switch to TCP and request again, but glibc incorrectly
keeps the EDNS0 RR opt, with the same 1200 payload limit.  Most dns
nameservers ignore EDNS0 payload limit for TCP, since per RFC it applies
only to UDP, but resolved does not and again marks the response as
truncated.  This prevents getaddrinfo() from being able to resolve any
records with a response over 1200 bytes.

[test case]

use ping or telnet, which use getaddrinfo(), to lookup an A record with
a lot of results, like toomany100.ddstreet.org

$ telnet toomany100.ddstreet.org
telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure in 
name resolution

[regression potential]

any regression would likely result in failure to correctly lookup a
hostname or to provide the correct response to a local client.

[other info]

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

** Affects: systemd (Ubuntu Bionic)
 Importance: Medium
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress

** Affects: systemd (Ubuntu Disco)
 Importance: Medium
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress

** Affects: systemd (Ubuntu Eoan)
 Importance: Medium
 Assignee: Dan Streetman (ddstreet)
 Status: Fix Released

** Also affects: systemd (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: systemd (Ubuntu Eoan)
   Status: New => Fix Released

** Changed in: systemd (Ubuntu Disco)
   Status: New => In Progress

** Changed in: systemd (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: systemd (Ubuntu Disco)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Eoan)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Disco)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Bionic)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

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

Title:
  resolved incorrectly limits TCP reply to edns0 payload

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its
  payload limit to 1200.  When the response is larger than 1200,
  resolved will limit the response and set the truncate flag.  This
  causes getaddrinfo() to switch to TCP and request again, but glibc
  incorrectly keeps the EDNS0 RR opt, with the same 1200 payload limit.
  Most dns nameservers ignore EDNS0 payload limit for TCP, since per RFC
  it applies only to UDP, but resolved does not and again marks the
  response as truncated.  This prevents getaddrinfo() from being able to
  resolve any records with a response over 1200 bytes.

  [test case]

  use ping or telnet, which use getaddrinfo(), to lookup an A record
  with a lot of results, like toomany100.ddstreet.org

  $ telnet toomany100.ddstreet.org
  telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure 
in name resolution

  [regression potential]

  any regression would likely result in failure to correctly lookup a
  hostname or to provide the correct response to a local client.

  [other info]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849733/+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 1830502] Re: apparmor uses excessive memory leading to oom kill

[Jamie Strandboge]

@Ivan, we are going to fix snapd for the excessive memory usage.
AppArmor upstream already uses expr-simplify by default and newer
release of Ubuntu use parser.conf to set -O no-expr-simplify so users
can manage the setting like any other conffile.

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

Title:
  apparmor uses excessive memory leading to oom kill

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  When attempting to load the profile from comment #7, apparmor uses
  excessive amounts of memory leading to being killed by the OOM killer
  and thus the apparmor.service failing.

  Original bug description:

  On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk,
  my system was unable to finish booting and I had to go into recovery
  mode and remove a number of files before the system would boot. After
  doing so I discovered that now the apparmor.service systemd unit
  always fails to start. I see this in dmesg:

  [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 
or sacrifice child
  [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, 
anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB
  [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now 
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

  Whenever apparmor.service is attempted to be started by systemd, i.e.
  either on boot, or later with `systemctl start apparmor`.

  The log from journalctl doesn't show any actual issues with any
  profiles just this:

  -- Reboot --
  May 25 17:00:58 systemd[1]: Starting AppArmor initialization...
  May 25 17:00:58 apparmor[1521]:  * Starting AppArmor profiles
  May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: 
usr.bin.firefox
  May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: 
usr.sbin.rsyslogd
  May 25 17:01:40 apparmor[1521]:...fail!
  May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, 
code=exited, status=123/n/a
  May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'.
  May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization.
  May 25 17:04:53 systemd[1]: Starting AppArmor initialization...
  May 25 17:04:53 apparmor[4747]:  * Starting AppArmor profiles
  May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: 
usr.bin.firefox
  May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: 
usr.sbin.rsyslogd
  May 25 17:05:25 apparmor[4747]:...fail!
  May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, 
code=exited, status=123/n/a
  May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'.
  May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization.

  I can see that apparmor profiles are active after doing this (using
  aa-status), but it's still troubling that apparmor runs into an issue
  without actually saying what the error is.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1735981] Re: Huawei ME936 mobile broadband can't connect

[Matthias Prinz]

Workarount badpractice works! Thank you!

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

Title:
  Huawei ME936 mobile broadband can't connect

Status in modemmanager package in Ubuntu:
  Confirmed

Bug description:
  Hi, I have an Acer Travelmate P648 with a Huawei ME936
  internal USB mobile broadband card, and can't connect.
  This didn't work in 17.04, and still does not work in 17.10.

  The USB device is successfully connected, 
  ModemManager gets as far as "Simple connect state (8/8): All done"
  During the setup ModemManager complains with "Couldn't find associated 
cdc-wdm port for 'net/wwp0s20f0u9c2'"

  DHCP tries to get a configuration, but " dhcp4 (wwp0s20f0u9c2): request timed 
out".
  IP6 is set to "automatically" in the network settings for this configuration. 

  and finally connection fails with 
  "device (ttyUSB0): state change: ip-config -> failed (reason 
'ip-config-unavailable', internal state 'managed')"

  I checked that there are enough credits left in my account with the
  provider.

  Any ideas what else to check ?

  Yours,
  Steffen

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: modemmanager 1.6.8-1
  ProcVersionSignature: Ubuntu 4.13.0-17.20-generic 4.13.8
  Uname: Linux 4.13.0-17-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.5
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Dec  3 11:27:49 2017
  InstallationDate: Installed on 2017-04-24 (222 days ago)
  InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: modemmanager
  UpgradeStatus: Upgraded to artful on 2017-12-02 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1735981/+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 1848354] Re: upgrade-between-snapshots autopkgtest is flaky

[Brian Murray]

Hello Balint, or anyone else affected,

Accepted unattended-upgrades into bionic-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.12 in a few hours, and then in the
-proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-bionic to verification-done-bionic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-bionic. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: unattended-upgrades (Ubuntu Bionic)
   Status: New => Fix Committed

** Tags added: verification-needed-bionic

** Changed in: unattended-upgrades (Ubuntu Xenial)
   Status: New => Fix Committed

** Tags added: verification-needed-xenial

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

Title:
  upgrade-between-snapshots autopkgtest is flaky

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Committed
Status in unattended-upgrades source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Flaky upgrade-between-snapshots autopkgtest prevents developers to
  use the test efficiently.

  [Test Case]

   * Run autopkgtests, observe the upgrade-between-snapshots test
  passing or failing but being marked as FLAKY.

  [Regression Potential]

   * None, the test was failing often due to connectivity/internal
  errors of snapshot.debian.org.

  [Other Info]

   * The whole autopkgtest is marked to be failing on amd64 to mitigate
  the single flaky test, this marking can be removed after marking this
  single flaky test.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1848354/+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 1823070] Please test proposed package

[Brian Murray]

Hello Steve, or anyone else affected,

Accepted unattended-upgrades into xenial-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.7~16.04.4 in a few hours, and then
in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

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

Title:
  unattended-upgrades should tell the user (via motd) when security
  updates are held back

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Committed

Bug description:
  [Impact]

   * MOTD does not go into details about upgradable packages being security 
fixes or just normal updates.
   * Users should be made aware if some of the security updates could not have 
been applied.
   * The fix is adding a snipped to MOTD where the number of packages kept back 
by unattended-upgrades is shown.

  [Test Case]

   * The debian/tests/upgrade-all-security is extended to check if the number 
of kept back packages are shown in MOTD and a new test is added 
(test/test_motd.py) to check if the list of kept back packages are saved 
properly.
   * To test the fix manually:
 1. Mark a package upgradable from the -security pocket as held, then run 
unattended-upgrades.
 2. Observe MOTD messate showing the number of packages being kept back.

  [Regression Potential]

   * Unattended-upgrades may crash when saving kept packages and always
  return with failure. MOTD may hang or print error while printing the
  packages kept back by u-u.

  [Original Bug Text]

  Currently we have the following pieces as part of the default UX on
  Ubuntu 18.04 and later:

   1) unattended-upgrades automatically installs security updates daily by 
default
   2) the motd reports the number of available updates, including security 
updates.

  A user who knows about 1) also knows that a non-zero number of pending
  security updates listed in 2) is nothing to worry about.

  However, unattended-upgrades will also cleverly detect when a security
  update cannot safely be installed non-interactively due to conffile
  changes on the system.

  In this case, unattended-upgrades should also inform the user via the
  motd that these updates are not being installed.  Otherwise, there's
  nothing to tell the user that the non-zero count of available security
  updates in motd is a *problem*.

  Suggested wording:

   N security updates will not be automatically installed due to local changes.
   See /var/log/foo for details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1823070/+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 1821376] Please test proposed package

[Brian Murray]

Hello Balint, or anyone else affected,

Accepted unattended-upgrades into xenial-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.7~16.04.4 in a few hours, and then
in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

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

Title:
  Report packages kept back by origins

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Committed

Bug description:
  [Impact]

  * Packages kept back are listed in the email report, but it is not
  clear from which origins they are installable. This information may
  help administrators to decide if the packages need to be manually
  upgraded.

  [Test Case]

  * test_mail.py test is updated to check if the kept back packages are
  reported per origin and this is checked at build time.

  *  For manual testing:
1. Configure u-u to allow upgrades from the -updates pocket and send email 
with the upgrade report.
2. Set up the system to have a few packages upgradable from both the 
-security and -updates pockets.
3. Mark a subset of packages which are upgradable as held, marking packages 
from each of the pockets.
4. Run u-u and observe the kept packages listed in the email. Each package 
is listed only in the allowed origin providing the highest version. (LP: 
#1848697 covers listing them in all origins from which the packages could be 
upgraded to.)

  [Regression Potential]

  * Unattended upgrades may crash while trying to perform updates or
  while trying to send the summary email. Build-time tests and
  autopkgtests include testing both functions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1821376/+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 1821376] Re: Report packages kept back by origins

[Brian Murray]

Hello Balint, or anyone else affected,

Accepted unattended-upgrades into bionic-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.12 in a few hours, and then in the
-proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-bionic to verification-done-bionic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-bionic. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: unattended-upgrades (Ubuntu Bionic)
   Status: New => Fix Committed

** Tags added: verification-needed-bionic

** Changed in: unattended-upgrades (Ubuntu Xenial)
   Status: New => Fix Committed

** Tags added: verification-needed-xenial

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

Title:
  Report packages kept back by origins

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Committed

Bug description:
  [Impact]

  * Packages kept back are listed in the email report, but it is not
  clear from which origins they are installable. This information may
  help administrators to decide if the packages need to be manually
  upgraded.

  [Test Case]

  * test_mail.py test is updated to check if the kept back packages are
  reported per origin and this is checked at build time.

  *  For manual testing:
1. Configure u-u to allow upgrades from the -updates pocket and send email 
with the upgrade report.
2. Set up the system to have a few packages upgradable from both the 
-security and -updates pockets.
3. Mark a subset of packages which are upgradable as held, marking packages 
from each of the pockets.
4. Run u-u and observe the kept packages listed in the email. Each package 
is listed only in the allowed origin providing the highest version. (LP: 
#1848697 covers listing them in all origins from which the packages could be 
upgraded to.)

  [Regression Potential]

  * Unattended upgrades may crash while trying to perform updates or
  while trying to send the summary email. Build-time tests and
  autopkgtests include testing both functions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1821376/+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 1848354] Please test proposed package

[Brian Murray]

Hello Balint, or anyone else affected,

Accepted unattended-upgrades into xenial-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.7~16.04.4 in a few hours, and then
in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

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

Title:
  upgrade-between-snapshots autopkgtest is flaky

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Committed
Status in unattended-upgrades source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Flaky upgrade-between-snapshots autopkgtest prevents developers to
  use the test efficiently.

  [Test Case]

   * Run autopkgtests, observe the upgrade-between-snapshots test
  passing or failing but being marked as FLAKY.

  [Regression Potential]

   * None, the test was failing often due to connectivity/internal
  errors of snapshot.debian.org.

  [Other Info]

   * The whole autopkgtest is marked to be failing on amd64 to mitigate
  the single flaky test, this marking can be removed after marking this
  single flaky test.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1848354/+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 1823070] Re: unattended-upgrades should tell the user (via motd) when security updates are held back

[Brian Murray]

Hello Steve, or anyone else affected,

Accepted unattended-upgrades into bionic-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.12 in a few hours, and then in the
-proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-bionic to verification-done-bionic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-bionic. In either case, without details of
your testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: unattended-upgrades (Ubuntu Bionic)
   Status: Confirmed => Fix Committed

** Tags added: verification-needed-bionic

** Changed in: unattended-upgrades (Ubuntu Xenial)
   Status: New => Fix Committed

** Tags added: verification-needed-xenial

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

Title:
  unattended-upgrades should tell the user (via motd) when security
  updates are held back

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Committed

Bug description:
  [Impact]

   * MOTD does not go into details about upgradable packages being security 
fixes or just normal updates.
   * Users should be made aware if some of the security updates could not have 
been applied.
   * The fix is adding a snipped to MOTD where the number of packages kept back 
by unattended-upgrades is shown.

  [Test Case]

   * The debian/tests/upgrade-all-security is extended to check if the number 
of kept back packages are shown in MOTD and a new test is added 
(test/test_motd.py) to check if the list of kept back packages are saved 
properly.
   * To test the fix manually:
 1. Mark a package upgradable from the -security pocket as held, then run 
unattended-upgrades.
 2. Observe MOTD messate showing the number of packages being kept back.

  [Regression Potential]

   * Unattended-upgrades may crash when saving kept packages and always
  return with failure. MOTD may hang or print error while printing the
  packages kept back by u-u.

  [Original Bug Text]

  Currently we have the following pieces as part of the default UX on
  Ubuntu 18.04 and later:

   1) unattended-upgrades automatically installs security updates daily by 
default
   2) the motd reports the number of available updates, including security 
updates.

  A user who knows about 1) also knows that a non-zero number of pending
  security updates listed in 2) is nothing to worry about.

  However, unattended-upgrades will also cleverly detect when a security
  update cannot safely be installed non-interactively due to conffile
  changes on the system.

  In this case, unattended-upgrades should also inform the user via the
  motd that these updates are not being installed.  Otherwise, there's
  nothing to tell the user that the non-zero count of available security
  updates in motd is a *problem*.

  Suggested wording:

   N security updates will not be automatically installed due to local changes.
   See /var/log/foo for details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1823070/+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 1821376] Re: Report packages kept back by origins

[Brian Murray]

Hello Balint, or anyone else affected,

Accepted unattended-upgrades into disco-proposed. The package will build
now and be available at https://launchpad.net/ubuntu/+source/unattended-
upgrades/1.10ubuntu5.2 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-disco to verification-done-disco. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-disco. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: unattended-upgrades (Ubuntu Disco)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-disco

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

Title:
  Report packages kept back by origins

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Committed

Bug description:
  [Impact]

  * Packages kept back are listed in the email report, but it is not
  clear from which origins they are installable. This information may
  help administrators to decide if the packages need to be manually
  upgraded.

  [Test Case]

  * test_mail.py test is updated to check if the kept back packages are
  reported per origin and this is checked at build time.

  *  For manual testing:
1. Configure u-u to allow upgrades from the -updates pocket and send email 
with the upgrade report.
2. Set up the system to have a few packages upgradable from both the 
-security and -updates pockets.
3. Mark a subset of packages which are upgradable as held, marking packages 
from each of the pockets.
4. Run u-u and observe the kept packages listed in the email. Each package 
is listed only in the allowed origin providing the highest version. (LP: 
#1848697 covers listing them in all origins from which the packages could be 
upgraded to.)

  [Regression Potential]

  * Unattended upgrades may crash while trying to perform updates or
  while trying to send the summary email. Build-time tests and
  autopkgtests include testing both functions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1821376/+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 1823070] Re: unattended-upgrades should tell the user (via motd) when security updates are held back

[Brian Murray]

Hello Steve, or anyone else affected,

Accepted unattended-upgrades into disco-proposed. The package will build
now and be available at https://launchpad.net/ubuntu/+source/unattended-
upgrades/1.10ubuntu5.2 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-disco to verification-done-disco. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-disco. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: unattended-upgrades (Ubuntu Disco)
   Status: Confirmed => Fix Committed

** Tags added: verification-needed verification-needed-disco

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

Title:
  unattended-upgrades should tell the user (via motd) when security
  updates are held back

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Committed

Bug description:
  [Impact]

   * MOTD does not go into details about upgradable packages being security 
fixes or just normal updates.
   * Users should be made aware if some of the security updates could not have 
been applied.
   * The fix is adding a snipped to MOTD where the number of packages kept back 
by unattended-upgrades is shown.

  [Test Case]

   * The debian/tests/upgrade-all-security is extended to check if the number 
of kept back packages are shown in MOTD and a new test is added 
(test/test_motd.py) to check if the list of kept back packages are saved 
properly.
   * To test the fix manually:
 1. Mark a package upgradable from the -security pocket as held, then run 
unattended-upgrades.
 2. Observe MOTD messate showing the number of packages being kept back.

  [Regression Potential]

   * Unattended-upgrades may crash when saving kept packages and always
  return with failure. MOTD may hang or print error while printing the
  packages kept back by u-u.

  [Original Bug Text]

  Currently we have the following pieces as part of the default UX on
  Ubuntu 18.04 and later:

   1) unattended-upgrades automatically installs security updates daily by 
default
   2) the motd reports the number of available updates, including security 
updates.

  A user who knows about 1) also knows that a non-zero number of pending
  security updates listed in 2) is nothing to worry about.

  However, unattended-upgrades will also cleverly detect when a security
  update cannot safely be installed non-interactively due to conffile
  changes on the system.

  In this case, unattended-upgrades should also inform the user via the
  motd that these updates are not being installed.  Otherwise, there's
  nothing to tell the user that the non-zero count of available security
  updates in motd is a *problem*.

  Suggested wording:

   N security updates will not be automatically installed due to local changes.
   See /var/log/foo for details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1823070/+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 1735981] Re: Huawei ME936 mobile broadband can't connect

[Michael Weimann]

Works with Philipp Hufnagl's workaround.

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

Title:
  Huawei ME936 mobile broadband can't connect

Status in modemmanager package in Ubuntu:
  Confirmed

Bug description:
  Hi, I have an Acer Travelmate P648 with a Huawei ME936
  internal USB mobile broadband card, and can't connect.
  This didn't work in 17.04, and still does not work in 17.10.

  The USB device is successfully connected, 
  ModemManager gets as far as "Simple connect state (8/8): All done"
  During the setup ModemManager complains with "Couldn't find associated 
cdc-wdm port for 'net/wwp0s20f0u9c2'"

  DHCP tries to get a configuration, but " dhcp4 (wwp0s20f0u9c2): request timed 
out".
  IP6 is set to "automatically" in the network settings for this configuration. 

  and finally connection fails with 
  "device (ttyUSB0): state change: ip-config -> failed (reason 
'ip-config-unavailable', internal state 'managed')"

  I checked that there are enough credits left in my account with the
  provider.

  Any ideas what else to check ?

  Yours,
  Steffen

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: modemmanager 1.6.8-1
  ProcVersionSignature: Ubuntu 4.13.0-17.20-generic 4.13.8
  Uname: Linux 4.13.0-17-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.5
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Dec  3 11:27:49 2017
  InstallationDate: Installed on 2017-04-24 (222 days ago)
  InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: modemmanager
  UpgradeStatus: Upgraded to artful on 2017-12-02 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1735981/+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 1848354] Re: upgrade-between-snapshots autopkgtest is flaky

[Brian Murray]

Hello Balint, or anyone else affected,

Accepted unattended-upgrades into disco-proposed. The package will build
now and be available at https://launchpad.net/ubuntu/+source/unattended-
upgrades/1.10ubuntu5.2 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-disco to verification-done-disco. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-disco. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: unattended-upgrades (Ubuntu Disco)
   Status: New => Fix Committed

** Tags added: verification-needed-disco

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

Title:
  upgrade-between-snapshots autopkgtest is flaky

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Disco:
  Fix Committed
Status in unattended-upgrades source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Flaky upgrade-between-snapshots autopkgtest prevents developers to
  use the test efficiently.

  [Test Case]

   * Run autopkgtests, observe the upgrade-between-snapshots test
  passing or failing but being marked as FLAKY.

  [Regression Potential]

   * None, the test was failing often due to connectivity/internal
  errors of snapshot.debian.org.

  [Other Info]

   * The whole autopkgtest is marked to be failing on amd64 to mitigate
  the single flaky test, this marking can be removed after marking this
  single flaky test.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1848354/+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 1345847] Re: Impossible to disable IPv6 auto, params "accept_ra & autoconf = 0" have no effect on VLAN interfaces

[Vintozver]

This is a kernel bug. I don't have ifupdown (use networkd instead) -
problem confirmed.

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

Title:
  Impossible to disable IPv6 auto, params "accept_ra & autoconf = 0"
  have no effect on VLAN interfaces

Status in ifupdown package in Ubuntu:
  Confirmed

Bug description:
  Guys,

  I'm trying to disable IPv6 autoconf (and accept_ra too) in one of my
  servers (Samba4 AC DC) and I am unable to disable it. IPv6 keep
  appearing no matter what.

  Steps to reproduce:

  1- Join a Network with a working IPv6 radvd within a tagged VLAN 10,
  for example:

  * Router Ubuntu with:

  --
  interface vlan10 {
  AdvSendAdvert on;
  MinRtrAdvInterval 5;
  MaxRtrAdvInterval 20;
  AdvLinkMTU 1500;
  AdvDefaultPreference high;
  prefix 2001:db8:1:10::/64 {
  DeprecatePrefix on;
  AdvOnLink on;
  AdvAutonomous on;
  AdvRouterAddr on;
  };
  route ::/0 {
  RemoveRoute on;
  };
  RDNSS 2001:4860:4860::8844 2001:4860:4860:: { };
  DNSSL domain.com.br { };
  };
  --

   Of course, for example, vlan10 on Ubuntu router have IPv6 addr =
  2001:db8:1:10::1/64, so radvd can work. Also, vlan10 of router have
  IPv4 172.16.0.1/24 (it is a dual-stacked router).

  -

  2- Configure your Ubuntu 14.04 server interfaces like this:

  --
  auto vlan10
  iface vlan10 inet static
vlan_raw_device eth0
accept_ra 0
autoconf 0
address 172.16.0.10
netmask 24
gateway 172.16.0.1
dns-nameservers 172.16.0.1
  --

  3- Turn it up:

  --
  ifup vlan10

  * Here is the BUG, IPv6 appear anyway! But it should not!

  -
  root@ubuntu-srv-1:~# ip -6 r
  2001:db8:1:10::/64 dev vlan10  proto kernel  metric 256  expires 86389sec
  fe80::/64 dev eth0  proto kernel  metric 256 
  fe80::/64 dev vlan10  proto kernel  metric 256 
  default via fe80::5054:ff:feae:1407 dev vlan10  proto ra  metric 1024  
expires 49sec
  -

   This is undesired and a security breach. It facilitates MITM IPv6
  attacks for tagged vlans.

  --

   As a workaround, I'm adding the following lines at my /etc/rc.local
  (of ubuntu-srv-1):

  --
  # Workaroung against IPv6 autoconf & accept_ra
  sysctl -p
  ifconfig vlan10 down ; ifconfig vlan10 up
  --

  Where "sysctl -p" returns:

  --
  root@ubuntu-srv-1:~# sysctl -p
  net.ipv6.conf.all.accept_ra = 0
  net.ipv6.conf.all.autoconf = 0
  net.ipv6.conf.eth0.accept_ra = 0
  net.ipv6.conf.eth0.autoconf = 0
  net.ipv6.conf.vlan10.accept_ra = 0
  net.ipv6.conf.vlan10.autoconf = 0
  --

  This workaround is the only way I'm seeing to completely disable IPv6
  for this server (ubuntu-srv-1).

  Best,
  Thiago

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1345847/+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 1846140] Re: Realtek RTL8723BU doesn't work well in ubuntu

[Sebastien Bacher]

** No longer affects: network-manager (Ubuntu)

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

Title:
  Realtek RTL8723BU doesn't work well in ubuntu

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have one laptop with Realtek RTL8723BU wifi card. It runs, but
  signal is weak (it only works if the router is less than a meter
  away), and even if it gets signal it's slow and it gets interrupted
  frequently. In windows it works normally, and with a much stronger
  signal. I tested it on Ubuntu 18.04.3 and 19.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1846140/+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 1671951] Re: networkd should allow configuring IPV6 MTU

[Ryan Harper]

I did some more testing today.  I upgraded systemd and netplan.io to
disco level, rebooted and tested the MTU  settings; disco packages fail
as well.  I then upgraded to eoan systemd/netplan.io rebooted and the
MTU settings are correct.

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

Title:
  networkd should allow configuring IPV6 MTU

Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in cloud-init source package in Disco:
  New
Status in netplan.io source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  New

Bug description:
  = netplan.io =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]
   * Apply a netplan configuration that specifices ipv6-mtu:

  network:
version: 2
ethernets:
  eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000

   * Check that MTU bytes, is at least IPv6MTUBytes on the interface:

  $ sysctl net.ipv6.conf.eth0.mtu
  net.ipv6.conf.eth0.mtu = 6000

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]

   * Use IPv6MTUBytes= setting in a .network unit
   * Restart systemd-network
   * Check that there no error messages / warnings about not-recognizing this 
option
   * Check that MTU bytes, is at least IPv6MTUBytes on the interface

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of systemd =

  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  Some context from those discussions

  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu lowered.  They could lower their link mtu,
  >> so their ipv6 packets are small enough, but that reduces performance
  >> of their ipv4 network.

  Yes.  Anything that creates a PMTUD black hole can result in
  situations where the higher header overhead of IPv6 will cause IPv4 to
  pass but IPv6 traffic to be dropped.

  One example here is egress from an ipsec tunnel wherein the next
  hop MTU is too low for IPv6 datagrams to pass.  Another is VM ->
  whatever -> host bridge -> tunnel ingress.  If the datagram cannot enter
  the tunnel due to size, it is dropped, and an ICMP response uses the
  tunnel address as a source, which may not be routable back to the
  origin.  This one is an issue with IPv4 as well, and is one case where
  manually setting the IPv6 MTU lower than the (also manually set) device
  MTU is of benefit.

  In essence, any of these sort of cases that require an explicit
  setting of the device MTU will likely require a setting of the IPv6 mtu
  as well to account for its larger header overhead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+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 1671951] Re: networkd should allow configuring IPV6 MTU

[Ryan Harper]

In the Eoan version of systemd, I can see in the logs these messages:

Oct 24 18:52:32.753746 ubuntu systemd-networkd[1167]: Setting 
'/proc/sys/net/ipv6/conf/interface1/proxy_ndp' to '0'
Oct 24 18:52:32.753848 ubuntu systemd-networkd[1167]: Setting 
'/proc/sys/net/ipv6/conf/interface1/use_tempaddr' to '0'
Oct 24 18:52:32.753884 ubuntu systemd-networkd[1167]: Setting 
'/proc/sys/net/ipv6/conf/interface1/accept_ra' to '0'
Oct 24 18:52:32.753962 ubuntu systemd-networkd[1167]: Setting 
'/proc/sys/net/ipv6/conf/interface1/mtu' to '5634'

These are not emitted in bionic or disco versions of systemd.

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

Title:
  networkd should allow configuring IPV6 MTU

Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in cloud-init source package in Disco:
  New
Status in netplan.io source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  New

Bug description:
  = netplan.io =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]
   * Apply a netplan configuration that specifices ipv6-mtu:

  network:
version: 2
ethernets:
  eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000

   * Check that MTU bytes, is at least IPv6MTUBytes on the interface:

  $ sysctl net.ipv6.conf.eth0.mtu
  net.ipv6.conf.eth0.mtu = 6000

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]

   * Use IPv6MTUBytes= setting in a .network unit
   * Restart systemd-network
   * Check that there no error messages / warnings about not-recognizing this 
option
   * Check that MTU bytes, is at least IPv6MTUBytes on the interface

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of systemd =

  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  Some context from those discussions

  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu lowered.  They could lower their link mtu,
  >> so their ipv6 packets are small enough, but that reduces performance
  >> of their ipv4 network.

  Yes.  Anything that creates a PMTUD black hole can result in
  situations where the higher header overhead of IPv6 will cause IPv4 to
  pass but IPv6 traffic to be dropped.

  One example here is egress from an ipsec tunnel wherein the next
  hop MTU is too low for IPv6 datagrams to pass.  Another is VM ->
  whatever -> host bridge -> tunnel ingress.  If the datagram cannot enter
  the tunnel due to size, it is dropped, and an ICMP response uses the
  tunnel address as a source, which may not be routable back to the
  origin.  This one is an issue with IPv4 as well, and is one case where
  manually setting the IPv6 MTU lower than the (also manually set) device
  MTU is of benefit.

  In essence, any of these sort of cases that require an explicit
  setting of the device MTU will likely require a setting of the IPv6 mtu
  as well to account for its larger header overhead.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1846140] Re: Realtek RTL8723BU doesn't work well in ubuntu

[Roque]

Thanks, hope it will be added to mainline soon.

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

Title:
  Realtek RTL8723BU doesn't work well in ubuntu

Status in linux package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  New

Bug description:
  I have one laptop with Realtek RTL8723BU wifi card. It runs, but
  signal is weak (it only works if the router is less than a meter
  away), and even if it gets signal it's slow and it gets interrupted
  frequently. In windows it works normally, and with a much stronger
  signal. I tested it on Ubuntu 18.04.3 and 19.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1846140/+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 1846208] Re: [MIR] abootimg (dependency of initramfs-tools-ubuntu-core)

[Brian Murray]

Provided the following changes are merged the MIR will no longer be
required.

https://github.com/snapcore/core-build/pull/55/commits

** Tags removed: rls-ee-incoming

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

Title:
  [MIR] abootimg (dependency of initramfs-tools-ubuntu-core)

Status in abootimg package in Ubuntu:
  Incomplete

Bug description:
  needs a MIR (or removal of the dependency): abootimg (dependency of
  initramfs-tools-ubuntu-core)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/abootimg/+bug/1846208/+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 1848064] Re: /usr/share/apport/whoopsie-upload-all:PermissionError:/usr/share/apport/whoopsie-upload-all@168:collect_info:process_report

[Brian Murray]

** Also affects: apport (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Tags removed: rls-ee-incoming

** Changed in: apport (Ubuntu Eoan)
   Importance: Undecided => High

** Changed in: apport (Ubuntu Eoan)
   Status: New => Confirmed

** Changed in: apport (Ubuntu)
   Status: New => Confirmed

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

Title:
  /usr/share/apport/whoopsie-upload-
  all:PermissionError:/usr/share/apport/whoopsie-upload-
  all@168:collect_info:process_report

Status in apport package in Ubuntu:
  Confirmed
Status in apport source package in Eoan:
  Confirmed

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apport.  This problem was most recently seen with package version 
2.20.11-0ubuntu8, the problem page at 
https://errors.ubuntu.com/problem/d9f09f3b3e7aa8ab77434ef30f33416a856971ae 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1848064/+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 1849711] [NEW] Only GRUB2 have MAX BRIGHTNESS in 19.04 and 19.10

[raza]

Public bug reported:

whenever I boot into Ubuntu the grub 2 boot loader have maximum brightness but 
after selecting Ubuntu OS, system return to its normal brightness value , 
previously my Ubuntu version is 19.04 and this problem exists but after 
upgrading to 19.10 this issue still there and nothing works by upgrading 
system, grub remains at high brightness value (even function keys not working 
at that time). Every time i reboot the system the grub 2 have max brightness 
and it returns to normal brightness after reaching to log on screen and then 
everything works fine even functions keys also working.
laptop specs:
AMD reyzen 3 2200u
AMD Radeon Vega 3
HP g7 245

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: xorg 1:7.7+19ubuntu12
ProcVersionSignature: Ubuntu 5.0.0-32.34-generic 5.0.21
Uname: Linux 5.0.0-32-generic x86_64
ApportVersion: 2.20.11-0ubuntu8
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Thu Oct 24 21:52:44 2019
DistUpgraded: Fresh install
DistroCodename: eoan
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / 
Radeon Vega Mobile Series] [1002:15dd] (rev c5) (prog-if 00 [VGA controller])
   Subsystem: Hewlett-Packard Company Raven Ridge [Radeon Vega Series / Radeon 
Vega Mobile Series] [103c:8562]
MachineType: Hewlett-Packard HP 245 G7 Notebook PC
ProcEnviron:
 LANGUAGE=en_IN:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_IN
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic 
root=UUID=380079ae-40a6-4aed-8280-2b263a41cf1e ro quiet splash 
acpi_backlight=vendor quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/03/2019
dmi.bios.vendor: AMI
dmi.bios.version: F.42
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 8562
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 84.24
dmi.chassis.asset.tag: 5CG9212QLP
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: Chassis Version
dmi.modalias: 
dmi:bvnAMI:bvrF.42:bd07/03/2019:svnHewlett-Packard:pnHP245G7NotebookPC:pvr:rvnHewlett-Packard:rn8562:rvr84.24:cvnHewlett-Packard:ct10:cvrChassisVersion:
dmi.product.family: 103C_5336AN HP 200
dmi.product.name: HP 245 G7 Notebook PC
dmi.product.sku: 6JM93PA#ACJ
dmi.sys.vendor: Hewlett-Packard
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.99-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-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.0.1-1ubuntu1
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 eoan ubuntu

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

Title:
  Only GRUB2 have MAX BRIGHTNESS  in 19.04 and 19.10

Status in xorg package in Ubuntu:
  New

Bug description:
  whenever I boot into Ubuntu the grub 2 boot loader have maximum brightness 
but after selecting Ubuntu OS, system return to its normal brightness value , 
previously my Ubuntu version is 19.04 and this problem exists but after 
upgrading to 19.10 this issue still there and nothing works by upgrading 
system, grub remains at high brightness value (even function keys not working 
at that time). Every time i reboot the system the grub 2 have max brightness 
and it returns to normal brightness after reaching to log on screen and then 
everything works fine even functions keys also working.
  laptop specs:
  AMD reyzen 3 2200u
  AMD Radeon Vega 3
  HP g7 245

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.0.0-32.34-generic 5.0.21
  Uname: Linux 5.0.0-32-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Oct 24 21:52:44 2019
  DistUpgraded: Fresh install
  DistroCodename: eoan
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / 
Radeon Vega Mobile Series] [1002:15dd] (rev c5) (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Raven Ridge [Radeon Vega Series / 
Radeon Vega Mobile Series] [103c:8562]
  MachineType: Hewlett-Packard HP 245 G7 Notebook PC
  ProcEnviron:
   

[Touch-packages] [Bug 1827253] Re: [apparmor] missing 'mr' on binary for usage on containers

[Christian Ehrhardt ]

Thanks for the review Łukasz,
I somewhat agree with your summary. The reason I went on with it was because it 
was very low hanging fruit and Simon (Bug reporter) is like "The Ubuntu 
community good bug reports role model".
But I agree that the update for everyone (it is always installed) might be too 
much.

I'd be ok getting it only to proposed, we have done so in the past for
other things and since it can be changed by the user prio is low anyway.

@Simon - opinions on proposed / abort / convince ?

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

Title:
  [apparmor] missing 'mr' on binary for usage on containers

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Bionic:
  Triaged
Status in rsyslog source package in Disco:
  Triaged

Bug description:
  [Impact]

   * rsyslog ships with a (Default disable) apparmor profile.
   * Security sensitive users are in general encouraged to enable such
     profiles but unfortunately due to slightly new behavior of the program
     the profile prevents its usage.
   * Allow the program to map/read its binary to get this working again

  [Test Case]

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  [Regression Potential]

   * This is just opening up the apparmor profile a bit. Therefore the only
     regression it could cause IMHO is a security issue. But then what it
     actually allows is reading (not writing!) its own binary which should
     be very safe.
   * Thinking further it came to my mind that package updates (independent 
 to the change) might restart services and that means if there is any 
 issue e.g. in a local config that worked but now fails (not by this 
 change but in general) then the upgrade will not cause, but trigger 
 this. This is a general regression risk for any upload, but in this 
 case worth to mention as it is about log handling - which if broken - 
 makes large scale systems hard to debug.

  [Other Info]

   * n/a

  ---

  Issue description:

  Enabling the rsyslog (disabled by default) Apparmor profile causes
  rsyslog to fail to start when running *inside a container*.

  Steps to reproduce:

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  Workaround:

    echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog

  Additional information:

  root@rs1:~# uname -a
  Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
  root@rs1:~# lsb_release -rd
  Description:  Ubuntu Eoan EANIMAL (development branch)
  Release:  19.10
  root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
  ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
  ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: rsyslog 8.32.0-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
  Uname: Linux 4.15.0-48-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Wed May  1 17:36:29 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+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 1827253] Re: [apparmor] missing 'mr' on binary for usage on containers

[Łukasz Zemczak]

Reviewing this, it feels to me like something nice to have, but low-
importance enough that I'd be worried about users getting an upgrade
with no impact for them (and, as per the regression potential, some low-
chance but still regression risk). The SRU policy is a bit conflicted
there: on one side we should only do high-impact bugs *or* low-risk bugs
in case of applications. But this is rsyslog, so something a bit more
low-level, so it's up to some interpretation as to what the policy
thinks about it.

One option would be to accept it into -proposed pockets and set the
block-proposed-* tags to not make it migrate, only including it in case
some additional SRU gets uploaded on top. Would that be fine? The only
problem I see is that rsyslog doesn't seem to have an active SRU history
looking a disco and bionic, so the chances this would go out into
-updates would be low...

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

Title:
  [apparmor] missing 'mr' on binary for usage on containers

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Bionic:
  Triaged
Status in rsyslog source package in Disco:
  Triaged

Bug description:
  [Impact]

   * rsyslog ships with a (Default disable) apparmor profile.
   * Security sensitive users are in general encouraged to enable such
     profiles but unfortunately due to slightly new behavior of the program
     the profile prevents its usage.
   * Allow the program to map/read its binary to get this working again

  [Test Case]

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  [Regression Potential]

   * This is just opening up the apparmor profile a bit. Therefore the only
     regression it could cause IMHO is a security issue. But then what it
     actually allows is reading (not writing!) its own binary which should
     be very safe.
   * Thinking further it came to my mind that package updates (independent 
 to the change) might restart services and that means if there is any 
 issue e.g. in a local config that worked but now fails (not by this 
 change but in general) then the upgrade will not cause, but trigger 
 this. This is a general regression risk for any upload, but in this 
 case worth to mention as it is about log handling - which if broken - 
 makes large scale systems hard to debug.

  [Other Info]

   * n/a

  ---

  Issue description:

  Enabling the rsyslog (disabled by default) Apparmor profile causes
  rsyslog to fail to start when running *inside a container*.

  Steps to reproduce:

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  Workaround:

    echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog

  Additional information:

  root@rs1:~# uname -a
  Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
  root@rs1:~# lsb_release -rd
  Description:  Ubuntu Eoan EANIMAL (development branch)
  Release:  19.10
  root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
  ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
  ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: rsyslog 8.32.0-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
  Uname: Linux 4.15.0-48-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Wed May  1 17:36:29 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+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 1849608] Re: systemd resolv should separate the output of stdout and stderr

[Dan Streetman]

** Also affects: systemd (Ubuntu Focal)
   Importance: Undecided
   Status: Confirmed

** Also affects: systemd (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Description changed:

+ [impact]
+ 
+ dhclient fails to notify resolved about DNS servers due to bash-specific
+ redirect inside 'resolved' hook script
+ 
+ [test case]
+ 
+ see original description below
+ 
+ [regression potential]
+ 
+ any regression would likely cause resolved not to be aware of dhclient-
+ provided dns servers
+ 
+ [other info]
+ 
+ This is needed only in Eoan and later; X/B/D do not have the bash-
+ specific redirect '&>' in their hook file.
+ 
+ original description:
+ ---
+ 
+ 
  The file /etc/dhcp/dhclient-enter-hooks.d/resolved
  provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
  This issue can be reproduced on Ubuntu Eoan:
  ==
- root@eoan:~# dhclient -v 
+ root@eoan:~# dhclient -v
  Internet Systems Consortium DHCP Client 4.4.1
  Copyright 2004-2018 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/
  
  Listening on LPF/ens224/00:0c:29:92:d4:da
  Sending on   LPF/ens224/00:0c:29:92:d4:da
  Listening on LPF/ens192/00:0c:29:92:d4:d0
  Sending on   LPF/ens192/00:0c:29:92:d4:d0
  Listening on LPF/ens160/00:0c:29:92:d4:c6
  Sending on   LPF/ens160/00:0c:29:92:d4:c6
  Sending on   Socket/fallback
  DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
  DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
  DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 
(xid=0x6d39545d)
  DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d)
  RTNETLINK answers: File exists
  d41d8cd98f00b204e9800998ecf8427e  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  5025823d750dda1f3f15e306c4a0afce  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  bound to 192.168.120.4 -- renewal in 111 seconds.
  root@eoan:~# resolvectl status |grep DNS
  MulticastDNS setting: no
-   DNSOverTLS setting: no
-   DNSSEC setting: no
- DNSSEC supported: no
-   DNSSEC NTA: 10.in-addr.arpa
+   DNSOverTLS setting: no
+   DNSSEC setting: no
+ DNSSEC supported: no
+   DNSSEC NTA: 10.in-addr.arpa
  MulticastDNS setting: no
-   DNSOverTLS setting: no
-   DNSSEC setting: no
- DNSSEC supported: no
+   DNSOverTLS setting: no
+   DNSSEC setting: no
+ DNSSEC supported: no
  MulticastDNS setting: no
-   DNSOverTLS setting: no
-   DNSSEC setting: no
- DNSSEC supported: no
+   DNSOverTLS setting: no
+   DNSSEC setting: no
+ DNSSEC supported: no
  MulticastDNS setting: no
-   DNSOverTLS setting: no
-   DNSSEC setting: no
- DNSSEC supported: no
+   DNSOverTLS setting: no
+   DNSSEC setting: no
+ DNSSEC supported: no
  ==
  
  Attached please find the patch for this. The output for md5sum in the
  hook file resolv should separate the stdout and stderr so it won't
  compare the wrong data.

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

Title:
  systemd resolv should separate the output of stdout and stderr

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Eoan:
  New
Status in systemd source package in Focal:
  Confirmed

Bug description:
  [impact]

  dhclient fails to notify resolved about DNS servers due to bash-
  specific redirect inside 'resolved' hook script

  [test case]

  see original description below

  [regression potential]

  any regression would likely cause resolved not to be aware of
  dhclient-provided dns servers

  [other info]

  This is needed only in Eoan and later; X/B/D do not have the bash-
  specific redirect '&>' in their hook file.

  original description:
  ---

  
  The file /etc/dhcp/dhclient-enter-hooks.d/resolved
  provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
  This issue can be reproduced on Ubuntu Eoan:
  ==
  root@eoan:~# dhclient -v
  Internet Systems Consortium DHCP Client 4.4.1
  Copyright 2004-2018 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens224/00:0c:29:92:d4:da
  Sending on   LPF/ens224/00:0c:29:92:d4:da
  Listening on LPF/ens192/00:0c:29:92:d4:d0
  Sending on   LPF/ens192/00:0c:29:92:d4:d0
  Listening on LPF/ens160/00:0c:29:92:d4:c6
  Sending on   LPF/ens160/00:0c:29:92:d4:c6
  Sending on   Socket/fallback
  DHCPDISCOVER on ens224 to 255.255.255.255 port 

[Touch-packages] [Bug 1844853] Re: IBus no longer works in Qt applications after upgrade

[Bug Watch Updater]

** Changed in: glib
   Status: Unknown => New

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

Title:
  IBus no longer works in Qt applications after upgrade

Status in GLib:
  New
Status in ibus:
  Fix Released
Status in glib2.0 package in Ubuntu:
  Confirmed
Status in ibus package in Ubuntu:
  Fix Released
Status in ibus package in Debian:
  Confirmed

Bug description:
  Kubuntu Release 18.04.3 LTS

  Expected behavior:
  ibus continues working as before after applying security update 
1.5.17-ubuntu5.1 from version 1.5.17-ubuntu5.

  Observed behavior:
  ibus is not usable anymore in Qt applications.

  After updating ibus and the related packages ibus-gtk, ibus-gtk3, 
libibus-1.0-5 and gir1.2-ibus-1.0 all from version 1.5.17-ubuntu5 to 
1.5.17-ubuntu5.1, I can no longer use ibus in Qt applications. Using 
shift-space no longer changes the selected input method and even when i switch 
to the mozc input method in a gtk application, i can not use it in any Qt 
applications.
  When starting qtconfig in a terminal, I also get the following message:

  Bus::open: Connect ibus failed! 
  IBusInputContext::createInputContext: no connection to ibus-daemon

  This bug was not present in version 1.5.17-3ubuntu5 and I also
  confirmed that downgrading the packages to version 1.5.17-3ubuntu4
  restores ibus functionality in Qt applications.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: ibus 1.5.17-3ubuntu5.1
  ProcVersionSignature: Ubuntu 5.0.0-30.32~18.04.1-generic 5.0.21
  Uname: Linux 5.0.0-30-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Sat Sep 21 07:58:56 2019
  InstallationDate: Installed on 2019-06-28 (84 days ago)
  InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  SourcePackage: ibus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/glib/+bug/1844853/+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 1848587] Re: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2

[Seth Forshee]

Seems /dev/network_latency was removed upstream.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c3082a674f46fe49383b157882c41dfabaa37113

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

Title:
  lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2

Status in lxc package in Ubuntu:
  New

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/amd64/l/lxc/20191016_150939_0f81d@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/arm64/l/lxc/20191016_152027_0f81d@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/ppc64el/l/lxc/20191016_150251_0f81d@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/s390x/l/lxc/20191016_150201_0f81d@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587/+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 1849680] [NEW] audit spam in dmesg (libreoffice)

[Christian Pernegger]

Public bug reported:

My dmesg is getting flooded by apparmor audit messages, mostly from
libreoffice (profiles libreoffice-soffice and libreoffice-oosplash):

$ dmesg | tail -n 25
[13682.452555] audit: type=1400 audit(1571920851.001:3672): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/usr/share/drirc.d/00-mesa-defaults.conf" pid=17792 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[13682.453430] audit: type=1400 audit(1571920851.001:3673): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/usr/share/drirc.d/00-mesa-defaults.conf" pid=17792 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[13682.453933] audit: type=1400 audit(1571920851.001:3674): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/usr/share/libdrm/amdgpu.ids" pid=17792 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[13682.455491] audit: type=1400 audit(1571920851.005:3675): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/home/chris/.cache/mesa_shader_cache/index" pid=17792 comm="soffice.bin" 
requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000
[13682.604100] audit: type=1400 audit(1571920851.153:3676): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/home/chris/.local/share/gvfs-metadata/smb-share:server=buddha,share=chris"
 pid=17791 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
[13682.604138] audit: type=1400 audit(1571920851.153:3677): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/home/chris/.local/share/gvfs-metadata/smb-share:server=buddha,share=chris-22028640.log"
 pid=17791 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
[13683.097648] audit: type=1400 audit(1571920851.645:3678): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/home/chris/.mozilla/firefox/vq2zzheq.chris-2019-09/cert8.db" pid=17791 
comm="soffice.bin" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
[16676.510664] kauditd_printk_skb: 1210 callbacks suppressed
[16676.510665] audit: type=1400 audit(1571923845.047:4889): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/usr/share/drirc.d/00-mesa-defaults.conf" pid=18543 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16676.511473] audit: type=1400 audit(1571923845.047:4890): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/usr/share/drirc.d/00-mesa-defaults.conf" pid=18543 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16676.550636] audit: type=1400 audit(1571923845.087:4891): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/usr/share/drirc.d/00-mesa-defaults.conf" pid=18543 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16676.551394] audit: type=1400 audit(1571923845.087:4892): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/usr/share/drirc.d/00-mesa-defaults.conf" pid=18543 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16676.552145] audit: type=1400 audit(1571923845.087:4893): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/usr/share/drirc.d/00-mesa-defaults.conf" pid=18543 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16676.552568] audit: type=1400 audit(1571923845.087:4894): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/usr/share/libdrm/amdgpu.ids" pid=18543 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16676.553912] audit: type=1400 audit(1571923845.091:4895): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/home/chris/.cache/mesa_shader_cache/index" pid=18543 comm="soffice.bin" 
requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000
[16694.388901] audit: type=1400 audit(1571923862.923:4896): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" name="/proc/18541/mountinfo" 
pid=18541 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
[16694.388972] audit: type=1400 audit(1571923862.923:4897): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" name="/proc/18541/cgroup" 
pid=18541 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
[16694.388992] audit: type=1400 audit(1571923862.923:4898): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/sys/fs/cgroup/memory/memory.limit_in_bytes" pid=18541 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16694.389011] audit: type=1400 audit(1571923862.923:4899): apparmor="ALLOWED" 
operation="open" profile="libreoffice-soffice" 
name="/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us" pid=18541 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16694.389017] 

[Touch-packages] [Bug 1849608] Re: systemd resolv should separate the output of stdout and stderr

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu)
   Status: New => Confirmed

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

Title:
  systemd resolv should separate the output of stdout and stderr

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  The file /etc/dhcp/dhclient-enter-hooks.d/resolved
  provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
  This issue can be reproduced on Ubuntu Eoan:
  ==
  root@eoan:~# dhclient -v 
  Internet Systems Consortium DHCP Client 4.4.1
  Copyright 2004-2018 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens224/00:0c:29:92:d4:da
  Sending on   LPF/ens224/00:0c:29:92:d4:da
  Listening on LPF/ens192/00:0c:29:92:d4:d0
  Sending on   LPF/ens192/00:0c:29:92:d4:d0
  Listening on LPF/ens160/00:0c:29:92:d4:c6
  Sending on   LPF/ens160/00:0c:29:92:d4:c6
  Sending on   Socket/fallback
  DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
  DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
  DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 
(xid=0x6d39545d)
  DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d)
  RTNETLINK answers: File exists
  d41d8cd98f00b204e9800998ecf8427e  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  5025823d750dda1f3f15e306c4a0afce  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  bound to 192.168.120.4 -- renewal in 111 seconds.
  root@eoan:~# resolvectl status |grep DNS
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  ==

  Attached please find the patch for this. The output for md5sum in the
  hook file resolv should separate the stdout and stderr so it won't
  compare the wrong data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849608/+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 1834138] Update Released

[Łukasz Zemczak]

The verification of the Stable Release Update for pulseaudio has
completed successfully and the package is now being released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  PA: Don't restore the streams to sinks/sources with only unavailable
  ports

Status in HWE Next:
  New
Status in OEM Priority Project:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Bionic:
  Fix Committed
Status in pulseaudio source package in Disco:
  Fix Released
Status in pulseaudio source package in Eoan:
  Fix Released

Bug description:
  SRU Document:

  [Impact]

  The Lenovo P520 machine has dual analogue codecs, so there are two
  sinks and two sources in the PA, one has the front headphone and front
  microphone, the other has the rear lineout, linein and rear
  microphone, and the rear microphone always shows up in the gnome-
  sound-setting, When we plug a microphone to front audio jack, there
  are two input devices: rear mic and front mic in the gnome-sound-
  setting, and suppose users select the the front mic to record sound
  via audio app like arecord, the front mic will be bond the arecord,
  after the front mic is unplugged, there is only one rear mic left in
  the gnome-sound-setting, but the binding will not be changed, the
  arecrod still bind to front mic, under this situation if users record
  sound via arecord, they will find they can't record any sound from any
  other input devices even they are listed in the gnome-sound-setting.
  This problem also happens to output devices too.

  [Test Case]

  After applying this patch, I did the same test: unplug the front mic,
  then use the arecord to record sound, the app can record sound from
  rear mic now. After I plug the front mic back, the arecord still
  record from front mic. Also did the similar test for output devices,
  it worked as expected too.

  [Regression Potential]

  Low, Just make a simple check when creating new streams
  (sink_input/source_output), If the restored device (sink/source) has
  ports and all ports are unavialble, it will not restore the binding,
  otherwise it will work as before.

  For the Bionic, This SRU also includes the fix of LP: #1556439, this
  fix is safe and is very low possible to introduce any regression too,
  because it just adds a sink-input/source-output state checking, if the
  sink-input/source-output is unlinking or unlinked, it is useless to
  move it to a new sink/source, furthermore it will trigger an assertion
  that make the pulseaudio crash, adding this check can fix this problem
  (LP: #1556439).

  [Other Info]

  No more info here

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1834138/+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 1827842] Re: pulseaudio should not load module-x11-bell in gnome-shell

[Launchpad Bug Tracker]

This bug was fixed in the package pulseaudio - 1:12.2-2ubuntu3.1

---
pulseaudio (1:12.2-2ubuntu3.1) disco; urgency=medium

  * debian/patches/0006-load-module-x11-bell.patch:
- remove that old distro patch, it's undocumented, not needed since
  GNOME handles the login sound by itself and create issues in some
  cases (duplicate sound, not respecting the UI choice)
  (lp: #1827842)

  [ Hui Wang ]
  * d/p/0800-stream-restore-Don-t-restore-if-the-active_port-is-P.patch:
- Don't restore the streams to sinks/sources with only unavailable ports
  (LP: #1834138)

 -- Sebastien Bacher   Fri, 28 Jun 2019 11:45:10
+0200

** Changed in: pulseaudio (Ubuntu Disco)
   Status: Fix Committed => Fix Released

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

Title:
  pulseaudio should not load module-x11-bell in gnome-shell

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Disco:
  Fix Released

Bug description:
  * Impact
  The package force load a bell sound which can conflicts with the user 
configuration

  * Test case
  - Enable a login sound in session
  - Login into a GNOME/Ubuntu session
  -> the configured sound should be played

  * Regression potential
  Try other desktop environments to make sure their login sound behaviour isn't 
changed, it shouldn't since the customization dropped was specific to the 
Ubuntu sound theme

  ---

  The package `pulseaudio` installs a startup script in 
`/etc/xdg/autostart/pulseaudio.desktop`,
  which itself runs `/usr/bin/start-pulseaudio-x11`,
  which loads a number of x11 related modules in `pulseaudio`.

  One of these modules is `module-x11-bell`,
  which makes `pulseaudio` play a sound each time a system bell is emitted
  (usually by terminal applications, such as bash or vim).

  This is redundant with gnome-shell, which is also able to handle the system 
bell
  (through the gsetting key `org.gnome.desktop.sound event-sounds`).

  The gnome system bell is directly configurable by the user (Settings > Sound),
  so it should be preferred over pulseaudio's own system bell.

  I suggest to patch the `/usr/bin/start-pulseaudio-x11`,
  to avoid loading `start-pulseaudio-x11` if it detects it is running in Gnome 
Shell
  (e.g. if GNOME_SHELL_SESSION_MODE is set).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1827842/+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 1827842] Update Released

[Łukasz Zemczak]

The verification of the Stable Release Update for pulseaudio has
completed successfully and the package is now being released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  pulseaudio should not load module-x11-bell in gnome-shell

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Disco:
  Fix Released

Bug description:
  * Impact
  The package force load a bell sound which can conflicts with the user 
configuration

  * Test case
  - Enable a login sound in session
  - Login into a GNOME/Ubuntu session
  -> the configured sound should be played

  * Regression potential
  Try other desktop environments to make sure their login sound behaviour isn't 
changed, it shouldn't since the customization dropped was specific to the 
Ubuntu sound theme

  ---

  The package `pulseaudio` installs a startup script in 
`/etc/xdg/autostart/pulseaudio.desktop`,
  which itself runs `/usr/bin/start-pulseaudio-x11`,
  which loads a number of x11 related modules in `pulseaudio`.

  One of these modules is `module-x11-bell`,
  which makes `pulseaudio` play a sound each time a system bell is emitted
  (usually by terminal applications, such as bash or vim).

  This is redundant with gnome-shell, which is also able to handle the system 
bell
  (through the gsetting key `org.gnome.desktop.sound event-sounds`).

  The gnome system bell is directly configurable by the user (Settings > Sound),
  so it should be preferred over pulseaudio's own system bell.

  I suggest to patch the `/usr/bin/start-pulseaudio-x11`,
  to avoid loading `start-pulseaudio-x11` if it detects it is running in Gnome 
Shell
  (e.g. if GNOME_SHELL_SESSION_MODE is set).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1827842/+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 1827842] Re: pulseaudio should not load module-x11-bell in gnome-shell

[Łukasz Zemczak]

Yeah, I guess this will have to do it for the verification. Please be
sure to re-open the bug in case someone reports the issue as not being
fixed in the end.

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

Title:
  pulseaudio should not load module-x11-bell in gnome-shell

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Disco:
  Fix Released

Bug description:
  * Impact
  The package force load a bell sound which can conflicts with the user 
configuration

  * Test case
  - Enable a login sound in session
  - Login into a GNOME/Ubuntu session
  -> the configured sound should be played

  * Regression potential
  Try other desktop environments to make sure their login sound behaviour isn't 
changed, it shouldn't since the customization dropped was specific to the 
Ubuntu sound theme

  ---

  The package `pulseaudio` installs a startup script in 
`/etc/xdg/autostart/pulseaudio.desktop`,
  which itself runs `/usr/bin/start-pulseaudio-x11`,
  which loads a number of x11 related modules in `pulseaudio`.

  One of these modules is `module-x11-bell`,
  which makes `pulseaudio` play a sound each time a system bell is emitted
  (usually by terminal applications, such as bash or vim).

  This is redundant with gnome-shell, which is also able to handle the system 
bell
  (through the gsetting key `org.gnome.desktop.sound event-sounds`).

  The gnome system bell is directly configurable by the user (Settings > Sound),
  so it should be preferred over pulseaudio's own system bell.

  I suggest to patch the `/usr/bin/start-pulseaudio-x11`,
  to avoid loading `start-pulseaudio-x11` if it detects it is running in Gnome 
Shell
  (e.g. if GNOME_SHELL_SESSION_MODE is set).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1827842/+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 1834138] Re: PA: Don't restore the streams to sinks/sources with only unavailable ports

[Launchpad Bug Tracker]

This bug was fixed in the package pulseaudio - 1:12.2-2ubuntu3.1

---
pulseaudio (1:12.2-2ubuntu3.1) disco; urgency=medium

  * debian/patches/0006-load-module-x11-bell.patch:
- remove that old distro patch, it's undocumented, not needed since
  GNOME handles the login sound by itself and create issues in some
  cases (duplicate sound, not respecting the UI choice)
  (lp: #1827842)

  [ Hui Wang ]
  * d/p/0800-stream-restore-Don-t-restore-if-the-active_port-is-P.patch:
- Don't restore the streams to sinks/sources with only unavailable ports
  (LP: #1834138)

 -- Sebastien Bacher   Fri, 28 Jun 2019 11:45:10
+0200

** Changed in: pulseaudio (Ubuntu Disco)
   Status: Fix Committed => Fix Released

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

Title:
  PA: Don't restore the streams to sinks/sources with only unavailable
  ports

Status in HWE Next:
  New
Status in OEM Priority Project:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Bionic:
  Fix Committed
Status in pulseaudio source package in Disco:
  Fix Released
Status in pulseaudio source package in Eoan:
  Fix Released

Bug description:
  SRU Document:

  [Impact]

  The Lenovo P520 machine has dual analogue codecs, so there are two
  sinks and two sources in the PA, one has the front headphone and front
  microphone, the other has the rear lineout, linein and rear
  microphone, and the rear microphone always shows up in the gnome-
  sound-setting, When we plug a microphone to front audio jack, there
  are two input devices: rear mic and front mic in the gnome-sound-
  setting, and suppose users select the the front mic to record sound
  via audio app like arecord, the front mic will be bond the arecord,
  after the front mic is unplugged, there is only one rear mic left in
  the gnome-sound-setting, but the binding will not be changed, the
  arecrod still bind to front mic, under this situation if users record
  sound via arecord, they will find they can't record any sound from any
  other input devices even they are listed in the gnome-sound-setting.
  This problem also happens to output devices too.

  [Test Case]

  After applying this patch, I did the same test: unplug the front mic,
  then use the arecord to record sound, the app can record sound from
  rear mic now. After I plug the front mic back, the arecord still
  record from front mic. Also did the similar test for output devices,
  it worked as expected too.

  [Regression Potential]

  Low, Just make a simple check when creating new streams
  (sink_input/source_output), If the restored device (sink/source) has
  ports and all ports are unavialble, it will not restore the binding,
  otherwise it will work as before.

  For the Bionic, This SRU also includes the fix of LP: #1556439, this
  fix is safe and is very low possible to introduce any regression too,
  because it just adds a sink-input/source-output state checking, if the
  sink-input/source-output is unlinking or unlinked, it is useless to
  move it to a new sink/source, furthermore it will trigger an assertion
  that make the pulseaudio crash, adding this check can fix this problem
  (LP: #1556439).

  [Other Info]

  No more info here

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1834138/+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 1849399] Re: ibus in 19.10 misinterprets ~/.XCompose, somehow maps to the Delete key

[Gunnar Hjalmarsson]

On 2019-10-24 07:50, Steve Langasek wrote:
> On Thu, Oct 24, 2019 at 12:06:38AM -, Gunnar Hjalmarsson wrote:
>> wondering if that line shouldn't rather read something like this:
>> 
>> : "☭"   # HAMMER AND SICKLE
>> 
>> (which works with IBus provided that there is a defined compose key)
> 
> Sure, this is a valid alternative, and just replacing the <\> with
>  is enough to unbreak my Delete key.  (I don't care about
> whether it causes the compose sequence to work,

Please.. Whether it works in some case is reasonably relevant.

If I open gedit from terminal, I get these complaints:

(org.gnome.gedit:3821): Gtk-WARNING **: 14:11:14.241: Could not get code
point of keysym \

(org.gnome.gedit:3821): Gtk-WARNING **: 14:11:14.242: Could not get code
point of keysym )

(org.gnome.gedit:3821): Gtk-WARNING **: 14:11:14.242: compose file
/home/gunnar/.XCompose does not include any keys besides keys in en-us
compose file

So Gtk does not understand it, and - needless to say - it doesn't work.

If I replace <\> with  and <)> with , Gtk stops
complaining and it works, kind of. I.e. pressing \ followed by ) gives
me ☭. But then I can't use my \ key for anything else, so this kind of
composing is pretty useless without including  too.

My observations are true both with and without IBus. IBus provides the
extra 'feature' with involving the Delete key, though.

> IBus does not define the syntax of .XCompose,

Right. Probably Gtk or libx11 does.

> It is not for ibus to retroactively declare the file to be
> "syntactically incorrect";

I suppose you don't know if it worked in 19.04. I guess it did not, and
then the file has been incorrect for a long time.

> and regardless, if it has decided that the file is syntactically
> incorrect, this should not result in changes to the behavior of an
> unrelated key.

Ok.. Do you plan to submit an upstream issue?

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

Title:
  ibus in 19.10 misinterprets ~/.XCompose, somehow maps to the Delete
  key

Status in ibus package in Ubuntu:
  Triaged

Bug description:
  After upgrade to 19.10, I found that my Delete key was not working as
  a Delete key, but that instead if I hit Delete twice it would print
  the character ☭.

  Since others were not reporting this issue, I had a look around at my
  input config and remembered that I had ibus configured from a long
  time ago in order to support Chinese input.

  If I disable ibus (either by unsetting the environment variables; or
  by killing ibus-daemon), then the Delete key works again as expected.

  This is a regression in behavior since Ubuntu 19.04, where I had the
  same input setup on my desktop but the Delete key worked without
  problems.

  I'm also not sure how to disable ibus, now that I am in this
  situation; or if ibus is expected to always be running.

  The problem persists if I run ibus-setup and remove Chinese SunPinyin
  from the list of input methods, leaving only "English - English (US)".

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1849399/+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 1230031] Re: dbus-daemon consumes 100% cpu without reason

[Colin Watson]

** Summary changed:

- Buy Tramadol Online Next Day Delivery
+ dbus-daemon consumes 100% cpu without reason

** Description changed:

- Buy Tramadol Online Next Day Delivery
- 
- Safe and Secure Order Delivery
- 
- >>  http://yourchemiststore.net
- 
- Buy Tramadol Online
- 
- Buy Tramadol 100mg online
- 
- Buy Tramadol Online 200mg
- 
- Buy Tramadol 50mg
- 
- Buy Tramadol Online Legally
- 
- Buy Tramadol Online cheap
- 
- 
  Just login in to session, and dbus-daemon consumes 100% of cpu. Before,
  I did a login and logout. This problem appears randomly, not all the
  time.
  
-  9107 sergio20   0 30376 1660 1356 R 100,1  0,0  11:35.08 dbus-daemon
- 11692 root  20   0  433m  54m  37m S   1,0  1,4   0:05.46 Xorg
- 12279 sergio20   0 1506m  78m  30m S   0,7  2,1   0:05.40 compiz
- 12417 sergio20   0  553m  20m  11m S   0,7  0,6   0:00.93 gnome-terminal
+  9107 sergio20   0 30376 1660 1356 R 100,1  0,0  11:35.08 dbus-daemon 

  
+ 11692 root  20   0  433m  54m  37m S   1,0  1,4   0:05.46 Xorg

  
+ 12279 sergio20   0 1506m  78m  30m S   0,7  2,1   0:05.40 compiz  

  
+ 12417 sergio20   0  553m  20m  11m S   0,7  0,6   0:00.93 gnome-terminal  

  
  13757 sergio20   0  853m 160m  40m S   0,7  4,2   0:06.83 firefox
  
  See sensors, dbus-daemon is heating up my laptop:
  
  Adapter: Virtual device
  temp1:+68.0°C  (crit = +98.0°C)
  
  coretemp-isa-
  Adapter: ISA adapter
  Physical id 0:  +69.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 0: +49.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 1: +51.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 2: +69.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 3: +55.0°C  (high = +84.0°C, crit = +100.0°C)
  
  asus-isa-
  Adapter: ISA adapter
- temp1:   +6280.0°C
+ temp1:   +6280.0°C  
  
  pkg-temp-0-virtual-0
  Adapter: Virtual device
  temp1:+68.0°C
  
  ---
  
  Description:  Ubuntu Saucy Salamander (development branch)
  Release:  13.10
  Linux sergio-X751JB 3.11.0-8-generic #15-Ubuntu SMP Fri Sep 20 04:11:26 UTC 
2013 x86_64 x86_64 x86_64 GNU/Linux
  
  dbus:
-   Installed: 1.6.12-0ubuntu5
-   Candidate: 1.6.12-0ubuntu5
-   Version table:
-  *** 1.6.12-0ubuntu5 0
- 500 http://archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
- 100 /var/lib/dpkg/status
+   Installed: 1.6.12-0ubuntu5
+   Candidate: 1.6.12-0ubuntu5
+   Version table:
+  *** 1.6.12-0ubuntu5 0
+ 500 http://archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
+ 100 /var/lib/dpkg/status
  
  ProblemType: Bug
  DistroRelease: Ubuntu 13.10
  Package: dbus 1.6.12-0ubuntu5
  ProcVersionSignature: Ubuntu 3.11.0-8.15-generic 3.11.1
  Uname: Linux 3.11.0-8-generic x86_64
  ApportVersion: 2.12.4-0ubuntu1
  Architecture: amd64
  Date: Wed Sep 25 04:31:14 2013
  InstallationDate: Installed on 2013-09-20 (4 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130920)
  MarkForUpload: True
  SourcePackage: dbus
  UpgradeStatus: No upgrade log present (probably fresh install)

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

Title:
  dbus-daemon consumes 100% cpu without reason

Status in dbus package in Ubuntu:
  Confirmed

Bug description:
  Just login in to session, and dbus-daemon consumes 100% of cpu.
  Before, I did a login and logout. This problem appears randomly, not
  all the time.

   9107 sergio20   0 30376 1660 1356 R 100,1  0,0  11:35.08 dbus-daemon 

  
  11692 root  20   0  433m  54m  37m S   1,0  1,4   0:05.46 Xorg

  
  12279 sergio20   0 1506m  78m  30m S   0,7  2,1   0:05.40 compiz  

  
  12417 sergio20   0  553m  20m  11m S   0,7  0,6   0:00.93 gnome-terminal  

  
  13757 sergio20   0  853m 160m  40m S   0,7  4,2   0:06.83 firefox

  See sensors, dbus-daemon is heating up my laptop:

  Adapter: Virtual device
  temp1:+68.0°C  (crit = +98.0°C)

  coretemp-isa-
  Adapter: ISA adapter
  Physical id 0:  +69.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 0: +49.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 1: +51.0°C  (high = +84.0°C, crit = +100.0°C)
  

[Touch-packages] [Bug 1844853] Re: IBus no longer works in Qt applications after upgrade

[Gunnar Hjalmarsson]

** Bug watch added: gitlab.gnome.org/GNOME/glib/issues #1831
   https://gitlab.gnome.org/GNOME/glib/issues/1831

** Also affects: glib via
   https://gitlab.gnome.org/GNOME/glib/issues/1831
   Importance: Unknown
   Status: Unknown

** Also affects: glib2.0 (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: glib2.0 (Ubuntu)
   Importance: Undecided => High

** Changed in: glib2.0 (Ubuntu)
   Status: New => Confirmed

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

Title:
  IBus no longer works in Qt applications after upgrade

Status in GLib:
  Unknown
Status in ibus:
  Fix Released
Status in glib2.0 package in Ubuntu:
  Confirmed
Status in ibus package in Ubuntu:
  Fix Released
Status in ibus package in Debian:
  Confirmed

Bug description:
  Kubuntu Release 18.04.3 LTS

  Expected behavior:
  ibus continues working as before after applying security update 
1.5.17-ubuntu5.1 from version 1.5.17-ubuntu5.

  Observed behavior:
  ibus is not usable anymore in Qt applications.

  After updating ibus and the related packages ibus-gtk, ibus-gtk3, 
libibus-1.0-5 and gir1.2-ibus-1.0 all from version 1.5.17-ubuntu5 to 
1.5.17-ubuntu5.1, I can no longer use ibus in Qt applications. Using 
shift-space no longer changes the selected input method and even when i switch 
to the mozc input method in a gtk application, i can not use it in any Qt 
applications.
  When starting qtconfig in a terminal, I also get the following message:

  Bus::open: Connect ibus failed! 
  IBusInputContext::createInputContext: no connection to ibus-daemon

  This bug was not present in version 1.5.17-3ubuntu5 and I also
  confirmed that downgrading the packages to version 1.5.17-3ubuntu4
  restores ibus functionality in Qt applications.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: ibus 1.5.17-3ubuntu5.1
  ProcVersionSignature: Ubuntu 5.0.0-30.32~18.04.1-generic 5.0.21
  Uname: Linux 5.0.0-30-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Sat Sep 21 07:58:56 2019
  InstallationDate: Installed on 2019-06-28 (84 days ago)
  InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  SourcePackage: ibus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/glib/+bug/1844853/+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 1849666] [NEW] can not see hdmi

[emre]

Public bug reported:

i can not see hdmi, and i don't know why?

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 5.0.0-32.34~18.04.2-generic 5.0.21
Uname: Linux 5.0.0-32-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Thu Oct 24 15:27:11 2019
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
DkmsStatus: nvidia, 430.50, 5.0.0-32-generic, x86_64: installed
GraphicsCard:
 Intel Corporation Device [8086:3e9b] (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:39fe]
 NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1) 
(prog-if 00 [VGA controller])
   Subsystem: Lenovo GP107M [GeForce GTX 1050 Mobile] [17aa:39fe]
InstallationDate: Installed on 2019-10-22 (2 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 04ca:7070 Lite-On Technology Corp. 
 Bus 001 Device 002: ID 145f:01e7 Trust 
 Bus 001 Device 004: ID 0bda:b023 Realtek Semiconductor Corp. 
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: LENOVO 81FV
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic 
root=UUID=6747b4a8-5274-45de-a7f5-f774e2c086d9 ro quiet splash vt.handoff=1
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/02/2018
dmi.bios.vendor: LENOVO
dmi.bios.version: 8JCN48WW
dmi.board.asset.tag: NO Asset Tag
dmi.board.name: LNVNB161216
dmi.board.vendor: LENOVO
dmi.board.version: SDK0R33126 WIN
dmi.chassis.asset.tag: NO Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Lenovo Legion Y530-15ICH
dmi.modalias: 
dmi:bvnLENOVO:bvr8JCN48WW:bd11/02/2018:svnLENOVO:pn81FV:pvrLenovoLegionY530-15ICH:rvnLENOVO:rnLNVNB161216:rvrSDK0R33126WIN:cvnLENOVO:ct10:cvrLenovoLegionY530-15ICH:
dmi.product.family: Legion Y530-15ICH
dmi.product.name: 81FV
dmi.product.sku: LENOVO_MT_81FV_BU_idea_FM_Legion Y530-15ICH
dmi.product.version: Lenovo Legion Y530-15ICH
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.100+git1910210630.c69c9c~oibaf~b
version.libgl1-mesa-dri: libgl1-mesa-dri 19.3~git1910240730.196165~oibaf~b
version.libgl1-mesa-glx: libgl1-mesa-glx 19.3~git1910240730.196165~oibaf~b
version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 
1:19.1.0+git1910151930.b9bd80~oibaf~b
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git1910071930.bff5ec~oibaf~b
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.16+git1906080730.ec2b45~oibaf~b

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


** Tags: amd64 apport-bug bionic possible-manual-nvidia-install 
third-party-packages ubuntu

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

Title:
  can not see hdmi

Status in xorg package in Ubuntu:
  New

Bug description:
  i can not see hdmi, and i don't know why?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 5.0.0-32.34~18.04.2-generic 5.0.21
  Uname: Linux 5.0.0-32-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Oct 24 15:27:11 2019
  DistUpgraded: Fresh install
  DistroCodename: bionic
  DistroVariant: ubuntu
  DkmsStatus: nvidia, 430.50, 5.0.0-32-generic, x86_64: installed
  GraphicsCard:
   Intel Corporation Device [8086:3e9b] (prog-if 00 [VGA controller])
 Subsystem: Lenovo Device [17aa:39fe]
   NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1) 
(prog-if 00 [VGA controller])
 Subsystem: Lenovo GP107M [GeForce GTX 1050 Mobile] [17aa:39fe]
  InstallationDate: Installed on 2019-10-22 (2 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 04ca:7070 Lite-On Technology Corp. 
   Bus 001 Device 002: ID 145f:01e7 Trust 
   Bus 001 Device 004: ID 0bda:b023 Realtek Semiconductor Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: LENOVO 81FV
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic 
root=UUID=6747b4a8-5274-45de-a7f5-f774e2c086d9 ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/02/2018
  

[Touch-packages] [Bug 1844853] Re: IBus no longer works in Qt applications after upgrade

[Bug Watch Updater]

** Changed in: ibus
   Status: New => Fix Released

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

Title:
  IBus no longer works in Qt applications after upgrade

Status in ibus:
  Fix Released
Status in ibus package in Ubuntu:
  Fix Released
Status in ibus package in Debian:
  Confirmed

Bug description:
  Kubuntu Release 18.04.3 LTS

  Expected behavior:
  ibus continues working as before after applying security update 
1.5.17-ubuntu5.1 from version 1.5.17-ubuntu5.

  Observed behavior:
  ibus is not usable anymore in Qt applications.

  After updating ibus and the related packages ibus-gtk, ibus-gtk3, 
libibus-1.0-5 and gir1.2-ibus-1.0 all from version 1.5.17-ubuntu5 to 
1.5.17-ubuntu5.1, I can no longer use ibus in Qt applications. Using 
shift-space no longer changes the selected input method and even when i switch 
to the mozc input method in a gtk application, i can not use it in any Qt 
applications.
  When starting qtconfig in a terminal, I also get the following message:

  Bus::open: Connect ibus failed! 
  IBusInputContext::createInputContext: no connection to ibus-daemon

  This bug was not present in version 1.5.17-3ubuntu5 and I also
  confirmed that downgrading the packages to version 1.5.17-3ubuntu4
  restores ibus functionality in Qt applications.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: ibus 1.5.17-3ubuntu5.1
  ProcVersionSignature: Ubuntu 5.0.0-30.32~18.04.1-generic 5.0.21
  Uname: Linux 5.0.0-30-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Sat Sep 21 07:58:56 2019
  InstallationDate: Installed on 2019-06-28 (84 days ago)
  InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  SourcePackage: ibus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1844853/+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 1849658] [NEW] resolved fallback to TCP fails for truncated UDP replies

[Dan Streetman]

Public bug reported:

[impact]

for DNS UDP replies larger than 512 bytes, fallback to TCP is used.  For
example 'host toomany.ddstreet.org'.

Due to a bug in resolved in refcounting DNS stream types, the refcount
underflows for type 0 streams (which resolved uses to talk to upstream
nameservers), resulting in resolved being unable to fallback to TCP to
handle truncated UDP replies.

[test case]

ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683
;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;toomany.ddstreet.org.  IN  A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Oct 24 11:40:29 UTC 2019
;; MSG SIZE  rcvd: 678

ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches
ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org
;; global options: +cmd
;; connection timed out; no servers could be reached

[regression potential]

very low, as this only properly sets the stream type in the DnsStream
object; any regression would be a failure to be able to use TCP for DNS
requests or replies.

[other info]

https://github.com/systemd/systemd/pull/13838

The commit adding stream types is not present in x/b, so this is needed
only for disco and later.

** Affects: systemd (Ubuntu)
 Importance: Medium
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress

** Affects: systemd (Ubuntu Disco)
 Importance: Medium
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress

** Affects: systemd (Ubuntu Eoan)
 Importance: Medium
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress

** Affects: systemd (Ubuntu Focal)
 Importance: Medium
 Assignee: Dan Streetman (ddstreet)
 Status: In Progress


** Tags: ddstreet disco eoan focal sts systemd

** Also affects: systemd (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Description changed:

  [impact]
  
  for DNS UDP replies larger than 512 bytes, fallback to TCP is used.  For
  example 'host toomany.ddstreet.org'.
  
  Due to a bug in resolved in refcounting DNS stream types, the refcount
  underflows for type 0 streams (which resolved uses to talk to upstream
  nameservers), resulting in resolved being unable to fallback to TCP to
  handle truncated UDP replies.
  
  [test case]
  
  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org
  ;; Truncated, retrying in TCP mode.
  
  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0
  
  ;; QUESTION SECTION:
  ;toomany.ddstreet.org.IN  A
  
  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53)
  ;; WHEN: Thu Oct 24 11:40:29 UTC 2019
  ;; MSG SIZE  rcvd: 678
  
- ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches 
+ ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches
  ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org
  
  ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns 
toomany.ddstreet.org
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached
  
  [regression potential]
  
  very low, as this only properly sets the stream type in the DnsStream
  object; any regression would be a failure to be able to use TCP for DNS
  requests or replies.
  
  [other info]
  
  https://github.com/systemd/systemd/pull/13838
+ 
+ The commit adding stream types is not present in x/b, so this is needed
+ only for disco and later.

** Also affects: systemd (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Changed in: systemd (Ubuntu Disco)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Disco)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Eoan)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Eoan)
   Status: New => In Progress

** Changed in: systemd (Ubuntu Disco)
   Status: New => In Progress

** Changed in: systemd (Ubuntu Focal)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Focal)
   Status: New => In Progress

** Tags added: ddstreet disco eoan focal sts systemd

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded 

[Touch-packages] [Bug 1663679] Re: tracker-miner-fs assert failure: *** Error in `/usr/lib/tracker/tracker-miner-fs': double free or corruption (out): 0x000055c09c7eab30 ***

[Sebastien Bacher]

is that still an issue and if so could you describe how to trigger it?

** Changed in: tracker (Ubuntu)
   Status: Confirmed => Incomplete

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

Title:
  tracker-miner-fs assert failure: *** Error in `/usr/lib/tracker
  /tracker-miner-fs': double free or corruption (out):
  0x55c09c7eab30 ***

Status in tracker package in Ubuntu:
  Incomplete

Bug description:
  When I boot the computer

  ProblemType: Crash
  DistroRelease: Ubuntu 17.04
  Package: tracker-miner-fs 1.10.4-1ubuntu2
  ProcVersionSignature: Ubuntu 4.9.0-15.16-generic 4.9.5
  Uname: Linux 4.9.0-15-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.4-0ubuntu2
  Architecture: amd64
  AssertionMessage: *** Error in `/usr/lib/tracker/tracker-miner-fs': double 
free or corruption (out): 0x55c09c7eab30 ***
  CrashCounter: 1
  CurrentDesktop: GNOME
  Date: Fri Feb 10 18:36:26 2017
  ExecutablePath: /usr/lib/tracker/tracker-miner-fs
  InstallationDate: Installed on 2014-12-30 (772 days ago)
  InstallationMedia: Edubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.1)
  ProcCmdline: /usr/lib/tracker/tracker-miner-fs
  ProcEnviron:
   LANGUAGE=es_ES
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=es_ES.UTF-8
   SHELL=/bin/bash
  Signal: 6
  SourcePackage: tracker
  StacktraceTop:
   __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f561dd8c3a8 "*** 
Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
   malloc_printerr (ar_ptr=, ptr=, 
str=0x7f561dd8c4b8 "double free or corruption (out)", action=3) at malloc.c:5046
   _int_free (av=, p=, have_lock=) 
at malloc.c:3902
   __GI___libc_free (mem=) at malloc.c:2982
   g_pattern_match () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  Title: tracker-miner-fs assert failure: *** Error in 
`/usr/lib/tracker/tracker-miner-fs': double free or corruption (out): 
0x55c09c7eab30 ***
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm audio cdrom dialout dip epoptes fuse lpadmin mysql mythtv 
plugdev sambashare sudo vboxsf vboxusers video

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/1663679/+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 1230031] Re: Buy Tramadol Online Next Day Delivery

[gbkgjkbnkjb]

** Summary changed:

- dbus-daemon consumes 100% cpu without reason
+ Buy Tramadol Online Next Day Delivery

** Description changed:

+ Buy Tramadol Online Next Day Delivery
+ 
+ Safe and Secure Order Delivery
+ 
+ >>  http://yourchemiststore.net
+ 
+ Buy Tramadol Online
+ 
+ Buy Tramadol 100mg online
+ 
+ Buy Tramadol Online 200mg
+ 
+ Buy Tramadol 50mg
+ 
+ Buy Tramadol Online Legally
+ 
+ Buy Tramadol Online cheap
+ 
+ 
  Just login in to session, and dbus-daemon consumes 100% of cpu. Before,
  I did a login and logout. This problem appears randomly, not all the
  time.
  
-  9107 sergio20   0 30376 1660 1356 R 100,1  0,0  11:35.08 dbus-daemon 

  
- 11692 root  20   0  433m  54m  37m S   1,0  1,4   0:05.46 Xorg

  
- 12279 sergio20   0 1506m  78m  30m S   0,7  2,1   0:05.40 compiz  

  
- 12417 sergio20   0  553m  20m  11m S   0,7  0,6   0:00.93 gnome-terminal  

  
+  9107 sergio20   0 30376 1660 1356 R 100,1  0,0  11:35.08 dbus-daemon
+ 11692 root  20   0  433m  54m  37m S   1,0  1,4   0:05.46 Xorg
+ 12279 sergio20   0 1506m  78m  30m S   0,7  2,1   0:05.40 compiz
+ 12417 sergio20   0  553m  20m  11m S   0,7  0,6   0:00.93 gnome-terminal
  13757 sergio20   0  853m 160m  40m S   0,7  4,2   0:06.83 firefox
  
  See sensors, dbus-daemon is heating up my laptop:
  
  Adapter: Virtual device
  temp1:+68.0°C  (crit = +98.0°C)
  
  coretemp-isa-
  Adapter: ISA adapter
  Physical id 0:  +69.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 0: +49.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 1: +51.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 2: +69.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 3: +55.0°C  (high = +84.0°C, crit = +100.0°C)
  
  asus-isa-
  Adapter: ISA adapter
- temp1:   +6280.0°C  
+ temp1:   +6280.0°C
  
  pkg-temp-0-virtual-0
  Adapter: Virtual device
  temp1:+68.0°C
  
  ---
  
  Description:  Ubuntu Saucy Salamander (development branch)
  Release:  13.10
  Linux sergio-X751JB 3.11.0-8-generic #15-Ubuntu SMP Fri Sep 20 04:11:26 UTC 
2013 x86_64 x86_64 x86_64 GNU/Linux
  
  dbus:
-   Installed: 1.6.12-0ubuntu5
-   Candidate: 1.6.12-0ubuntu5
-   Version table:
-  *** 1.6.12-0ubuntu5 0
- 500 http://archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
- 100 /var/lib/dpkg/status
+   Installed: 1.6.12-0ubuntu5
+   Candidate: 1.6.12-0ubuntu5
+   Version table:
+  *** 1.6.12-0ubuntu5 0
+ 500 http://archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
+ 100 /var/lib/dpkg/status
  
  ProblemType: Bug
  DistroRelease: Ubuntu 13.10
  Package: dbus 1.6.12-0ubuntu5
  ProcVersionSignature: Ubuntu 3.11.0-8.15-generic 3.11.1
  Uname: Linux 3.11.0-8-generic x86_64
  ApportVersion: 2.12.4-0ubuntu1
  Architecture: amd64
  Date: Wed Sep 25 04:31:14 2013
  InstallationDate: Installed on 2013-09-20 (4 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130920)
  MarkForUpload: True
  SourcePackage: dbus
  UpgradeStatus: No upgrade log present (probably fresh install)

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

Title:
  Buy Tramadol Online Next Day Delivery

Status in dbus package in Ubuntu:
  Confirmed

Bug description:
  Buy Tramadol Online Next Day Delivery

  Safe and Secure Order Delivery

  >>  http://yourchemiststore.net

  Buy Tramadol Online

  Buy Tramadol 100mg online

  Buy Tramadol Online 200mg

  Buy Tramadol 50mg

  Buy Tramadol Online Legally

  Buy Tramadol Online cheap


  Just login in to session, and dbus-daemon consumes 100% of cpu.
  Before, I did a login and logout. This problem appears randomly, not
  all the time.

   9107 sergio20   0 30376 1660 1356 R 100,1  0,0  11:35.08 dbus-daemon
  11692 root  20   0  433m  54m  37m S   1,0  1,4   0:05.46 Xorg
  12279 sergio20   0 1506m  78m  30m S   0,7  2,1   0:05.40 compiz
  12417 sergio20   0  553m  20m  11m S   0,7  0,6   0:00.93 gnome-terminal
  13757 sergio20   0  853m 160m  40m S   0,7  4,2   0:06.83 firefox

  See sensors, dbus-daemon is heating up my laptop:

  Adapter: Virtual device
  temp1:+68.0°C  (crit = +98.0°C)

  coretemp-isa-
  Adapter: ISA adapter
  Physical id 0:  +69.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 0: +49.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 1: +51.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 2: +69.0°C  (high = +84.0°C, crit = +100.0°C)
  Core 3: +55.0°C  (high = +84.0°C, crit = 

[Touch-packages] [Bug 1849641] Re: New upstream release: bluez 5.51

[Daniel van Vugt]

** Attachment added: "bluez_5.51-0ubuntu1.debian.tar.xz"
   
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1849641/+attachment/5299667/+files/bluez_5.51-0ubuntu1.debian.tar.xz

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

Title:
  New upstream release: bluez 5.51

Status in bluez package in Ubuntu:
  In Progress

Bug description:
  New upstream release: bluez 5.51

  http://www.bluez.org/release-of-bluez-5-51/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1849641/+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 1849641] Re: New upstream release: bluez 5.51

[Daniel van Vugt]

** Attachment added: "bluez_5.51.orig.tar.xz"
   
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1849641/+attachment/5299666/+files/bluez_5.51.orig.tar.xz

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

Title:
  New upstream release: bluez 5.51

Status in bluez package in Ubuntu:
  In Progress

Bug description:
  New upstream release: bluez 5.51

  http://www.bluez.org/release-of-bluez-5-51/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1849641/+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 1849641] [NEW] New upstream release: bluez 5.51

[Daniel van Vugt]

Public bug reported:

New upstream release: bluez 5.51

http://www.bluez.org/release-of-bluez-5-51/

** Affects: bluez (Ubuntu)
 Importance: Medium
 Assignee: Daniel van Vugt (vanvugt)
 Status: In Progress


** Tags: focal

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

Title:
  New upstream release: bluez 5.51

Status in bluez package in Ubuntu:
  In Progress

Bug description:
  New upstream release: bluez 5.51

  http://www.bluez.org/release-of-bluez-5-51/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1849641/+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 1849641] Re: New upstream release: bluez 5.51

[Daniel van Vugt]

https://git.launchpad.net/~bluetooth/bluez/log/

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

Title:
  New upstream release: bluez 5.51

Status in bluez package in Ubuntu:
  In Progress

Bug description:
  New upstream release: bluez 5.51

  http://www.bluez.org/release-of-bluez-5-51/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1849641/+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 1834138] Re: PA: Don't restore the streams to sinks/sources with only unavailable ports

[Hui Wang]

Verification done on the Bionic, it fixed the problem.

On the lenovo P520, I installed OEM image (18.04), edit the 
/etc/apt/sources.list to add bionic-proposed repository, then run apt-get 
update abd sudo apt install pulseaudio, now the pulseaudio is:
ii pulseaudio 1:11.1-1ubuntu7.4 amd64 PulseAudio sound server
ii pulseaudio-utils 1:11.1-1ubuntu7.4 amd64 Command line tools for the 
PulseAudio sound server

recording: plug a mic into the front audio jack, and select it from
sound-setting, use arecord to record sound, after recording, unplug the
front mic and plug it to rear mic, use arecord to record sound again, it
still can record sound.

playback: plug a headphone to rear lineout and select lineout as output
device, then play sound via totem, after a while, close the totem and
unplug the rear lineout and plug the headphone to front headphone jack,
use totem to play sound, I can hear the sound from front headphone.


** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic

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

Title:
  PA: Don't restore the streams to sinks/sources with only unavailable
  ports

Status in HWE Next:
  New
Status in OEM Priority Project:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Bionic:
  Fix Committed
Status in pulseaudio source package in Disco:
  Fix Committed
Status in pulseaudio source package in Eoan:
  Fix Released

Bug description:
  SRU Document:

  [Impact]

  The Lenovo P520 machine has dual analogue codecs, so there are two
  sinks and two sources in the PA, one has the front headphone and front
  microphone, the other has the rear lineout, linein and rear
  microphone, and the rear microphone always shows up in the gnome-
  sound-setting, When we plug a microphone to front audio jack, there
  are two input devices: rear mic and front mic in the gnome-sound-
  setting, and suppose users select the the front mic to record sound
  via audio app like arecord, the front mic will be bond the arecord,
  after the front mic is unplugged, there is only one rear mic left in
  the gnome-sound-setting, but the binding will not be changed, the
  arecrod still bind to front mic, under this situation if users record
  sound via arecord, they will find they can't record any sound from any
  other input devices even they are listed in the gnome-sound-setting.
  This problem also happens to output devices too.

  [Test Case]

  After applying this patch, I did the same test: unplug the front mic,
  then use the arecord to record sound, the app can record sound from
  rear mic now. After I plug the front mic back, the arecord still
  record from front mic. Also did the similar test for output devices,
  it worked as expected too.

  [Regression Potential]

  Low, Just make a simple check when creating new streams
  (sink_input/source_output), If the restored device (sink/source) has
  ports and all ports are unavialble, it will not restore the binding,
  otherwise it will work as before.

  For the Bionic, This SRU also includes the fix of LP: #1556439, this
  fix is safe and is very low possible to introduce any regression too,
  because it just adds a sink-input/source-output state checking, if the
  sink-input/source-output is unlinking or unlinked, it is useless to
  move it to a new sink/source, furthermore it will trigger an assertion
  that make the pulseaudio crash, adding this check can fix this problem
  (LP: #1556439).

  [Other Info]

  No more info here

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1834138/+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 1748839] Re: Problem to connect to WPA2/PEAP WIFI - gnome-shell

[Solomon Nadar]

I have the problem despite I tried to forget the network and tried
connecting again.

snadar@ThinkPad-T480:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.3 LTS
Release:18.04
Codename:   bionic

snadar@ThinkPad-T480:~$ cat /var/log/syslog
Oct 24 11:18:04 ThinkPad-T480 wpa_supplicant[1205]: wlp3s0: 
CTRL-EVENT-SCAN-STARTED
Oct 24 11:18:07 ThinkPad-T480 NetworkManager[1173]:   [1571908687.5057] 
audit: op="connection-delete" uuid="36692638-6bb6-4bc7-8425-849f3cb9ff70" 
name="apname" pid=5766 uid=1000 result="success"
Oct 24 11:18:16 ThinkPad-T480 wpa_supplicant[1205]: wlp3s0: 
CTRL-EVENT-SCAN-STARTED
Oct 24 11:19:04 ThinkPad-T480 wpa_supplicant[1205]: message repeated 3 times: [ 
wlp3s0: CTRL-EVENT-SCAN-STARTED]
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.3918] 
keyfile: add connection in-memory 
(660e7552-b847-4063-803c-6de6da411f0b,"apname")
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.3936] 
device (wlp3s0): disconnecting for new activation request.
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.3936] 
device (wlp3s0): state change: activated -> deactivating (reason 
'new-activation', sys-iface-state: 'managed')
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4074] 
settings-connection[0x55affb554360,660e7552-b847-4063-803c-6de6da411f0b]: 
write: successfully commited (keyfile: update 
/etc/NetworkManager/system-connections/apname 
(660e7552-b847-4063-803c-6de6da411f0b,"apname") and persist connection)
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4075] 
audit: op="connection-add-activate" uuid="660e7552-b847-4063-803c-6de6da411f0b" 
name="apname" pid=5766 uid=1000 result="success"
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4169] 
device (wlp3s0): state change: deactivating -> disconnected (reason 
'new-activation', sys-iface-state: 'managed')
Oct 24 11:19:09 ThinkPad-T480 avahi-daemon[1120]: Withdrawing address record 
for fe80::5eb2:7428:835c:e20e on wlp3s0.
Oct 24 11:19:09 ThinkPad-T480 avahi-daemon[1120]: Leaving mDNS multicast group 
on interface wlp3s0.IPv6 with address fe80::5eb2:7428:835c:e20e.
Oct 24 11:19:09 ThinkPad-T480 avahi-daemon[1120]: Interface wlp3s0.IPv6 no 
longer relevant for mDNS.
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4505] 
dhcp4 (wlp3s0): canceled DHCP transaction, DHCP client pid 8389
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4505] 
dhcp4 (wlp3s0): state changed bound -> done
Oct 24 11:19:09 ThinkPad-T480 kernel: [ 3539.473650] wlp3s0: deauthenticating 
from a0:04:60:7c:6f:31 by local choice (Reason: 3=DEAUTH_LEAVING)
Oct 24 11:19:09 ThinkPad-T480 wpa_supplicant[1205]: wlp3s0: 
CTRL-EVENT-DISCONNECTED bssid=a0:04:60:7c:6f:31 reason=3 locally_generated=1
Oct 24 11:19:09 ThinkPad-T480 avahi-daemon[1120]: Withdrawing address record 
for 192.168.44.148 on wlp3s0.
Oct 24 11:19:09 ThinkPad-T480 avahi-daemon[1120]: Leaving mDNS multicast group 
on interface wlp3s0.IPv4 with address 192.168.44.148.
Oct 24 11:19:09 ThinkPad-T480 avahi-daemon[1120]: Interface wlp3s0.IPv4 no 
longer relevant for mDNS.
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4654] 
device (wlp3s0): Activation: starting connection 'apname' 
(660e7552-b847-4063-803c-6de6da411f0b)
Oct 24 11:19:09 ThinkPad-T480 dbus-daemon[1139]: [system] Activating via 
systemd: service name='org.freedesktop.nm_dispatcher' 
unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.11' (uid=0 
pid=1173 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Oct 24 11:19:09 ThinkPad-T480 systemd[1]: Starting Network Manager Script 
Dispatcher Service...
Oct 24 11:19:09 ThinkPad-T480 wpa_supplicant[1205]: wlp3s0: 
CTRL-EVENT-SCAN-STARTED
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4701] 
sup-iface[0x55affb6bc0d0,wlp3s0]: connection disconnected (reason -3)
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4702] 
device (wlp3s0): supplicant interface state: completed -> disconnected
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4705] 
sup-iface[0x55affb6bc0d0,wlp3s0]: connection disconnected (reason -3)
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4720] 
device (wlp3s0): state change: disconnected -> prepare (reason 'none', 
sys-iface-state: 'managed')
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4728] 
device (wlp3s0): state change: prepare -> config (reason 'none', 
sys-iface-state: 'managed')
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4730] 
device (wlp3s0): Activation: (wifi) access point 'apname' has security, but 
secrets are required.
Oct 24 11:19:09 ThinkPad-T480 NetworkManager[1173]:   [1571908749.4730] 
device (wlp3s0): state change: config -> need-auth (reason 'none', 
sys-iface-state: 'managed')
Oct 24 11:19:09 ThinkPad-T480 

[Touch-packages] [Bug 1849559] Re: /etc/dbus-1/system.d/wpa_supplicant.conf is in wrong location

[Sebastien Bacher]

That's coming from upstream/Debian, would be worth reporting to them
since that's probably not something we want to carry as an Ubuntu delta
right?

** Changed in: wpa (Ubuntu)
   Importance: Undecided => Low

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

Title:
  /etc/dbus-1/system.d/wpa_supplicant.conf is in wrong location

Status in wpa package in Ubuntu:
  New

Bug description:
  The /etc/dbus-1/system.d/wpa_supplicant.conf is installed in the wrong
  location. It is a system-wide default config for dbus, and as such
  probably should be in /usr/share/dbus-1/system.d instead; like most
  other DBus definitions installed on a typical system.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1849559/+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 1849608] Re: systemd resolv should separate the output of stdout and stderr

[Ubuntu Foundations Team Bug Bot]

The attachment "resolved.patch" seems to be a patch.  If it isn't,
please remove the "patch" flag from the attachment, remove the "patch"
tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the
team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issues please contact him.]

** Tags added: patch

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

Title:
  systemd resolv should separate the output of stdout and stderr

Status in systemd package in Ubuntu:
  New

Bug description:
  The file /etc/dhcp/dhclient-enter-hooks.d/resolved
  provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
  This issue can be reproduced on Ubuntu Eoan:
  ==
  root@eoan:~# dhclient -v 
  Internet Systems Consortium DHCP Client 4.4.1
  Copyright 2004-2018 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens224/00:0c:29:92:d4:da
  Sending on   LPF/ens224/00:0c:29:92:d4:da
  Listening on LPF/ens192/00:0c:29:92:d4:d0
  Sending on   LPF/ens192/00:0c:29:92:d4:d0
  Listening on LPF/ens160/00:0c:29:92:d4:c6
  Sending on   LPF/ens160/00:0c:29:92:d4:c6
  Sending on   Socket/fallback
  DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
  DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
  DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 
(xid=0x6d39545d)
  DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d)
  RTNETLINK answers: File exists
  d41d8cd98f00b204e9800998ecf8427e  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  5025823d750dda1f3f15e306c4a0afce  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  bound to 192.168.120.4 -- renewal in 111 seconds.
  root@eoan:~# resolvectl status |grep DNS
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  ==

  Attached please find the patch for this. The output for md5sum in the
  hook file resolv should separate the stdout and stderr so it won't
  compare the wrong data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849608/+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 1827842] Re: pulseaudio should not load module-x11-bell in gnome-shell

[Sebastien Bacher]

1:12.2-2ubuntu3.1 is working fine and not creating regressions, even if
the bug seems to not happen on every install which makes the fix harder
to verify the change is right on principle, marking as verified

** Tags removed: removal-candidate verification-needed verification-needed-disco
** Tags added: verification-done verification-done-disco

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

Title:
  pulseaudio should not load module-x11-bell in gnome-shell

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Disco:
  Fix Committed

Bug description:
  * Impact
  The package force load a bell sound which can conflicts with the user 
configuration

  * Test case
  - Enable a login sound in session
  - Login into a GNOME/Ubuntu session
  -> the configured sound should be played

  * Regression potential
  Try other desktop environments to make sure their login sound behaviour isn't 
changed, it shouldn't since the customization dropped was specific to the 
Ubuntu sound theme

  ---

  The package `pulseaudio` installs a startup script in 
`/etc/xdg/autostart/pulseaudio.desktop`,
  which itself runs `/usr/bin/start-pulseaudio-x11`,
  which loads a number of x11 related modules in `pulseaudio`.

  One of these modules is `module-x11-bell`,
  which makes `pulseaudio` play a sound each time a system bell is emitted
  (usually by terminal applications, such as bash or vim).

  This is redundant with gnome-shell, which is also able to handle the system 
bell
  (through the gsetting key `org.gnome.desktop.sound event-sounds`).

  The gnome system bell is directly configurable by the user (Settings > Sound),
  so it should be preferred over pulseaudio's own system bell.

  I suggest to patch the `/usr/bin/start-pulseaudio-x11`,
  to avoid loading `start-pulseaudio-x11` if it detects it is running in Gnome 
Shell
  (e.g. if GNOME_SHELL_SESSION_MODE is set).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1827842/+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 1804280] Re: intermittent periods of packet loss and high latency

[Andrew]

At one point in my in-home streaming past I had to set the BSSID to my
current router's IP address which resolved latency problems. I have
multiple routers on my property with the same SSID, this is to provide
wifi coverage to the entire property. I had to change the BSSID to the
router I was using at any given time. Hopefully this is useful in some
way.

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

Title:
  intermittent periods of packet loss and high latency

Status in linux package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  Intermittently and unpredictably, ping response times and packet loss
  will spike to unusable levels.  Normal ping times are about .25 ms for
  other hosts on the local network, with essentially no packet loss.
  During the problematic periods (usually lasting 2-10 minutes), packet
  loss jumps to about 50% and ping response times on the packets that
  aren't dropped jump to between 250 and 750 ms.

  This behavior started when I upgraded from Kubuntu 16.04 to Kubuntu
  18.04.  Changing which host on the network I test this with has no
  effect (and during this, those other hosts are able to use the network
  without any problem).  Replacing the cable changes nothing.  Using a
  different Ethernet interface changes nothing.  Replacing the switch
  changes nothing.  This is almost certainly not a hardware problem.

  There is a chance that using wireless instead of Ethernet would fix
  the issue, but I have been avoiding that since the wired connection is
  much faster when Kubuntu is not malfunctioning.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: network-manager 1.10.6-2ubuntu1.1
  ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18
  Uname: Linux 4.15.0-39-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Tue Nov 20 12:48:05 2018
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2016-12-09 (711 days ago)
  InstallationMedia: Kubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  IpRoute:
   default via [removed] dev enp0s31f6 proto dhcp metric 100
   169.254.0.0/16 dev enp0s31f6 scope link metric 1000
   [removed]/24 dev enp0s31f6 proto kernel scope link src [removed] metric 100
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to bionic on 2018-08-19 (92 days ago)
  nmcli-dev:
   DEVICE TYPE  STATE DBUS-PATH 
 CONNECTION  CON-UUID  CON-PATH
   enp0s31f6  ethernet  connected 
/org/freedesktop/NetworkManager/Devices/2  Wired connection 1  
2e0d0ce3-8ee2-3c06-815d-eb9a42873b3b  
/org/freedesktop/NetworkManager/ActiveConnection/5
   [removed]  btdisconnected  /org/freedesktop/NetworkManager/Devices/5 
 --  ----
   wlp3s0 wifi  disconnected  
/org/freedesktop/NetworkManager/Devices/4  --  --   
 --
   lo loopback  unmanaged 
/org/freedesktop/NetworkManager/Devices/1  --  --   
 --
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.10.6   connected  started  full  enabled enabled  
enabled  enabled  enabled
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  dan2053 F pulseaudio
   /dev/snd/pcmC1D0c:   dan2053 F...m pulseaudio
   /dev/snd/controlC1:  dan2053 F pulseaudio
  CurrentDesktop: KDE
  DistroRelease: Ubuntu 18.04
  HibernationDevice: RESUME=UUID=4eadd7fe-e046-471d-b0ee-f1c85365411e
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2016-12-09 (712 days ago)
  InstallationMedia: Kubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  IpRoute:
   default via 192.168.4.1 dev enp0s31f6 proto dhcp metric 100 
   169.254.0.0/16 dev enp0s31f6 scope link metric 1000 
   192.168.4.0/24 dev enp0s31f6 proto kernel scope link src 192.168.4.42 metric 
100
  MachineType: Dell Inc. Precision Tower 3420
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  Package: network-manager 1.10.6-2ubuntu1.1
  PackageArchitecture: amd64
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-39-generic 

[Touch-packages] [Bug 1804280] Re: intermittent periods of packet loss and high latency

[Andrew]

I'm also affected by this bug. I'm using Wireless AC 5ghz on an Acer
Spin 5 which apparently uses the Ath10k drivers if that's relevant.
Ubuntu 18.04 is the most recent version of Ubuntu that I've confirmed to
not be affected by this bug. I have tested every release thereafter
(18.10, 19.04, 19.10) and every one of them has the "bouts of high
latency" bug. I wrote a more detailed description of what I experience
on Ask Ubuntu: https://askubuntu.com/questions/1144521/bouts-of-high-
latency-over-wifi-with-steam-in-home-streaming

** Attachment added: "Graph showing bout of high latency"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1804280/+attachment/5299640/+files/Screenshot%20from%202019-10-24%2008-20-02.png

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

Title:
  intermittent periods of packet loss and high latency

Status in linux package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  Intermittently and unpredictably, ping response times and packet loss
  will spike to unusable levels.  Normal ping times are about .25 ms for
  other hosts on the local network, with essentially no packet loss.
  During the problematic periods (usually lasting 2-10 minutes), packet
  loss jumps to about 50% and ping response times on the packets that
  aren't dropped jump to between 250 and 750 ms.

  This behavior started when I upgraded from Kubuntu 16.04 to Kubuntu
  18.04.  Changing which host on the network I test this with has no
  effect (and during this, those other hosts are able to use the network
  without any problem).  Replacing the cable changes nothing.  Using a
  different Ethernet interface changes nothing.  Replacing the switch
  changes nothing.  This is almost certainly not a hardware problem.

  There is a chance that using wireless instead of Ethernet would fix
  the issue, but I have been avoiding that since the wired connection is
  much faster when Kubuntu is not malfunctioning.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: network-manager 1.10.6-2ubuntu1.1
  ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18
  Uname: Linux 4.15.0-39-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Tue Nov 20 12:48:05 2018
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2016-12-09 (711 days ago)
  InstallationMedia: Kubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  IpRoute:
   default via [removed] dev enp0s31f6 proto dhcp metric 100
   169.254.0.0/16 dev enp0s31f6 scope link metric 1000
   [removed]/24 dev enp0s31f6 proto kernel scope link src [removed] metric 100
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to bionic on 2018-08-19 (92 days ago)
  nmcli-dev:
   DEVICE TYPE  STATE DBUS-PATH 
 CONNECTION  CON-UUID  CON-PATH
   enp0s31f6  ethernet  connected 
/org/freedesktop/NetworkManager/Devices/2  Wired connection 1  
2e0d0ce3-8ee2-3c06-815d-eb9a42873b3b  
/org/freedesktop/NetworkManager/ActiveConnection/5
   [removed]  btdisconnected  /org/freedesktop/NetworkManager/Devices/5 
 --  ----
   wlp3s0 wifi  disconnected  
/org/freedesktop/NetworkManager/Devices/4  --  --   
 --
   lo loopback  unmanaged 
/org/freedesktop/NetworkManager/Devices/1  --  --   
 --
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.10.6   connected  started  full  enabled enabled  
enabled  enabled  enabled
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  dan2053 F pulseaudio
   /dev/snd/pcmC1D0c:   dan2053 F...m pulseaudio
   /dev/snd/controlC1:  dan2053 F pulseaudio
  CurrentDesktop: KDE
  DistroRelease: Ubuntu 18.04
  HibernationDevice: RESUME=UUID=4eadd7fe-e046-471d-b0ee-f1c85365411e
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2016-12-09 (712 days ago)
  InstallationMedia: Kubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  IpRoute:
   default via 192.168.4.1 dev enp0s31f6 proto dhcp metric 100 
   169.254.0.0/16 dev enp0s31f6 scope link metric 1000 
   192.168.4.0/24 dev enp0s31f6 proto kernel scope link src 

[Touch-packages] [Bug 1849608] Re: systemd resolv should separate the output of stdout and stderr

[Steven Shiau]

BTW, forgot to mention, after applying the patch in my system, I have to
reboot the system then run "dhclient -v" so that the stale status of
previous dhclient won't  confuse it.

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

Title:
  systemd resolv should separate the output of stdout and stderr

Status in systemd package in Ubuntu:
  New

Bug description:
  The file /etc/dhcp/dhclient-enter-hooks.d/resolved
  provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
  This issue can be reproduced on Ubuntu Eoan:
  ==
  root@eoan:~# dhclient -v 
  Internet Systems Consortium DHCP Client 4.4.1
  Copyright 2004-2018 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens224/00:0c:29:92:d4:da
  Sending on   LPF/ens224/00:0c:29:92:d4:da
  Listening on LPF/ens192/00:0c:29:92:d4:d0
  Sending on   LPF/ens192/00:0c:29:92:d4:d0
  Listening on LPF/ens160/00:0c:29:92:d4:c6
  Sending on   LPF/ens160/00:0c:29:92:d4:c6
  Sending on   Socket/fallback
  DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
  DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
  DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 
(xid=0x6d39545d)
  DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d)
  RTNETLINK answers: File exists
  d41d8cd98f00b204e9800998ecf8427e  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  5025823d750dda1f3f15e306c4a0afce  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  bound to 192.168.120.4 -- renewal in 111 seconds.
  root@eoan:~# resolvectl status |grep DNS
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  ==

  Attached please find the patch for this. The output for md5sum in the
  hook file resolv should separate the stdout and stderr so it won't
  compare the wrong data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849608/+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 1849608] [NEW] systemd resolv should separate the output of stdout and stderr

[Steven Shiau]

Public bug reported:

The file /etc/dhcp/dhclient-enter-hooks.d/resolved
provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
This issue can be reproduced on Ubuntu Eoan:
==
root@eoan:~# dhclient -v 
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/ens224/00:0c:29:92:d4:da
Sending on   LPF/ens224/00:0c:29:92:d4:da
Listening on LPF/ens192/00:0c:29:92:d4:d0
Sending on   LPF/ens192/00:0c:29:92:d4:d0
Listening on LPF/ens160/00:0c:29:92:d4:c6
Sending on   LPF/ens160/00:0c:29:92:d4:c6
Sending on   Socket/fallback
DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 
(xid=0x6d39545d)
DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d)
RTNETLINK answers: File exists
d41d8cd98f00b204e9800998ecf8427e  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
5025823d750dda1f3f15e306c4a0afce  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
bound to 192.168.120.4 -- renewal in 111 seconds.
root@eoan:~# resolvectl status |grep DNS
MulticastDNS setting: no
  DNSOverTLS setting: no
  DNSSEC setting: no
DNSSEC supported: no
  DNSSEC NTA: 10.in-addr.arpa
MulticastDNS setting: no
  DNSOverTLS setting: no
  DNSSEC setting: no
DNSSEC supported: no
MulticastDNS setting: no
  DNSOverTLS setting: no
  DNSSEC setting: no
DNSSEC supported: no
MulticastDNS setting: no
  DNSOverTLS setting: no
  DNSSEC setting: no
DNSSEC supported: no
==

Attached please find the patch for this. The output for md5sum in the
hook file resolv should separate the stdout and stderr so it won't
compare the wrong data.

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

** Patch added: "resolved.patch"
   
https://bugs.launchpad.net/bugs/1849608/+attachment/5299633/+files/resolved.patch

** Package changed: grub-efi-amd64-signed (Ubuntu) => systemd (Ubuntu)

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

Title:
  systemd resolv should separate the output of stdout and stderr

Status in systemd package in Ubuntu:
  New

Bug description:
  The file /etc/dhcp/dhclient-enter-hooks.d/resolved
  provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
  This issue can be reproduced on Ubuntu Eoan:
  ==
  root@eoan:~# dhclient -v 
  Internet Systems Consortium DHCP Client 4.4.1
  Copyright 2004-2018 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens224/00:0c:29:92:d4:da
  Sending on   LPF/ens224/00:0c:29:92:d4:da
  Listening on LPF/ens192/00:0c:29:92:d4:d0
  Sending on   LPF/ens192/00:0c:29:92:d4:d0
  Listening on LPF/ens160/00:0c:29:92:d4:c6
  Sending on   LPF/ens160/00:0c:29:92:d4:c6
  Sending on   Socket/fallback
  DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
  DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
  DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 
(xid=0x6d39545d)
  DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d)
  RTNETLINK answers: File exists
  d41d8cd98f00b204e9800998ecf8427e  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  5025823d750dda1f3f15e306c4a0afce  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
  bound to 192.168.120.4 -- renewal in 111 seconds.
  root@eoan:~# resolvectl status |grep DNS
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
  ==

  Attached please find the patch for this. The output for md5sum in the
  hook file resolv should separate the stdout and stderr so it won't
  compare the wrong data.

To manage notifications about 

[Touch-packages] [Bug 1849608] [NEW] systemd resolv should separate the output of stdout and stderr

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

The file /etc/dhcp/dhclient-enter-hooks.d/resolved
provided by systemd (242-7ubuntu3) causes the dhclient failing to get DNS due 
to systemd-resolved is not run.
This issue can be reproduced on Ubuntu Eoan:
==
root@eoan:~# dhclient -v 
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/ens224/00:0c:29:92:d4:da
Sending on   LPF/ens224/00:0c:29:92:d4:da
Listening on LPF/ens192/00:0c:29:92:d4:d0
Sending on   LPF/ens192/00:0c:29:92:d4:d0
Listening on LPF/ens160/00:0c:29:92:d4:c6
Sending on   LPF/ens160/00:0c:29:92:d4:c6
Sending on   Socket/fallback
DHCPDISCOVER on ens224 to 255.255.255.255 port 67 interval 3 (xid=0x6d9fb33d)
DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 3 (xid=0xeb8fda26)
DHCPREQUEST for 192.168.120.4 on ens160 to 255.255.255.255 port 67 
(xid=0x6d39545d)
DHCPACK of 192.168.120.4 from 192.168.120.254 (xid=0x5d54396d)
RTNETLINK answers: File exists
d41d8cd98f00b204e9800998ecf8427e  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
5025823d750dda1f3f15e306c4a0afce  
/run/systemd/resolved.conf.d/isc-dhcp-v4-ens160.conf
md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-ens160.conf: No such file or 
directory
bound to 192.168.120.4 -- renewal in 111 seconds.
root@eoan:~# resolvectl status |grep DNS
MulticastDNS setting: no
  DNSOverTLS setting: no
  DNSSEC setting: no
DNSSEC supported: no
  DNSSEC NTA: 10.in-addr.arpa
MulticastDNS setting: no
  DNSOverTLS setting: no
  DNSSEC setting: no
DNSSEC supported: no
MulticastDNS setting: no
  DNSOverTLS setting: no
  DNSSEC setting: no
DNSSEC supported: no
MulticastDNS setting: no
  DNSOverTLS setting: no
  DNSSEC setting: no
DNSSEC supported: no
==

Attached please find the patch for this. The output for md5sum in the
hook file resolv should separate the stdout and stderr so it won't
compare the wrong data.

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

-- 
systemd resolv should separate the output of stdout and stderr
https://bugs.launchpad.net/bugs/1849608
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to systemd in Ubuntu.

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

Re: [Touch-packages] [Bug 1849399] Re: ibus in 19.10 misinterprets ~/.XCompose, somehow maps to the Delete key

[Steve Langasek]

On Thu, Oct 24, 2019 at 12:06:38AM -, Gunnar Hjalmarsson wrote:
> On 2019-10-24 00:56, Steve Langasek wrote:
> > Contents of the file are:

> > include "/usr/share/X11/locale/en_US.UTF-8/Compose"
> > <\> <)> : "☭"   # HAMMER AND SICKLE

> Hmm.. Looking at  and
> wondering if that line shouldn't rather read something like this:

> : "☭"   # HAMMER AND SICKLE

> (which works with IBus provided that there is a defined compose key)

Sure, this is a valid alternative, and just replacing the <\> with
 is enough to unbreak my Delete key.  (I don't care about whether
it causes the compose sequence to work, I clearly forgot I had ever even
configured this!)

> Even if there was a regression due to the 1.5.19 -> 1.5.21 upgrade of
> ibus

> * the changed behavior is upstream in nature

> * a possible upstream issue would basically say: "Why does IBus no
>   longer interpret my syntactically incorrect ~/.XCompose file in
>   accordance with my intention?"

IBus does not define the syntax of .XCompose, and this file is an interface.
It is not for ibus to retroactively declare the file to be "syntactically
incorrect"; and regardless, if it has decided that the file is syntactically
incorrect, this should not result in changes to the behavior of an unrelated
key.

> So I tend to think that this bug should be closed as invalid, unless you
> have some convincing arguments for keeping it open. Your call. :)

It is absolutely not invalid.  I accept that it's not a high priority, but
it remains the case that ibus is interpreting ~/.XCompose in a way that is
inconsistent with how X itself does so.

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

Title:
  ibus in 19.10 misinterprets ~/.XCompose, somehow maps to the Delete
  key

Status in ibus package in Ubuntu:
  Triaged

Bug description:
  After upgrade to 19.10, I found that my Delete key was not working as
  a Delete key, but that instead if I hit Delete twice it would print
  the character ☭.

  Since others were not reporting this issue, I had a look around at my
  input config and remembered that I had ibus configured from a long
  time ago in order to support Chinese input.

  If I disable ibus (either by unsetting the environment variables; or
  by killing ibus-daemon), then the Delete key works again as expected.

  This is a regression in behavior since Ubuntu 19.04, where I had the
  same input setup on my desktop but the Delete key worked without
  problems.

  I'm also not sure how to disable ibus, now that I am in this
  situation; or if ibus is expected to always be running.

  The problem persists if I run ibus-setup and remove Chinese SunPinyin
  from the list of input methods, leaving only "English - English (US)".

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1849399/+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