date:20190118

First of all, I apologise for the delay.

Given what upstream, below, answered, I am closing this bug WONTFIX.
Please contact Coreutils upstream at coreut...@gnu.org for more details.

In general, changes to Coreutils code should be submitted upstream.
Distro-wise, we very rarely deviate from upstream (and, for Coreutils
and many of the Ubuntu packages, from Debian).

Cheers,

-- email from upstream --

Hello,

On 2018-12-28 11:21 a.m., C de-Avillez wrote:
> We have had some bugs reported recently at our BTS:
> 
> https://bugs.launchpad.net/bugs/1807295
> https://bugs.launchpad.net/bugs/1807797
> https://bugs.launchpad.net/bugs/1808092
> https://bugs.launchpad.net/bugs/1808095
> 
> They deal with sort, split, fmt, and uniq, respectively, and provide
> tentative patches.

A summary other mailing-list readers:

The "filetype" in question is regular files vs fifo / char devices / 
block /devices.

The four requests all say something like:

==

"Sort like many other applications does not check for file types of the 
inputs that are passed in as arguments. [...] For example, sorting files 
that of type block/character/fifo does not make much sense as it will 
just hang or use up all cpu cycles. "

==

> I would like to re-direct the reporters to upstream (i.e., you folks),
> but I feel it would be nice to do the redirect with a small blurb of
> what upstream thinks about that.

First and foremost,
I think these are not bugs, and this is perfectly valid behavior.
If a user wants to process a non-regular file, they can do so.

The reasoning of "wasting" CPU/memory can be just as valid to
processing arbitrary large binary files.

---

Also,
Few observations:
1. These four issues were reported by different people (all new 
LaunchPad users), during very short time period (second week of
december).

2. Three out of the four link to this
document, which explains about different file types as part of what
looks like a sys-call exerciser:
https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md

3. The above document mention but does not explain what "S_IFSOCK" is,
and (perhaps as a result) none of their patches deals with S_IFSOCK
(despite that everything said about char-devices and fifos applies
to sockets as well).

4. Rejecting FIFOs as input indicates the submitters have some lack of
familiarity with unix command-line.

Given all the above,
I suspect this is part of a homework exercise given to students at some
college, perhaps something like "find bugs in an free software project
and submit a patch to them".

While good intentioned, these suggestions should be rejected as
"wontfix".

For any students or potential contributers who want to start working on
GNU coreutils - PLEASE write to coreut...@gnu.org and introduce
yourself, and we will easily provide ideas on useful contributions
that would be accepted.

Of course, the above is just my opinion, and others are welcomed
to chime in.

regards,
  - assaf

** Changed in: coreutils (Ubuntu)
   Status: New => Won't Fix

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

Title:
  Split doesn't check for filetype

Status in coreutils package in Ubuntu:
  Won't Fix

Bug description:
  Hello! I noticed that Split doesn't check for filetypes before it
  starts splitting the file. As a result, it's possible to eat up CPU
  and Disk memory by passing in a character device as input. I wanted to
  make Split  more robust by adding a patch to check for file type.

  This patch do break some of the tests for Split. The tests that are
  checking Split's ability to "elide empty files" by using /dev/null as
  input fail with this patch, since /dev/null is a character device. I
  would love to modify those tests to use a regular empty file, upon the
  approval of this patch.

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1807797/+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 1807295] Re: Sort - Checking & Handling File Types

First of all, I apologise for the delay.

Given what upstream, below, answered, I am closing this bug WONTFIX.
Please contact Coreutils upstream at coreut...@gnu.org for more details.

In general, changes to Coreutils code should be submitted upstream.
Distro-wise, we very rarely deviate from upstream (and, for Coreutils
and many of the Ubuntu packages, from Debian).

Cheers,

-- email from upstream --

Hello,

On 2018-12-28 11:21 a.m., C de-Avillez wrote:
> We have had some bugs reported recently at our BTS:
> 
> https://bugs.launchpad.net/bugs/1807295
> https://bugs.launchpad.net/bugs/1807797
> https://bugs.launchpad.net/bugs/1808092
> https://bugs.launchpad.net/bugs/1808095
> 
> They deal with sort, split, fmt, and uniq, respectively, and provide
> tentative patches.

A summary other mailing-list readers:

The "filetype" in question is regular files vs fifo / char devices / 
block /devices.

The four requests all say something like:

==

"Sort like many other applications does not check for file types of the 
inputs that are passed in as arguments. [...] For example, sorting files 
that of type block/character/fifo does not make much sense as it will 
just hang or use up all cpu cycles. "

==

> I would like to re-direct the reporters to upstream (i.e., you folks),
> but I feel it would be nice to do the redirect with a small blurb of
> what upstream thinks about that.

First and foremost,
I think these are not bugs, and this is perfectly valid behavior.
If a user wants to process a non-regular file, they can do so.

The reasoning of "wasting" CPU/memory can be just as valid to
processing arbitrary large binary files.

---

Also,
Few observations:
1. These four issues were reported by different people (all new 
LaunchPad users), during very short time period (second week of
december).

2. Three out of the four link to this
document, which explains about different file types as part of what
looks like a sys-call exerciser:
https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md

3. The above document mention but does not explain what "S_IFSOCK" is,
and (perhaps as a result) none of their patches deals with S_IFSOCK
(despite that everything said about char-devices and fifos applies
to sockets as well).

4. Rejecting FIFOs as input indicates the submitters have some lack of
familiarity with unix command-line.

Given all the above,
I suspect this is part of a homework exercise given to students at some
college, perhaps something like "find bugs in an free software project
and submit a patch to them".

While good intentioned, these suggestions should be rejected as
"wontfix".

For any students or potential contributers who want to start working on
GNU coreutils - PLEASE write to coreut...@gnu.org and introduce
yourself, and we will easily provide ideas on useful contributions
that would be accepted.

Of course, the above is just my opinion, and others are welcomed
to chime in.

regards,
  - assaf

** Changed in: coreutils (Ubuntu)
   Status: New => Won't Fix

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

Title:
  Sort - Checking & Handling File Types

Status in coreutils package in Ubuntu:
  Won't Fix

Bug description:
  I am not completely sure if you would consider this a bug or not. Sort
  like many other applications does not check for file types of the
  inputs that are passed in as arguments. Any case, I wanted to
  entertain the idea of checking file types
  (https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md).
  For example, sorting files that of type block/character/fifo does not
  make much sense as it will just hang or use up all cpu cycles. The
  best implementation of file type checking is in the coreutils
  application mv (copy.c).

  I have included a patch that adds file type check for the types
  mentioned above. Any input or criticism is highly appreciated. I would
  be happy to look an an alternative option or otherwise.

  Thanks!
  Amit
  abis...@nyu.edu

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1807295/+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 1808092] Re: Checking and handling various filetypes in fmt

First of all, I apologise for the delay.

Given what upstream, below, answered, I am closing this bug WONTFIX.
Please contact Coreutils upstream at coreut...@gnu.org for more details.

In general, changes to Coreutils code should be submitted upstream.
Distro-wise, we very rarely deviate from upstream (and, for Coreutils
and many of the Ubuntu packages, from Debian).

Cheers,

-- email from upstream --

Hello,

On 2018-12-28 11:21 a.m., C de-Avillez wrote:
> We have had some bugs reported recently at our BTS:
> 
> https://bugs.launchpad.net/bugs/1807295
> https://bugs.launchpad.net/bugs/1807797
> https://bugs.launchpad.net/bugs/1808092
> https://bugs.launchpad.net/bugs/1808095
> 
> They deal with sort, split, fmt, and uniq, respectively, and provide
> tentative patches.

A summary other mailing-list readers:

The "filetype" in question is regular files vs fifo / char devices / 
block /devices.

The four requests all say something like:

==

"Sort like many other applications does not check for file types of the 
inputs that are passed in as arguments. [...] For example, sorting files 
that of type block/character/fifo does not make much sense as it will 
just hang or use up all cpu cycles. "

==

> I would like to re-direct the reporters to upstream (i.e., you folks),
> but I feel it would be nice to do the redirect with a small blurb of
> what upstream thinks about that.

First and foremost,
I think these are not bugs, and this is perfectly valid behavior.
If a user wants to process a non-regular file, they can do so.

The reasoning of "wasting" CPU/memory can be just as valid to
processing arbitrary large binary files.

---

Also,
Few observations:
1. These four issues were reported by different people (all new 
LaunchPad users), during very short time period (second week of
december).

2. Three out of the four link to this
document, which explains about different file types as part of what
looks like a sys-call exerciser:
https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md

3. The above document mention but does not explain what "S_IFSOCK" is,
and (perhaps as a result) none of their patches deals with S_IFSOCK
(despite that everything said about char-devices and fifos applies
to sockets as well).

4. Rejecting FIFOs as input indicates the submitters have some lack of
familiarity with unix command-line.

Given all the above,
I suspect this is part of a homework exercise given to students at some
college, perhaps something like "find bugs in an free software project
and submit a patch to them".

While good intentioned, these suggestions should be rejected as
"wontfix".

For any students or potential contributers who want to start working on
GNU coreutils - PLEASE write to coreut...@gnu.org and introduce
yourself, and we will easily provide ideas on useful contributions
that would be accepted.

Of course, the above is just my opinion, and others are welcomed
to chime in.

regards,
  - assaf

** Changed in: coreutils (Ubuntu)
   Status: New => Won't Fix

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

Title:
  Checking and handling various filetypes in fmt

Status in coreutils package in Ubuntu:
  Won't Fix

Bug description:
  fmt doesn't check filetypes of the input arguments passed to it, it
  just opens the file and reads from it without checking its st_mode. It
  only throws an error if the file doesn't exist and can't handle the
  following filetypes - S_IFCHR, S_IFBLK and S_IFBLK. Passing a file
  from any of these types will possibly hang or crash the application.

  For more reference, please visit the below link-
  (https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md)

  I have attached a patch that checks for the above mentioned filetypes and 
handles them accordingly.
  Please let me know if you have any questions or suggestions regarding this, 
will be happy to answer them.

  Thank you
  Snahil Singh
  ss11...@nyu.edu

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: coreutils 8.28-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18
  Uname: Linux 4.15.0-39-generic i686
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: i386
  CurrentDesktop: XFCE
  Date: Tue Dec 11 20:01:58 2018
  ExecutablePath: /usr/bin/fmt
  InstallationDate: Installed on 2018-11-07 (35 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release i386 (20180426)
  SourcePackage: coreutils
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1808092/+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 1808095] Re: uniq is not checking and handling all file types

First of all, I apologise for the delay.

Given what upstream, below, answered, I am closing this bug WONTFIX.
Please contact Coreutils upstream at coreut...@gnu.org for more details.

In general, changes to Coreutils code should be submitted upstream.
Distro-wise, we very rarely deviate from upstream (and, for Coreutils
and many of the Ubuntu packages, from Debian).

Cheers,

-- email from upstream --

Hello,

On 2018-12-28 11:21 a.m., C de-Avillez wrote:
> We have had some bugs reported recently at our BTS:
> 
> https://bugs.launchpad.net/bugs/1807295
> https://bugs.launchpad.net/bugs/1807797
> https://bugs.launchpad.net/bugs/1808092
> https://bugs.launchpad.net/bugs/1808095
> 
> They deal with sort, split, fmt, and uniq, respectively, and provide
> tentative patches.

A summary other mailing-list readers:

The "filetype" in question is regular files vs fifo / char devices / 
block /devices.

The four requests all say something like:

==

"Sort like many other applications does not check for file types of the 
inputs that are passed in as arguments. [...] For example, sorting files 
that of type block/character/fifo does not make much sense as it will 
just hang or use up all cpu cycles. "

==

> I would like to re-direct the reporters to upstream (i.e., you folks),
> but I feel it would be nice to do the redirect with a small blurb of
> what upstream thinks about that.

First and foremost,
I think these are not bugs, and this is perfectly valid behavior.
If a user wants to process a non-regular file, they can do so.

The reasoning of "wasting" CPU/memory can be just as valid to
processing arbitrary large binary files.

---

Also,
Few observations:
1. These four issues were reported by different people (all new 
LaunchPad users), during very short time period (second week of
december).

2. Three out of the four link to this
document, which explains about different file types as part of what
looks like a sys-call exerciser:
https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md

3. The above document mention but does not explain what "S_IFSOCK" is,
and (perhaps as a result) none of their patches deals with S_IFSOCK
(despite that everything said about char-devices and fifos applies
to sockets as well).

4. Rejecting FIFOs as input indicates the submitters have some lack of
familiarity with unix command-line.

Given all the above,
I suspect this is part of a homework exercise given to students at some
college, perhaps something like "find bugs in an free software project
and submit a patch to them".

While good intentioned, these suggestions should be rejected as
"wontfix".

For any students or potential contributers who want to start working on
GNU coreutils - PLEASE write to coreut...@gnu.org and introduce
yourself, and we will easily provide ideas on useful contributions
that would be accepted.

Of course, the above is just my opinion, and others are welcomed
to chime in.

regards,
  - assaf

** Changed in: coreutils (Ubuntu)
   Status: New => Won't Fix

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

Title:
  uniq is not checking and handling all file types

Status in coreutils package in Ubuntu:
  Won't Fix

Bug description:
  Hi,

  The utility uniq allows all types of files as input. Allowing block
  devices or character devices as input can lead to unwanted behavior
  such as the utility executes indefinitely when device '/dev/urandom'
  is passed as an input. Please refer this for more information
  regarding this issue
  (https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md).

  I've included a patch which checks and handles character devices and
  block devices when passed as input. I've tested the patched version
  and it doesn't seem to break any tests but I'm always glad to further
  work on it. Please get back to me with any feedback or for more
  information.

  Regards,
  Anoop Nadig

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: coreutils 8.28-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
  Uname: Linux 4.15.0-42-generic i686
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: i386
  CurrentDesktop: XFCE
  Date: Tue Dec 11 20:23:32 2018
  ExecutablePath: /usr/bin/uniq
  InstallationDate: Installed on 2018-11-07 (35 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release i386 (20180426)
  SourcePackage: coreutils
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1808095/+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 1812430] [NEW] intel hd 500 - j3455 no graphic driver

2019-01-18 Thread dadanana777777

Public bug reported:

need driver please

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: xorg 1:7.7+19ubuntu8
ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
Uname: Linux 4.18.0-13-generic x86_64
ApportVersion: 2.20.10-0ubuntu13.1
Architecture: amd64
CompositorRunning: None
Date: Fri Jan 18 20:13:31 2019
DistUpgraded: Fresh install
DistroCodename: cosmic
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, including running git bisection searches
GraphicsCard:
 Intel Corporation Device [8086:5a85] (rev 0b) (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. Device [1043:8738]
InstallationDate: Installed on 2019-01-16 (2 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 002: ID 045e:0750 Microsoft Corp. Wired Keyboard 600
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: System manufacturer System Product Name
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=sk_SK.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-13-generic 
root=UUID=427002da-8ec4-4338-927f-12021ee7cea4 ro quiet splash vt.handoff=1
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 02/07/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0802
dmi.board.asset.tag: Default string
dmi.board.name: J3455M-E
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr0802:bd02/07/2018:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnJ3455M-E:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: System Product Name
dmi.product.sku: SKU
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.95-1
version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.8-0ubuntu0~18.10.1~ppa1
version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.8-0ubuntu0~18.10.1~ppa1
version.xserver-xorg-core: xserver-xorg-core 2:1.20.1-3ubuntu2.1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-3

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


** Tags: amd64 apport-bug cosmic 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/1812430

Title:
  intel hd 500 - j3455 no graphic driver

Status in xorg package in Ubuntu:
  New

Bug description:
  need driver please

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: xorg 1:7.7+19ubuntu8
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CompositorRunning: None
  Date: Fri Jan 18 20:13:31 2019
  DistUpgraded: Fresh install
  DistroCodename: cosmic
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, including running git bisection searches
  GraphicsCard:
   Intel Corporation Device [8086:5a85] (rev 0b) (prog-if 00 [VGA controller])
 Subsystem: ASUSTeK Computer Inc. Device [1043:8738]
  InstallationDate: Installed on 2019-01-16 (2 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 045e:0750 Microsoft Corp. Wired Keyboard 600
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: System manufacturer System Product Name
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=sk_SK.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-13-generic 
root=UUID=427002da-8ec4-4338-927f-12021ee7cea4 ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 02/07/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 0802
  dmi.board.asset.tag: Default string
  dmi.board.name: J3455M-E
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev X.0x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr0802:bd02/07/2018:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnJ3455M-E:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:

[Touch-packages] [Bug 1808092] Re: Checking and handling various filetypes in fmt

** Information type changed from Public Security to Public

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

Title:
  Checking and handling various filetypes in fmt

Status in coreutils package in Ubuntu:
  New

Bug description:
  fmt doesn't check filetypes of the input arguments passed to it, it
  just opens the file and reads from it without checking its st_mode. It
  only throws an error if the file doesn't exist and can't handle the
  following filetypes - S_IFCHR, S_IFBLK and S_IFBLK. Passing a file
  from any of these types will possibly hang or crash the application.

  For more reference, please visit the below link-
  (https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md)

  I have attached a patch that checks for the above mentioned filetypes and 
handles them accordingly.
  Please let me know if you have any questions or suggestions regarding this, 
will be happy to answer them.

  Thank you
  Snahil Singh
  ss11...@nyu.edu

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: coreutils 8.28-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18
  Uname: Linux 4.15.0-39-generic i686
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: i386
  CurrentDesktop: XFCE
  Date: Tue Dec 11 20:01:58 2018
  ExecutablePath: /usr/bin/fmt
  InstallationDate: Installed on 2018-11-07 (35 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release i386 (20180426)
  SourcePackage: coreutils
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1808092/+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 1807514] Re: update error

Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  update error

Status in xorg package in Ubuntu:
  New

Bug description:
  installed systemd-shim package post-removal script subprocess returned
  error exit status 2

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
  Uname: Linux 4.15.0-42-generic i686
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: i386
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Sat Dec  8 17:13:53 2018
  DistUpgraded: 2018-12-08 17:07:42,953 DEBUG /openCache(), new cache size 61306
  DistroCodename: bionic
  DistroVariant: ubuntu
  ExtraDebuggingInterest: I just need to know a workaround
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 
Series] [1002:68f9] (prog-if 00 [VGA controller])
 Subsystem: XFX Pine Group Inc. Cedar [Radeon HD 5000/6000/7350/8350 
Series] [1682:3030]
  InstallationDate: Installed on 2014-02-15 (1757 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release i386 (20131016.1)
  MachineType: Dell Inc. Dell DXP051
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-42-generic 
root=UUID=e3337e9d-4116-4f99-b96f-8019182e5c07 ro
  Renderer: Software
  SourcePackage: xorg
  UpgradeStatus: Upgraded to bionic on 2018-12-08 (0 days ago)
  dmi.bios.date: 01/08/2007
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A07
  dmi.board.name: 0YC523
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 7
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA07:bd01/08/2007:svnDellInc.:pnDellDXP051:pvr:rvnDellInc.:rn0YC523:rvr:cvnDellInc.:ct7:cvr:
  dmi.product.name: Dell DXP051
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
  version.libdrm2: libdrm2 2.4.91-2
  version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.5-0ubuntu0~18.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.5-0ubuntu0~18.04.1
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
  xserver.bootTime: Sun Nov  4 10:33:25 2018
  xserver.configfile: default
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.19.6-1ubuntu4.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1807514/+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 1808095] Re: uniq is not checking and handling all file types

** Information type changed from Public Security to Public

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

Title:
  uniq is not checking and handling all file types

Status in coreutils package in Ubuntu:
  New

Bug description:
  Hi,

  The utility uniq allows all types of files as input. Allowing block
  devices or character devices as input can lead to unwanted behavior
  such as the utility executes indefinitely when device '/dev/urandom'
  is passed as an input. Please refer this for more information
  regarding this issue
  (https://github.com/pkmoore/rrapper/blob/master/anomalies/weird_filetypes.md).

  I've included a patch which checks and handles character devices and
  block devices when passed as input. I've tested the patched version
  and it doesn't seem to break any tests but I'm always glad to further
  work on it. Please get back to me with any feedback or for more
  information.

  Regards,
  Anoop Nadig

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: coreutils 8.28-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
  Uname: Linux 4.15.0-42-generic i686
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: i386
  CurrentDesktop: XFCE
  Date: Tue Dec 11 20:23:32 2018
  ExecutablePath: /usr/bin/uniq
  InstallationDate: Installed on 2018-11-07 (35 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release i386 (20180426)
  SourcePackage: coreutils
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1808095/+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 1808861] Re: Problem crashes Unreportable - Invalid core dump: BFD: warning: apport_core is truncated

2019-01-18 Thread Mario Vukelic

I have hundreds of gigs free disk space and 16 GB or RAM of which
typically only 50% is even used

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

Title:
  Problem crashes Unreportable - Invalid core dump: BFD: warning:
  apport_core is truncated

Status in apport package in Ubuntu:
  Invalid
Status in chromium-browser package in Ubuntu:
  Invalid

Bug description:
  Trying to report a crash in chromium-browser, get Unreportable reason
  Invalid core dump: BFD: warning apport_core is truncated (see
  screenshot, can't copy message from apport dialog - bug # 1273752).

  UnreportableReason:
   Invalid core dump: BFD: warning: /tmp/apport_core_6yb3cl_7 is truncated: 
expected core file size >= 1245646848, found: 760283136
   warning: core file may not match specified executable file.

  
  Expected: able to report ?

  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: apport 2.20.9-0ubuntu7.5
  ProcVersionSignature: User Name 4.15.0-42.45-generic 4.15.18
  Uname: Linux 4.15.0-42-generic x86_64
  ApportLog:
   ERROR: apport (pid 31805) Mon Dec 17 15:14:09 2018: called for pid 15848, 
signal 5, core limit 0, dump mode 1
   ERROR: apport (pid 31805) Mon Dec 17 15:14:09 2018: executable: 
/usr/lib/chromium-browser/chromium-browser (command line 
"/usr/lib/chromium-browser/chromium-browser\ --enable-pinch")
   ERROR: apport (pid 31805) Mon Dec 17 15:14:09 2018: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
   ERROR: apport (pid 31805) Mon Dec 17 15:15:23 2018: wrote report 
/var/crash/_usr_lib_chromium-browser_chromium-browser.1000.crash
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Dec 17 15:30:28 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2018-09-12 (96 days ago)
  InstallationMedia: Ubuntu 16.04.5 LTS "Xenial Xerus" - Release amd64 
(20180731)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: apport
  UpgradeStatus: Upgraded to bionic on 2018-09-28 (80 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1808861/+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 1811471] Re: local resolver stub fails to handle multiple TCP dns queries

2019-01-18 Thread Dan Streetman

> Also is this then just not a simple cherrypick of:
> 
> https://github.com/systemd/systemd/commit/93158c77bc69fde7cf5cff733617631c1e566fe8

that's one way to work around it, although glibc is not necessarily the
only thing that might do pipelined TCP dns lookups to the local stub
resolver (though I have no examples of anything else that does).  It
certainly should fix/workaround this for Ubuntu installs using the
default systemd-resolved setup and only having issues with getaddrinfo()
failures.

I still plan to fix systemd's stub resolver to correctly respond to
pipelined TCP dns queries.

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

Title:
  local resolver stub fails to handle multiple TCP dns queries

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [Impact]

  The systemd local 'stub' resolver handles all local DNS queries (by
  default configuration used in Ubuntu), and essentially proxies all
  requests to its configured upstream DNS resolvers.

  Most local DNS resolution by applications uses glibc's getaddrinfo()
  function.  This function is configured in various ways by the
  /etc/resolv.conf file, which tells glibc what nameserver/resolver to
  contact as well as how to talk to the name server.

  By default, glibc performs UDP DNS queries, with a single DNS query
  per UDP packet.  The UDP packet size is limited per DNS spec to 512
  bytes.  For some DNS lookups, a 512 byte UDP packet is not large
  enough to contain the entire response - for example, an A record
  lookup with a large number (e.g. 30) of A record addresses.  This
  number of A record entries is possible in some cases of load
  balancing.  When the DNS UDP response size is larger than 512 bytes,
  the server puts as much response as it can into the DNS UDP response,
  and marks the "trunacted" flag.  This lets glibc know that the DNS UDP
  packet did not contain the entire response for all the A records.

  When glibc sees a UDP response that is "trunacted", by default it
  ignores the contents of that response and issues a new DNS query,
  using TCP instead of UDP.  The TCP packet size has a higher size limit
  (though see bug 1804487 which is a bug in systemd's max-sizing of TCP
  DNS packets), and so *should* allow glibc to receive the entire DNS
  response.

  However, glibc issues DNS queries for both A and  records.  When
  it uses UDP, those DNS queries are separate (i.e. one UDP DNS packet
  with a single A query, and one UDP DNS packet with a single 
  query).  When glibc uses TCP, it puts both DNS queries into a single
  TCP DNS packet - the RFC refers to this as "pipelining"
  (https://tools.ietf.org/html/rfc7766#section-6.2.1.1) and states that
  clients SHOULD do this, and that servers MUST expect to receive
  pipelined queries and SHOULD respond to all of them.  (Technically
  pipelining can be separate DNS queries, one per TCP packet, but both
  using the same TCP connection - but the clear intention of pipelining
  is to improve TCP performance, and putting both DNS queries into a
  single TCP packet is clearly more performant than using separate TCP
  packets).

  Unfortunately, systemd's local stub resolver has only very basic
  support for TCP DNS, and it handles TCP DNS queries almost identically
  to UDP DNS queries - it reads the DNS query 2-byte header (containing
  the length of the query data), reads in the single DNS query data,
  performs lookup and sends a response to that DNS query, and closes the
  TCP connection.  It does not check for "pipelined" queries in the TCP
  connection.

  That would be bad enough, as glibc is (rightly) expecting a response
  to both its A and  queries; however what glibc gets is a TCP
  connection-reset error.  That is because the local systemd stub
  resolver has closed its TCP socket while input data was still pending
  (i.e. it never even read the second pipelined DNS query).  When the
  kernel sees unread input bytes in a TCP connection that is closed, it
  sends a TCP RST to the peer (i.e. glibc) and when the kernel sees the
  RST, it dumps all data in its socket buffer and passes the ECONNRESET
  error up to the application.  So glibc gets nothing besides a
  connection reset error.

  Note also that even if the systemd local stub resolver's socket
  flushes its input buffer before closing the TCP connection (which will
  avoid the TCP RST), glibc still expects responses to both its A and
   queries before systemd closes the TCP connection, and so a simple
  change to systemd to flush

[Touch-packages] [Bug 1811930] Re: package unattended-upgrades 1.1ubuntu1.18.04.8 failed to install/upgrade: installed unattended-upgrades package post-installation script subprocess returned error ex

Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  package unattended-upgrades 1.1ubuntu1.18.04.8 failed to
  install/upgrade: installed unattended-upgrades package post-
  installation script subprocess returned error exit status 10

Status in unattended-upgrades package in Ubuntu:
  New

Bug description:
  this error occoured while upgrade

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: unattended-upgrades 1.1ubuntu1.18.04.8
  ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
  Uname: Linux 4.15.0-29-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  Date: Wed Jan 16 11:53:24 2019
  DuplicateSignature:
   package:unattended-upgrades:1.1ubuntu1.18.04.8
   Setting up unattended-upgrades (1.1ubuntu1.18.04.8) ...
   dpkg: error processing package unattended-upgrades (--configure):
installed unattended-upgrades package post-installation script subprocess 
returned error exit status 10
  ErrorMessage: installed unattended-upgrades package post-installation script 
subprocess returned error exit status 10
  InstallationDate: Installed on 2018-12-06 (40 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.6, Python 3.6.7, unpackaged
  PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, unpackaged
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.1
   apt  1.6.6
  SourcePackage: unattended-upgrades
  Title: package unattended-upgrades 1.1ubuntu1.18.04.8 failed to 
install/upgrade: installed unattended-upgrades package post-installation script 
subprocess returned error exit status 10
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1811930/+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 1811719] Re: sfd

Thank you for using Ubuntu and taking the time to report a bug. Your
report should contain, at a minimum, the following information so we can
better find the source of the bug and work to resolve it.

Submitting the bug about the proper source package is essential. For
help see https://wiki.ubuntu.com/Bugs/FindRightPackage . Additionally,
in the report please include:

1) The release of Ubuntu you are using, via 'cat /etc/lsb-release' or System -> 
About Ubuntu.
2) The version of the package you are using, via 'dpkg -l PKGNAME | cat' or by 
checking in Synaptic.
3) What happened and what you expected to happen.

The Ubuntu community has also created debugging procedures for a wide
variety of packages at https://wiki.ubuntu.com/DebuggingProcedures .
Following the debugging instructions for the affected package will make
your bug report much more complete. Thanks!


** Information type changed from Private Security to Public

** Changed in: xorg (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/1811719

Title:
  sfd

Status in xorg package in Ubuntu:
  Invalid

Bug description:
  dfsfd

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18
  Uname: Linux 4.15.0-43-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Mon Jan 14 23:02:27 2019
  DistUpgraded: 2018-12-12 20:39:45,935 ERROR got error from PostInstallScript 
./xorg_fix_proprietary.py (g-exec-error-quark: Failed to execute child process 
"./xorg_fix_proprietary.py" (No such file or directory) (8))
  DistroCodename: bionic
  DistroVariant: ubuntu
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 7340] [1002:9808] 
(prog-if 00 [VGA controller])
 Subsystem: Sony Corporation Wrestler [Radeon HD 7340] [104d:90ad]
  InstallationDate: Installed on 2016-04-24 (995 days ago)
  InstallationMedia: Ubuntu 14.04.4 LTS "Trusty Tahr" - Release amd64 
(20160217.1)
  MachineType: Sony Corporation SVE1112M1EW
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-43-generic 
root=UUID=40da7131-b99a-4e5b-9c5e-81ba4975e74c ro nopat vesafb.invalid=1 
drm.debug=0xe plymouth:debug
  SourcePackage: xorg
  UpgradeStatus: Upgraded to bionic on 2018-12-12 (33 days ago)
  dmi.bios.date: 08/22/2012
  dmi.bios.vendor: Insyde Corp.
  dmi.bios.version: R0120D8
  dmi.board.asset.tag: N/A
  dmi.board.name: VAIO
  dmi.board.vendor: Sony Corporation
  dmi.board.version: N/A
  dmi.chassis.asset.tag: N/A
  dmi.chassis.type: 10
  dmi.chassis.vendor: Sony Corporation
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnInsydeCorp.:bvrR0120D8:bd08/22/2012:svnSonyCorporation:pnSVE1112M1EW:pvrC60B8BEP:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A:
  dmi.product.family: VAIO
  dmi.product.name: SVE1112M1EW
  dmi.product.version: C60B8BEP
  dmi.sys.vendor: Sony Corporation
  version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
  version.libdrm2: libdrm2 2.4.91-2
  version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.5-0ubuntu0~18.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.5-0ubuntu0~18.04.1
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
  xserver.bootTime: Wed Dec 12 18:07:04 2018
  xserver.configfile: default
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.18.4-0ubuntu0.8
  xserver.video_driver: radeon

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1811719/+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 1811930] Re: package unattended-upgrades 1.1ubuntu1.18.04.8 failed to install/upgrade: installed unattended-upgrades package post-installation script subprocess returned error ex

2019-01-18 Thread Apport retracing service

** Tags removed: need-duplicate-check

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

Title:
  package unattended-upgrades 1.1ubuntu1.18.04.8 failed to
  install/upgrade: installed unattended-upgrades package post-
  installation script subprocess returned error exit status 10

Status in unattended-upgrades package in Ubuntu:
  New

Bug description:
  this error occoured while upgrade

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: unattended-upgrades 1.1ubuntu1.18.04.8
  ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
  Uname: Linux 4.15.0-29-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  Date: Wed Jan 16 11:53:24 2019
  DuplicateSignature:
   package:unattended-upgrades:1.1ubuntu1.18.04.8
   Setting up unattended-upgrades (1.1ubuntu1.18.04.8) ...
   dpkg: error processing package unattended-upgrades (--configure):
installed unattended-upgrades package post-installation script subprocess 
returned error exit status 10
  ErrorMessage: installed unattended-upgrades package post-installation script 
subprocess returned error exit status 10
  InstallationDate: Installed on 2018-12-06 (40 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.6, Python 3.6.7, unpackaged
  PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, unpackaged
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.1
   apt  1.6.6
  SourcePackage: unattended-upgrades
  Title: package unattended-upgrades 1.1ubuntu1.18.04.8 failed to 
install/upgrade: installed unattended-upgrades package post-installation script 
subprocess returned error exit status 10
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1811930/+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 1783499] Re: systemd: Failed to send signal

2019-01-18 Thread Kai-Heng Feng

Have you tried other reboot quirk like "reboot=pci"? It may help.

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

Title:
  systemd: Failed to send signal

Status in dbus package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  systemd: Failed to send signal.

  [3.137257] systemd[1]: Failed to send job remove signal for 109: 
Connection reset by peer
  [3.138119] systemd[1]: run-rpc_pipefs.mount: Failed to send unit change 
signal for run-rpc_pipefs.mount: Transport endpoint is not connected
  [3.138185] systemd[1]: dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: Failed 
to send unit change signal for dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: 
Transport endpoint is not connected
  [3.138512] systemd[1]: run-rpc_pipefs.mount: Failed to send unit change 
signal for run-rpc_pipefs.mount: Transport endpoint is not connected
  [3.142719] systemd[1]: Failed to send job remove signal for 134: 
Transport endpoint is not connected
  [3.142958] systemd[1]: auth-rpcgss-module.service: Failed to send unit 
change signal for auth-rpcgss-module.service: Transport endpoint is not 
connected
  [3.165359] systemd[1]: Failed to send job remove signal for 133: 
Transport endpoint is not connected
  [3.165505] systemd[1]: proc-fs-nfsd.mount: Failed to send unit change 
signal for proc-fs-nfsd.mount: Transport endpoint is not connected
  [3.165541] systemd[1]: dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: Failed 
to send unit change signal for dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: 
Transport endpoint is not connected
  [3.166854] systemd[1]: Failed to send job remove signal for 66: Transport 
endpoint is not connected
  [3.167072] systemd[1]: proc-fs-nfsd.mount: Failed to send unit change 
signal for proc-fs-nfsd.mount: Transport endpoint is not connected
  [3.167130] systemd[1]: systemd-modules-load.service: Failed to send unit 
change signal for systemd-modules-load.service: Transport endpoint is not 
connected
  [2.929018] systemd[1]: Failed to send job remove signal for 53: Transport 
endpoint is not connected
  [2.929220] systemd[1]: systemd-random-seed.service: Failed to send unit 
change signal for systemd-random-seed.service: Transport endpoint is not 
connected
  [3.024320] systemd[1]: sys-devices-platform-serial8250-tty-ttyS12.device: 
Failed to send unit change signal for 
sys-devices-platform-serial8250-tty-ttyS12.device: Transport endpoint is not 
connected
  [3.024421] systemd[1]: dev-ttyS12.device: Failed to send unit change 
signal for dev-ttyS12.device: Transport endpoint is not connected
  [3.547019] systemd[1]: proc-sys-fs-binfmt_misc.automount: Failed to send 
unit change signal for proc-sys-fs-binfmt_misc.automount: Connection reset by 
peer
  [3.547144] systemd[1]: Failed to send job change signal for 207: 
Transport endpoint is not connected

  
  How to reproduce:
  1. enable debug level journal
  LogLevel=debug in /etc/systemd/system.conf
  2. reboot the system
  3. journalctl | grep "Failed to send"

  
  sliu@vmlxhi-094:~$ lsb_release -rd
  Description:  Ubuntu 16.04.4 LTS
  Release:  16.04

  sliu@vmlxhi-094:~$ systemctl --version
  systemd 229
  +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN

  sliu@vmlxhi-094:~$ dbus-daemon --version
  D-Bus Message Bus Daemon 1.10.6
  Copyright (C) 2002, 2003 Red Hat, Inc., CodeFactory AB, and others
  This is free software; see the source for copying conditions.
  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1783499/+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 1812150] Re: qhelpgenerator and qcollectiongenerator will not run

2019-01-18 Thread Andrew Janke

Sounds good. I'll take it up with the Qt folks.

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

Title:
  qhelpgenerator and qcollectiongenerator will not run

Status in qtchooser package in Ubuntu:
  Invalid

Bug description:
  I have qttols5-dev-tools installed, which provides a qthelpgenerator
  implementation. But when I try to run qhelpgenerator (or
  qcollectiongenerator) through their usual /usr/bin shims, it errors
  out:

  janke@ubuntu:~/local/repos/octave-addons-chrono/doc$ dpkg -S 
/usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator 
  qttools5-dev-tools: /usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator
  janke@ubuntu:~/local/repos/octave-addons-chrono/doc$ ls -l 
/usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator
  lrwxrwxrwx 1 root root 31 Apr 14  2018 
/usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator -> 
../../../qt5/bin/qhelpgenerator
  janke@ubuntu:~/local/repos/octave-addons-chrono/doc$ which qhelpgenerator
  /usr/bin/qhelpgenerator
  janke@ubuntu:~/local/repos/octave-addons-chrono/doc$ ls -l 
/usr/bin/qhelpgenerator
  lrwxrwxrwx 1 root root 9 Dec 21  2017 /usr/bin/qhelpgenerator -> qtchooser
  janke@ubuntu:~/local/repos/octave-addons-chrono/doc$ qhelpgenerator -v
  qhelpgenerator: could not find a Qt installation of ''
  janke@ubuntu:~/local/repos/octave-addons-chrono/doc$ qcollectiongenerator -v
  qcollectiongenerator: could not find a Qt installation of ''
  janke@ubuntu:~/local/repos/octave-addons-chrono/doc$ 

  Running them directly works:

  janke@ubuntu:~/local/repos/octave-addons-chrono/doc$ 
/usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator -v
  Qt Help Generator version 1.0 (Qt 5.9.5)
  janke@ubuntu:~/local/repos/octave-addons-chrono/doc$ 
/usr/lib/x86_64-linux-gnu/qt5/bin/qcollectiongenerator -v
  Qt Collection Generator version 1.0 (Qt 5.9.5)

  
  But most software will locate the /usr/bin shims instead of this actual 
binary.

  Looks like a problem with qtchooser?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: qtchooser 64-ga1b6736-5
  ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
  Uname: Linux 4.15.0-29-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Jan 16 20:00:43 2019
  Dependencies:
   gcc-8-base 8.2.0-1ubuntu2~18.04
   libc6 2.27-3ubuntu1
   libgcc1 1:8.2.0-1ubuntu2~18.04
   libstdc++6 8.2.0-1ubuntu2~18.04
  InstallationDate: Installed on 2019-01-15 (1 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: qtchooser
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtchooser/+bug/1812150/+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 1808861] Re: Problem crashes Unreportable - Invalid core dump: BFD: warning: apport_core is truncated

What happened is that gdb did not complete writing the core file
possibly due to a lack of memory or disk space on the system, then
because the core file is incomplete apport will not create a crash file
with the core dump. There isn't anything we can do here, sometimes core
file creation just fails.

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

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

Title:
  Problem crashes Unreportable - Invalid core dump: BFD: warning:
  apport_core is truncated

Status in apport package in Ubuntu:
  Invalid
Status in chromium-browser package in Ubuntu:
  Invalid

Bug description:
  Trying to report a crash in chromium-browser, get Unreportable reason
  Invalid core dump: BFD: warning apport_core is truncated (see
  screenshot, can't copy message from apport dialog - bug # 1273752).

  UnreportableReason:
   Invalid core dump: BFD: warning: /tmp/apport_core_6yb3cl_7 is truncated: 
expected core file size >= 1245646848, found: 760283136
   warning: core file may not match specified executable file.

  
  Expected: able to report ?

  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: apport 2.20.9-0ubuntu7.5
  ProcVersionSignature: User Name 4.15.0-42.45-generic 4.15.18
  Uname: Linux 4.15.0-42-generic x86_64
  ApportLog:
   ERROR: apport (pid 31805) Mon Dec 17 15:14:09 2018: called for pid 15848, 
signal 5, core limit 0, dump mode 1
   ERROR: apport (pid 31805) Mon Dec 17 15:14:09 2018: executable: 
/usr/lib/chromium-browser/chromium-browser (command line 
"/usr/lib/chromium-browser/chromium-browser\ --enable-pinch")
   ERROR: apport (pid 31805) Mon Dec 17 15:14:09 2018: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
   ERROR: apport (pid 31805) Mon Dec 17 15:15:23 2018: wrote report 
/var/crash/_usr_lib_chromium-browser_chromium-browser.1000.crash
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Dec 17 15:30:28 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2018-09-12 (96 days ago)
  InstallationMedia: Ubuntu 16.04.5 LTS "Xenial Xerus" - Release amd64 
(20180731)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: apport
  UpgradeStatus: Upgraded to bionic on 2018-09-28 (80 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1808861/+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 1811471] Re: local resolver stub fails to handle multiple TCP dns queries

2019-01-18 Thread Dimitri John Ledkov

Also is this then just not a simple cherrypick of:

https://github.com/systemd/systemd/commit/93158c77bc69fde7cf5cff733617631c1e566fe8

?

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

Title:
  local resolver stub fails to handle multiple TCP dns queries

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [Impact]

  The systemd local 'stub' resolver handles all local DNS queries (by
  default configuration used in Ubuntu), and essentially proxies all
  requests to its configured upstream DNS resolvers.

  Most local DNS resolution by applications uses glibc's getaddrinfo()
  function.  This function is configured in various ways by the
  /etc/resolv.conf file, which tells glibc what nameserver/resolver to
  contact as well as how to talk to the name server.

  By default, glibc performs UDP DNS queries, with a single DNS query
  per UDP packet.  The UDP packet size is limited per DNS spec to 512
  bytes.  For some DNS lookups, a 512 byte UDP packet is not large
  enough to contain the entire response - for example, an A record
  lookup with a large number (e.g. 30) of A record addresses.  This
  number of A record entries is possible in some cases of load
  balancing.  When the DNS UDP response size is larger than 512 bytes,
  the server puts as much response as it can into the DNS UDP response,
  and marks the "trunacted" flag.  This lets glibc know that the DNS UDP
  packet did not contain the entire response for all the A records.

  When glibc sees a UDP response that is "trunacted", by default it
  ignores the contents of that response and issues a new DNS query,
  using TCP instead of UDP.  The TCP packet size has a higher size limit
  (though see bug 1804487 which is a bug in systemd's max-sizing of TCP
  DNS packets), and so *should* allow glibc to receive the entire DNS
  response.

  However, glibc issues DNS queries for both A and  records.  When
  it uses UDP, those DNS queries are separate (i.e. one UDP DNS packet
  with a single A query, and one UDP DNS packet with a single 
  query).  When glibc uses TCP, it puts both DNS queries into a single
  TCP DNS packet - the RFC refers to this as "pipelining"
  (https://tools.ietf.org/html/rfc7766#section-6.2.1.1) and states that
  clients SHOULD do this, and that servers MUST expect to receive
  pipelined queries and SHOULD respond to all of them.  (Technically
  pipelining can be separate DNS queries, one per TCP packet, but both
  using the same TCP connection - but the clear intention of pipelining
  is to improve TCP performance, and putting both DNS queries into a
  single TCP packet is clearly more performant than using separate TCP
  packets).

  Unfortunately, systemd's local stub resolver has only very basic
  support for TCP DNS, and it handles TCP DNS queries almost identically
  to UDP DNS queries - it reads the DNS query 2-byte header (containing
  the length of the query data), reads in the single DNS query data,
  performs lookup and sends a response to that DNS query, and closes the
  TCP connection.  It does not check for "pipelined" queries in the TCP
  connection.

  That would be bad enough, as glibc is (rightly) expecting a response
  to both its A and  queries; however what glibc gets is a TCP
  connection-reset error.  That is because the local systemd stub
  resolver has closed its TCP socket while input data was still pending
  (i.e. it never even read the second pipelined DNS query).  When the
  kernel sees unread input bytes in a TCP connection that is closed, it
  sends a TCP RST to the peer (i.e. glibc) and when the kernel sees the
  RST, it dumps all data in its socket buffer and passes the ECONNRESET
  error up to the application.  So glibc gets nothing besides a
  connection reset error.

  Note also that even if the systemd local stub resolver's socket
  flushes its input buffer before closing the TCP connection (which will
  avoid the TCP RST), glibc still expects responses to both its A and
   queries before systemd closes the TCP connection, and so a simple
  change to systemd to flush the input buffer is not enough to fix the
  bug (and would also not actually fix the bug since glibc would never
  get the  response).

  [Test Case]

  This can be reproduced on any system using a local systemd stub
  resolver, when using an application that uses getaddrinfo() - such as
  ssh, telnet, ping, etc - or with a simple C program that uses
  getaddrinfo().  The dns name looked up must have enough A records to
  overflow the 512 byte maximum

[Touch-packages] [Bug 1811471] Re: local resolver stub fails to handle multiple TCP dns queries

2019-01-18 Thread Dimitri John Ledkov

I am happy to add "options edns0" in the generated file by resolved.

But we also need to file this case upstream, and start implementing
pipelined requests handling in resolved too.

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

Title:
  local resolver stub fails to handle multiple TCP dns queries

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [Impact]

  The systemd local 'stub' resolver handles all local DNS queries (by
  default configuration used in Ubuntu), and essentially proxies all
  requests to its configured upstream DNS resolvers.

  Most local DNS resolution by applications uses glibc's getaddrinfo()
  function.  This function is configured in various ways by the
  /etc/resolv.conf file, which tells glibc what nameserver/resolver to
  contact as well as how to talk to the name server.

  By default, glibc performs UDP DNS queries, with a single DNS query
  per UDP packet.  The UDP packet size is limited per DNS spec to 512
  bytes.  For some DNS lookups, a 512 byte UDP packet is not large
  enough to contain the entire response - for example, an A record
  lookup with a large number (e.g. 30) of A record addresses.  This
  number of A record entries is possible in some cases of load
  balancing.  When the DNS UDP response size is larger than 512 bytes,
  the server puts as much response as it can into the DNS UDP response,
  and marks the "trunacted" flag.  This lets glibc know that the DNS UDP
  packet did not contain the entire response for all the A records.

  When glibc sees a UDP response that is "trunacted", by default it
  ignores the contents of that response and issues a new DNS query,
  using TCP instead of UDP.  The TCP packet size has a higher size limit
  (though see bug 1804487 which is a bug in systemd's max-sizing of TCP
  DNS packets), and so *should* allow glibc to receive the entire DNS
  response.

  However, glibc issues DNS queries for both A and  records.  When
  it uses UDP, those DNS queries are separate (i.e. one UDP DNS packet
  with a single A query, and one UDP DNS packet with a single 
  query).  When glibc uses TCP, it puts both DNS queries into a single
  TCP DNS packet - the RFC refers to this as "pipelining"
  (https://tools.ietf.org/html/rfc7766#section-6.2.1.1) and states that
  clients SHOULD do this, and that servers MUST expect to receive
  pipelined queries and SHOULD respond to all of them.  (Technically
  pipelining can be separate DNS queries, one per TCP packet, but both
  using the same TCP connection - but the clear intention of pipelining
  is to improve TCP performance, and putting both DNS queries into a
  single TCP packet is clearly more performant than using separate TCP
  packets).

  Unfortunately, systemd's local stub resolver has only very basic
  support for TCP DNS, and it handles TCP DNS queries almost identically
  to UDP DNS queries - it reads the DNS query 2-byte header (containing
  the length of the query data), reads in the single DNS query data,
  performs lookup and sends a response to that DNS query, and closes the
  TCP connection.  It does not check for "pipelined" queries in the TCP
  connection.

  That would be bad enough, as glibc is (rightly) expecting a response
  to both its A and  queries; however what glibc gets is a TCP
  connection-reset error.  That is because the local systemd stub
  resolver has closed its TCP socket while input data was still pending
  (i.e. it never even read the second pipelined DNS query).  When the
  kernel sees unread input bytes in a TCP connection that is closed, it
  sends a TCP RST to the peer (i.e. glibc) and when the kernel sees the
  RST, it dumps all data in its socket buffer and passes the ECONNRESET
  error up to the application.  So glibc gets nothing besides a
  connection reset error.

  Note also that even if the systemd local stub resolver's socket
  flushes its input buffer before closing the TCP connection (which will
  avoid the TCP RST), glibc still expects responses to both its A and
   queries before systemd closes the TCP connection, and so a simple
  change to systemd to flush the input buffer is not enough to fix the
  bug (and would also not actually fix the bug since glibc would never
  get the  response).

  [Test Case]

  This can be reproduced on any system using a local systemd stub
  resolver, when using an application that uses getaddrinfo() - such as
  ssh, telnet, ping, etc - or with a simple C program that uses
  getaddrinfo().  The dns name looked up must have enough

[Touch-packages] [Bug 1805027] Re: systemd-resolved can't resolve Comcast mail server addresses

The workaround, of adding "options edns0" to my /etc/resolv.conf, in bug
1811471 resolved the issue for me. That's only temporary though as
/etc/resolv.conf will get overwritten.

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

Title:
  systemd-resolved can't resolve Comcast mail server addresses

Status in systemd package in Ubuntu:
  Triaged

Bug description:
  1) Ubuntu release:  18.10
  2) systemd-resolved version: (Default latest version that comes with Ubuntu 
18.10)
  3) Expected behavior: Comcast's POP3 mail server addresses to be resolved to 
IP addresses
  4) Actual behavior:  Comcast's POP3 mail server addresses can't be resolved 
to IP addresses

  Starting on Monday, November 19, 2018, Comcast made a DNS change
  related to its POP3 mail servers (mail.comcast.net and
  pop3.comcast.net) that prevent resolved from being able to resolve
  those domains into IP addresses.  When I try to ping either host
  (mail.comcast.net or pop2.comcast.net), I get this error:

  tom@deathstar:~$ ping mail.comcast.net
  ping: mail.comcast.net: Name or service not known
  tom@deathstar:~$

  When I manually lookup up the domain, I get these results:

  tom@deathstar:~$ nslookup mail.comcast.net
  Server:   127.0.0.53
  Address:  127.0.0.53#53

  Non-authoritative answer:
  mail.comcast.net  canonical name = imap.ge.xfinity.com.
  Name: imap.ge.xfinity.com
  Address: 96.118.242.209
  Name: imap.ge.xfinity.com
  Address: 96.118.242.197
  Name: imap.ge.xfinity.com
  Address: 96.118.242.233
  Name: imap.ge.xfinity.com
  Address: 96.118.242.225
  Name: imap.ge.xfinity.com
  Address: 96.118.242.226
  Name: imap.ge.xfinity.com
  Address: 96.118.242.217
  Name: imap.ge.xfinity.com
  Address: 96.118.242.208
  Name: imap.ge.xfinity.com
  Address: 96.118.242.230
  Name: imap.ge.xfinity.com
  Address: 96.118.242.232
  Name: imap.ge.xfinity.com
  Address: 96.118.242.218
  Name: imap.ge.xfinity.com
  Address: 96.118.242.211
  Name: imap.ge.xfinity.com
  Address: 96.118.242.242
  Name: imap.ge.xfinity.com
  Address: 96.118.242.221
  Name: imap.ge.xfinity.com
  Address: 96.118.242.196
  Name: imap.ge.xfinity.com
  Address: 96.118.208.40
  Name: imap.ge.xfinity.com
  Address: 96.118.208.99
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fee8:4f07
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fe7d:1b0c
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fe25:5ae5
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fef6:babc
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fe87:c172
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fee6:7a57
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fe0f:a4a
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:2:f816:3eff:fec7:cb93
  Name: imap.ge.xfinity.com
  Address: 2001:558:fee2:1000:f816:3eff:fe42:4f14
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:fe33:9aaa
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:feb2:8c0d
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:fef1:25a5
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:febd:320a
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:fe36:aba3
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:fe3f:76f2
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:fe45:1d1e

  tom@deathstar:~$ dig mail.comcast.net

  ; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> mail.comcast.net
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15037
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 65494
  ;; QUESTION SECTION:
  ;mail.comcast.net.IN  A

  ;; ANSWER SECTION:
  mail.comcast.net. 15  IN  CNAME   imap.ge.xfinity.com.
  imap.ge.xfinity.com.  12  IN  A   96.117.3.119
  imap.ge.xfinity.com.  12  IN  A   96.117.3.96
  imap.ge.xfinity.com.  12  IN  A   96.117.3.143
  imap.ge.xfinity.com.  12  IN  A   96.117.3.145
  imap.ge.xfinity.com.  12  IN  A   96.117.3.129
  imap.ge.xfinity.com.  12  IN  A   96.117.3.148
  imap.ge.xfinity.com.  12  IN  A   96.117.3.201
  imap.ge.xfinity.com.  12  IN  A   96.117.3.136
  imap.ge.xfinity.com.  12  IN  A   96.118.133.238
  imap.ge.xfinity.com.  12  IN  A   96.117.3.128
  imap.ge.xfinity.com.  12  IN  A   96.117.3.144
  imap.ge.xfinity.com.  12  IN  A   96.117.2.238
  imap.ge.xfinity.com.  12  IN  A   96.117.3.110
  imap.ge.xfinity.com.  12  IN  A   96.117.3.140
  imap.ge.xfinity.com.  12  IN  A   96.117.3.154
  imap.ge.xfinity.com.

[Touch-packages] [Bug 1811471] Re: local resolver stub fails to handle multiple TCP dns queries

Adding "options edns0" to /etc/resolv.conf ended up resolving bug
1805027 for me.

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

Title:
  local resolver stub fails to handle multiple TCP dns queries

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [Impact]

  The systemd local 'stub' resolver handles all local DNS queries (by
  default configuration used in Ubuntu), and essentially proxies all
  requests to its configured upstream DNS resolvers.

  Most local DNS resolution by applications uses glibc's getaddrinfo()
  function.  This function is configured in various ways by the
  /etc/resolv.conf file, which tells glibc what nameserver/resolver to
  contact as well as how to talk to the name server.

  By default, glibc performs UDP DNS queries, with a single DNS query
  per UDP packet.  The UDP packet size is limited per DNS spec to 512
  bytes.  For some DNS lookups, a 512 byte UDP packet is not large
  enough to contain the entire response - for example, an A record
  lookup with a large number (e.g. 30) of A record addresses.  This
  number of A record entries is possible in some cases of load
  balancing.  When the DNS UDP response size is larger than 512 bytes,
  the server puts as much response as it can into the DNS UDP response,
  and marks the "trunacted" flag.  This lets glibc know that the DNS UDP
  packet did not contain the entire response for all the A records.

  When glibc sees a UDP response that is "trunacted", by default it
  ignores the contents of that response and issues a new DNS query,
  using TCP instead of UDP.  The TCP packet size has a higher size limit
  (though see bug 1804487 which is a bug in systemd's max-sizing of TCP
  DNS packets), and so *should* allow glibc to receive the entire DNS
  response.

  However, glibc issues DNS queries for both A and  records.  When
  it uses UDP, those DNS queries are separate (i.e. one UDP DNS packet
  with a single A query, and one UDP DNS packet with a single 
  query).  When glibc uses TCP, it puts both DNS queries into a single
  TCP DNS packet - the RFC refers to this as "pipelining"
  (https://tools.ietf.org/html/rfc7766#section-6.2.1.1) and states that
  clients SHOULD do this, and that servers MUST expect to receive
  pipelined queries and SHOULD respond to all of them.  (Technically
  pipelining can be separate DNS queries, one per TCP packet, but both
  using the same TCP connection - but the clear intention of pipelining
  is to improve TCP performance, and putting both DNS queries into a
  single TCP packet is clearly more performant than using separate TCP
  packets).

  Unfortunately, systemd's local stub resolver has only very basic
  support for TCP DNS, and it handles TCP DNS queries almost identically
  to UDP DNS queries - it reads the DNS query 2-byte header (containing
  the length of the query data), reads in the single DNS query data,
  performs lookup and sends a response to that DNS query, and closes the
  TCP connection.  It does not check for "pipelined" queries in the TCP
  connection.

  That would be bad enough, as glibc is (rightly) expecting a response
  to both its A and  queries; however what glibc gets is a TCP
  connection-reset error.  That is because the local systemd stub
  resolver has closed its TCP socket while input data was still pending
  (i.e. it never even read the second pipelined DNS query).  When the
  kernel sees unread input bytes in a TCP connection that is closed, it
  sends a TCP RST to the peer (i.e. glibc) and when the kernel sees the
  RST, it dumps all data in its socket buffer and passes the ECONNRESET
  error up to the application.  So glibc gets nothing besides a
  connection reset error.

  Note also that even if the systemd local stub resolver's socket
  flushes its input buffer before closing the TCP connection (which will
  avoid the TCP RST), glibc still expects responses to both its A and
   queries before systemd closes the TCP connection, and so a simple
  change to systemd to flush the input buffer is not enough to fix the
  bug (and would also not actually fix the bug since glibc would never
  get the  response).

  [Test Case]

  This can be reproduced on any system using a local systemd stub
  resolver, when using an application that uses getaddrinfo() - such as
  ssh, telnet, ping, etc - or with a simple C program that uses
  getaddrinfo().  The dns name looked up must have enough A records to
  overflow the 512 byte maximum for a UDP DNS packet.

  Alternately, and trivially,

[Touch-packages] [Bug 1776626] Re: [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab part

** Changed in: systemd (Ubuntu Bionic)
   Status: Fix Committed => Triaged

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

Title:
  [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab
  part

Status in Ubuntu on IBM z Systems:
  In Progress
Status in cryptsetup package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cryptsetup source package in Bionic:
  New
Status in systemd source package in Bionic:
  Triaged

Bug description:
  [Impact]

   * cryptsetup in bionic supports creating luks volumes with a non-
  standard sector-size option, and thus this option also needs to be
  used when activating the LUKS volumes. Add sector-size= option support
  to /etc/crypttab.

  [Test Case]

   * Create a plain LUKS volume with sector-size 4096
   * Specify sector-size=4096 option in /etc/crypttab
   * reload systemd, start systemd-cryptsetup@.service for that volume
   * check the journal, to ensure that `sector-size` option was recognized and 
is active. (i.e. there is not error messages about unrecognized option 
`sector-size` from systemd-cryptsetup)

  [Regression Potential]

   * This is an optional argument, not used by default. Currently custom
  sector-size crypttab does not work correctly, and thus cannot regress.

  [Other Info]
   
   * Original bug report

  Support fast clear key dm-crypt with 4k support

  Extend /etc/crypttab  to enable 4k sector support in plain mode

  The proposed enhancements are posted on github, see
   https://github.com/systemd/systemd/issues/8881

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1776626/+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 939224] Re: Places menu / Nautilus side-bar ignores xdg-user-dirs

** No longer affects: nautilus (Ubuntu)

** No longer affects: unity

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

Title:
  Places menu / Nautilus side-bar ignores xdg-user-dirs

Status in gtk+3.0 package in Ubuntu:
  New

Bug description:
  Why does Ubuntu/Nautilus/Gnome not use the xdg-user-dirs info?

  I have a separate /data partition where my personal info is stored, but I 
allowed Ubuntu to set up its /home directory within / so that if/when I install 
newer Ubuntu versions or other Linux distros, the app data specific to that 
installation will not conflict with that of other distros/versions.
  I have set up xdg-user-dirs to point at my /data partition directories for 
documents, photos, etc.
  However,  when I select the Places menu, only the /home/scott installed 
documents/photos/etc. directories show up.
  I must select Computer, then when the window finally comes up (why is 
everything so slow now?),
  I can see my directories listed under the Computer heading, but the other 
non-used directories are listed first, under Bookmarks.
  While it is possible that once in a while, I might want to access the 
configuration files or whatever that apps would store in /home/scott, having 
the directories under /home/scott the only ones visible from the main Places 
menu, and the ones given pride-of-place in the Nautilus side-bar seems not to 
make much sense.

  I also take issue with the fact that other partitions that I mounted from 
/etc/fstab so that I could have easy access to them  do not come up in either 
the main Places menu or in the Nautilus side-bar, but are  accessible only by 
clicking on “File System”, and then on the individual directories in /  that 
fstab sets up.
  This includes my /data partition.
  Not only that, but two partitions that have nothing in them, and are not 
mentioned in fstab ARE available in the main Places menu AND in the Nautilus 
side-bar (each as “17 GB File System”).

  This same behavior is evident when one uses the “SaveAs” or
  “Save-A-Copy” from Evince, Gedit, LibreOffice Writer,  Eye-Of-Gnome,
  etc. (In fact, I get the impression from the similarity in windows
  that appear when the save request is made, that there is some
  universal (Gnome?) requester that all(?) apps use/modify to save
  data):  my personal directories in /data are nowhere to be seen, the
  /home directories elsewhere christened “Bookmarks” are there, and the
  two unused partitions are there also.

  Surely this behavior is nonsensical – stuff that should be easily accessible, 
isn't; stuff that is shouldn't be accessible at all (for ordinary use), is...
  The purpose of  xdg-user-dirs is to REPLACE the original 
photos/downloads/etc. locations, so one should expect to see the directories in 
(in my case)  /data/scott, in Places and Nautilus side-bar, and NOT see the 
directories in /home/scott.

  I am sure that somebody will tell me how to “fix” this issue, and I
  will be happy to accept and implement such advice, but why was this
  set up this way in the first place, and if incorrect, why has it not
  been fixed...?

  I am using Ubuntu 11.10, and usually use Gnome Classic ("Fallback Session"?), 
but the same thing seems to occur in Unity and Gnome-Shell (and I believe 
Englightenment).
  [I have since read that one can access a Places style menu in Unity by moving 
the mouse up to the top bar, but I have not tested this out yet to see what it 
shows - I suspect it will show the same info as for Classic Gnome's Places 
menu...]

  -Scott

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/939224/+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 860536] Re: Please integrate with software-center to search for new apps

The 'open with' widget is coming from gtk nowadays

** Package changed: nautilus (Ubuntu) => gtk+3.0 (Ubuntu)

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

Title:
  Please integrate with software-center to search for new apps

Status in gtk+3.0 package in Ubuntu:
  Confirmed

Bug description:
  The current "right-click/open with/other application/find applications" could 
be improved by just offering
  to launch software-center with "--search mime:text/html" (or whatever 
mime-type).

  It should probably also a bit less nested ;) Like: "open-with/Find
  available applications" or even a top-level item for this in the
  context-menu. I leave the exact location to the designers. This would
  offer all the benefits of s-c like screenshots, reviews etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/860536/+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 1811630] Re: Please merge openldap 2.4.47+dfsg-2 (main) from Debian unstable (main)

2019-01-18 Thread Andreas Hasenack

Sponsored. Migration is currently slow, as the autopkgtest queues are
large, but I'll keep an eye on it over the weekend.

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

Title:
  Please merge openldap 2.4.47+dfsg-2 (main) from Debian unstable (main)

Status in openldap package in Ubuntu:
  In Progress

Bug description:
  Hello,

  I have prepared the merge of openldap 2.4.47+dfsg-2. This will
  probably be the version released in Debian buster unless any release
  critical bugs show up.

  I made changes in Debian to how the contrib modules are built. I made
  the same changes for nssov in this merge and tested it with the
  current nss/pam-ldapd. I also added its man page which doesn't seem to
  have been included before.

  I performed a test build in a PPA:
  https://launchpad.net/~rtandy/+archive/ubuntu/openldap2.4.47

  Please consider sponsoring this update. Thank you!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1811630/+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 860536] [NEW] Please integrate with software-center to search for new apps

You have been subscribed to a public bug:

The current "right-click/open with/other application/find applications" could 
be improved by just offering
to launch software-center with "--search mime:text/html" (or whatever 
mime-type).

It should probably also a bit less nested ;) Like: "open-with/Find
available applications" or even a top-level item for this in the
context-menu. I leave the exact location to the designers. This would
offer all the benefits of s-c like screenshots, reviews etc.

** Affects: gtk+3.0 (Ubuntu)
 Importance: Wishlist
 Status: Confirmed

-- 
Please integrate with software-center to search for new apps
https://bugs.launchpad.net/bugs/860536
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to gtk+3.0 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 1783499] Re: systemd: Failed to send signal

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

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

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

Title:
  systemd: Failed to send signal

Status in dbus package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  systemd: Failed to send signal.

  [3.137257] systemd[1]: Failed to send job remove signal for 109: 
Connection reset by peer
  [3.138119] systemd[1]: run-rpc_pipefs.mount: Failed to send unit change 
signal for run-rpc_pipefs.mount: Transport endpoint is not connected
  [3.138185] systemd[1]: dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: Failed 
to send unit change signal for dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: 
Transport endpoint is not connected
  [3.138512] systemd[1]: run-rpc_pipefs.mount: Failed to send unit change 
signal for run-rpc_pipefs.mount: Transport endpoint is not connected
  [3.142719] systemd[1]: Failed to send job remove signal for 134: 
Transport endpoint is not connected
  [3.142958] systemd[1]: auth-rpcgss-module.service: Failed to send unit 
change signal for auth-rpcgss-module.service: Transport endpoint is not 
connected
  [3.165359] systemd[1]: Failed to send job remove signal for 133: 
Transport endpoint is not connected
  [3.165505] systemd[1]: proc-fs-nfsd.mount: Failed to send unit change 
signal for proc-fs-nfsd.mount: Transport endpoint is not connected
  [3.165541] systemd[1]: dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: Failed 
to send unit change signal for dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: 
Transport endpoint is not connected
  [3.166854] systemd[1]: Failed to send job remove signal for 66: Transport 
endpoint is not connected
  [3.167072] systemd[1]: proc-fs-nfsd.mount: Failed to send unit change 
signal for proc-fs-nfsd.mount: Transport endpoint is not connected
  [3.167130] systemd[1]: systemd-modules-load.service: Failed to send unit 
change signal for systemd-modules-load.service: Transport endpoint is not 
connected
  [2.929018] systemd[1]: Failed to send job remove signal for 53: Transport 
endpoint is not connected
  [2.929220] systemd[1]: systemd-random-seed.service: Failed to send unit 
change signal for systemd-random-seed.service: Transport endpoint is not 
connected
  [3.024320] systemd[1]: sys-devices-platform-serial8250-tty-ttyS12.device: 
Failed to send unit change signal for 
sys-devices-platform-serial8250-tty-ttyS12.device: Transport endpoint is not 
connected
  [3.024421] systemd[1]: dev-ttyS12.device: Failed to send unit change 
signal for dev-ttyS12.device: Transport endpoint is not connected
  [3.547019] systemd[1]: proc-sys-fs-binfmt_misc.automount: Failed to send 
unit change signal for proc-sys-fs-binfmt_misc.automount: Connection reset by 
peer
  [3.547144] systemd[1]: Failed to send job change signal for 207: 
Transport endpoint is not connected

  
  How to reproduce:
  1. enable debug level journal
  LogLevel=debug in /etc/systemd/system.conf
  2. reboot the system
  3. journalctl | grep "Failed to send"

  
  sliu@vmlxhi-094:~$ lsb_release -rd
  Description:  Ubuntu 16.04.4 LTS
  Release:  16.04

  sliu@vmlxhi-094:~$ systemctl --version
  systemd 229
  +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN

  sliu@vmlxhi-094:~$ dbus-daemon --version
  D-Bus Message Bus Daemon 1.10.6
  Copyright (C) 2002, 2003 Red Hat, Inc., CodeFactory AB, and others
  This is free software; see the source for copying conditions.
  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1783499/+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 1810346] Re: VLC interface not displayed correctly

2019-01-18 Thread Sebastian Ramacher

This looks like the typical Qt HiDPI breakage and needs to be fixed in
Qt. As a temporary workaround, disable scaling for Qt.

** Package changed: vlc (Ubuntu) => qtbase-opensource-src (Ubuntu)

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

Title:
  VLC interface not displayed correctly

Status in qtbase-opensource-src package in Ubuntu:
  New

Bug description:
  I use vlc on a Dell E-5530 laptop seated on its docking station.
  The laptop display cover is closed, the output is sent on an external LG TV 
with 1920x1080.
  This system has been working flawlessly for many years, resp. under late 
14.04 and 16.04.
  After recently upgrading to 18.04, I noticed VLC wouldn't display correctly - 
see attachment.
  This only occurs on the external display ; if I open the cover and use the 
internal display, there is no problem - except I cannot work on the internal 
display.
  regards,
  J.-Luc

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: vlc-bin 3.0.4-1ubuntu0.2
  ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18
  Uname: Linux 4.15.0-43-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Jan  2 23:38:36 2019
  ExecutablePath: /usr/bin/vlc
  InstallationDate: Installed on 2018-12-19 (14 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  ProcEnviron:
   PATH=(custom, user)
   XDG_RUNTIME_DIR=
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  SourcePackage: vlc
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1810346/+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 1783499] Re: systemd: Failed to send signal

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 dbus in Ubuntu.
https://bugs.launchpad.net/bugs/1783499

Title:
  systemd: Failed to send signal

Status in dbus package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  systemd: Failed to send signal.

  [3.137257] systemd[1]: Failed to send job remove signal for 109: 
Connection reset by peer
  [3.138119] systemd[1]: run-rpc_pipefs.mount: Failed to send unit change 
signal for run-rpc_pipefs.mount: Transport endpoint is not connected
  [3.138185] systemd[1]: dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: Failed 
to send unit change signal for dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: 
Transport endpoint is not connected
  [3.138512] systemd[1]: run-rpc_pipefs.mount: Failed to send unit change 
signal for run-rpc_pipefs.mount: Transport endpoint is not connected
  [3.142719] systemd[1]: Failed to send job remove signal for 134: 
Transport endpoint is not connected
  [3.142958] systemd[1]: auth-rpcgss-module.service: Failed to send unit 
change signal for auth-rpcgss-module.service: Transport endpoint is not 
connected
  [3.165359] systemd[1]: Failed to send job remove signal for 133: 
Transport endpoint is not connected
  [3.165505] systemd[1]: proc-fs-nfsd.mount: Failed to send unit change 
signal for proc-fs-nfsd.mount: Transport endpoint is not connected
  [3.165541] systemd[1]: dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: Failed 
to send unit change signal for dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: 
Transport endpoint is not connected
  [3.166854] systemd[1]: Failed to send job remove signal for 66: Transport 
endpoint is not connected
  [3.167072] systemd[1]: proc-fs-nfsd.mount: Failed to send unit change 
signal for proc-fs-nfsd.mount: Transport endpoint is not connected
  [3.167130] systemd[1]: systemd-modules-load.service: Failed to send unit 
change signal for systemd-modules-load.service: Transport endpoint is not 
connected
  [2.929018] systemd[1]: Failed to send job remove signal for 53: Transport 
endpoint is not connected
  [2.929220] systemd[1]: systemd-random-seed.service: Failed to send unit 
change signal for systemd-random-seed.service: Transport endpoint is not 
connected
  [3.024320] systemd[1]: sys-devices-platform-serial8250-tty-ttyS12.device: 
Failed to send unit change signal for 
sys-devices-platform-serial8250-tty-ttyS12.device: Transport endpoint is not 
connected
  [3.024421] systemd[1]: dev-ttyS12.device: Failed to send unit change 
signal for dev-ttyS12.device: Transport endpoint is not connected
  [3.547019] systemd[1]: proc-sys-fs-binfmt_misc.automount: Failed to send 
unit change signal for proc-sys-fs-binfmt_misc.automount: Connection reset by 
peer
  [3.547144] systemd[1]: Failed to send job change signal for 207: 
Transport endpoint is not connected

  
  How to reproduce:
  1. enable debug level journal
  LogLevel=debug in /etc/systemd/system.conf
  2. reboot the system
  3. journalctl | grep "Failed to send"

  
  sliu@vmlxhi-094:~$ lsb_release -rd
  Description:  Ubuntu 16.04.4 LTS
  Release:  16.04

  sliu@vmlxhi-094:~$ systemctl --version
  systemd 229
  +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN

  sliu@vmlxhi-094:~$ dbus-daemon --version
  D-Bus Message Bus Daemon 1.10.6
  Copyright (C) 2002, 2003 Red Hat, Inc., CodeFactory AB, and others
  This is free software; see the source for copying conditions.
  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1783499/+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 1801496] Re: Printing job in 16.04 is slower than in 14.04

2019-01-18 Thread Till Kamppeter

A problem I have observed in the logs is that foomatic-rip calls
Ghostscript twice here. Once to convert the PDF input into PostrScript
and then to convert the PostScript into PCL XL.

Can you please try to set up your printer with the attached PPD file?

TRhe difference to the original is the following:

--
--- 
/home/till/printing/foomatic/foomatic/foomatic-db/db/source/PPD/Ricoh/PXL/Ricoh-MP_C5503_PXL.ppd
2018-02-11 17:19:34.966351964 +0100
+++ ./Ricoh-MP_C5503_PXL.ppd2019-01-18 15:46:25.888616617 +0100
@@ -58,6 +58,10 @@
 (gs -q -dBATCH -dPARANOIDSAFER -dNOPAUSE -dNOINTERPOLATE %B%A%C %D%E | perl -p 
-e s/^\x1b\x25-12345X// | perl -p -e 
s/\xc1\x01\x00\xf8\x31\x44/\x44/g);
 (printf @PJL\n@PJL EOJ\n\033%%-12345X)"
 *End
+*FoomaticRIPCommandLinePDF: "(printf \033%%-12345X@PJL\n@PJL JOB\n@PJL 
SET COPIES=\n%G|perl -p -e s/\x26copies\x3b/1/);
+(gs -q -dBATCH -dPARANOIDSAFER -dNOPAUSE -dNOINTERPOLATE %B%A%C %D%E | perl -p 
-e s/^\x1b\x25-12345X// | perl -p -e 
s/\xc1\x01\x00\xf8\x31\x44/\x44/g);
+(printf @PJL\n@PJL EOJ\n\033%%-12345X)"
+*End
 
 *%== Basic Device Capabilities ==
--

I simply have copied the part which defines the Ghostscript command line
with the copy using the keyword "*FoomaticRIPCommandLinePDF:" instead of
"*FoomaticRIPCommandLine:". This tells foomatic-rip that the command
line is also vald for PDF input and no conversion to PostScript is
required.

If this solves the problem, I recommend to do this for all non-
PostScript PPD files.


** Attachment added: "Ricoh-MP_C5503_PXL.ppd"
   
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1801496/+attachment/5230310/+files/Ricoh-MP_C5503_PXL.ppd

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

Title:
  Printing job in 16.04 is slower than in 14.04

Status in cups package in Ubuntu:
  Incomplete

Bug description:
  Ubuntu 16.04LTS
  OS Version：   16.04.5
  CUPS Version： 2.1.3
  Ghostscript Version：  9.25 （2018-09-13）

  Printing job in 16.04 is slower than in 14.04

  We(RICOH printer driver developer) are report a problem from our printer 
users:
  I print file Ubuntu 14.04.5, CUPS 2.1.3,Ghostscript 9.25 is fast(12 Seconds).

  But, after I update to Ubuntu 16.04, CUPS 2.1.3, Ghostscript 9.25, I
  print the same file with the same driver is slow(326 Seconds).

  I figure out that all the print jobs is much slower on Ubuntu 16.04.

  I view the "CUPS Error Log",   it shows that there are three points
  which maybe the reasons that makes the print job slowly.

  
  FIRST:
  
  By counting the time from "Starting renderer" to "renderer exited with status 
0", we figure out that 16.04 spend more time than 14.04 on "renderer" process.
  So we assuming that："renderer" is one of the key process that makes the print 
job slowly.

  "Starting renderer with command: \"printf \'\\033%%-12345X@PJL 
JOB\\012\';printf \'@PJL SET DATAMODE=TWIN\\  @PJL 
EOJ\\012\\033%%-12345X\'\""
  .
  renderer exited with status 0"
  


  SECOND:
  
  On 16.04, a print job outputs lots of logs as below:
  "[Job xxx] Removing document files."

  This step(“Removing document files”)does not exsit on 14.04.
  

  
  The phenomenon that print jobs slower in 16.04 is more obvious when printing 
many jobs in the same time.

  THIRD
  We tried drivers form other company(HP,Brother…), the printings also slow 
down in Ubuntu 16.04 than 14.04.

  Our question is:
  1. Do you have any plan to improve the performance of printing on Ubuntu 
16.04?
  2. Do you have any workaround before this problems fixed?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1801496/+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 1783499] Re: systemd: Failed to send signal

2019-01-18 Thread Attila

Here at Mozilla, we have 200 servers running on HP Moonshot system, all
have same hardware configuration and Ubuntu 16.04.2. The OS is not up to
date, we use it as is was released. We using a program to tests Firefox
source code and after each test we reboot the servers using
/sbin/reboot. After a while (between 24-48h - during this period ~6
reboots/h are made), randomly, all 200 servers get stuck at the reboot -
see the ILO capture - and to bring it back we have to power cycle each
of them.

On one of the beta servers, we have made the bellow updates/changes, set debug, 
set cron to reboot server after 5-10 min, however, the reboot freeze is still 
present:
- upgraded OS to Ubuntu 16.04.5 latest packages;
- used GRUB_CMDLINE_LINUX_DEFAULT="reboot=bios" 
- used GRUB_CMDLINE_LINUX_DEFAULT="acpi=off"
- GRUB_CMDLINE_LINUX_DEFAULT="reboot=force"
- upgraded Kernel to v4.15 (the main one from Ubuntu's repo);
- upgraded Kernel to v4.20 from https://kernel.ubuntu.com/~kernel-ppa/mainline/
- now we are testing the reboot with 4.20.3 from the above repo and working to 
update systemd.

Attached you can find the debug-log for:
- kernel 4.4.0-66-generic #87-Ubuntu - shutdown-debuglogkernel-4.4.txt
- kernel 4.15 - shutdown-log-kernel4-15.txt 
- kernel 4.20 shutdown-log-kernel420.txt
- ILO capture with the freeze ILO-reboot-freeze.PNG

Please check all this logs/capture and let us know a solution. Thanks.

** Attachment added: "UbuntuBug.zip"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1783499/+attachment/5230309/+files/UbuntuBug.zip

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

Title:
  systemd: Failed to send signal

Status in dbus package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  systemd: Failed to send signal.

  [3.137257] systemd[1]: Failed to send job remove signal for 109: 
Connection reset by peer
  [3.138119] systemd[1]: run-rpc_pipefs.mount: Failed to send unit change 
signal for run-rpc_pipefs.mount: Transport endpoint is not connected
  [3.138185] systemd[1]: dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: Failed 
to send unit change signal for dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: 
Transport endpoint is not connected
  [3.138512] systemd[1]: run-rpc_pipefs.mount: Failed to send unit change 
signal for run-rpc_pipefs.mount: Transport endpoint is not connected
  [3.142719] systemd[1]: Failed to send job remove signal for 134: 
Transport endpoint is not connected
  [3.142958] systemd[1]: auth-rpcgss-module.service: Failed to send unit 
change signal for auth-rpcgss-module.service: Transport endpoint is not 
connected
  [3.165359] systemd[1]: Failed to send job remove signal for 133: 
Transport endpoint is not connected
  [3.165505] systemd[1]: proc-fs-nfsd.mount: Failed to send unit change 
signal for proc-fs-nfsd.mount: Transport endpoint is not connected
  [3.165541] systemd[1]: dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: Failed 
to send unit change signal for dev-mapper-ubuntu\x2d\x2dvg\x2droot.device: 
Transport endpoint is not connected
  [3.166854] systemd[1]: Failed to send job remove signal for 66: Transport 
endpoint is not connected
  [3.167072] systemd[1]: proc-fs-nfsd.mount: Failed to send unit change 
signal for proc-fs-nfsd.mount: Transport endpoint is not connected
  [3.167130] systemd[1]: systemd-modules-load.service: Failed to send unit 
change signal for systemd-modules-load.service: Transport endpoint is not 
connected
  [2.929018] systemd[1]: Failed to send job remove signal for 53: Transport 
endpoint is not connected
  [2.929220] systemd[1]: systemd-random-seed.service: Failed to send unit 
change signal for systemd-random-seed.service: Transport endpoint is not 
connected
  [3.024320] systemd[1]: sys-devices-platform-serial8250-tty-ttyS12.device: 
Failed to send unit change signal for 
sys-devices-platform-serial8250-tty-ttyS12.device: Transport endpoint is not 
connected
  [3.024421] systemd[1]: dev-ttyS12.device: Failed to send unit change 
signal for dev-ttyS12.device: Transport endpoint is not connected
  [3.547019] systemd[1]: proc-sys-fs-binfmt_misc.automount: Failed to send 
unit change signal for proc-sys-fs-binfmt_misc.automount: Connection reset by 
peer
  [3.547144] systemd[1]: Failed to send job change signal for 207: 
Transport endpoint is not connected

  
  How to reproduce:
  1. enable debug level journal
  LogLevel=debug in /etc/systemd/system.conf
  2. reboot the system
  3. journalctl | grep "Failed to send"

  
  sliu@vmlxhi-094:~$ lsb_release -rd
  Description:  Ubuntu 16.04.4 LTS
  Release:  16.04

  sliu@vmlxhi-094:~$ systemctl --version
  systemd 229
  +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN

[Touch-packages] [Bug 1810346] [NEW] VLC interface not displayed correctly

You have been subscribed to a public bug:

I use vlc on a Dell E-5530 laptop seated on its docking station.
The laptop display cover is closed, the output is sent on an external LG TV 
with 1920x1080.
This system has been working flawlessly for many years, resp. under late 14.04 
and 16.04.
After recently upgrading to 18.04, I noticed VLC wouldn't display correctly - 
see attachment.
This only occurs on the external display ; if I open the cover and use the 
internal display, there is no problem - except I cannot work on the internal 
display.
regards,
J.-Luc

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: vlc-bin 3.0.4-1ubuntu0.2
ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18
Uname: Linux 4.15.0-43-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Jan  2 23:38:36 2019
ExecutablePath: /usr/bin/vlc
InstallationDate: Installed on 2018-12-19 (14 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
ProcEnviron:
 PATH=(custom, user)
 XDG_RUNTIME_DIR=
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: vlc
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: qtbase-opensource-src (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic
-- 
VLC interface not displayed correctly
https://bugs.launchpad.net/bugs/1810346
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to qtbase-opensource-src 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 1656100] Re: Unable to remove signing keys using gnome-software-properties

This bug was fixed in the package software-properties - 0.96.30

---
software-properties (0.96.30) disco; urgency=medium

  [ Carlo Vanini ]
  * Fix removal of signing keys in the Authentication tab always failing.
(lp: #1656100)

 -- Sebastien Bacher   Tue, 15 Jan 2019 10:48:27
+0100

** Changed in: software-properties (Ubuntu)
   Status: Fix Committed => Fix Released

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

Title:
  Unable to remove signing keys using gnome-software-properties

Status in Ubuntu GNOME:
  Invalid
Status in software-properties package in Ubuntu:
  Fix Released

Bug description:
  I have found that on Ubuntu GNOME 16.10 with GNOME 3.22 that I am
  unable to remove signing keys in the Authentication tab. If I select a
  key I wish to remove and click the Remove button, either nothing will
  happen, or it will ask me for authentication, upon giving it the
  correct password all that will happen is it will deselect the key I
  select, but at no point will it actually remove it, which is rather
  annoying.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: software-properties-gtk 0.96.24.7
  ProcVersionSignature: Ubuntu 4.8.0-34.36-generic 4.8.11
  Uname: Linux 4.8.0-34-generic x86_64
  ApportVersion: 2.20.3-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Thu Jan 12 21:35:55 2017
  InstallationDate: Installed on 2017-01-09 (3 days ago)
  InstallationMedia: Ubuntu-GNOME 16.10 "Yakkety Yak" - Release amd64 
(20161012.1)
  PackageArchitecture: all
  SourcePackage: software-properties
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-gnome/+bug/1656100/+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 1801496] Re: Printing job in 16.04 is slower than in 14.04

2019-01-18 Thread Till Kamppeter

One thing you should test is to run Ghostscript separately. For this,
take the Ghostscript command line from the error_log and feed your PDF
file directly into it. How long does it take? Is it much faster than
running as part of the print job? Or is it more or less the same?

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

Title:
  Printing job in 16.04 is slower than in 14.04

Status in cups package in Ubuntu:
  Incomplete

Bug description:
  Ubuntu 16.04LTS
  OS Version：   16.04.5
  CUPS Version： 2.1.3
  Ghostscript Version：  9.25 （2018-09-13）

  Printing job in 16.04 is slower than in 14.04

  We(RICOH printer driver developer) are report a problem from our printer 
users:
  I print file Ubuntu 14.04.5, CUPS 2.1.3,Ghostscript 9.25 is fast(12 Seconds).

  But, after I update to Ubuntu 16.04, CUPS 2.1.3, Ghostscript 9.25, I
  print the same file with the same driver is slow(326 Seconds).

  I figure out that all the print jobs is much slower on Ubuntu 16.04.

  I view the "CUPS Error Log",   it shows that there are three points
  which maybe the reasons that makes the print job slowly.

  
  FIRST:
  
  By counting the time from "Starting renderer" to "renderer exited with status 
0", we figure out that 16.04 spend more time than 14.04 on "renderer" process.
  So we assuming that："renderer" is one of the key process that makes the print 
job slowly.

  "Starting renderer with command: \"printf \'\\033%%-12345X@PJL 
JOB\\012\';printf \'@PJL SET DATAMODE=TWIN\\  @PJL 
EOJ\\012\\033%%-12345X\'\""
  .
  renderer exited with status 0"
  


  SECOND:
  
  On 16.04, a print job outputs lots of logs as below:
  "[Job xxx] Removing document files."

  This step(“Removing document files”)does not exsit on 14.04.
  

  
  The phenomenon that print jobs slower in 16.04 is more obvious when printing 
many jobs in the same time.

  THIRD
  We tried drivers form other company(HP,Brother…), the printings also slow 
down in Ubuntu 16.04 than 14.04.

  Our question is:
  1. Do you have any plan to improve the performance of printing on Ubuntu 
16.04?
  2. Do you have any workaround before this problems fixed?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1801496/+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 1576559] Re: Refused to switch profile to headset_head_unit: Not connected

2019-01-18 Thread Tom Mercelis

Hi,

I seem to have same problem with bluetooth headset Plantronics Backbeat pro2: 
A2DP works fine, media keys work. But when switching to HSF/HFP, no playback 
and no audio from mic. 
Headset seems to switch the mode (something in the Noice cancellation audibly 
changes) when switching between A2DP and HSP/HFP profile; on occasions the 
headset "reboots" when changing mode as mentioned in the previous comment.

In
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1768625/comments/3
it was suggested this could be due to missing Headset profile, but on
this device both Headset and Handsfree profile are available.

Device E4:22:A5:XX:XX:XX (public)
Name: PLT BB PRO 2
Alias: PLT BB PRO 2
Class: 0x00240404
Icon: audio-card
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Headset   (1108--1000-8000-00805f9b34fb)
UUID: Audio Sink(110b--1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (110c--1000-8000-00805f9b34fb)
UUID: Advanced Audio Distribu.. (110d--1000-8000-00805f9b34fb)
UUID: A/V Remote Control(110e--1000-8000-00805f9b34fb)
UUID: Handsfree (111e--1000-8000-00805f9b34fb)
UUID: PnP Information   (1200--1000-8000-00805f9b34fb)
Modalias: bluetooth:v0055p0113d0110

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

Title:
  Refused to switch profile to headset_head_unit: Not connected

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  I'm trying to connect a bluetooth-speaker-with-microphone (Mi
  Bluetooth Speaker) to Ubuntu. It works well as an A2DP sync, but can't
  use it as a headset with microphone.

  The device doesn't list in the "Input Devices" by default, and using
  the sound settings to change the profile of the device to HSP/HFP
  results in this log message:

  W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to
  headset_head_unit: Not connected

  
  I'm running Ubuntu 16.04 LTS. I did an upgrade from Ubuntu 15.10.

  pulseaudio:
Installed: 1:8.0-0ubuntu3

  bluez:
Installed: 5.37-0ubuntu5

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1576559/+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 1809827] Re: --add-file broken in bionic

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

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

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

Title:
  --add-file broken in bionic

Status in tar package in Ubuntu:
  Confirmed
Status in tar package in Fedora:
  Unknown

Bug description:
  same error like this one:
  https://bugzilla.redhat.com/show_bug.cgi?id=1436030#c0

  Description of problem:
  tar supplied in bionic has --add-file option broken.

  Version-Release number of selected component:
  tar-1.29b-2_amd64

  Reproducible: Always

  Steps to Reproduce:
  1. echo >a.txt
  2. echo >b.txt
  3. tar cf a.tar a.txt
  4. tar rf a.tar --add-file=b.txt

  Actual results:
  tar: unhandled positional option 0

  Is likely fixed by this:
  
http://git.savannah.gnu.org/cgit/tar.git/commit/?id=3a283cfe9f8f1f127e8dc5597a5ea1d249985a54

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tar/+bug/1809827/+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 1760106] Re: FFe: Enable configuring resume offset via sysfs

2019-01-18 Thread Dimitri John Ledkov

klibc ftbfs on i386 in disco.

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

Title:
  FFe: Enable configuring resume offset via sysfs

Status in OEM Priority Project:
  Fix Released
Status in klibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in klibc source package in Bionic:
  New
Status in linux source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in klibc source package in Cosmic:
  New
Status in linux source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * Cannot hibernate & resume from a swapfile

  [Test Case]

   * Create or enlarge swapfile to be big enough for hibernation
   * Attempt to hibernate and resume

  [Regression Potential]

   * Hibernation is not reliable technology in itself, and multiple
  things may cause failure to resume. Thus it is sufficient to validate
  this bug after swapfile is attempted for hibernation and the disk
  offset kernel parameter is modified. Irrespective if actual suspending
  or resume were successful or not.

  [Other Info]
   
   * Original bug report

  In 4.17 a new attribute is introduced to configure the hibernation
  resume offset. Since Ubuntu enables a swapfile by default this
  attribute is important to be able to make hibernation work "out of the
  box".

  The patch in the kernel is here:
  
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=355064675f1c997cea017ea64c8f2c216e5425d9

  Systemd support for adopting this change is available here:
  https://github.com/systemd/systemd/pull/8406
  As of 3/30/18 it's not yet been merged however.

  Klibc support for adopting this change is available here:
  https://www.zytor.com/pipermail/klibc/2018-March/003986.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1760106/+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 1729432] Re: /usr/lib/tracker/tracker-extract:31:__libc_open:open:tracker_file_open_fd:get_file_content:tracker_extract_get_metadata

2019-01-18 Thread Andrea Azzarone

errors.ubuntu.com shows that 17.04 is the only affected release. I'm
closing this bug considering that 17.04 is no longer supported.

** Changed in: tracker (Ubuntu)
   Status: New => Won't Fix

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

Title:
  /usr/lib/tracker/tracker-
  
extract:31:__libc_open:open:tracker_file_open_fd:get_file_content:tracker_extract_get_metadata

Status in tracker package in Ubuntu:
  Won't Fix

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
tracker.  This problem was most recently seen with package version 
1.12.0-0ubuntu1, the problem page at 
https://errors.ubuntu.com/problem/b0761680bfed1375ae63256a0ee820ef7d451ac7 
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/tracker/+bug/1729432/+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 1729426] Re: /usr/lib/tracker/tracker-extract:31:__libc_open:open:tracker_file_open_fd:tracker_extract_get_metadata:get_file_metadata

2019-01-18 Thread Andrea Azzarone

errors.ubuntu.com shows that 17.04 is the only affected release. I'm
closing this bug considering that 17.04 is no longer supported.

** Changed in: tracker (Ubuntu)
   Status: New => Won't Fix

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

Title:
  /usr/lib/tracker/tracker-
  
extract:31:__libc_open:open:tracker_file_open_fd:tracker_extract_get_metadata:get_file_metadata

Status in tracker package in Ubuntu:
  Won't Fix

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
tracker.  This problem was most recently seen with package version 
1.12.0-0ubuntu1, the problem page at 
https://errors.ubuntu.com/problem/4b39df259d38dd7cdef459d695995c7ab6f8fa05 
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/tracker/+bug/1729426/+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 1812367] Re: Issuing right button click by xdotool does not work as expected

2019-01-18 Thread Jarno Suni

** Also affects: xorg (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Issuing right button click by xdotool does not work as expected

Status in xdotool package in Ubuntu:
  New
Status in xfce4-settings package in Ubuntu:
  New
Status in xorg package in Ubuntu:
  New

Bug description:
  'xdotool click 3' does not work. Actual left mouse button does not
  work afterwards. Using right mouse button before may help. This
  happens when I run the command as a keyboard shortcut in Xfce. If I
  use --clearmodifiers, it also happens when I use the command on
  terminal.

  Besides: if I use the command as a keyboard shortcut (in Xfce at
  least) it does not work as a right button click unless I add short
  delay by sleep command in a script before running xdotool.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: xdotool 1:3.20150503.1-2
  ProcVersionSignature: Ubuntu 4.4.0-141.167-generic 4.4.162
  Uname: Linux 4.4.0-141-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Fri Jan 18 11:29:52 2019
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2014-09-21 (1580 days ago)
  InstallationMedia: Ubuntu-Studio 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.1)
  SourcePackage: xdotool
  UpgradeStatus: Upgraded to xenial on 2018-04-14 (279 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xdotool/+bug/1812367/+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 1812132] Re: Does not return results with files that have hyphens in the filename

Thank you for your bug report. What's the output of that command on your system?
- dpkg -l | grep tracker?

Tracker is not installed by default on your version of Ubuntu, is your
issue really with it or with the dash search (which is using nautilus)?

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

** Changed in: tracker (Ubuntu)
   Status: New => 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/1812132

Title:
  Does not return results with files that have hyphens in the filename

Status in tracker package in Ubuntu:
  Incomplete

Bug description:
  On Ubuntu 18.04 using the `vanilla-gnome-desktop` session (i.e. Gnome
  Shell), tracker does not return any files if there is a hyphen (-) in
  the search string.

  To recreate:

  - Create a file named `foo-bar`.

  - Press  to open Overview.

  - Type foo. Observe that the `foo-bar` file appears.

  - Type foo-. Observe that the overview says "No results."

  This is a regression as files with hyphens in the filename were
  included in search results in 16.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/1812132/+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 1811902] Re: Echo cancelation should be enabled by default

2019-01-18 Thread Pedro Côrte-Real

Thanks for that.

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

Title:
  Echo cancelation should be enabled by default

Status in pulseaudio package in Ubuntu:
  Opinion

Bug description:
  Echo cancellation is a basic feature for anything where you are using
  a video or audio conference. According to instructions like these:

  https://bugs.launchpad.net/elementaryos/+bug/1682253
  
https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Enable_Echo/Noise-Cancellation
  
https://medium.com/@tim_73574/ubuntu-microphone-noise-cancellation-and-volume-auto-adjusted-issue-2c79678542bb

  There is now enough support in pulseaudio to do this well, but it's
  just not enabled by default. Users shouldn't need to fish around for
  strange things to add to config files. More complete defaults should
  be included.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: pulseaudio 1:11.1-1ubuntu7.1
  ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18
  Uname: Linux 4.15.0-43-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   pedrocr2684 F...m pulseaudio
   /dev/snd/controlC0:  pedrocr2684 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jan 15 23:45:10 2019
  InstallationDate: Installed on 2018-05-31 (229 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: pulseaudio
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/22/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N1CET66W (1.34 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20FAS5TS00
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.modalias: 
dmi:bvnLENOVO:bvrN1CET66W(1.34):bd03/22/2018:svnLENOVO:pn20FAS5TS00:pvrThinkPadT460s:rvnLENOVO:rn20FAS5TS00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad T460s
  dmi.product.name: 20FAS5TS00
  dmi.product.version: ThinkPad T460s
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1811902/+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 1691556] Re: Can't send audio to Amazon Echo via Bluetooth

2019-01-18 Thread Andrzej Machalski

I had the same issue with Device or resource busy and the same problem when
Alexa says that is connected to pc and no sound - but it's because your pc
becomes bluetooth speaker for Echo, in that state pacmd list-cards shows:
...
a2dp_source: Przechwytywanie o wysokiej dokładności (źródło A2DP) (priority 20,
available: yes)
a2dp_sink: Odtwarzanie o wysokiej dokładności (odpływ A2DP) (priority 40,
available: no)
off: Wyłączone (priority 0, available: yes)
...

Finally I got connected Echo as bluetooth speaker and it's working now
after reboot too.

Steps to get Echo working as bluetooth speaker that works for me:

1. Echo doesn't know anything about bluetooth connection - so first forget your
device in Alexa App, and other devices.
2. Reinstall your pulseaudio-module-bluetooth: for fedora: sudo dnf reinstall
pulseaudio-module-bluetooth
3. Uncomment MultiProfile in /etc/bluetooth/main.conf and set it to multiple.
(not sure if it is nesesery)
4. If you made modifications do:
sudo systemctl daemon-reload
sudo service bluetooth restart

5. Check if A2DPSink and source is registred with sudo service bluetooth status
6. If not do:
pacmd load-module module-bluetooth-discover
7. Reset adapter:
sudo hciconfig hci0 reset
8.Check if adapter works good: (my class is 0x1c0104)
hciconfig -a
9. Now unload pulseaudio modules:
pacmd unload-module module-switch-on-connect
pacmd unload-module module-switch-on-port-available

Now open terminal and run bluetoothctl, and in bluetoothctl type:
default-agent
remove ECHO_MAC (if you have saved it before)

Now tell to Echo "Alexa, bluetooth" and after "Searching" Echo should show in
bluetoothctl so connect it:
connect ECHO_MAC
exit

After that bluetoothctl should show that connects to echo and pairs it,
then pacmd list-cards will show a2dp_sink available yes. After reboot
when you want to connect, don't say anything to echo, just run
bluetoothctl and connect echo.

If after connect bluetoothctl doesn't show anything about pair and connect, you
can try to manualy connect to a2dp_sink with:
dbus-send --print-reply --system --dest=org.bluez
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX org.bluez.Device1.ConnectProfile
string:110b--1000-8000-00805f9b34f
Replace XX with your echo MAC.

Fedora 29, BlueZ 5.50.

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

Title:
Can't send audio to Amazon Echo via Bluetooth

Status in bluez package in Ubuntu:
Confirmed

Bug description:
Pairing and coupling to Amazon Echo works, but no sound is heard.

I believe the issue is related to the fact that Amazon Echo is paired
as a handset (i.e., speaker + microphone) rather than just as a
speaker. I believe the critical error is found in a dmesg line such
as:

Feb 28 10:59:05 n1 bluetoothd[1025]: a2dp-source profile connect
failed for 50:F5:DA:A6:3F:EA: Device or resource busy

as I describe in the askubuntu.com discussion at:

https://askubuntu.com/questions/871630/cant-send-audio-to-amazon-echo-
via-bluetooth

I have clarified there my thinking and the steps I've taken thus far
on this issue, which includes trying debug bluetooth per the Ubuntu
wiki page which describes how to do so.

This is probably an upstream issue, as Mike H-R has commented there
that the problem also occurs on ArchLinux.

I and a few others would like to get this resolved, and I am happy to
help (I'm a software developer). However, at this point, I'm not sure
how to proceed without some assistance. I suppose I could report it
to Debain, but I've only ever used Debain vis a vis Ubuntu, so I
thought it best to start here.

Thanks.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: bluez 5.37-0ubuntu5
ProcVersionSignature: Ubuntu 4.4.0-72.93-generic 4.4.49
Uname: Linux 4.4.0-72-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
CurrentDesktop: Unity
Date: Wed May 17 22:27:59 2017
InstallationDate: Installed on 2015-12-26 (507 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
InterestingModules: rfcomm bnep btusb bluetooth
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-72-generic
root=UUID=5950fbba-cde1-49ac-a918-04e517894c57 ro quiet splash vt.handoff=7
SourcePackage: bluez
UpgradeStatus: Upgraded to xenial on 2017-02-28 (78 days ago)
dmi.bios.date: 01/18/2017
dmi.bios.vendor: Intel Corporation
dmi.bios.version: RYBDWi35.86A.0362.2017.0118.0940
dmi.board.name: NUC5i5RYB
dmi.board.vendor: Intel Corporation
dmi.board.version: H40999-504
dmi.chassis.type: 3
dmi.modalias:
dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0362.2017.0118.0940:bd01/18/2017:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-504:cvn:ct3:cvr:
hciconfig:
hci0:Type: BR/EDR Bus: USB
BD Address: DC:53:60:97:55:17 ACL MTU: 1021:5 SCO MTU: 96:6
UP RUNNING PSCAN

[Touch-packages] [Bug 1801496] Re: Printing job in 16.04 is slower than in 14.04

2019-01-18 Thread William.Yeung

Dear Till,

Thank you very much for taking your time to help investigate this issue
and providing us a way to judge if "Ghostscript" causes the slowdown of
"pdftops" even when you are so busy.

If possible, can you do us a favor on the below investigation： 
We found that Ricoh PS driver does not slow down very much actually, we found 
that the drivers which uses "pxlcolor / pxlmono" slow down obviously, so we 
provided error_log of Ricoh pxlcolor driver in #9. 
You can refer to the error_log in #9 on this page.

In this log, we can see that the time interval between [Starting process
"renderer"] and [Closing renderer] really slowdown obviously in Ubuntu
16.04 than in 14.04. In the interval, there is "Running command line for
gs".

We doubted that maybe the Ghostscript causes the slow down, but the
developer of Ghostscript proved that the gs only slowdown very little
time. Please refer to
https://bugs.ghostscript.com/show_bug.cgi?id=700380

So, we doubted that maybe the module around Ghostscript(for example:
foomatic-rip) causes the slow down. Could you have a look at the log in
#9 (and later), and do some analysis when you have time?

If you have further investigation result, it’s appreciated to share with
us.

Best Regards,

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

Title:
  Printing job in 16.04 is slower than in 14.04

Status in cups package in Ubuntu:
  Incomplete

Bug description:
  Ubuntu 16.04LTS
  OS Version：   16.04.5
  CUPS Version： 2.1.3
  Ghostscript Version：  9.25 （2018-09-13）

  Printing job in 16.04 is slower than in 14.04

  We(RICOH printer driver developer) are report a problem from our printer 
users:
  I print file Ubuntu 14.04.5, CUPS 2.1.3,Ghostscript 9.25 is fast(12 Seconds).

  But, after I update to Ubuntu 16.04, CUPS 2.1.3, Ghostscript 9.25, I
  print the same file with the same driver is slow(326 Seconds).

  I figure out that all the print jobs is much slower on Ubuntu 16.04.

  I view the "CUPS Error Log",   it shows that there are three points
  which maybe the reasons that makes the print job slowly.

  
  FIRST:
  
  By counting the time from "Starting renderer" to "renderer exited with status 
0", we figure out that 16.04 spend more time than 14.04 on "renderer" process.
  So we assuming that："renderer" is one of the key process that makes the print 
job slowly.

  "Starting renderer with command: \"printf \'\\033%%-12345X@PJL 
JOB\\012\';printf \'@PJL SET DATAMODE=TWIN\\  @PJL 
EOJ\\012\\033%%-12345X\'\""
  .
  renderer exited with status 0"
  


  SECOND:
  
  On 16.04, a print job outputs lots of logs as below:
  "[Job xxx] Removing document files."

  This step(“Removing document files”)does not exsit on 14.04.
  

  
  The phenomenon that print jobs slower in 16.04 is more obvious when printing 
many jobs in the same time.

  THIRD
  We tried drivers form other company(HP,Brother…), the printings also slow 
down in Ubuntu 16.04 than 14.04.

  Our question is:
  1. Do you have any plan to improve the performance of printing on Ubuntu 
16.04?
  2. Do you have any workaround before this problems fixed?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1801496/+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 1560286] Re: Evince displays pdf file fine, but prints colors inverted

Upstream commited a fix in
https://gitlab.freedesktop.org/cairo/cairo/commit/bf597b89

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

** Changed in: evince (Ubuntu)
   Status: Confirmed => Fix Committed

** Package changed: evince (Ubuntu) => cairo (Ubuntu)

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

Title:
  Evince displays pdf file fine, but prints colors inverted

Status in cairo package in Ubuntu:
  Fix Committed

Bug description:
  I have several pdf files that when opened by evince, they appear to be fine 
until I try to print them.  When I do, they print with the colors inverted (the 
printout looks like a photograph negative).  This color inversion also occurs 
when viewed in the print preview screen.  If I click on File > Properties, I 
get some information...
  Producer : Adobe Acrobat 15.10 Image Conversion Plug-in
  Creator : Adobe Acrobat 15.10
  ...
  Format : PDF-1.6
  ...

  I am running ubuntu 14.04 LTS

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: evince 3.10.3-0ubuntu10.2
  ProcVersionSignature: Ubuntu 3.13.0-83.127-generic 3.13.11-ckt35
  Uname: Linux 3.13.0-83-generic x86_64
  NonfreeKernelModules: fglrx
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Mar 21 21:01:45 2016
  ExecutablePath: /usr/bin/evince
  InstallationDate: Installed on 2012-07-24 (1336 days ago)
  InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 
(20120425)
  ProcEnviron:
   LANGUAGE=en_US
   PATH=(custom, user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: evince
  UpgradeStatus: Upgraded to trusty on 2014-09-29 (539 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1560286/+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 1560286] [NEW] Evince displays pdf file fine, but prints colors inverted