date:20181206

** Merge proposal linked:
   
https://code.launchpad.net/~kzapalowicz/snappy-hwe-snaps/+git/network-manager/+merge/360284

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

Title:
  Out-of-Bounds write in systemd-networkd dhcpv6 option handling

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  systemd-networkd contains a DHCPv6 client which is written from
  scratch and can be spawned automatically on managed interfaces when
  IPv6 router advertisement are received:

  "Note that DHCPv6 will by default be triggered by Router Advertisement, if 
that is enabled, regardless of this parameter. By enabling DHCPv6 support 
explicitly, the DHCPv6 client will be started regardless of the presence of 
routers on the link, or what flags the routers pass" 
  (https://www.freedesktop.org/software/systemd/man/systemd.network.html)

  
  The function dhcp6_option_append_ia function is used to encode Identity 
Associations received by the server into the options buffer of an outgoing 
DHCPv6 packet:

  // 
https://github.com/systemd/systemd/blob/master/src/libsystemd-network/dhcp6-option.c#L82
  int dhcp6_option_append_ia(uint8_t **buf, size_t *buflen, DHCP6IA *ia) {
  uint16_t len;
  uint8_t *ia_hdr;
  size_t iaid_offset, ia_buflen, ia_addrlen = 0;
  DHCP6Address *addr;
  int r;

  assert_return(buf && *buf && buflen && ia, -EINVAL);

  switch (ia->type) {
  case SD_DHCP6_OPTION_IA_NA:
  len = DHCP6_OPTION_IA_NA_LEN;
  iaid_offset = offsetof(DHCP6IA, ia_na);
  break;

  case SD_DHCP6_OPTION_IA_TA:
  len = DHCP6_OPTION_IA_TA_LEN;
  iaid_offset = offsetof(DHCP6IA, ia_ta);
  break;

  default:
  return -EINVAL;
  }

  A:  if (*buflen < len)
  return -ENOBUFS;

  ia_hdr = *buf;
  ia_buflen = *buflen;

  *buf += sizeof(DHCP6Option);
  B:  *buflen -= sizeof(DHCP6Option);

  C:   memcpy(*buf, (char*) ia + iaid_offset, len);

  *buf += len;
  D:  *buflen -= len;

  E:LIST_FOREACH(addresses, addr, ia->addresses) {
  r = option_append_hdr(buf, buflen, SD_DHCP6_OPTION_IAADDR,
sizeof(addr->iaaddr));
  if (r < 0)
  return r;

  memcpy(*buf, >iaaddr, sizeof(addr->iaaddr));

  *buf += sizeof(addr->iaaddr);
  *buflen -= sizeof(addr->iaaddr);

  ia_addrlen += sizeof(DHCP6Option) + sizeof(addr->iaaddr);
  }

  r = option_append_hdr(_hdr, _buflen, ia->type, len + 
ia_addrlen);
  if (r < 0)
  return r;

  return 0;
  }

  
  The function receives a pointer to the option buffer buf, it's remaining size 
buflen and the IA to be added to the buffer. While the check at (A) tries to 
ensure that the buffer has enough space left to store the IA option, it does 
not take the additional 4 bytes from the DHCP6Option header into account (B). 
Due to this the memcpy at (C) can go out-of-bound and *buflen can underflow in 
(D) giving an attacker a very powerful and largely controlled OOB heap write 
starting at (E).

  The overflow can be triggered relatively easy by advertising a DHCPv6
  server with a server-id >= 493 characters long. This will trigger the
  following code once the client tries to create a REQUEST message:

  
//https://github.com/systemd/systemd/blob/7bcf8123c0305131ace02480763377af974924ef/src/libsystemd-network/sd-dhcp6-client.c#L493
  case DHCP6_STATE_REQUEST:
  case DHCP6_STATE_RENEW:

  if (client->state == DHCP6_STATE_REQUEST)
  message->type = DHCP6_REQUEST;
  else
  message->type = DHCP6_RENEW;

  A:  r = dhcp6_option_append(, , 
SD_DHCP6_OPTION_SERVERID,
  client->lease->serverid_len,
  client->lease->serverid);
  if (r < 0)
  return r;

  if (FLAGS_SET(client->request, DHCP6_REQUEST_IA_NA)) {
  B:  r = dhcp6_option_append_ia(, ,
 >lease->ia);
  if (r < 0)
  return r;
  }

  optlen starts with the value 512 and gets decreased to 15 (512 - 493 -
  4) after the call in A. As 15 > DHCP6_OPTION_IA_NA_LEN but 15 <
  (DHCP6_OPTION_IA_NA_LEN + 4) this triggers the memory corruption:

  # journalctl -u systemd-networkd
  Oct 03 14:27:50 ubuntu18 systemd-networkd[45095]: malloc(): memory corruption
  Oct 03 14:27:50 ubuntu18

[Touch-packages] [Bug 1807262] Re: stein unit tests fail with sqlalchemy.exc.NoSuchTableError: migration_tmp

2018-12-06 Thread Christian Ehrhardt 

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

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

Title:
  stein unit tests fail with sqlalchemy.exc.NoSuchTableError:
  migration_tmp

Status in cinder package in Ubuntu:
  Triaged
Status in nova package in Ubuntu:
  Triaged
Status in sqlite3 package in Ubuntu:
  New

Bug description:
  Several tests that use sqlite fail with:
  "sqlalchemy.exc.NoSuchTableError: migration_tmp". I'm currently
  hitting this with nova and cinder packages in disco.

  Note this started sometime after 11/19 when nova
  2:19.0.0~b1~git2018111953.3e756ff674-0ubuntu1 was uploaded (and built
  successfully at the time).

  After doing some digging this appears to occur with libsqlite3-0
  3.26.0-1 but does not occur with libsqlite3-0 3.25.3-1. Here are some
  more details on that, shown by running a failing unit test from the
  cinder package: https://paste.ubuntu.com/p/hsnQFQD572/

  Update: The test in the paste above also works successfully with
  libsqlite3-0 3.25.3-2.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cinder/+bug/1807262/+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 1698693] Re: cups-pdf blocked by apparmor

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

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

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

Title:
  cups-pdf blocked by apparmor

Status in cups package in Ubuntu:
  Expired

Bug description:
  cups-pdf cannot create the ~/PDF directory if it does not exist and
  fails with no indication to the user.

  It should however be pointed out that cups-pdf allows the system
  administrator to change it's output directory by changing the Out key
  in /etc/cups/cups-pdf.conf. As such apparmor will get in the way again
  if the admin changes the Out key to some other location outside of the
  ${HOME}/PDF directory. (It's default setting.)

  cups-pdf also does not have an #include for using local overrides in
  it's apparmor config. As such any fixes that the local admin makes
  will be overwritten by the next update to the cups package, breaking
  it again.

  
  Description:  Ubuntu 16.04.2 LTS
  Release:  16.04

  printer-driver-cups-pdf:
Installed: 2.6.1-21
Candidate: 2.6.1-21
Version table:
   *** 2.6.1-21 500
  500 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
  100 /var/lib/dpkg/status

  cups:
Installed: 2.1.3-4
Candidate: 2.1.3-4
Version table:
   *** 2.1.3-4 500
  500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  What happened:
  cups-pdf when installed for the first time fails with the following apparmor 
denials:

  [ 6117.686934] audit: type=1400 audit(1497816878.998:1079): apparmor="DENIED" 
operation="file_inherit" profile="/usr/lib/cups/backend/cups-pdf" pid=6015 
comm="cups-pdf" family="unix" sock_type="stream" protocol=0 
requested_mask="send receive" denied_mask="send receive" addr=none 
peer_addr=none peer="/usr/sbin/cupsd"
  [ 6117.686948] audit: type=1400 audit(1497816878.998:1080): apparmor="DENIED" 
operation="file_inherit" profile="/usr/sbin/cupsd" pid=6015 comm="cups-pdf" 
family="unix" sock_type="stream" protocol=0 requested_mask="send receive" 
denied_mask="send receive" addr=none peer_addr=none 
peer="/usr/lib/cups/backend/cups-pdf"
  [ 6117.688671] audit: type=1400 audit(1497816879.002:1081): apparmor="DENIED" 
operation="open" profile="/usr/lib/cups/backend/cups-pdf" 
name="/var/lib/sss/mc/initgroups" pid=6015 comm="cups-pdf" requested_mask="r" 
denied_mask="r" fsuid=0 ouid=0
  [ 6117.688688] audit: type=1400 audit(1497816879.002:1082): apparmor="DENIED" 
operation="open" profile="/usr/lib/cups/backend/cups-pdf" 
name="/var/lib/sss/mc/initgroups" pid=6015 comm="cups-pdf" requested_mask="r" 
denied_mask="r" fsuid=0 ouid=0
  [ 6117.689719] audit: type=1400 audit(1497816879.002:1083): apparmor="DENIED" 
operation="mkdir" profile="/usr/lib/cups/backend/cups-pdf" 
name="/home/CODENET.LOCAL/codebase/PDF/" pid=6015 comm="cups-pdf" 
requested_mask="c" denied_mask="c" fsuid=0 ouid=0

  
  What I expected to happen:
  cups-pdf creates the pdf file it was supposed to.

  
  As a workaround, I set cups-pdf to use the third-party settings from the cups 
profile, then it worked as expected.
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CupsErrorLog: Error: [Errno 13] Permission denied: '/var/log/cups/error_log'
  CurrentDesktop: MATE
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2017-11-24 (281 days ago)
  InstallationMedia: Ubuntu-MATE 17.10 "Artful Aardvark" - Release amd64 
(20171018)
  Lpstat:
   device for EPSONET-4550: 
ipp://call.codenet.local:631/printers/EPSON_ET-4550_Series
   device for PDF: cups-pdf:/
  MachineType: Gigabyte Technology Co., Ltd. A320M-S2H
  NonfreeKernelModules: nvidia_modeset nvidia
  Package: cups 2.2.7-1ubuntu2.1
  PackageArchitecture: amd64
  Papersize: letter
  PpdFiles: Error: command ['fgrep', '-H', '*NickName', 
'/etc/cups/ppd/PDF.ppd'] failed with exit code 2: grep: /etc/cups/ppd/PDF.ppd: 
Permission denied
  ProcCmdline: BOOT_IMAGE=/vmlinuz-4.15.0-33-generic 
root=UUID=b719b98c-6702-467b-bad1-38f7ecaed813 ro video=vesafb:off vga=normal 
quiet splash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-33-generic 
root=UUID=b719b98c-6702-467b-bad1-38f7ecaed813 ro video=vesafb:off vga=normal 
quiet splash
  ProcVersionSignature: Ubuntu 4.15.0-33.36-generic 4.15.18
  Tags:  bionic apparmor apparmor apparmor apparmor
  Uname: Linux 4.15.0-33-generic x86_64
  UpgradeStatus: Upgraded to bionic on 2018-05-20 (104 days ago)
  UserGroups:
   
  _MarkForUpload: True
  dmi.bios.date: 02/08/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F21
  dmi.board.asset.tag: Default string
  dmi.board.name: A320M-S2H-CF
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: x.x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3

[Touch-packages] [Bug 1795853] Re: Assembler crashes when building ndiswrapper

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

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

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

Title:
  Assembler crashes when building ndiswrapper

Status in binutils package in Ubuntu:
  Expired

Bug description:
  > lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04

  --
  > apt-cache policy ndiswrapper-dkms
  ndiswrapper-dkms:
Installato: 1.60-6
Candidato:  1.60-6
Tabella versione:
   *** 1.60-6 500
  500 http://it.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
  500 http://it.archive.ubuntu.com/ubuntu bionic/universe i386 Packages
  100 /var/lib/dpkg/status

  --
  when installing via apt-get:

  Loading new ndiswrapper-1.60 DKMS files...
  Building for 4.15.0-34-generic 4.15.0-36-generic
  Building initial module for 4.15.0-34-generic
  Done.

  ndiswrapper:
  Running module version sanity check.
   - Original module
 - No original module exists within this kernel
   - Installation
 - Installing to /lib/modules/4.15.0-34-generic/updates/dkms/

  depmod...

  DKMS: install completed.
  Building initial module for 4.15.0-36-generic
  Error! Bad return status for module build on kernel: 4.15.0-36-generic 
(x86_64)
  Consult /var/lib/dkms/ndiswrapper/1.60/build/make.log for more information.

  ---
  contents of the log file:
  DKMS make.log for ndiswrapper-1.60 for kernel 4.15.0-36-generic (x86_64)
  mer  3 ott 2018, 12.29.37, CEST
  make: ingresso nella directory "/usr/src/linux-headers-4.15.0-36-generic"
MKEXPORT /var/lib/dkms/ndiswrapper/1.60/build/crt_exports.h
MKEXPORT /var/lib/dkms/ndiswrapper/1.60/build/hal_exports.h
MKEXPORT /var/lib/dkms/ndiswrapper/1.60/build/ndis_exports.h
MKEXPORT /var/lib/dkms/ndiswrapper/1.60/build/ntoskernel_exports.h
MKEXPORT /var/lib/dkms/ndiswrapper/1.60/build/ntoskernel_io_exports.h
MKEXPORT /var/lib/dkms/ndiswrapper/1.60/build/rtl_exports.h
MKEXPORT /var/lib/dkms/ndiswrapper/1.60/build/usb_exports.h
MKSTUBS /var/lib/dkms/ndiswrapper/1.60/build/win2lin_stubs.h
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/crt.o
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/hal.o
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/iw_ndis.o
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/loader.o
  symbolmap: sezione: invalid section
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/ndis.o
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/ntoskernel.o
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/ntoskernel_io.o
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/pe_linker.o
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/pnp.o
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/proc.o
  symbolmap: sezione: invalid section
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/rtl.o
  symbolmap: sezione: invalid section
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/wrapmem.o
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/wrapndis.o
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/wrapper.o
  Assembler messages:
  Internal error (Errore di segmentazione).
  Please report this bug.
CC [M]  /var/lib/dkms/ndiswrapper/1.60/build/usb.o
AS [M]  /var/lib/dkms/ndiswrapper/1.60/build/win2lin_stubs.o
  scripts/Makefile.build:332: recipe for target 
'/var/lib/dkms/ndiswrapper/1.60/build/wrapper.o' failed
  make[1]: *** [/var/lib/dkms/ndiswrapper/1.60/build/wrapper.o] Error 2
  make[1]: *** Attesa per i processi non terminati
  symbolmap: sezione: invalid section
  symbolmap: sezione: invalid section
  Makefile:1551: recipe for target 
'_module_/var/lib/dkms/ndiswrapper/1.60/build' failed
  make: *** [_module_/var/lib/dkms/ndiswrapper/1.60/build] Error 2
  make: uscita dalla directory "/usr/src/linux-headers-4.15.0-36-generic"

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: ndiswrapper-dkms 1.60-6
  ProcVersionSignature: Ubuntu 4.15.0-34.37-generic 4.15.18
  Uname: Linux 4.15.0-34-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  DKMSKernelVersion: 4.15.0-36-generic
  Date: Wed Oct  3 12:29:45 2018
  InstallationDate: Installed on 2016-01-25 (981 days ago)
  InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
  PackageArchitecture: all
  PackageVersion: 1.60-6
  Python3Details: /usr/bin/python3.6, Python 3.6.6, python3-minimal, 
3.6.5-3ubuntu1
  PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 
2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2
   apt  1.6.3ubuntu0.1
  SourcePackage: ndiswrapper
  Title: ndiswrapper-dkms 1.60-6: ndiswrapper kernel module failed to build
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage

[Touch-packages] [Bug 1807288] Re: mkfs.ext4 -d $directory_with_acls leads to EINVAL

2018-12-06 Thread Ubuntu Foundations Team Bug Bot

The attachment "0001-libext2fs-fix-regression-so-we-are-correctly-
transla.patch" seems to be a patch.  If it isn't, please remove the
"patch" flag from the attachment, remove the "patch" tag, and if you are
a member of the ~ubuntu-reviewers, unsubscribe the team.

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

** Tags added: patch

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

Title:
  mkfs.ext4 -d $directory_with_acls leads to EINVAL

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  This looks an awful lot like bug 1645232 but that is claimed to be
  fixed:

  mwhudson@ringil:~/tmp$ mkfs.ext4 -V
  mke2fs 1.44.1 (24-Mar-2018)
Using EXT2FS Library version 1.44.1
  mwhudson@ringil:~/tmp$ dd if=/dev/zero count=0 bs=1M seek=100 of=./fake.img
  0+0 records in
  0+0 records out
  0 bytes copied, 0.0015871 s, 0.0 kB/s
  mwhudson@ringil:~/tmp$ mkdir -p stuff/journal
  mwhudson@ringil:~/tmp$ setfacl -m g:adm:rwx stuff/journal
  mwhudson@ringil:~/tmp$ mkfs.ext4 -L lala -O -metadata_csum -T default -O 
uninit_bg fake.img -d ./stuff/
  mke2fs 1.44.1 (24-Mar-2018)
  Discarding device blocks: done
  Creating filesystem with 25600 4k blocks and 6400 inodes

  Allocating group tables: done
  Writing inode tables: done
  Creating journal (1024 blocks): done
  Copying files into the device: done
  Writing superblocks and filesystem accounting information: done

  mwhudson@ringil:~/tmp$ sudo mount ./fake.img /mnt
  mwhudson@ringil:~/tmp$ getfacl /mnt/journal/
  getfacl: /mnt/journal/: Invalid argument

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

2018-12-06 Thread Ubuntu Foundations Team Bug Bot

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

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

** Tags added: patch

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

Title:
  Sort - Checking & Handling File Types

Status in coreutils package in Ubuntu:
  New

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 1807294] Re: package libgme0 0.5.5-2ubuntu0.14.04.1 failed to install/upgrade: cannot copy extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to '/usr/lib/i386-linux-g

2018-12-06 Thread Ubuntu Foundations Team Bug Bot

Thank you for taking the time to report this bug and helping to make
Ubuntu better.  It seems that there was an error on your system when
trying to install a particular package.  Please execute the following
command, as it will clear your package cache, in a terminal:

sudo apt-get clean

Then try performing the update again.  This will likely resolve your
issue, but the failure could be caused by filesystem or memory
corruption.  So please also run a fsck on your filesystem(s) and a
memory test.  Thanks in advance!

[This is an automated message.  I apologize if it reached you
inappropriately; please just reply to this message indicating so.]

** Tags added: corrupted-package

** Changed in: game-music-emu (Ubuntu)
   Status: New => Invalid

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

Title:
  package libgme0 0.5.5-2ubuntu0.14.04.1 failed to install/upgrade:
  cannot copy extracted data for './usr/lib/i386-linux-
  gnu/libgme.so.0.6.0' to '/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-
  new': unexpected end of file or stream

Status in game-music-emu package in Ubuntu:
  Invalid

Bug description:
  would not install while attempting to install Ubuntu update

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: libgme0 0.5.5-2ubuntu0.14.04.1
  ProcVersionSignature: Ubuntu 4.4.0-31.50~14.04.1-generic 4.4.13
  Uname: Linux 4.4.0-31-generic i686
  ApportVersion: 2.14.1-0ubuntu3.29
  Architecture: i386
  Date: Thu Dec  6 19:46:42 2018
  DuplicateSignature: package:libgme0:0.5.5-2ubuntu0.14.04.1:cannot copy 
extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
  ErrorMessage: cannot copy extracted data for 
'./usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
  InstallationDate: Installed on 2018-12-06 (0 days ago)
  InstallationMedia: Ubuntu 14.04.5 LTS "Trusty Tahr" - Release i386 (20160803)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.5
   apt  1.0.1ubuntu2.18
  SourcePackage: game-music-emu
  Title: package libgme0 0.5.5-2ubuntu0.14.04.1 failed to install/upgrade: 
cannot copy extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
  UpgradeStatus: Upgraded to xenial on 2018-12-07 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/game-music-emu/+bug/1807294/+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 1807288] Re: mkfs.ext4 -d $directory_with_acls leads to EINVAL

2018-12-06 Thread Theodore Ts'o

Yep, it looks like it was a regression that was introduced by commit
50d0998cfee ("libext2fs: add ea_inode support to set xattr").   The
following patch should fix things.


** Patch added: 
"0001-libext2fs-fix-regression-so-we-are-correctly-transla.patch"
   
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1807288/+attachment/5219885/+files/0001-libext2fs-fix-regression-so-we-are-correctly-transla.patch

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

Title:
  mkfs.ext4 -d $directory_with_acls leads to EINVAL

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  This looks an awful lot like bug 1645232 but that is claimed to be
  fixed:

  mwhudson@ringil:~/tmp$ mkfs.ext4 -V
  mke2fs 1.44.1 (24-Mar-2018)
Using EXT2FS Library version 1.44.1
  mwhudson@ringil:~/tmp$ dd if=/dev/zero count=0 bs=1M seek=100 of=./fake.img
  0+0 records in
  0+0 records out
  0 bytes copied, 0.0015871 s, 0.0 kB/s
  mwhudson@ringil:~/tmp$ mkdir -p stuff/journal
  mwhudson@ringil:~/tmp$ setfacl -m g:adm:rwx stuff/journal
  mwhudson@ringil:~/tmp$ mkfs.ext4 -L lala -O -metadata_csum -T default -O 
uninit_bg fake.img -d ./stuff/
  mke2fs 1.44.1 (24-Mar-2018)
  Discarding device blocks: done
  Creating filesystem with 25600 4k blocks and 6400 inodes

  Allocating group tables: done
  Writing inode tables: done
  Creating journal (1024 blocks): done
  Copying files into the device: done
  Writing superblocks and filesystem accounting information: done

  mwhudson@ringil:~/tmp$ sudo mount ./fake.img /mnt
  mwhudson@ringil:~/tmp$ getfacl /mnt/journal/
  getfacl: /mnt/journal/: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1807288/+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 1805978] Re: ubuntu_lxc test is failed with lxc-utils package not installed

2018-12-06 Thread Po-Hsu Lin

** Tags added: bionic

** Tags added: package-from-proposed

** Changed in: ubuntu-kernel-tests
   Status: In Progress => Confirmed

** Changed in: ubuntu-kernel-tests
 Assignee: Po-Hsu Lin (cypressyew) => (unassigned)

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

Title:
  ubuntu_lxc test is failed with lxc-utils package not installed

Status in ubuntu-kernel-tests:
  Confirmed
Status in lxc package in Ubuntu:
  New

Bug description:
  On Bionic since Nov.29,
  the ubuntu_lxc test is failing with:

   Running 'apt-get install --yes automake autopkgtest build-essential 
cloud-image-utils dh-autoreconf lxc texinfo gcc-multilib liblxc1'
   [stdout] Reading package lists...
   [stdout] Building dependency tree...
   [stdout] Reading state information...
   [stdout] liblxc1 is already the newest version (3.0.3-0ubuntu1~18.04.1).
   [stdout] Some packages could not be installed. This may mean that you have
   [stdout] requested an impossible situation or if you are using the unstable
   [stdout] distribution that some required packages have not yet been created
   [stdout] or been moved out of Incoming.
   [stdout] The following information may help to resolve the situation:
   [stdout]
   [stdout] The following packages have unmet dependencies:
   [stdout] lxc : Depends: lxc-utils (>= 3.0.2-0ubuntu1~18.04.1) but it is not 
going to be installed
   [stderr] E: Unable to correct problems, you have held broken packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1805978/+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 1805978] Re: ubuntu_lxc test is failed with lxc-utils package not installed

2018-12-06 Thread Po-Hsu Lin

I can see this issue again, seems that there is another new update for
it...

Running 'apt-get install --yes automake autopkgtest build-essential 
cloud-image-utils dh-autoreconf lxc lxc-utils texinfo gcc-multilib liblxc1'
 Reading package lists...
 Building dependency tree...
 Reading state information...
 liblxc1 is already the newest version (3.0.3-0ubuntu1~18.04.1).
 Some packages could not be installed. This may mean that you have
 requested an impossible situation or if you are using the unstable
 distribution that some required packages have not yet been created
 or been moved out of Incoming.
 The following information may help to resolve the situation:
 
 The following packages have unmet dependencies:
  lxc-utils : Depends: liblxc1 (= 3.0.2-0ubuntu1~18.04.1) but 
3.0.3-0ubuntu1~18.04.1 is to be installed
  Recommends: libpam-cgfs but it is not going to be installed
 E: Unable to correct problems, you have held broken packages.


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

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

Title:
  ubuntu_lxc test is failed with lxc-utils package not installed

Status in ubuntu-kernel-tests:
  In Progress
Status in lxc package in Ubuntu:
  New

Bug description:
  On Bionic since Nov.29,
  the ubuntu_lxc test is failing with:

   Running 'apt-get install --yes automake autopkgtest build-essential 
cloud-image-utils dh-autoreconf lxc texinfo gcc-multilib liblxc1'
   [stdout] Reading package lists...
   [stdout] Building dependency tree...
   [stdout] Reading state information...
   [stdout] liblxc1 is already the newest version (3.0.3-0ubuntu1~18.04.1).
   [stdout] Some packages could not be installed. This may mean that you have
   [stdout] requested an impossible situation or if you are using the unstable
   [stdout] distribution that some required packages have not yet been created
   [stdout] or been moved out of Incoming.
   [stdout] The following information may help to resolve the situation:
   [stdout]
   [stdout] The following packages have unmet dependencies:
   [stdout] lxc : Depends: lxc-utils (>= 3.0.2-0ubuntu1~18.04.1) but it is not 
going to be installed
   [stderr] E: Unable to correct problems, you have held broken packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1805978/+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] [NEW] Sort - Checking & Handling File Types

2018-12-06 Thread Amit Biswas

Public bug reported:

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

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


** Tags: file sort type

** Patch added: "patch for checking file type"
   
https://bugs.launchpad.net/bugs/1807295/+attachment/5219857/+files/file_type_check.patch

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

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 1807294] Re: package libgme0 0.5.5-2ubuntu0.14.04.1 failed to install/upgrade: cannot copy extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to '/usr/lib/i386-linux-g

2018-12-06 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 game-music-emu in Ubuntu.
https://bugs.launchpad.net/bugs/1807294

Title:
  package libgme0 0.5.5-2ubuntu0.14.04.1 failed to install/upgrade:
  cannot copy extracted data for './usr/lib/i386-linux-
  gnu/libgme.so.0.6.0' to '/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-
  new': unexpected end of file or stream

Status in game-music-emu package in Ubuntu:
  New

Bug description:
  would not install while attempting to install Ubuntu update

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: libgme0 0.5.5-2ubuntu0.14.04.1
  ProcVersionSignature: Ubuntu 4.4.0-31.50~14.04.1-generic 4.4.13
  Uname: Linux 4.4.0-31-generic i686
  ApportVersion: 2.14.1-0ubuntu3.29
  Architecture: i386
  Date: Thu Dec  6 19:46:42 2018
  DuplicateSignature: package:libgme0:0.5.5-2ubuntu0.14.04.1:cannot copy 
extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
  ErrorMessage: cannot copy extracted data for 
'./usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
  InstallationDate: Installed on 2018-12-06 (0 days ago)
  InstallationMedia: Ubuntu 14.04.5 LTS "Trusty Tahr" - Release i386 (20160803)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.5
   apt  1.0.1ubuntu2.18
  SourcePackage: game-music-emu
  Title: package libgme0 0.5.5-2ubuntu0.14.04.1 failed to install/upgrade: 
cannot copy extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
  UpgradeStatus: Upgraded to xenial on 2018-12-07 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/game-music-emu/+bug/1807294/+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 1807294] [NEW] package libgme0 0.5.5-2ubuntu0.14.04.1 failed to install/upgrade: cannot copy extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to '/usr/lib/i386-linux

2018-12-06 Thread Ken Jones

Public bug reported:

would not install while attempting to install Ubuntu update

ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: libgme0 0.5.5-2ubuntu0.14.04.1
ProcVersionSignature: Ubuntu 4.4.0-31.50~14.04.1-generic 4.4.13
Uname: Linux 4.4.0-31-generic i686
ApportVersion: 2.14.1-0ubuntu3.29
Architecture: i386
Date: Thu Dec  6 19:46:42 2018
DuplicateSignature: package:libgme0:0.5.5-2ubuntu0.14.04.1:cannot copy 
extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
ErrorMessage: cannot copy extracted data for 
'./usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
InstallationDate: Installed on 2018-12-06 (0 days ago)
InstallationMedia: Ubuntu 14.04.5 LTS "Trusty Tahr" - Release i386 (20160803)
RelatedPackageVersions:
 dpkg 1.18.4ubuntu1.5
 apt  1.0.1ubuntu2.18
SourcePackage: game-music-emu
Title: package libgme0 0.5.5-2ubuntu0.14.04.1 failed to install/upgrade: cannot 
copy extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
UpgradeStatus: Upgraded to xenial on 2018-12-07 (0 days ago)

** Affects: game-music-emu (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: apport-package i386 need-duplicate-check xenial

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

Title:
  package libgme0 0.5.5-2ubuntu0.14.04.1 failed to install/upgrade:
  cannot copy extracted data for './usr/lib/i386-linux-
  gnu/libgme.so.0.6.0' to '/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-
  new': unexpected end of file or stream

Status in game-music-emu package in Ubuntu:
  New

Bug description:
  would not install while attempting to install Ubuntu update

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: libgme0 0.5.5-2ubuntu0.14.04.1
  ProcVersionSignature: Ubuntu 4.4.0-31.50~14.04.1-generic 4.4.13
  Uname: Linux 4.4.0-31-generic i686
  ApportVersion: 2.14.1-0ubuntu3.29
  Architecture: i386
  Date: Thu Dec  6 19:46:42 2018
  DuplicateSignature: package:libgme0:0.5.5-2ubuntu0.14.04.1:cannot copy 
extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
  ErrorMessage: cannot copy extracted data for 
'./usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
  InstallationDate: Installed on 2018-12-06 (0 days ago)
  InstallationMedia: Ubuntu 14.04.5 LTS "Trusty Tahr" - Release i386 (20160803)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.5
   apt  1.0.1ubuntu2.18
  SourcePackage: game-music-emu
  Title: package libgme0 0.5.5-2ubuntu0.14.04.1 failed to install/upgrade: 
cannot copy extracted data for './usr/lib/i386-linux-gnu/libgme.so.0.6.0' to 
'/usr/lib/i386-linux-gnu/libgme.so.0.6.0.dpkg-new': unexpected end of file or 
stream
  UpgradeStatus: Upgraded to xenial on 2018-12-07 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/game-music-emu/+bug/1807294/+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 1807288] Re: mkfs.ext4 -d $directory_with_acls leads to EINVAL

Also reproducible without the -O options.

Can confirm that this works with e2fslibs from e2fsprogs 1.43.4:

$ dpkg -x ./e2fslibs_1.43.4-2_amd64.deb e2fsprogs
$ LD_LIBRARY_PATH=./e2fsprogs/lib/x86_64-linux-gnu/ e2fsprogs/sbin/mkfs.ext4 -L 
lala -T default fake.img -d ./stuff/
$ sudo mount ./fake.img /mnt
$ getfacl /mnt/journal/
getfacl: Removing leading '/' from absolute path names
# file: mnt/journal/
# owner: vorlon
# group: vorlon
user::rwx
group::r-x
group:adm:rwx
mask::rwx
other::r-x

$ sudo umount /mnt
$

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

Title:
  mkfs.ext4 -d $directory_with_acls leads to EINVAL

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  This looks an awful lot like bug 1645232 but that is claimed to be
  fixed:

  mwhudson@ringil:~/tmp$ mkfs.ext4 -V
  mke2fs 1.44.1 (24-Mar-2018)
Using EXT2FS Library version 1.44.1
  mwhudson@ringil:~/tmp$ dd if=/dev/zero count=0 bs=1M seek=100 of=./fake.img
  0+0 records in
  0+0 records out
  0 bytes copied, 0.0015871 s, 0.0 kB/s
  mwhudson@ringil:~/tmp$ mkdir -p stuff/journal
  mwhudson@ringil:~/tmp$ setfacl -m g:adm:rwx stuff/journal
  mwhudson@ringil:~/tmp$ mkfs.ext4 -L lala -O -metadata_csum -T default -O 
uninit_bg fake.img -d ./stuff/
  mke2fs 1.44.1 (24-Mar-2018)
  Discarding device blocks: done
  Creating filesystem with 25600 4k blocks and 6400 inodes

  Allocating group tables: done
  Writing inode tables: done
  Creating journal (1024 blocks): done
  Copying files into the device: done
  Writing superblocks and filesystem accounting information: done

  mwhudson@ringil:~/tmp$ sudo mount ./fake.img /mnt
  mwhudson@ringil:~/tmp$ getfacl /mnt/journal/
  getfacl: /mnt/journal/: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1807288/+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 1807288] [NEW] mkfs.ext4 -d $directory_with_acls leads to EINVAL

2018-12-06 Thread Michael Hudson-Doyle

Public bug reported:

This looks an awful lot like bug 1645232 but that is claimed to be
fixed:

mwhudson@ringil:~/tmp$ mkfs.ext4 -V
mke2fs 1.44.1 (24-Mar-2018)
Using EXT2FS Library version 1.44.1
mwhudson@ringil:~/tmp$ dd if=/dev/zero count=0 bs=1M seek=100 of=./fake.img
0+0 records in
0+0 records out
0 bytes copied, 0.0015871 s, 0.0 kB/s
mwhudson@ringil:~/tmp$ mkdir -p stuff/journal
mwhudson@ringil:~/tmp$ setfacl -m g:adm:rwx stuff/journal
mwhudson@ringil:~/tmp$ mkfs.ext4 -L lala -O -metadata_csum -T default -O 
uninit_bg fake.img -d ./stuff/
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 25600 4k blocks and 6400 inodes

Allocating group tables: done
Writing inode tables: done
Creating journal (1024 blocks): done
Copying files into the device: done
Writing superblocks and filesystem accounting information: done

mwhudson@ringil:~/tmp$ sudo mount ./fake.img /mnt
mwhudson@ringil:~/tmp$ getfacl /mnt/journal/
getfacl: /mnt/journal/: Invalid argument

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

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

Title:
  mkfs.ext4 -d $directory_with_acls leads to EINVAL

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  This looks an awful lot like bug 1645232 but that is claimed to be
  fixed:

  mwhudson@ringil:~/tmp$ mkfs.ext4 -V
  mke2fs 1.44.1 (24-Mar-2018)
Using EXT2FS Library version 1.44.1
  mwhudson@ringil:~/tmp$ dd if=/dev/zero count=0 bs=1M seek=100 of=./fake.img
  0+0 records in
  0+0 records out
  0 bytes copied, 0.0015871 s, 0.0 kB/s
  mwhudson@ringil:~/tmp$ mkdir -p stuff/journal
  mwhudson@ringil:~/tmp$ setfacl -m g:adm:rwx stuff/journal
  mwhudson@ringil:~/tmp$ mkfs.ext4 -L lala -O -metadata_csum -T default -O 
uninit_bg fake.img -d ./stuff/
  mke2fs 1.44.1 (24-Mar-2018)
  Discarding device blocks: done
  Creating filesystem with 25600 4k blocks and 6400 inodes

  Allocating group tables: done
  Writing inode tables: done
  Creating journal (1024 blocks): done
  Copying files into the device: done
  Writing superblocks and filesystem accounting information: done

  mwhudson@ringil:~/tmp$ sudo mount ./fake.img /mnt
  mwhudson@ringil:~/tmp$ getfacl /mnt/journal/
  getfacl: /mnt/journal/: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1807288/+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 1806463] Re: Unattended-Upgrade::InstallOnShutdown "true" not working

2018-12-06 Thread Justin V

After reading the NEWS file, it seems that it is necessary for the dbus
signal to be sent first, at which point the upgrade begins.  Next, the
SIGTERM is received, but the upgrade has already started.  So, "shutdown
-r now" will not trigger an upgrade.

I'll need some time to be able to experiment with a reboot.  I was doing
"shutdown -r now".  Also, I am using xfce, so maybe it is not sending a
signal (either).

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

Title:
  Unattended-Upgrade::InstallOnShutdown "true" not working

Status in unattended-upgrades package in Ubuntu:
  Incomplete

Bug description:
  Cosmic, unattended-upgrades 1.5ubuntu3.18.10.0

  Trying to get install-on-shutdown working.  Added << Unattended-
  Upgrade::InstallOnShutdown "true"; >> to apt.conf.

  It appears that the logic for install-on-shutdown is in /usr/share
  /unattended-upgrades/unattended-upgrade-shutdown.  The logic for run-
  on-shutdown is in UnattendedUpgradesShutdown.try_iter_on_shutdown,
  which is only called by iter "if not
  self.stop_signal_received.is_set()".  However, since --wait-for-signal
  is true, it waits for a signal, then the iter says "signal recieved,
  so skip upgrade":

  1. apt.conf: Unattended-Upgrade::InstallOnShutdown "true" (though, unused)
  2. unattended-upgrades.service: .../unattended-upgrade-shutdown 
--wait-for-signal
  3. UnattendedUpgradesShutdown.run: signal_handler is installed; wait.
  4. UUS.run.signal_handler: stop_signal_received.set(); start_iterations()
  5. UUS.start_iterations: scheduler timer to call self.iter
  6. UUS.iter: not self.stop_signal_received.is_set() is always False
  7. UUS.try_iter_on_shutdown is never called

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1806463/+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 1751252] Re: [regression] ubiquity crashed in debconf.py:104 with ValueError: invalid literal for int() with base 10: ''

2018-12-06 Thread Seyed Mustafa Afzouni

In the Live Version on MacBook Pro 2015 (13 inches, Retina) I changed
the 'Screen Scale' from 200% to 100%, settings > Device > Display, and
solved!

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

Title:
  [regression] ubiquity crashed in debconf.py:104 with ValueError:
  invalid literal for int() with base 10: ''

Status in cairo:
  Unknown
Status in OEM Priority Project:
  Fix Released
Status in cairo package in Ubuntu:
  In Progress
Status in ubiquity package in Ubuntu:
  Fix Released
Status in ubiquity source package in Bionic:
  Fix Released

Bug description:
  * Impact
  The Ubuntu installer crashes on some machines (seems more often on hiDPI 
machines (QHD/UHD etc)).

  * Test case
  Try installing Ubuntu on an hidpi machine, it should complete installation 
instead of crashing.

  * Regression potential
  The fix in ubiquity touches the code handle uid drop/privilege, that can have 
unexpected side effects so we need proper/complete testing of the installer

  --

  Update: Actually the crash occurs on slow-ish systems due to a race
  condition. It's not strictly only hi-DPI machines - that's just the
  most common place it is experienced.

  ---

  https://errors.ubuntu.com/problem/82f7f7e7923663c7b2123c7f1f49af29f6ff4d77
  https://errors.ubuntu.com/problem/735a2b847e0eeab6c8a7b954de5110e43889be15
  https://errors.ubuntu.com/problem/dcd4c9da5ee0cc6d36324446e0e49d39705c90b7
  https://errors.ubuntu.com/problem/cb82f70f9ede07369e8104da9ddf87e28b42257d
  https://errors.ubuntu.com/problem/84a5563af3d2b85f098da832ece4cb8450bfd524

  ---

  WORKAROUND:

  1. Boot into the live session.
  2. Settings > Devices > Displays > Scale = 100%
  3. Click Apply.
  4. Proceed with installation: Click "Install Ubuntu 18.04 LTS".

  ---

  Crashed in a VM in the middle of installation. The host is Bionic up
  to date.

  From the journal
  Feb 23 12:52:27 ubuntu kernel: traps: ubiquity[2646] trap int3 
ip:7f5a76936961 sp:7ffde5090c50 error:0 in 
libglib-2.0.so.0.5400.1[7f5a768e6000+111000]
  Feb 23 12:52:41 ubuntu /install.py[6858]: Exception during installation:
  Feb 23 12:52:41 ubuntu /install.py[6858]: Traceback (most recent call last):
  Feb 23 12:52:41 ubuntu /install.py[6858]:   File 
"/usr/share/ubiquity/install.py", line 757, in 
  Feb 23 12:52:41 ubuntu /install.py[6858]: install.run()
  Feb 23 12:52:41 ubuntu /install.py[6858]:   File 
"/usr/share/ubiquity/install.py", line 135, in run
  Feb 23 12:52:41 ubuntu /install.py[6858]: self.copy_all()
  Feb 23 12:52:41 ubuntu /install.py[6858]:   File 
"/usr/share/ubiquity/install.py", line 505, in copy_all
  Feb 23 12:52:41 ubuntu /install.py[6858]: self.db.progress('SET', 10 + 
copy_progress)
  Feb 23 12:52:41 ubuntu /install.py[6858]:   File 
"/usr/lib/python3/dist-packages/debconf.py", line 83, in 
  Feb 23 12:52:41 ubuntu /install.py[6858]: lambda *args, **kw: 
self.command(command, *args, **kw))
  Feb 23 12:52:41 ubuntu /install.py[6858]:   File 
"/usr/lib/python3/dist-packages/debconf.py", line 104, in command
  Feb 23 12:52:41 ubuntu /install.py[6858]: status = int(status)
  Feb 23 12:52:41 ubuntu /install.py[6858]: ValueError: invalid literal for 
int() with base 10: ''

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: ubiquity 18.04.1
  ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CasperVersion: 1.388
  Date: Fri Feb 23 12:52:28 2018
  ExecutablePath: /usr/lib/ubiquity/bin/ubiquity
  InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper 
initrd=/casper/initrd.lz quiet splash --- keyboard-configuration/layoutcode=fr 
keyboard-configuration/variantcode=oss
  InterpreterPath: /usr/bin/python3.6
  LiveMediaBuild: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180222)
  ProcCmdline: /usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity -d
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  Python3Details: /usr/bin/python3.6, Python 3.6.4+, python3-minimal, 3.6.4-1
  PythonDetails: /usr/bin/python2.7, Python 2.7.14+, python-minimal, 2.7.14-4
  Signal: 5
  SourcePackage: ubiquity
  StacktraceTop:
   ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
   ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
  Title: ubiquity crashed with signal 5 in _XEventsQueued()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/cairo/+bug/1751252/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe :

[Touch-packages] [Bug 1458204] Re: removing kernels should not require a restart afterward

2018-12-06 Thread Balint Reczey

@bhkolts: Thank you for your feedback. Linux-image-
extra-4.4.0-138-generic.postrm still runs /etc/kernel/postinst.d/update-
notifier that places /var/run/reboot-required, the file u-u acts upon
and reboots.

Update-notifier is fixed in Bionic, but I'm hereby nominating the fix
for Xenial.

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

Title:
  removing kernels should not require a restart afterward

Status in unattended-upgrades:
  New
Status in update notifier:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in update-notifier package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Won't Fix
Status in unattended-upgrades source package in Artful:
  Won't Fix
Status in update-notifier source package in Artful:
  Won't Fix

Bug description:
  1. Perform a kernel upgrade normally via "apt-get dist-upgrade".
  2. Reboot.
  3. Run "apt-get autoremove" to delete the old kernel packages.
  4. "System Notification Helper" now reports that the computer requires a 
reboot.

  The "autoremove" operation shouldn't require a reboot, logically
  speaking, because it's just removing files that are unused by the OS.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: apt 1.0.1ubuntu2.7
  ProcVersionSignature: Ubuntu 3.13.0-53.89-generic 3.13.11-ckt19
  Uname: Linux 3.13.0-53-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.11
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Sat May 23 12:47:15 2015
  InstallationDate: Installed on 2013-08-31 (629 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  SourcePackage: apt
  UpgradeStatus: Upgraded to trusty on 2014-04-26 (391 days ago)
  --- 
  ApportVersion: 2.14.1-0ubuntu3.11
  Architecture: amd64
  CurrentDesktop: KDE
  DistroRelease: Ubuntu 14.04
  HibernationDevice: RESUME=UUID=66f11ff7-00bb-4452-9168-003cf9078308
  InstallationDate: Installed on 2013-08-31 (632 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  MachineType: System manufacturer System Product Name
  Package: linux (not installed)
  ProcFB: 0 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-53-generic 
root=UUID=02741f1f-8107-4a0f-b9a6-31ef470b1389 ro libata.force=noncq quiet 
splash vt.handoff=7
  ProcVersionSignature: Ubuntu 3.13.0-53.89-generic 3.13.11-ckt19
  RelatedPackageVersions:
   linux-restricted-modules-3.13.0-53-generic N/A
   linux-backports-modules-3.13.0-53-generic  N/A
   linux-firmware 1.127.12
  RfKill:
   
  Tags:  trusty
  Uname: Linux 3.13.0-53-generic x86_64
  UpgradeStatus: Upgraded to trusty on 2014-04-26 (395 days ago)
  UserGroups: adm cdrom dialout dip fuse lightdm lpadmin plugdev sambashare sudo
  WifiSyslog:
   
  _MarkForUpload: True
  dmi.bios.date: 08/12/2013
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4210
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: P9X79
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev 1.xx
  dmi.chassis.asset.tag: Asset-1234567890
  dmi.chassis.type: 3
  dmi.chassis.vendor: Chassis Manufacture
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4210:bd08/12/2013:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP9X79:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
  dmi.product.name: System Product Name
  dmi.product.version: System Version
  dmi.sys.vendor: System manufacturer

To manage notifications about this bug go to:
https://bugs.launchpad.net/unattended-upgrades/+bug/1458204/+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 1458204] Re: removing kernels should not require a restart afterward

2018-12-06 Thread Balint Reczey

No, I can't nominate it. :-)
Brian, could you please do nominate this for u-n in Xenial?

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

Title:
  removing kernels should not require a restart afterward

Status in unattended-upgrades:
  New
Status in update notifier:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in update-notifier package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Won't Fix
Status in unattended-upgrades source package in Artful:
  Won't Fix
Status in update-notifier source package in Artful:
  Won't Fix

Bug description:
  1. Perform a kernel upgrade normally via "apt-get dist-upgrade".
  2. Reboot.
  3. Run "apt-get autoremove" to delete the old kernel packages.
  4. "System Notification Helper" now reports that the computer requires a 
reboot.

  The "autoremove" operation shouldn't require a reboot, logically
  speaking, because it's just removing files that are unused by the OS.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: apt 1.0.1ubuntu2.7
  ProcVersionSignature: Ubuntu 3.13.0-53.89-generic 3.13.11-ckt19
  Uname: Linux 3.13.0-53-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.11
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Sat May 23 12:47:15 2015
  InstallationDate: Installed on 2013-08-31 (629 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  SourcePackage: apt
  UpgradeStatus: Upgraded to trusty on 2014-04-26 (391 days ago)
  --- 
  ApportVersion: 2.14.1-0ubuntu3.11
  Architecture: amd64
  CurrentDesktop: KDE
  DistroRelease: Ubuntu 14.04
  HibernationDevice: RESUME=UUID=66f11ff7-00bb-4452-9168-003cf9078308
  InstallationDate: Installed on 2013-08-31 (632 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  MachineType: System manufacturer System Product Name
  Package: linux (not installed)
  ProcFB: 0 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-53-generic 
root=UUID=02741f1f-8107-4a0f-b9a6-31ef470b1389 ro libata.force=noncq quiet 
splash vt.handoff=7
  ProcVersionSignature: Ubuntu 3.13.0-53.89-generic 3.13.11-ckt19
  RelatedPackageVersions:
   linux-restricted-modules-3.13.0-53-generic N/A
   linux-backports-modules-3.13.0-53-generic  N/A
   linux-firmware 1.127.12
  RfKill:
   
  Tags:  trusty
  Uname: Linux 3.13.0-53-generic x86_64
  UpgradeStatus: Upgraded to trusty on 2014-04-26 (395 days ago)
  UserGroups: adm cdrom dialout dip fuse lightdm lpadmin plugdev sambashare sudo
  WifiSyslog:
   
  _MarkForUpload: True
  dmi.bios.date: 08/12/2013
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4210
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: P9X79
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev 1.xx
  dmi.chassis.asset.tag: Asset-1234567890
  dmi.chassis.type: 3
  dmi.chassis.vendor: Chassis Manufacture
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4210:bd08/12/2013:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP9X79:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
  dmi.product.name: System Product Name
  dmi.product.version: System Version
  dmi.sys.vendor: System manufacturer

To manage notifications about this bug go to:
https://bugs.launchpad.net/unattended-upgrades/+bug/1458204/+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 349469] Re: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable

** Changed in: aptdaemon
 Assignee: Morais (morais28) => (unassigned)

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

Title:
  debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by
  another process: Resource temporarily unavailable

Status in Aptdaemon:
  Fix Released
Status in Debconf:
  New
Status in aptdaemon package in Ubuntu:
  Invalid
Status in debconf package in Ubuntu:
  Triaged

Bug description:
  Upgrading packages that use debconf sometimes fail with the following
  error:

  debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by
  another process: Resource temporarily unavailable

To manage notifications about this bug go to:
https://bugs.launchpad.net/aptdaemon/+bug/349469/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

2018-12-06 Thread Jeremy Bicha

I am unsubscribing the Sponsors Team since there doesn't appear to be
anything left to sponsor here. Please feel to resubscribe if you have
anything else that needs to be sponsored.

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  In Progress
Status in cups source package in Trusty:
  Invalid
Status in cups source package in Xenial:
  In Progress
Status in cups source package in Bionic:
  In Progress
Status in cups source package in Cosmic:
  In Progress
Status in cups source package in Disco:
  In Progress
Status in cups package in Debian:
  New

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no
   difference in behavior except for the special value of MaxJobTime=0.

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

  Trusty is not affected by this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1787729] Re: [FAILED] Failed to start Process error reports when automatic reporting is enabled.

2018-12-06 Thread Chris Rainey

I just figured-out how to get "apport-autoreport.service",
"whoopsie.service" & "systemd-networkd-wait-online.service" starting
correctly on a networkd(netplan)-only(NetworkManager.service _disabled_
system) desktop which uses WiFi and a static-ip on Ubuntu 18.10 Desktop.

I'm commenting here in case it provides insight or another angle to
approach the resolution of this bug.

BTW:  the test system _was_ experiencing this bug on a clean-install of
18.10 Desktop ISO.

TL;DR

Adding a new variable(optional: yes) in the netplan yaml config for a
static IP addy allows the "systemd-networkd-wait-online.service" to
_ignore_ interfaces that may be blocking or inhibiting the proper
startup of the apport-auto/whoopsie units.


Steps to reproduce:

1. Disable all NetworkManager related services:

$ systemctl list-unit-files | grep Net
NetworkManager-dispatcher.service  disabled   
NetworkManager-wait-online.service disabled   
NetworkManager.service disabled 


2. Create new yaml config for static IP's on all IF's(notice the 'optional: 
yes' directives!):

$ cat /etc/netplan/01-static-ip.yaml 
network:
  version: 2
  renderer: networkd
  ethernets:
enp2s0:
  optional: yes
  dhcp4: no
  dhcp6: no
  addresses: [192.168.1.201/24]
  gateway4: 192.168.1.254
  nameservers:
addresses: [8.8.8.8, 8.8.4.4]
  wifis:
wlp3s0:
  optional: yes
  dhcp4: no
  dhcp6: no
  addresses: [192.168.1.202/24]
  gateway4: 192.168.1.254
  nameservers:
addresses: [8.8.8.8, 8.8.4.4]
  access-points:
"Chez Merkle-Mac-Rainey 5 GHz":
  password: "BIG SECRET"


3. Reboot and confirm proper startup of all service units:

$ systemctl --failed 
0 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.


$ systemctl status 
● CKR-1
State: running
 Jobs: 0 queued
   Failed: 0 units
Since: Thu 2018-12-06 15:02:16 CST; 22min ago


HTH!

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

Title:
  [FAILED] Failed to start Process error reports when automatic
  reporting is enabled.

Status in apport package in Ubuntu:
  Incomplete

Bug description:
  Hello,

  Attached image.

  Regards,
  --
  Cristian Aravena Romero (caravena)

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: apport 2.20.10-0ubuntu7
  Uname: Linux 4.18.3-041803-generic x86_64
  ApportLog:
   
  ApportVersion: 2.20.10-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Aug 18 11:48:00 2018
  InstallationDate: Installed on 2017-10-13 (308 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170926)
  PackageArchitecture: all
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1787729/+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 1807272] Re: package libpolkit-backend-1-0:amd64 0.105-14.1 failed to install/upgrade: package libpolkit-backend-1-0:amd64 is not ready for configuration cannot configure (curren

2018-12-06 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 policykit-1 in Ubuntu.
https://bugs.launchpad.net/bugs/1807272

Title:
  package libpolkit-backend-1-0:amd64 0.105-14.1 failed to
  install/upgrade: package libpolkit-backend-1-0:amd64 is not ready for
  configuration  cannot configure (current status 'half-installed')

Status in policykit-1 package in Ubuntu:
  New

Bug description:
  I install Ubuntu 16.04 two days ago and install package only with
  synaptic.

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: libpolkit-backend-1-0:amd64 0.105-14.1
  ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
  Uname: Linux 4.4.0-31-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Fri Dec  7 00:30:14 2018
  DuplicateSignature:
   package:libpolkit-backend-1-0:amd64:0.105-14.1
   Processing triggers for libglib2.0-0:amd64 (2.48.2-0ubuntu4.1) ...
   dpkg: error processing package libpolkit-backend-1-0:amd64 (--configure):
package libpolkit-backend-1-0:amd64 is not ready for configuration
  ErrorMessage: package libpolkit-backend-1-0:amd64 is not ready for 
configuration  cannot configure (current status 'half-installed')
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15ubuntu0.2
  SourcePackage: policykit-1
  Title: package libpolkit-backend-1-0:amd64 0.105-14.1 failed to 
install/upgrade: package libpolkit-backend-1-0:amd64 is not ready for 
configuration  cannot configure (current status 'half-installed')
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1807272/+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 1807272] [NEW] package libpolkit-backend-1-0:amd64 0.105-14.1 failed to install/upgrade: package libpolkit-backend-1-0:amd64 is not ready for configuration cannot configure (curr

2018-12-06 Thread mohammad

Public bug reported:

I install Ubuntu 16.04 two days ago and install package only with
synaptic.

ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: libpolkit-backend-1-0:amd64 0.105-14.1
ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
Uname: Linux 4.4.0-31-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
Date: Fri Dec  7 00:30:14 2018
DuplicateSignature:
 package:libpolkit-backend-1-0:amd64:0.105-14.1
 Processing triggers for libglib2.0-0:amd64 (2.48.2-0ubuntu4.1) ...
 dpkg: error processing package libpolkit-backend-1-0:amd64 (--configure):
  package libpolkit-backend-1-0:amd64 is not ready for configuration
ErrorMessage: package libpolkit-backend-1-0:amd64 is not ready for 
configuration  cannot configure (current status 'half-installed')
RelatedPackageVersions:
 dpkg 1.18.4ubuntu1.1
 apt  1.2.15ubuntu0.2
SourcePackage: policykit-1
Title: package libpolkit-backend-1-0:amd64 0.105-14.1 failed to 
install/upgrade: package libpolkit-backend-1-0:amd64 is not ready for 
configuration  cannot configure (current status 'half-installed')
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: policykit-1 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package xenial

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

Title:
  package libpolkit-backend-1-0:amd64 0.105-14.1 failed to
  install/upgrade: package libpolkit-backend-1-0:amd64 is not ready for
  configuration  cannot configure (current status 'half-installed')

Status in policykit-1 package in Ubuntu:
  New

Bug description:
  I install Ubuntu 16.04 two days ago and install package only with
  synaptic.

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: libpolkit-backend-1-0:amd64 0.105-14.1
  ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
  Uname: Linux 4.4.0-31-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Fri Dec  7 00:30:14 2018
  DuplicateSignature:
   package:libpolkit-backend-1-0:amd64:0.105-14.1
   Processing triggers for libglib2.0-0:amd64 (2.48.2-0ubuntu4.1) ...
   dpkg: error processing package libpolkit-backend-1-0:amd64 (--configure):
package libpolkit-backend-1-0:amd64 is not ready for configuration
  ErrorMessage: package libpolkit-backend-1-0:amd64 is not ready for 
configuration  cannot configure (current status 'half-installed')
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.15ubuntu0.2
  SourcePackage: policykit-1
  Title: package libpolkit-backend-1-0:amd64 0.105-14.1 failed to 
install/upgrade: package libpolkit-backend-1-0:amd64 is not ready for 
configuration  cannot configure (current status 'half-installed')
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1807272/+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 1698270] Re: Totem pauses and stutters during video playback even when CPU usage is low

2018-12-06 Thread Bug Watch Updater

** Changed in: gstreamer
   Status: Confirmed => Expired

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

Title:
  Totem pauses and stutters during video playback even when CPU usage is
  low

Status in GStreamer:
  Expired
Status in GTK+:
  Fix Released
Status in totem-pl-parser:
  Expired
Status in clutter-1.0 package in Ubuntu:
  Confirmed
Status in clutter-gst-3.0 package in Ubuntu:
  Incomplete
Status in clutter-gtk package in Ubuntu:
  Fix Released
Status in gstreamer-vaapi package in Ubuntu:
  Incomplete
Status in gtk+3.0 package in Ubuntu:
  Fix Released
Status in totem-pl-parser package in Ubuntu:
  Fix Released

Bug description:
  Totem pauses and stutters during video playback even when CPU usage is
  low.

  After figuring out how to play videos with full hardware accelerated
  decoding (e.g. <= 10% CPU), I was surprised to find Totem still pauses
  and stutters during playback. Other apps like Mplayer, VLC and even
  gst-play-1.0 never have this problem.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: totem 3.24.0-0ubuntu1
  ProcVersionSignature: Ubuntu 4.10.0-22.24-generic 4.10.15
  Uname: Linux 4.10.0-22-generic x86_64
  ApportVersion: 2.20.5-0ubuntu4
  Architecture: amd64
  Date: Fri Jun 16 12:03:18 2017
  InstallationDate: Installed on 2017-05-03 (44 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170502)
  SourcePackage: totem
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gstreamer/+bug/1698270/+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 1807077] Re: [SRU] mountall crashes on udev node with missing devname

2018-12-06 Thread Ryan Finnie

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

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

Title:
  [SRU] mountall crashes on udev node with missing devname

Status in mountall package in Ubuntu:
  Invalid
Status in mountall source package in Trusty:
  Confirmed
Status in mountall source package in Xenial:
  Won't Fix

Bug description:
  [Impact]

   * udev block nodes without a devname will crash mountall, resulting
  in an unbootable system (emergency root shell)

   * While this is not likely to happen in a matched distro/kernel
  environment (it was discovered while needing to run a bionic 4.15
  kernel on trusty), it is possible.

   * The code in try_udev_device() assumes a block subsystem will always
  have a devname; the SRU patches explicitly check for a devname and
  return if null.

  [Test Case]

   * HPE DL385 Gen10, Samsung a822 NVMe controller, trusty install

   * Kernels <4.15 (or possibly 4.14) do not expose nvme0c33n1 and do
  not trigger the bug.  Tested on 4.13, 4.4 and 3.13.

   * Kernel 4.15 exposes nvme0c33n1 in udev but does not have a devname,
  mountall crash ensues.

  [Regression Potential]

   * Patch might ignore legitimate block devices on existing
  installations.  Unlikely, since the logic path for null devname leads
  directly to a program crash.

  [Other Info]
   
   * Additional context for Canonical employees: PS4.5 is a trusty backend 
cloud, but we now have Gen10 hardware incoming (this was discovered while 
adding new nova-compute hardware).  Older kernels are not usable because Gen10 
requires ilorest, which requires a >4.4 kernel (at least artful 4.13 is known 
good).  So trusty+4.15 is the only viable combination for continued support of 
the cloud while adding new hardware.  This is done via apt pinning of bionic 
for the kernel packages, and, mountall notwithstanding, is working fine so far.

  
  Original description:

  Running bionic's 4.15 kernel on trusty on an HPE DL385 Gen10 results
  in a device node for the NVMe controller,
  /devices/pci:40/:40:03.1/:43:00.0/nvme/nvme0/nvme0c33n1
  which itself does not have a devname.  When mountall gets to it:

  fsck_update: updating check priorities
  try_mount: /srv/nova/instances waiting for device
  try_udev_device: ignored /dev/loop5 (not yet ready?)
  try_udev_device: ignored /dev/loop6 (not yet ready?)
  try_udev_device: ignored /dev/loop1 (not yet ready?)
  try_udev_device: ignored /dev/loop0 (not yet ready?)
  try_udev_device: block (null) (null) (null)

  and then crashes, leaving the boot at an emergency root shell.  A
  successful scan looks like this for comparison:

  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sda (null) (null)
  try_udev_device: block /dev/nvme0n1 ed56e3a9-60f7-4636-85a2-b53137b598e7 
(null)
  try_udev_device: block /dev/bcache0 756cb2c6-b999-4905-a021-c2e688e81a86 
instances

  The debdiffs check for a null devname in try_udev_device() and will
  not attempt to process it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1807077/+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 1807077] Re: [SRU] mountall crashes on udev node with missing devname

2018-12-06 Thread Ryan Finnie

Thanks.  I saw xenial had mountall and figured maybe there was
transition path where it was used, but if it's vestigial, I agree this
should be trusty-only.

** Tags removed: xenial

** Patch removed: "lp1807077-xenial.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1807077/+attachment/5219620/+files/lp1807077-xenial.debdiff

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

Title:
  [SRU] mountall crashes on udev node with missing devname

Status in mountall package in Ubuntu:
  Invalid
Status in mountall source package in Trusty:
  Confirmed
Status in mountall source package in Xenial:
  Won't Fix

Bug description:
  [Impact]

   * udev block nodes without a devname will crash mountall, resulting
  in an unbootable system (emergency root shell)

   * While this is not likely to happen in a matched distro/kernel
  environment (it was discovered while needing to run a bionic 4.15
  kernel on trusty), it is possible.

   * The code in try_udev_device() assumes a block subsystem will always
  have a devname; the SRU patches explicitly check for a devname and
  return if null.

  [Test Case]

   * HPE DL385 Gen10, Samsung a822 NVMe controller, trusty install

   * Kernels <4.15 (or possibly 4.14) do not expose nvme0c33n1 and do
  not trigger the bug.  Tested on 4.13, 4.4 and 3.13.

   * Kernel 4.15 exposes nvme0c33n1 in udev but does not have a devname,
  mountall crash ensues.

  [Regression Potential]

   * Patch might ignore legitimate block devices on existing
  installations.  Unlikely, since the logic path for null devname leads
  directly to a program crash.

  [Other Info]
   
   * Additional context for Canonical employees: PS4.5 is a trusty backend 
cloud, but we now have Gen10 hardware incoming (this was discovered while 
adding new nova-compute hardware).  Older kernels are not usable because Gen10 
requires ilorest, which requires a >4.4 kernel (at least artful 4.13 is known 
good).  So trusty+4.15 is the only viable combination for continued support of 
the cloud while adding new hardware.  This is done via apt pinning of bionic 
for the kernel packages, and, mountall notwithstanding, is working fine so far.

  
  Original description:

  Running bionic's 4.15 kernel on trusty on an HPE DL385 Gen10 results
  in a device node for the NVMe controller,
  /devices/pci:40/:40:03.1/:43:00.0/nvme/nvme0/nvme0c33n1
  which itself does not have a devname.  When mountall gets to it:

  fsck_update: updating check priorities
  try_mount: /srv/nova/instances waiting for device
  try_udev_device: ignored /dev/loop5 (not yet ready?)
  try_udev_device: ignored /dev/loop6 (not yet ready?)
  try_udev_device: ignored /dev/loop1 (not yet ready?)
  try_udev_device: ignored /dev/loop0 (not yet ready?)
  try_udev_device: block (null) (null) (null)

  and then crashes, leaving the boot at an emergency root shell.  A
  successful scan looks like this for comparison:

  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sda (null) (null)
  try_udev_device: block /dev/nvme0n1 ed56e3a9-60f7-4636-85a2-b53137b598e7 
(null)
  try_udev_device: block /dev/bcache0 756cb2c6-b999-4905-a021-c2e688e81a86 
instances

  The debdiffs check for a null devname in try_udev_device() and will
  not attempt to process it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1807077/+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 1804603] Re: systemd-tmpfiles-setup.service fails on btrfs

2018-12-06 Thread Jurit

I have server version Ubuntu 18.04.1 LTS bionic systemd 237.
systemd-tmpfiles-setup-dev.service  loaded failed failedCreate Static 
Device Nodes in /dev
systemd-tmpfiles-setup.service  loaded failed failedCreate Volatile 
Files and Directories

Problem started some weeks ago after I did apt-get upgrade

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

Title:
  systemd-tmpfiles-setup.service fails on btrfs

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Cosmic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

   * Last security update introduced a regression on btrfs based systems, 
causing systemd-tmpfiles-setup.service to fail to start, resulting in degraded 
machines.
   * Cherrypick upstream fixes to resolve this.

  [Test Case]

   * Install VM using btrfs for /
   * Boot, check that systemd-tmpfiles-setup.service is started successfully 
with:
  $ systemctl status systemd-tmpfiles-setup.service

  [Regression Potential]

   * btrfs fd doesn't support the set of flags that systemd used, with
  this patch, a compat set of flags is set instead, thus resolving the
  introduced regression. The worst case scenario is that creating
  subvolumes/directories is still broken (as in, the current status
  quo).

  [Other Info]
   
   * Example bad output

  
  After update to systemd 237-3ubuntu10.9 systemd-tmpfiles-setup.service fails 
with:

  Nov 21 13:44:12 node-blc49 systemd[1]: Starting Create Volatile Files and 
Directories...
  Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory 
or subvolume "/var": Bad file descriptor
  Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory 
or subvolume "/home": Bad file descriptor
  Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory 
or subvolume "/srv": Bad file descriptor
  Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Main 
process exited, code=exited, status=1/FAILURE
  Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Failed 
with result 'exit-code'.
  Nov 21 13:44:12 node-blc49 systemd[1]: Failed to start Create Volatile Files 
and Directories.

  This happens on btrfs root filesystems in real hardware and on our
  virtualized servers as well. 237-3ubuntu10.6 didnt show this errors
  and going back to 237-3ubuntu10 removes them as well.

  # lsb_release -rd
  Description:Ubuntu 18.04.1 LTS
  Release:18.04

  # apt-cache policy systemd
  systemd:
    Installiert:   237-3ubuntu10.9
    Installationskandidat: 237-3ubuntu10.9
    Versionstabelle:
   *** 237-3ubuntu10.9 500
  500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10 500
  500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804603/+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 1804603] Re: systemd-tmpfiles-setup.service fails on btrfs

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

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

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

Title:
  systemd-tmpfiles-setup.service fails on btrfs

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Cosmic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

   * Last security update introduced a regression on btrfs based systems, 
causing systemd-tmpfiles-setup.service to fail to start, resulting in degraded 
machines.
   * Cherrypick upstream fixes to resolve this.

  [Test Case]

   * Install VM using btrfs for /
   * Boot, check that systemd-tmpfiles-setup.service is started successfully 
with:
  $ systemctl status systemd-tmpfiles-setup.service

  [Regression Potential]

   * btrfs fd doesn't support the set of flags that systemd used, with
  this patch, a compat set of flags is set instead, thus resolving the
  introduced regression. The worst case scenario is that creating
  subvolumes/directories is still broken (as in, the current status
  quo).

  [Other Info]
   
   * Example bad output

  
  After update to systemd 237-3ubuntu10.9 systemd-tmpfiles-setup.service fails 
with:

  Nov 21 13:44:12 node-blc49 systemd[1]: Starting Create Volatile Files and 
Directories...
  Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory 
or subvolume "/var": Bad file descriptor
  Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory 
or subvolume "/home": Bad file descriptor
  Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory 
or subvolume "/srv": Bad file descriptor
  Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Main 
process exited, code=exited, status=1/FAILURE
  Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Failed 
with result 'exit-code'.
  Nov 21 13:44:12 node-blc49 systemd[1]: Failed to start Create Volatile Files 
and Directories.

  This happens on btrfs root filesystems in real hardware and on our
  virtualized servers as well. 237-3ubuntu10.6 didnt show this errors
  and going back to 237-3ubuntu10 removes them as well.

  # lsb_release -rd
  Description:Ubuntu 18.04.1 LTS
  Release:18.04

  # apt-cache policy systemd
  systemd:
    Installiert:   237-3ubuntu10.9
    Installationskandidat: 237-3ubuntu10.9
    Versionstabelle:
   *** 237-3ubuntu10.9 500
  500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10 500
  500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804603/+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 1806399] Re: package python3-minimal 3.6.7-1~18.04 failed to install/upgrade: installed python3-minimal package post-installation script subprocess returned error exit status 127

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

** Changed in: python3-defaults (Ubuntu)
   Status: New => Confirmed

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

Title:
  package python3-minimal 3.6.7-1~18.04 failed to install/upgrade:
  installed python3-minimal package post-installation script subprocess
  returned error exit status 127

Status in python3-defaults package in Ubuntu:
  Confirmed

Bug description:
  lkjhgfdsazASDERTYUIOP'/;.LKJHGFDSZ

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: python3-minimal 3.6.7-1~18.04
  ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18
  Uname: Linux 4.15.0-39-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  AptOrdering:
   python3-minimal:amd64: Configure
   python3:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  Date: Mon Dec  3 23:48:46 2018
  DpkgTerminalLog:
   Setting up python3-minimal (3.6.7-1~18.04) ...
   /var/lib/dpkg/info/python3-minimal.postinst: 5: 
/var/lib/dpkg/info/python3-minimal.postinst: py3compile: not found
   dpkg: error processing package python3-minimal (--configure):
installed python3-minimal package post-installation script subprocess 
returned error exit status 127
  DuplicateSignature:
   package:python3-minimal:3.6.7-1~18.04
   Setting up python3-minimal (3.6.7-1~18.04) ...
   /var/lib/dpkg/info/python3-minimal.postinst: 5: 
/var/lib/dpkg/info/python3-minimal.postinst: py3compile: not found
   dpkg: error processing package python3-minimal (--configure):
installed python3-minimal package post-installation script subprocess 
returned error exit status 127
  ErrorMessage: installed python3-minimal package post-installation script 
subprocess returned error exit status 127
  InstallationDate: Installed on 2018-01-05 (332 days ago)
  InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 
(20170801)
  Python3Details: /usr/bin/python3.6m, Python 3.6.7, python3-minimal, 
3.6.7-1~18.04
  PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 
2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.1
   apt  1.6.6
  SourcePackage: python3-defaults
  Title: package python3-minimal 3.6.7-1~18.04 failed to install/upgrade: 
installed python3-minimal package post-installation script subprocess returned 
error exit status 127
  UpgradeStatus: Upgraded to bionic on 2018-09-27 (67 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1806399/+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 1807023] Re: installer stock images fail to validate any HTTPS certificates (ca-certificates missing)

** Patch added: "lp1807023-ca-certificates-bionic.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219790/+files/lp1807023-ca-certificates-bionic.debdiff

** Patch removed: "ca-certificates_disco.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219559/+files/ca-certificates_disco.debdiff

** Patch removed: "ca-certificates_cosmic.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219560/+files/ca-certificates_cosmic.debdiff

** Patch removed: "ca-certificates_bionic.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219561/+files/ca-certificates_bionic.debdiff

** Patch removed: "d-i_cosmic.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219563/+files/d-i_cosmic.debdiff

** Patch removed: "d-i_bionic.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219564/+files/d-i_bionic.debdiff

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

Title:
  installer stock images fail to validate any HTTPS certificates (ca-
  certificates missing)

Status in ca-certificates package in Ubuntu:
  In Progress
Status in debian-installer package in Ubuntu:
  In Progress
Status in ca-certificates source package in Trusty:
  New
Status in debian-installer source package in Trusty:
  New
Status in ca-certificates source package in Xenial:
  New
Status in debian-installer source package in Xenial:
  New
Status in ca-certificates source package in Bionic:
  In Progress
Status in debian-installer source package in Bionic:
  In Progress
Status in ca-certificates source package in Cosmic:
  In Progress
Status in debian-installer source package in Cosmic:
  In Progress
Status in ca-certificates source package in Disco:
  In Progress
Status in debian-installer source package in Disco:
  In Progress
Status in debian-installer package in Debian:
  Fix Released

Bug description:
  [Impact]

   * The installer stock images fail to validate any HTTPS
     certificates because ca-certificates is not available
     in the installer environment.

   * This causes wget/download errors for preseed files on
     HTTPS servers (or HTTP servers that redirect to HTTPS,
     which are increasingly common nowadays - e.g., GitHub)
     and theoretically any other files that are downloaded
     with d-i-utils/fetch-url/wget.

   * The fix is to ship ca-certificates-udeb in installer
     stock images.

   * Debian already ships ca-certificate-udeb in the stock
     installer images; the fix is applied since Jan 2017.
     (reference: Debian Bug #842040 / d-i commit 2f00c51a [1])

  [Test Case]

   * In the installer shell:

     ~ # wget http://github.com  # or https://github.com

     - FAIL if ca-certificates-udeb is missing:
   "ERROR: cannot verify github.com's certificate, <...>'

     - PASS if ca-certificates-udeb is available
   "Saving to: 'index.html'"

   * Test steps with virt-install and netboot images
     are provided in the comments, for each release.

  [Regression Potential]

   * Low. This just adds the ca-certificates files in
     /etc/ssl/certs and symlink in /usr/lib/ssl/certs,
     so only tools looking for that would be affected.

   * Apparently only wget checks for/uses those files,
     and the difference in behavior is download errors
     no longer occur.

  [Notes]

   * The ca-certificates-udeb is not currently present
     in the Ubuntu archive despite being available for
     download in Launchpad with a link for some reason
     (perhaps a problem during import from Debian/sid?)

   * So this fix includes a no-change-rebuild for the
     ca-certificates package, in order to publish the
     udeb in the archive.

   * The ca-certificates and debian-installer builds
     have been done in a PPA using all architectures,
     and testing has been done with the amd64 images.

   * This fix is request for Bionic, Cosmic, Disco.

     The older releases (Trusty, Xenial) are affected,
     but not requested for, and would need more work,
     as the udeb is not yet in the packaging but that
     is doable if required for the process.

  [1] https://salsa.debian.org/installer-team/debian-
  installer/commit/2f00c51a7ead982ae1cd71bee06c8416890196b6

  [Debugging]

  For debugging purposes, one can install strace-udeb in the installer
  to verify wget's stat() calls to /usr/lib/ssl/certs.

  ~ # anna-install strace-udeb

  ~ # strace -e stat wget -O- https://github.com >/dev/null
  ...
  Resolving github.com... stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, 
st_size=20, ...}) = 0
  140.82.118.3, 140.82.118.4
  Connecting to github.com|140.82.118.3|:443... connected.

[Touch-packages] [Bug 1807023] Re: installer stock images fail to validate any HTTPS certificates (ca-certificates missing)

** Patch added: "lp1807023-ca-certificates-disco.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219788/+files/lp1807023-ca-certificates-disco.debdiff

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

Title:
  installer stock images fail to validate any HTTPS certificates (ca-
  certificates missing)

Status in ca-certificates package in Ubuntu:
  In Progress
Status in debian-installer package in Ubuntu:
  In Progress
Status in ca-certificates source package in Trusty:
  New
Status in debian-installer source package in Trusty:
  New
Status in ca-certificates source package in Xenial:
  New
Status in debian-installer source package in Xenial:
  New
Status in ca-certificates source package in Bionic:
  In Progress
Status in debian-installer source package in Bionic:
  In Progress
Status in ca-certificates source package in Cosmic:
  In Progress
Status in debian-installer source package in Cosmic:
  In Progress
Status in ca-certificates source package in Disco:
  In Progress
Status in debian-installer source package in Disco:
  In Progress
Status in debian-installer package in Debian:
  Fix Released

Bug description:
  [Impact]

   * The installer stock images fail to validate any HTTPS
     certificates because ca-certificates is not available
     in the installer environment.

   * This causes wget/download errors for preseed files on
     HTTPS servers (or HTTP servers that redirect to HTTPS,
     which are increasingly common nowadays - e.g., GitHub)
     and theoretically any other files that are downloaded
     with d-i-utils/fetch-url/wget.

   * The fix is to ship ca-certificates-udeb in installer
     stock images.

   * Debian already ships ca-certificate-udeb in the stock
     installer images; the fix is applied since Jan 2017.
     (reference: Debian Bug #842040 / d-i commit 2f00c51a [1])

  [Test Case]

   * In the installer shell:

     ~ # wget http://github.com  # or https://github.com

     - FAIL if ca-certificates-udeb is missing:
   "ERROR: cannot verify github.com's certificate, <...>'

     - PASS if ca-certificates-udeb is available
   "Saving to: 'index.html'"

   * Test steps with virt-install and netboot images
     are provided in the comments, for each release.

  [Regression Potential]

   * Low. This just adds the ca-certificates files in
     /etc/ssl/certs and symlink in /usr/lib/ssl/certs,
     so only tools looking for that would be affected.

   * Apparently only wget checks for/uses those files,
     and the difference in behavior is download errors
     no longer occur.

  [Notes]

   * The ca-certificates-udeb is not currently present
     in the Ubuntu archive despite being available for
     download in Launchpad with a link for some reason
     (perhaps a problem during import from Debian/sid?)

   * So this fix includes a no-change-rebuild for the
     ca-certificates package, in order to publish the
     udeb in the archive.

   * The ca-certificates and debian-installer builds
     have been done in a PPA using all architectures,
     and testing has been done with the amd64 images.

   * This fix is request for Bionic, Cosmic, Disco.

     The older releases (Trusty, Xenial) are affected,
     but not requested for, and would need more work,
     as the udeb is not yet in the packaging but that
     is doable if required for the process.

  [1] https://salsa.debian.org/installer-team/debian-
  installer/commit/2f00c51a7ead982ae1cd71bee06c8416890196b6

  [Debugging]

  For debugging purposes, one can install strace-udeb in the installer
  to verify wget's stat() calls to /usr/lib/ssl/certs.

  ~ # anna-install strace-udeb

  ~ # strace -e stat wget -O- https://github.com >/dev/null
  ...
  Resolving github.com... stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, 
st_size=20, ...}) = 0
  140.82.118.3, 140.82.118.4
  Connecting to github.com|140.82.118.3|:443... connected.
  stat("/usr/lib/ssl/certs/45bfefc3.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  ERROR: cannot verify github.com's certificate, issued by 'CN=DigiCert SHA2 
Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US':
    Unable to locally verify the issuer's authority.
  To connect to github.com insecurely, use `--no-check-certificate'.
  +++ exited with 5 +++
  ~ #

  ~ # anna-install ca-certificates-udeb  # not in archive yet.
  unknown udeb ca-certificates-udeb

  ~ # wget --no-check-certificate
  https://launchpad.net/ubuntu/+archive/primary/+files/ca-certificates-
  udeb_20180409_all.udeb

  ~ # udpkg -i ca-certificates-udeb_20180409_all.udeb

  ~ # strace -e stat wget -O-

[Touch-packages] [Bug 1807023] Re: installer stock images fail to validate any HTTPS certificates (ca-certificates missing)

attached debdiffs for ca-certificates and debian-installer for b/c/d
with LP: #NNN tag corrected to use this bug number.

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

Title:
  installer stock images fail to validate any HTTPS certificates (ca-
  certificates missing)

Status in ca-certificates package in Ubuntu:
  In Progress
Status in debian-installer package in Ubuntu:
  In Progress
Status in ca-certificates source package in Trusty:
  New
Status in debian-installer source package in Trusty:
  New
Status in ca-certificates source package in Xenial:
  New
Status in debian-installer source package in Xenial:
  New
Status in ca-certificates source package in Bionic:
  In Progress
Status in debian-installer source package in Bionic:
  In Progress
Status in ca-certificates source package in Cosmic:
  In Progress
Status in debian-installer source package in Cosmic:
  In Progress
Status in ca-certificates source package in Disco:
  In Progress
Status in debian-installer source package in Disco:
  In Progress
Status in debian-installer package in Debian:
  Fix Released

Bug description:
  [Impact]

   * The installer stock images fail to validate any HTTPS
     certificates because ca-certificates is not available
     in the installer environment.

   * This causes wget/download errors for preseed files on
     HTTPS servers (or HTTP servers that redirect to HTTPS,
     which are increasingly common nowadays - e.g., GitHub)
     and theoretically any other files that are downloaded
     with d-i-utils/fetch-url/wget.

   * The fix is to ship ca-certificates-udeb in installer
     stock images.

   * Debian already ships ca-certificate-udeb in the stock
     installer images; the fix is applied since Jan 2017.
     (reference: Debian Bug #842040 / d-i commit 2f00c51a [1])

  [Test Case]

   * In the installer shell:

     ~ # wget http://github.com  # or https://github.com

     - FAIL if ca-certificates-udeb is missing:
   "ERROR: cannot verify github.com's certificate, <...>'

     - PASS if ca-certificates-udeb is available
   "Saving to: 'index.html'"

   * Test steps with virt-install and netboot images
     are provided in the comments, for each release.

  [Regression Potential]

   * Low. This just adds the ca-certificates files in
     /etc/ssl/certs and symlink in /usr/lib/ssl/certs,
     so only tools looking for that would be affected.

   * Apparently only wget checks for/uses those files,
     and the difference in behavior is download errors
     no longer occur.

  [Notes]

   * The ca-certificates-udeb is not currently present
     in the Ubuntu archive despite being available for
     download in Launchpad with a link for some reason
     (perhaps a problem during import from Debian/sid?)

   * So this fix includes a no-change-rebuild for the
     ca-certificates package, in order to publish the
     udeb in the archive.

   * The ca-certificates and debian-installer builds
     have been done in a PPA using all architectures,
     and testing has been done with the amd64 images.

   * This fix is request for Bionic, Cosmic, Disco.

     The older releases (Trusty, Xenial) are affected,
     but not requested for, and would need more work,
     as the udeb is not yet in the packaging but that
     is doable if required for the process.

  [1] https://salsa.debian.org/installer-team/debian-
  installer/commit/2f00c51a7ead982ae1cd71bee06c8416890196b6

  [Debugging]

  For debugging purposes, one can install strace-udeb in the installer
  to verify wget's stat() calls to /usr/lib/ssl/certs.

  ~ # anna-install strace-udeb

  ~ # strace -e stat wget -O- https://github.com >/dev/null
  ...
  Resolving github.com... stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, 
st_size=20, ...}) = 0
  140.82.118.3, 140.82.118.4
  Connecting to github.com|140.82.118.3|:443... connected.
  stat("/usr/lib/ssl/certs/45bfefc3.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  ERROR: cannot verify github.com's certificate, issued by 'CN=DigiCert SHA2 
Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US':
    Unable to locally verify the issuer's authority.
  To connect to github.com insecurely, use `--no-check-certificate'.
  +++ exited with 5 +++
  ~ #

  ~ # anna-install ca-certificates-udeb  # not in archive yet.
  unknown udeb ca-certificates-udeb

  ~ # wget --no-check-certificate
  https://launchpad.net/ubuntu/+archive/primary/+files/ca-certificates-
  udeb_20180409_all.udeb

  ~ # udpkg -i ca-certificates-udeb_20180409_all.udeb

  ~ # strace -e stat wget -O- https://github.com >/dev/null
  ...
  Resolving github.com... stat("/etc/resolv.conf",

[Touch-packages] [Bug 1807023] Re: installer stock images fail to validate any HTTPS certificates (ca-certificates missing)

** Patch added: "lp1807023-ca-certificates-cosmic.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219789/+files/lp1807023-ca-certificates-cosmic.debdiff

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

Title:
  installer stock images fail to validate any HTTPS certificates (ca-
  certificates missing)

Status in ca-certificates package in Ubuntu:
  In Progress
Status in debian-installer package in Ubuntu:
  In Progress
Status in ca-certificates source package in Trusty:
  New
Status in debian-installer source package in Trusty:
  New
Status in ca-certificates source package in Xenial:
  New
Status in debian-installer source package in Xenial:
  New
Status in ca-certificates source package in Bionic:
  In Progress
Status in debian-installer source package in Bionic:
  In Progress
Status in ca-certificates source package in Cosmic:
  In Progress
Status in debian-installer source package in Cosmic:
  In Progress
Status in ca-certificates source package in Disco:
  In Progress
Status in debian-installer source package in Disco:
  In Progress
Status in debian-installer package in Debian:
  Fix Released

Bug description:
  [Impact]

   * The installer stock images fail to validate any HTTPS
     certificates because ca-certificates is not available
     in the installer environment.

   * This causes wget/download errors for preseed files on
     HTTPS servers (or HTTP servers that redirect to HTTPS,
     which are increasingly common nowadays - e.g., GitHub)
     and theoretically any other files that are downloaded
     with d-i-utils/fetch-url/wget.

   * The fix is to ship ca-certificates-udeb in installer
     stock images.

   * Debian already ships ca-certificate-udeb in the stock
     installer images; the fix is applied since Jan 2017.
     (reference: Debian Bug #842040 / d-i commit 2f00c51a [1])

  [Test Case]

   * In the installer shell:

     ~ # wget http://github.com  # or https://github.com

     - FAIL if ca-certificates-udeb is missing:
   "ERROR: cannot verify github.com's certificate, <...>'

     - PASS if ca-certificates-udeb is available
   "Saving to: 'index.html'"

   * Test steps with virt-install and netboot images
     are provided in the comments, for each release.

  [Regression Potential]

   * Low. This just adds the ca-certificates files in
     /etc/ssl/certs and symlink in /usr/lib/ssl/certs,
     so only tools looking for that would be affected.

   * Apparently only wget checks for/uses those files,
     and the difference in behavior is download errors
     no longer occur.

  [Notes]

   * The ca-certificates-udeb is not currently present
     in the Ubuntu archive despite being available for
     download in Launchpad with a link for some reason
     (perhaps a problem during import from Debian/sid?)

   * So this fix includes a no-change-rebuild for the
     ca-certificates package, in order to publish the
     udeb in the archive.

   * The ca-certificates and debian-installer builds
     have been done in a PPA using all architectures,
     and testing has been done with the amd64 images.

   * This fix is request for Bionic, Cosmic, Disco.

     The older releases (Trusty, Xenial) are affected,
     but not requested for, and would need more work,
     as the udeb is not yet in the packaging but that
     is doable if required for the process.

  [1] https://salsa.debian.org/installer-team/debian-
  installer/commit/2f00c51a7ead982ae1cd71bee06c8416890196b6

  [Debugging]

  For debugging purposes, one can install strace-udeb in the installer
  to verify wget's stat() calls to /usr/lib/ssl/certs.

  ~ # anna-install strace-udeb

  ~ # strace -e stat wget -O- https://github.com >/dev/null
  ...
  Resolving github.com... stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, 
st_size=20, ...}) = 0
  140.82.118.3, 140.82.118.4
  Connecting to github.com|140.82.118.3|:443... connected.
  stat("/usr/lib/ssl/certs/45bfefc3.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  ERROR: cannot verify github.com's certificate, issued by 'CN=DigiCert SHA2 
Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US':
    Unable to locally verify the issuer's authority.
  To connect to github.com insecurely, use `--no-check-certificate'.
  +++ exited with 5 +++
  ~ #

  ~ # anna-install ca-certificates-udeb  # not in archive yet.
  unknown udeb ca-certificates-udeb

  ~ # wget --no-check-certificate
  https://launchpad.net/ubuntu/+archive/primary/+files/ca-certificates-
  udeb_20180409_all.udeb

  ~ # udpkg -i ca-certificates-udeb_20180409_all.udeb

  ~ # strace -e stat wget -O-

[Touch-packages] [Bug 1807023] Re: installer stock images fail to validate any HTTPS certificates (ca-certificates missing)

** Patch added: "lp1807023-debian-installer-cosmic.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219786/+files/lp1807023-debian-installer-cosmic.debdiff

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

Title:
  installer stock images fail to validate any HTTPS certificates (ca-
  certificates missing)

Status in ca-certificates package in Ubuntu:
  In Progress
Status in debian-installer package in Ubuntu:
  In Progress
Status in ca-certificates source package in Trusty:
  New
Status in debian-installer source package in Trusty:
  New
Status in ca-certificates source package in Xenial:
  New
Status in debian-installer source package in Xenial:
  New
Status in ca-certificates source package in Bionic:
  In Progress
Status in debian-installer source package in Bionic:
  In Progress
Status in ca-certificates source package in Cosmic:
  In Progress
Status in debian-installer source package in Cosmic:
  In Progress
Status in ca-certificates source package in Disco:
  In Progress
Status in debian-installer source package in Disco:
  In Progress
Status in debian-installer package in Debian:
  Fix Released

Bug description:
  [Impact]

   * The installer stock images fail to validate any HTTPS
     certificates because ca-certificates is not available
     in the installer environment.

   * This causes wget/download errors for preseed files on
     HTTPS servers (or HTTP servers that redirect to HTTPS,
     which are increasingly common nowadays - e.g., GitHub)
     and theoretically any other files that are downloaded
     with d-i-utils/fetch-url/wget.

   * The fix is to ship ca-certificates-udeb in installer
     stock images.

   * Debian already ships ca-certificate-udeb in the stock
     installer images; the fix is applied since Jan 2017.
     (reference: Debian Bug #842040 / d-i commit 2f00c51a [1])

  [Test Case]

   * In the installer shell:

     ~ # wget http://github.com  # or https://github.com

     - FAIL if ca-certificates-udeb is missing:
   "ERROR: cannot verify github.com's certificate, <...>'

     - PASS if ca-certificates-udeb is available
   "Saving to: 'index.html'"

   * Test steps with virt-install and netboot images
     are provided in the comments, for each release.

  [Regression Potential]

   * Low. This just adds the ca-certificates files in
     /etc/ssl/certs and symlink in /usr/lib/ssl/certs,
     so only tools looking for that would be affected.

   * Apparently only wget checks for/uses those files,
     and the difference in behavior is download errors
     no longer occur.

  [Notes]

   * The ca-certificates-udeb is not currently present
     in the Ubuntu archive despite being available for
     download in Launchpad with a link for some reason
     (perhaps a problem during import from Debian/sid?)

   * So this fix includes a no-change-rebuild for the
     ca-certificates package, in order to publish the
     udeb in the archive.

   * The ca-certificates and debian-installer builds
     have been done in a PPA using all architectures,
     and testing has been done with the amd64 images.

   * This fix is request for Bionic, Cosmic, Disco.

     The older releases (Trusty, Xenial) are affected,
     but not requested for, and would need more work,
     as the udeb is not yet in the packaging but that
     is doable if required for the process.

  [1] https://salsa.debian.org/installer-team/debian-
  installer/commit/2f00c51a7ead982ae1cd71bee06c8416890196b6

  [Debugging]

  For debugging purposes, one can install strace-udeb in the installer
  to verify wget's stat() calls to /usr/lib/ssl/certs.

  ~ # anna-install strace-udeb

  ~ # strace -e stat wget -O- https://github.com >/dev/null
  ...
  Resolving github.com... stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, 
st_size=20, ...}) = 0
  140.82.118.3, 140.82.118.4
  Connecting to github.com|140.82.118.3|:443... connected.
  stat("/usr/lib/ssl/certs/45bfefc3.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  ERROR: cannot verify github.com's certificate, issued by 'CN=DigiCert SHA2 
Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US':
    Unable to locally verify the issuer's authority.
  To connect to github.com insecurely, use `--no-check-certificate'.
  +++ exited with 5 +++
  ~ #

  ~ # anna-install ca-certificates-udeb  # not in archive yet.
  unknown udeb ca-certificates-udeb

  ~ # wget --no-check-certificate
  https://launchpad.net/ubuntu/+archive/primary/+files/ca-certificates-
  udeb_20180409_all.udeb

  ~ # udpkg -i ca-certificates-udeb_20180409_all.udeb

  ~ # strace -e stat wget

[Touch-packages] [Bug 1807023] Re: installer stock images fail to validate any HTTPS certificates (ca-certificates missing)

** Patch added: "lp1807023-debian-installer-bionic.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219787/+files/lp1807023-debian-installer-bionic.debdiff

** Patch removed: "lp1807023-ca-certificates-disco.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/ca-certificates/+bug/1807023/+attachment/5219767/+files/lp1807023-ca-certificates-disco.debdiff

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

Title:
  installer stock images fail to validate any HTTPS certificates (ca-
  certificates missing)

Status in ca-certificates package in Ubuntu:
  In Progress
Status in debian-installer package in Ubuntu:
  In Progress
Status in ca-certificates source package in Trusty:
  New
Status in debian-installer source package in Trusty:
  New
Status in ca-certificates source package in Xenial:
  New
Status in debian-installer source package in Xenial:
  New
Status in ca-certificates source package in Bionic:
  In Progress
Status in debian-installer source package in Bionic:
  In Progress
Status in ca-certificates source package in Cosmic:
  In Progress
Status in debian-installer source package in Cosmic:
  In Progress
Status in ca-certificates source package in Disco:
  In Progress
Status in debian-installer source package in Disco:
  In Progress
Status in debian-installer package in Debian:
  Fix Released

Bug description:
  [Impact]

   * The installer stock images fail to validate any HTTPS
     certificates because ca-certificates is not available
     in the installer environment.

   * This causes wget/download errors for preseed files on
     HTTPS servers (or HTTP servers that redirect to HTTPS,
     which are increasingly common nowadays - e.g., GitHub)
     and theoretically any other files that are downloaded
     with d-i-utils/fetch-url/wget.

   * The fix is to ship ca-certificates-udeb in installer
     stock images.

   * Debian already ships ca-certificate-udeb in the stock
     installer images; the fix is applied since Jan 2017.
     (reference: Debian Bug #842040 / d-i commit 2f00c51a [1])

  [Test Case]

   * In the installer shell:

     ~ # wget http://github.com  # or https://github.com

     - FAIL if ca-certificates-udeb is missing:
   "ERROR: cannot verify github.com's certificate, <...>'

     - PASS if ca-certificates-udeb is available
   "Saving to: 'index.html'"

   * Test steps with virt-install and netboot images
     are provided in the comments, for each release.

  [Regression Potential]

   * Low. This just adds the ca-certificates files in
     /etc/ssl/certs and symlink in /usr/lib/ssl/certs,
     so only tools looking for that would be affected.

   * Apparently only wget checks for/uses those files,
     and the difference in behavior is download errors
     no longer occur.

  [Notes]

   * The ca-certificates-udeb is not currently present
     in the Ubuntu archive despite being available for
     download in Launchpad with a link for some reason
     (perhaps a problem during import from Debian/sid?)

   * So this fix includes a no-change-rebuild for the
     ca-certificates package, in order to publish the
     udeb in the archive.

   * The ca-certificates and debian-installer builds
     have been done in a PPA using all architectures,
     and testing has been done with the amd64 images.

   * This fix is request for Bionic, Cosmic, Disco.

     The older releases (Trusty, Xenial) are affected,
     but not requested for, and would need more work,
     as the udeb is not yet in the packaging but that
     is doable if required for the process.

  [1] https://salsa.debian.org/installer-team/debian-
  installer/commit/2f00c51a7ead982ae1cd71bee06c8416890196b6

  [Debugging]

  For debugging purposes, one can install strace-udeb in the installer
  to verify wget's stat() calls to /usr/lib/ssl/certs.

  ~ # anna-install strace-udeb

  ~ # strace -e stat wget -O- https://github.com >/dev/null
  ...
  Resolving github.com... stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, 
st_size=20, ...}) = 0
  140.82.118.3, 140.82.118.4
  Connecting to github.com|140.82.118.3|:443... connected.
  stat("/usr/lib/ssl/certs/45bfefc3.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  ERROR: cannot verify github.com's certificate, issued by 'CN=DigiCert SHA2 
Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US':
    Unable to locally verify the issuer's authority.
  To connect to github.com insecurely, use `--no-check-certificate'.
  +++ exited with 5 +++
  ~ #

  ~ # anna-install ca-certificates-udeb  # not in archive yet.
  unknown udeb ca-certificates-udeb

  ~ #

[Touch-packages] [Bug 1807023] Re: installer stock images fail to validate any HTTPS certificates (ca-certificates missing)

** Also affects: ca-certificates (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: ca-certificates (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: ca-certificates (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: ca-certificates (Ubuntu Bionic)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: ca-certificates (Ubuntu Cosmic)
   Importance: Undecided => Medium

** Changed in: ca-certificates (Ubuntu Cosmic)
   Status: New => In Progress

** Changed in: ca-certificates (Ubuntu Cosmic)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: ca-certificates (Ubuntu Disco)
   Importance: Undecided => Medium

** Changed in: ca-certificates (Ubuntu Disco)
   Status: New => In Progress

** Changed in: ca-certificates (Ubuntu Disco)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

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

Title:
  installer stock images fail to validate any HTTPS certificates (ca-
  certificates missing)

Status in ca-certificates package in Ubuntu:
  In Progress
Status in debian-installer package in Ubuntu:
  In Progress
Status in ca-certificates source package in Trusty:
  New
Status in debian-installer source package in Trusty:
  New
Status in ca-certificates source package in Xenial:
  New
Status in debian-installer source package in Xenial:
  New
Status in ca-certificates source package in Bionic:
  In Progress
Status in debian-installer source package in Bionic:
  In Progress
Status in ca-certificates source package in Cosmic:
  In Progress
Status in debian-installer source package in Cosmic:
  In Progress
Status in ca-certificates source package in Disco:
  In Progress
Status in debian-installer source package in Disco:
  In Progress
Status in debian-installer package in Debian:
  Fix Released

Bug description:
  [Impact]

   * The installer stock images fail to validate any HTTPS
     certificates because ca-certificates is not available
     in the installer environment.

   * This causes wget/download errors for preseed files on
     HTTPS servers (or HTTP servers that redirect to HTTPS,
     which are increasingly common nowadays - e.g., GitHub)
     and theoretically any other files that are downloaded
     with d-i-utils/fetch-url/wget.

   * The fix is to ship ca-certificates-udeb in installer
     stock images.

   * Debian already ships ca-certificate-udeb in the stock
     installer images; the fix is applied since Jan 2017.
     (reference: Debian Bug #842040 / d-i commit 2f00c51a [1])

  [Test Case]

   * In the installer shell:

     ~ # wget http://github.com  # or https://github.com

     - FAIL if ca-certificates-udeb is missing:
   "ERROR: cannot verify github.com's certificate, <...>'

     - PASS if ca-certificates-udeb is available
   "Saving to: 'index.html'"

   * Test steps with virt-install and netboot images
     are provided in the comments, for each release.

  [Regression Potential]

   * Low. This just adds the ca-certificates files in
     /etc/ssl/certs and symlink in /usr/lib/ssl/certs,
     so only tools looking for that would be affected.

   * Apparently only wget checks for/uses those files,
     and the difference in behavior is download errors
     no longer occur.

  [Notes]

   * The ca-certificates-udeb is not currently present
     in the Ubuntu archive despite being available for
     download in Launchpad with a link for some reason
     (perhaps a problem during import from Debian/sid?)

   * So this fix includes a no-change-rebuild for the
     ca-certificates package, in order to publish the
     udeb in the archive.

   * The ca-certificates and debian-installer builds
     have been done in a PPA using all architectures,
     and testing has been done with the amd64 images.

   * This fix is request for Bionic, Cosmic, Disco.

     The older releases (Trusty, Xenial) are affected,
     but not requested for, and would need more work,
     as the udeb is not yet in the packaging but that
     is doable if required for the process.

  [1] https://salsa.debian.org/installer-team/debian-
  installer/commit/2f00c51a7ead982ae1cd71bee06c8416890196b6

  [Debugging]

  For debugging purposes, one can install strace-udeb in the installer
  to verify wget's stat() calls to /usr/lib/ssl/certs.

  ~ # anna-install strace-udeb

  ~ # strace -e stat wget -O- https://github.com >/dev/null
  ...
  Resolving github.com... stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, 
st_size=20, ...}) = 0
  140.82.118.3, 140.82.118.4
  Connecting to github.com|140.82.118.3|:443... connected.
  stat("/usr/lib/ssl/certs/45bfefc3.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)
  stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such 
file or directory)

[Touch-packages] [Bug 349469] Re: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable

2018-12-06 Thread Morais

** Changed in: aptdaemon
 Assignee: (unassigned) => Ismael Morais (morais28)

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

Title:
  debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by
  another process: Resource temporarily unavailable

Status in Aptdaemon:
  Fix Released
Status in Debconf:
  New
Status in aptdaemon package in Ubuntu:
  Invalid
Status in debconf package in Ubuntu:
  Triaged

Bug description:
  Upgrading packages that use debconf sometimes fail with the following
  error:

  debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by
  another process: Resource temporarily unavailable

To manage notifications about this bug go to:
https://bugs.launchpad.net/aptdaemon/+bug/349469/+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 1784485] Re: [ZenBook S UX391UA, Realtek ALC294, Mic, Internal] No sound at all

2018-12-06 Thread Alban Boissard

Hello,
sorry for my poor english, I am french.

A had exactly the same issue with a ASUS Zenbook UX433, and I fund a
solution.

The issue comes from the Kernel part of the Alsa drivers.

Daniel Drake and Jian-Hong Pan provided a patch in the alsa mailing list to fix 
this issue for UX533/UX433 laptop (and maybe other Asus models) :
http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/142572.html

This patch is not in the current kernel, nor in 4.20rc tree as far I can see.
Fortunatly, you can find a patched version of the files in :
https://github.com/endlessm/linux/tree/master/sound
(A nice, easy to use linux distro)

What I did :
- clone official Kernel source repo (4.19-7 in my case)
- clone endless Os repo
- Copy the "sound" folder from endless tree to official kernel tree.
- Compile the "no more official" Kernel. 
(I followed this tuto : 
https://wiki.archlinux.org/index.php/Kernel/Traditional_compilation because I 
use Manjaro, based on Arch) You have to find an appropriate tuto for Ubuntu. It 
was the firt time I compile a kernel.) 
- Use this kernel : the sound work perfectly.

Note : I'm absolutly not a linux expert, it maybe exists a better way to
use the patch than recompile the kernel.

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

Title:
  [ZenBook S UX391UA, Realtek ALC294, Mic, Internal] No sound at all

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Internal speaker - not sound at all
  Cable Headphonse - realy quiet disorted sound
  Bluetooth headphones - sound works fine

  On Windows 10 everything works fine.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  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
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  pmichalski   7964 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Jul 30 22:32:10 2018
  InstallationDate: Installed on 2018-07-17 (12 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=pl_PL.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH failed
  Symptom_Card: Wbudowany dźwięk - HDA Intel PCH
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  gdm2988 F pulseaudio
pmichalski   7964 F pulseaudio
  Symptom_Jack: Mic, Internal
  Symptom_Type: No sound at all
  Title: [ZenBook S UX391UA, Realtek ALC294, Mic, Internal] No sound at all
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/18/2018
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX391UA.204
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX391UA
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrUX391UA.204:bd05/18/2018:svnASUSTeKCOMPUTERINC.:pnZenBookSUX391UA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX391UA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: ZenBook S
  dmi.product.name: ZenBook S UX391UA
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.

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

2018-12-06 Thread Brian Murray

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

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

Title:
  iPhone doesn't charge when plugged in after disconnect

Status in usbmuxd package in Ubuntu:
  Fix Released
Status in usbmuxd source package in Bionic:
  Fix Released
Status in usbmuxd package in Debian:
  New

Bug description:
  * Impact
  the usbmuxd service is not restarted after disconnecting/reconnecting a 
device, which means users need to reboot (or use the command line to activate 
the service) to have their iphone handled a second time in a session

  * Test case
  - open an Ubuntu/GNOME session and connect an iphone
  - disconnect the device
  - connect it again

  -> it should be handled the second time like it was the first time

  * Regression potential
  The changes are in the udev rule, just make sure that idevices are correctly 
detected when connected

  
  

  
  Plugging in the iPhone via usb will charge the iPhone after reboot, but after 
disconnect usbmuxd's systemctl service is inactive and does not start.

  Problem and workaround documented here:

  https://ubuntuforums.org/showthread.php?t=2376741=13779062#post13779062

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/usbmuxd/+bug/1778767/+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 1778767] Re: iPhone doesn't charge when plugged in after disconnect

This bug was fixed in the package usbmuxd - 1.1.0-2ubuntu0.1

---
usbmuxd (1.1.0-2ubuntu0.1) bionic; urgency=medium

  * debian/patches/git_events_tagging.patch,
debian/patches/git_events_filter.patch,
debian/patches/git_bind_events.patch:
- backport some fixes for missing udev events on new kernel which were
  leading to the service not restarting after disconnecting and
  reconnecting a device. Thanks Leo Soares for suggesting a first
  version of the backport (lp: #1778767)

 -- Sebastien Bacher   Thu, 22 Nov 2018 16:37:58
+0100

** Changed in: usbmuxd (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

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

Title:
  iPhone doesn't charge when plugged in after disconnect

Status in usbmuxd package in Ubuntu:
  Fix Released
Status in usbmuxd source package in Bionic:
  Fix Released
Status in usbmuxd package in Debian:
  New

Bug description:
  * Impact
  the usbmuxd service is not restarted after disconnecting/reconnecting a 
device, which means users need to reboot (or use the command line to activate 
the service) to have their iphone handled a second time in a session

  * Test case
  - open an Ubuntu/GNOME session and connect an iphone
  - disconnect the device
  - connect it again

  -> it should be handled the second time like it was the first time

  * Regression potential
  The changes are in the udev rule, just make sure that idevices are correctly 
detected when connected

  
  

  
  Plugging in the iPhone via usb will charge the iPhone after reboot, but after 
disconnect usbmuxd's systemctl service is inactive and does not start.

  Problem and workaround documented here:

  https://ubuntuforums.org/showthread.php?t=2376741=13779062#post13779062

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/usbmuxd/+bug/1778767/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

> Sponsored all the CUPS package uploads: disco, cosmic, bionic, xenial,
> and subscribed SRU team.

hmm, cups is still in disco-proposed currently, so hopefully that
proceeds to -updates without problems.

Thanks.

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  In Progress
Status in cups source package in Trusty:
  Invalid
Status in cups source package in Xenial:
  In Progress
Status in cups source package in Bionic:
  In Progress
Status in cups source package in Cosmic:
  In Progress
Status in cups source package in Disco:
  In Progress
Status in cups package in Debian:
  New

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no
   difference in behavior except for the special value of MaxJobTime=0.

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

  Trusty is not affected by this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1805027] Re: systemd-resolved can't resolve Comcast mail server addresses

2018-12-06 Thread Mathieu Trudel-Lapierre

Setting to Triaged: it's easily reproduced by developers, and we have
all the information we need to debug it -- nothing is secret or hidden,
just needs someone to look at the packets and what resolved does with
them.

** Changed in: systemd (Ubuntu)
   Status: Confirmed => 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/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

[Touch-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

2018-12-06 Thread Till Kamppeter

Sponsored all the CUPS package uploads: disco, cosmic, bionic, xenial,
and subscribed SRU team.

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  In Progress
Status in cups source package in Trusty:
  Invalid
Status in cups source package in Xenial:
  In Progress
Status in cups source package in Bionic:
  In Progress
Status in cups source package in Cosmic:
  In Progress
Status in cups source package in Disco:
  In Progress
Status in cups package in Debian:
  New

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no
   difference in behavior except for the special value of MaxJobTime=0.

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

  Trusty is not affected by this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1805027] Re: systemd-resolved can't resolve Comcast mail server addresses

2018-12-06 Thread Brian Murray

There is a systemd SRU for Cosmic in progress, bug 1804487, which may be
the same issue as this bug. If someone affected could install the
version of systemd from cosmic-proposed and report back that would be
helpful.  Thanks!

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

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

[Touch-packages] [Bug 1802135] Re: broken touchpad after i2c-i801 blacklist change

2018-12-06 Thread AaronMa

thinkpad 11e 3rd touchpad works fine on bionic proposed kernel 
linux-image-4.15.0-1029-oem.
i2c-i801 is loaded.
touchpad is detected as s3203_ver5.

Could you try this kernel with i2c_i801 unblacklisted?

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

Title:
  broken touchpad after i2c-i801 blacklist change

Status in kmod package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in kmod source package in Xenial:
  Fix Committed
Status in linux source package in Xenial:
  Confirmed
Status in kmod source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Confirmed
Status in kmod source package in Cosmic:
  Fix Committed
Status in linux source package in Cosmic:
  Confirmed

Bug description:
  SRU:
  

  [Impact]
  ThinkPad 11e 2nd/3rd touchpad not working when load i2c-i801.
  PNP LEN0049 will use smbus by default in kernel, but i2c bus is in
  runtime suspend mode in old touchpad fw.
  Then touchpad will not work.
  LEN2040 on 11e 3rd can reproduce this issue by passing
  psmouse.synaptics_intertouch=1

  These 2 pnp device should be the same one Synaptics s3203_ver5.

  [Fix]
  i2c-i801 should auto suspend when not used, no need runtime pm.

  [Test Case]
  Tested on Thinkpad 11e 3rd.
  Touchpad works fine.

  [Regression Potential]
  Low, upstream fix cherry-picked.

  4.18 kernel patch, no need for cosmic.

  
  Original bug report:
  =
  After upgrading to kmod (24-1ubuntu3.1) the trackpads stop working on Lenovo 
11e 2nd gen machines.

  We have a fleet of approximetly 1000 of them in production running
  ubuntu 18.04. Prior to this update the trackpads worked out of box in
  18.04.

  We are currently working around the issue by deploying our own
  blacklist files.

  Here is a link to the SRU justification: https://bugs.launchpad.net
  /hwe-next/+bug/1786574

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1802135/+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 1804027] Re: dbus-daemon sigsegv, apport cannot report it: expected core size ...

2018-12-06 Thread LGB [Gábor Lénárt]

OK, the touchpad issue is not related at all, there is a kernel driver
explanation of that. Now it works (the touchpad) but still, the
mentioned dbus error message occurs from time to time, not so consistent
though now.

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

Title:
  dbus-daemon sigsegv, apport cannot report it: expected core size ...

Status in dbus package in Ubuntu:
  Confirmed

Bug description:
  At almost every boot and login after a while I get a "Ubuntu 18.10 has
  experienced an internal error" window. However it says, coredump size
  is too small (see attached screenshot).

  Also no idea if it is related but touchpad of the notebook does not
  work only external mouse. This is a fresh 18.10 install on this new
  Lenovo L580 notebook, live version of ubuntu worked fine with touchpad
  and there was no window on dbus like that. However after the install
  it worked only once, then not anymore, regardless of reboot, powering
  off and on etc, and usually the mentioned internal error window is
  shown.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: dbus 1.12.10-1ubuntu2
  ProcVersionSignature: Ubuntu 4.18.0-11.12-generic 4.18.12
  Uname: Linux 4.18.0-11-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Nov 19 17:24:50 2018
  InstallationDate: Installed on 2018-11-15 (3 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  SourcePackage: dbus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1804027/+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 1804027] Re: dbus-daemon sigsegv, apport cannot report it: expected core size ...

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

Title:
  dbus-daemon sigsegv, apport cannot report it: expected core size ...

Status in dbus package in Ubuntu:
  Confirmed

Bug description:
  At almost every boot and login after a while I get a "Ubuntu 18.10 has
  experienced an internal error" window. However it says, coredump size
  is too small (see attached screenshot).

  Also no idea if it is related but touchpad of the notebook does not
  work only external mouse. This is a fresh 18.10 install on this new
  Lenovo L580 notebook, live version of ubuntu worked fine with touchpad
  and there was no window on dbus like that. However after the install
  it worked only once, then not anymore, regardless of reboot, powering
  off and on etc, and usually the mentioned internal error window is
  shown.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: dbus 1.12.10-1ubuntu2
  ProcVersionSignature: Ubuntu 4.18.0-11.12-generic 4.18.12
  Uname: Linux 4.18.0-11-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Nov 19 17:24:50 2018
  InstallationDate: Installed on 2018-11-15 (3 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  SourcePackage: dbus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1804027/+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 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath

2018-12-06 Thread Andrew Cloke

Update: IBM is working on the bionic verification.

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

Title:
  ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting
  partitions name for the mpath

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Bionic:
  Incomplete

Bug description:
  
  [Impact]
  Any user of Ubuntu on multipath, where the default path separator has been 
changed to something else. This possibly affects other scenarios where the 
partition separator can be changed.

  [Test case]
  1) Install Ubuntu on multipath system
  2) Change /etc/multipath.conf to set "path_separator" to "" or "p".
  3) Reboot
  4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions 
where the path separator would be visible.

  
  [Regression potential]
  Minimal. This only affects display. Default separator on Ubuntu remains 
"-part". If the separator is not one of "", "p", or "-part", then "-part" would 
be used, as is already the case.

  
  == Comment: #0 - Chanh H. Nguyen  - 2018-01-09 11:14:07 
==
  We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the 
Emulex adapter to have the mpath disk.
  Running the fdisk -l and ls -l showing the conflict name for the mpath.

  :~# uname -a
  Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
  root@boslcp4:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="18.04 LTS (Bionic Beaver)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Bionic Beaver (development branch)"
  VERSION_ID="18.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=bionic
  UBUNTU_CODENAME=bionic

  :~# fdisk -l /dev/mapper/mpatha
  Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 32768 bytes / 32768 bytes
  Disklabel type: dos
  Disk identifier: 0xa5be904b

  Device   Boot StartEnd   Sectors  Size Id Type
  /dev/mapper/mpatha-part1   2048  419432447 419430400  200G 83 Linux
  /dev/mapper/mpatha-part2  419432448  838862847 419430400  200G 83 Linux
  /dev/mapper/mpatha-part3  838862848 1258291199 419428352  200G 83 Linux

  :~# ls -l /dev/mapper/mpatha*
  lrwxrwxrwx 1 root root 7 Jan  9 04:04 /dev/mapper/mpatha -> ../dm-0
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha1 -> ../dm-1
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha2 -> ../dm-2
  lrwxrwxrwx 1 root root 7 Jan  9 04:03 /dev/mapper/mpatha3 -> ../dm-3

  == Comment: #2 - Chanh H. Nguyen  - 2018-01-09 11:35:04 
==
  I just modify the partitions and it is still showing the conflicting name on 
partitions.

  :~# ls -l /dev/mapper/mpatha*
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha -> ../dm-0
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha1 -> ../dm-1
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha2 -> ../dm-2
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha3 -> ../dm-3
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha4 -> ../dm-4
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha5 -> ../dm-5
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha6 -> ../dm-6
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha7 -> ../dm-7
  lrwxrwxrwx 1 root root 7 Jan  9 04:33 /dev/mapper/mpatha8 -> ../dm-8

  :~# fdisk -l /dev/mapper/mpatha
  Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 32768 bytes / 32768 bytes
  Disklabel type: dos
  Disk identifier: 0xa5be904b

  Device   Boot  StartEnd   Sectors  Size Id Type
  /dev/mapper/mpatha-part12048  419432447 419430400  200G 83 Linux
  /dev/mapper/mpatha-part2   419432448  838862847 419430400  200G 83 Linux
  /dev/mapper/mpatha-part3   838862848  964691967 125829120   60G 83 Linux
  /dev/mapper/mpatha-part4   964691968 1258291199 293599232  140G  5 
Extended
  /dev/mapper/mpatha-part5   964694016 1006637055  41943040   20G 83 Linux
  /dev/mapper/mpatha-part6  1006639104 1048582143  41943040   20G 83 Linux
  /dev/mapper/mpatha-part7  1048584192 1090527231  41943040   20G 83 Linux
  /dev/mapper/mpatha-part8  1090529280 1132472319  41943040   20G 83 Linux

  == Comment: #5 - Kyle Mahlkuch  - 2018-06-26 13:50:12 
==
  I have created and submitted a patch that should help with

[Touch-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

2018-12-06 Thread Bug Watch Updater

** Changed in: cups (Debian)
   Status: Unknown => New

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  In Progress
Status in cups source package in Trusty:
  Invalid
Status in cups source package in Xenial:
  In Progress
Status in cups source package in Bionic:
  In Progress
Status in cups source package in Cosmic:
  In Progress
Status in cups source package in Disco:
  In Progress
Status in cups package in Debian:
  New

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no
   difference in behavior except for the special value of MaxJobTime=0.

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

  Trusty is not affected by this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

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

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

** Patch added: "lp1804576-disco.debdiff"
   
https://bugs.launchpad.net/debian/+source/cups/+bug/1804576/+attachment/5219728/+files/lp1804576-disco.debdiff

** Patch removed: "disco_cups_2.2.9-3ubuntu1.debdiff"
   
https://bugs.launchpad.net/debian/+source/cups/+bug/1804576/+attachment/5219720/+files/disco_cups_2.2.9-3ubuntu1.debdiff

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  In Progress
Status in cups source package in Trusty:
  Invalid
Status in cups source package in Xenial:
  In Progress
Status in cups source package in Bionic:
  In Progress
Status in cups source package in Cosmic:
  In Progress
Status in cups source package in Disco:
  In Progress
Status in cups package in Debian:
  Unknown

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no
   difference in behavior except for the special value of MaxJobTime=0.

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

  Trusty is not affected by this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

** Changed in: cups (Ubuntu Disco)
 Assignee: Dariusz Gadomski (dgadomski) => Dan Streetman (ddstreet)

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  In Progress
Status in cups source package in Trusty:
  Invalid
Status in cups source package in Xenial:
  In Progress
Status in cups source package in Bionic:
  In Progress
Status in cups source package in Cosmic:
  In Progress
Status in cups source package in Disco:
  In Progress
Status in cups package in Debian:
  Unknown

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no
   difference in behavior except for the special value of MaxJobTime=0.

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

  Trusty is not affected by this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

** Tags added: sts-sponsor sts-sponsor-ddstreet

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  In Progress
Status in cups source package in Trusty:
  Invalid
Status in cups source package in Xenial:
  In Progress
Status in cups source package in Bionic:
  In Progress
Status in cups source package in Cosmic:
  In Progress
Status in cups source package in Disco:
  In Progress

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no
   difference in behavior except for the special value of MaxJobTime=0.

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

  Trusty is not affected by this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1807138] [NEW] [HDA-Intel - HDA Intel PCH, playback] Headphones not automatically detected

2018-12-06 Thread Arne De Herdt

Public bug reported:

Running the command alsamixer allows me to manually increase the sound levels 
for the headset, and sound plays properly through them. This requires me to 
disable the auto-mute feature.
I haven't rebooted my system yet to see if this is permanent.
But the UI doesn't show the heaphones at all and only sends sound through the 
main speakers of the laptop.

➜  ~ lspci -nnk | grep -i -A7 audio
00:1f.3 Audio device [0403]: Intel Corporation Device [8086:a348] (rev 10)
Subsystem: Razer USA Ltd. Device [1a58:2001]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:a323] (rev 10)
Subsystem: Razer USA Ltd. Device [1a58:2001]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801

➜  ~ cat /proc/asound/card0/codec* | grep Codec 
Codec: Realtek ALC256
Codec: Intel Kabylake HDMI

Using for example pavucontrol allows me to select the headphone, which are 
marked as unplugged, and I can play audio through them as long as I keep the 
application open.
If I reboot or close pavucontrol, everything is back to the original state and 
only the speakers work.

Additional Information:

➜  ~ lsb_release -rd 
Description:Ubuntu 18.04.1 LTS
Release:18.04

What I expect to happen:

When I plug in my headphones, Ubuntu and the UI should see them and
automatically redirect all sound through them.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
Uname: Linux 4.15.0-42-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
AudioDevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/pcmC0D0p:   olivar 8320 F...m pulseaudio
 /dev/snd/controlC0:  olivar 8320 F pulseaudio
CurrentDesktop: X-Cinnamon
Date: Thu Dec  6 13:02:14 2018
InstallationDate: Installed on 2018-11-21 (15 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful
Symptom_Card: Built-in Audio - HDA Intel PCH
Symptom_PulsePlaybackTest: PulseAudio playback test successful
Symptom_Type: Only some of outputs are working
Title: [HDA-Intel - HDA Intel PCH, playback] Playback problem
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/31/2018
dmi.bios.vendor: Razer
dmi.bios.version: 01.01
dmi.board.name: DANA_MB
dmi.board.vendor: Razer
dmi.chassis.type: 10
dmi.chassis.vendor: Razer
dmi.modalias: 
dmi:bvnRazer:bvr01.01:bd08/31/2018:svnRazer:pnBlade:pvr1.04:rvnRazer:rnDANA_MB:rvr:cvnRazer:ct10:cvr:
dmi.product.family: 1A582001 Razer Blade
dmi.product.name: Blade
dmi.product.version: 1.04
dmi.sys.vendor: Razer

** Affects: alsa-driver (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic

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

Title:
  [HDA-Intel - HDA Intel PCH, playback] Headphones not automatically
  detected

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  Running the command alsamixer allows me to manually increase the sound levels 
for the headset, and sound plays properly through them. This requires me to 
disable the auto-mute feature.
  I haven't rebooted my system yet to see if this is permanent.
  But the UI doesn't show the heaphones at all and only sends sound through the 
main speakers of the laptop.

  ➜  ~ lspci -nnk | grep -i -A7 audio
  00:1f.3 Audio device [0403]: Intel Corporation Device [8086:a348] (rev 10)
Subsystem: Razer USA Ltd. Device [1a58:2001]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
  00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:a323] (rev 10)
Subsystem: Razer USA Ltd. Device [1a58:2001]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801

  ➜  ~ cat /proc/asound/card0/codec* | grep Codec 
  Codec: Realtek ALC256
  Codec: Intel Kabylake HDMI

  Using for example pavucontrol allows me to select the headphone, which are 
marked as unplugged, and I can play audio through them as long as I keep the 
application open.
  If I reboot or close pavucontrol, everything is back to the original state 
and only the speakers work.

  Additional Information:

  ➜  ~ lsb_release -rd 
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04

  What I expect to happen:

  When I plug in my headphones, Ubuntu and the UI should see them and
  automatically redirect all sound through them.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu

[Touch-packages] [Bug 1807138] Re: [HDA-Intel - HDA Intel PCH, playback] Headphones not automatically detected

2018-12-06 Thread Arne De Herdt

I've taken a screenshot of the alsamixer.
This configuration currently is the only way for me to get sound out of my 
headset and not the speakers:

* Enable master sound
* Enable headphones, and assign volume
* Enable speakers, but put volume to 0, don't mute
* disable auto-mute

** Attachment added: "alsamixer confiugration"
   
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1807138/+attachment/5219727/+files/Screenshot%20from%202018-12-06%2013-15-32.png

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

Title:
  [HDA-Intel - HDA Intel PCH, playback] Headphones not automatically
  detected

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  Running the command alsamixer allows me to manually increase the sound levels 
for the headset, and sound plays properly through them. This requires me to 
disable the auto-mute feature.
  I haven't rebooted my system yet to see if this is permanent.
  But the UI doesn't show the heaphones at all and only sends sound through the 
main speakers of the laptop.

  ➜  ~ lspci -nnk | grep -i -A7 audio
  00:1f.3 Audio device [0403]: Intel Corporation Device [8086:a348] (rev 10)
Subsystem: Razer USA Ltd. Device [1a58:2001]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
  00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:a323] (rev 10)
Subsystem: Razer USA Ltd. Device [1a58:2001]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801

  ➜  ~ cat /proc/asound/card0/codec* | grep Codec 
  Codec: Realtek ALC256
  Codec: Intel Kabylake HDMI

  Using for example pavucontrol allows me to select the headphone, which are 
marked as unplugged, and I can play audio through them as long as I keep the 
application open.
  If I reboot or close pavucontrol, everything is back to the original state 
and only the speakers work.

  Additional Information:

  ➜  ~ lsb_release -rd 
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04

  What I expect to happen:

  When I plug in my headphones, Ubuntu and the UI should see them and
  automatically redirect all sound through them.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
  Uname: Linux 4.15.0-42-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   olivar 8320 F...m pulseaudio
   /dev/snd/controlC0:  olivar 8320 F pulseaudio
  CurrentDesktop: X-Cinnamon
  Date: Thu Dec  6 13:02:14 2018
  InstallationDate: Installed on 2018-11-21 (15 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful
  Symptom_Card: Built-in Audio - HDA Intel PCH
  Symptom_PulsePlaybackTest: PulseAudio playback test successful
  Symptom_Type: Only some of outputs are working
  Title: [HDA-Intel - HDA Intel PCH, playback] Playback problem
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/31/2018
  dmi.bios.vendor: Razer
  dmi.bios.version: 01.01
  dmi.board.name: DANA_MB
  dmi.board.vendor: Razer
  dmi.chassis.type: 10
  dmi.chassis.vendor: Razer
  dmi.modalias: 
dmi:bvnRazer:bvr01.01:bd08/31/2018:svnRazer:pnBlade:pvr1.04:rvnRazer:rnDANA_MB:rvr:cvnRazer:ct10:cvr:
  dmi.product.family: 1A582001 Razer Blade
  dmi.product.name: Blade
  dmi.product.version: 1.04
  dmi.sys.vendor: Razer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1807138/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

SRU proposal for disco (fixed)

** Patch removed: "disco_cups_2.2.9-3ubuntu1.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219664/+files/disco_cups_2.2.9-3ubuntu1.debdiff

** Patch added: "disco_cups_2.2.9-3ubuntu1.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219720/+files/disco_cups_2.2.9-3ubuntu1.debdiff

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  In Progress
Status in cups source package in Trusty:
  Invalid
Status in cups source package in Xenial:
  In Progress
Status in cups source package in Bionic:
  In Progress
Status in cups source package in Cosmic:
  In Progress
Status in cups source package in Disco:
  In Progress

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no
   difference in behavior except for the special value of MaxJobTime=0.

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

  Trusty is not affected by this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

** Changed in: cups (Ubuntu Trusty)
   Status: New => Invalid

** Description changed:

  [Impact]
  
-  Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
+  Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.
  
  [Test Case]
  
-  1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
-  2. Setup a filter that takes at least several seconds to process.
- (please find a sample imagetopdf wrapper introducing 5s delay)
-  3. Submit a print job matching the filter, e.g.
- lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper
+  1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
+  2. Setup a filter that takes at least several seconds to process.
+ (please find a sample imagetopdf wrapper introducing 5s delay)
+  3. Submit a print job matching the filter, e.g.
+ lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper
  
  Expected result:
  The job is printed after the 5s delay.
  
  Actual result:
  The job is cancelled.
  
  [Regression Potential]
  
-  The scope of the change is limited to fixing the MaxJobTime handling
-  in scheduler/job.c and scheduler/printers.c. There should be no 
-  difference in behavior except for the special value of MaxJobTime=0.
-  
+  The scope of the change is limited to fixing the MaxJobTime handling
+  in scheduler/job.c and scheduler/printers.c. There should be no
+  difference in behavior except for the special value of MaxJobTime=0.
  
  [Other Info]
  Original bug description:
  
  When using CUPS filters, these filters can take a few seconds to
  complete.
  
  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.
  
  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.
  
  Then, the job is deleted and lost.
  
  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".
  
  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438
  
  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)
+ 
+ Trusty is not affected by this bug.

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  In Progress
Status in cups source package in Trusty:
  Invalid
Status in cups source package in Xenial:
  In Progress
Status in cups source package in Bionic:
  In Progress
Status in cups source package in Cosmic:
  In Progress
Status in cups source package in Disco:
  In Progress

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no
   difference in behavior except for the special value of MaxJobTime=0.

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get

[Touch-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

** Also affects: cups (Ubuntu Disco)
   Importance: Medium
   Status: Confirmed

** Also affects: cups (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: cups (Ubuntu Disco)
 Assignee: (unassigned) => Dariusz Gadomski (dgadomski)

** Changed in: cups (Ubuntu Cosmic)
 Assignee: (unassigned) => Dariusz Gadomski (dgadomski)

** Changed in: cups (Ubuntu Bionic)
 Assignee: (unassigned) => Dariusz Gadomski (dgadomski)

** Changed in: cups (Ubuntu Xenial)
 Assignee: (unassigned) => Dariusz Gadomski (dgadomski)

** Changed in: cups (Ubuntu Cosmic)
   Importance: Undecided => Medium

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

** Changed in: cups (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cups (Ubuntu Cosmic)
   Status: New => In Progress

** Changed in: cups (Ubuntu Disco)
   Status: Confirmed => In Progress

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

** Changed in: cups (Ubuntu Xenial)
   Status: New => In Progress

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

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

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no 
   difference in behavior except for the special value of MaxJobTime=0.
   

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1807134] [NEW] lxc 3.0.2 - cannot create root password in privileged container

2018-12-06 Thread km

Public bug reported:

Prior filing this as potential bug help was sought but did not yield a
remedy

https://discuss.linuxcontainers.org/t/3-0-2-bug-cannot-create-root-
password-in-privileged-container/3425

host - ubuntu cosmic with 4.18.0-12 kernel / systemd 239-7 / apparmor
2.12

Whilst there is no issue with creating a root password via lxc-attach
and passwd in an unprivileged container it is however not possible to
create a password the same way for a privileged container (tried centos
7 and ubuntu cosmic).

Error reported from within the containers:

passwd: System error
passwd: Authentication token manipulation error

Error reported at the host:

passwd: PAM audit_log_acct_message() failed: Operation not permitted


Next tried with:

chroot /srv/lxc/container_name/rootfs passwd

but that produced the same error.


Next tried with:

lxc.cap.keep = CAP_AUDIT_WRITE

but the container would not boot.


Next tried with:

lxc.apparmor.profile = unconfined

but no remedy.


Next switched the kernel to 4.19.7 but no dice either.

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

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

Title:
  lxc 3.0.2  - cannot create root password in privileged container

Status in lxc package in Ubuntu:
  New

Bug description:
  Prior filing this as potential bug help was sought but did not yield a
  remedy

  https://discuss.linuxcontainers.org/t/3-0-2-bug-cannot-create-root-
  password-in-privileged-container/3425

  host - ubuntu cosmic with 4.18.0-12 kernel / systemd 239-7 / apparmor
  2.12

  Whilst there is no issue with creating a root password via lxc-attach
  and passwd in an unprivileged container it is however not possible to
  create a password the same way for a privileged container (tried
  centos 7 and ubuntu cosmic).

  Error reported from within the containers:

  passwd: System error
  passwd: Authentication token manipulation error

  Error reported at the host:

  passwd: PAM audit_log_acct_message() failed: Operation not permitted


  Next tried with:

  chroot /srv/lxc/container_name/rootfs passwd

  but that produced the same error.

  
  Next tried with:

  lxc.cap.keep = CAP_AUDIT_WRITE

  but the container would not boot.

  
  Next tried with:

  lxc.apparmor.profile = unconfined

  but no remedy.

  
  Next switched the kernel to 4.19.7 but no dice either.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1807134/+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 1807077] Re: [SRU] mountall crashes on udev node with missing devname

mountall is not used at boot in xenial, xenial is systemd-only for the
system init and upstart is only used for user sessions in xenial (so the
mountall dep is vestigial).  So we should not spend time fixing this bug
in xenial, it's not relevant.


** Changed in: mountall (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

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

Title:
  [SRU] mountall crashes on udev node with missing devname

Status in mountall package in Ubuntu:
  Invalid
Status in mountall source package in Trusty:
  Confirmed
Status in mountall source package in Xenial:
  Won't Fix

Bug description:
  [Impact]

   * udev block nodes without a devname will crash mountall, resulting
  in an unbootable system (emergency root shell)

   * While this is not likely to happen in a matched distro/kernel
  environment (it was discovered while needing to run a bionic 4.15
  kernel on trusty), it is possible.

   * The code in try_udev_device() assumes a block subsystem will always
  have a devname; the SRU patches explicitly check for a devname and
  return if null.

  [Test Case]

   * HPE DL385 Gen10, Samsung a822 NVMe controller, trusty install

   * Kernels <4.15 (or possibly 4.14) do not expose nvme0c33n1 and do
  not trigger the bug.  Tested on 4.13, 4.4 and 3.13.

   * Kernel 4.15 exposes nvme0c33n1 in udev but does not have a devname,
  mountall crash ensues.

  [Regression Potential]

   * Patch might ignore legitimate block devices on existing
  installations.  Unlikely, since the logic path for null devname leads
  directly to a program crash.

  [Other Info]
   
   * Additional context for Canonical employees: PS4.5 is a trusty backend 
cloud, but we now have Gen10 hardware incoming (this was discovered while 
adding new nova-compute hardware).  Older kernels are not usable because Gen10 
requires ilorest, which requires a >4.4 kernel (at least artful 4.13 is known 
good).  So trusty+4.15 is the only viable combination for continued support of 
the cloud while adding new hardware.  This is done via apt pinning of bionic 
for the kernel packages, and, mountall notwithstanding, is working fine so far.

  
  Original description:

  Running bionic's 4.15 kernel on trusty on an HPE DL385 Gen10 results
  in a device node for the NVMe controller,
  /devices/pci:40/:40:03.1/:43:00.0/nvme/nvme0/nvme0c33n1
  which itself does not have a devname.  When mountall gets to it:

  fsck_update: updating check priorities
  try_mount: /srv/nova/instances waiting for device
  try_udev_device: ignored /dev/loop5 (not yet ready?)
  try_udev_device: ignored /dev/loop6 (not yet ready?)
  try_udev_device: ignored /dev/loop1 (not yet ready?)
  try_udev_device: ignored /dev/loop0 (not yet ready?)
  try_udev_device: block (null) (null) (null)

  and then crashes, leaving the boot at an emergency root shell.  A
  successful scan looks like this for comparison:

  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sda (null) (null)
  try_udev_device: block /dev/nvme0n1 ed56e3a9-60f7-4636-85a2-b53137b598e7 
(null)
  try_udev_device: block /dev/bcache0 756cb2c6-b999-4905-a021-c2e688e81a86 
instances

  The debdiffs check for a null devname in try_udev_device() and will
  not attempt to process it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1807077/+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 1807077] Re: [SRU] mountall crashes on udev node with missing devname

And for devel, this is invalid because mountall does not exist in bionic
and later.

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

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

Title:
  [SRU] mountall crashes on udev node with missing devname

Status in mountall package in Ubuntu:
  Invalid
Status in mountall source package in Trusty:
  Confirmed
Status in mountall source package in Xenial:
  Won't Fix

Bug description:
  [Impact]

   * udev block nodes without a devname will crash mountall, resulting
  in an unbootable system (emergency root shell)

   * While this is not likely to happen in a matched distro/kernel
  environment (it was discovered while needing to run a bionic 4.15
  kernel on trusty), it is possible.

   * The code in try_udev_device() assumes a block subsystem will always
  have a devname; the SRU patches explicitly check for a devname and
  return if null.

  [Test Case]

   * HPE DL385 Gen10, Samsung a822 NVMe controller, trusty install

   * Kernels <4.15 (or possibly 4.14) do not expose nvme0c33n1 and do
  not trigger the bug.  Tested on 4.13, 4.4 and 3.13.

   * Kernel 4.15 exposes nvme0c33n1 in udev but does not have a devname,
  mountall crash ensues.

  [Regression Potential]

   * Patch might ignore legitimate block devices on existing
  installations.  Unlikely, since the logic path for null devname leads
  directly to a program crash.

  [Other Info]
   
   * Additional context for Canonical employees: PS4.5 is a trusty backend 
cloud, but we now have Gen10 hardware incoming (this was discovered while 
adding new nova-compute hardware).  Older kernels are not usable because Gen10 
requires ilorest, which requires a >4.4 kernel (at least artful 4.13 is known 
good).  So trusty+4.15 is the only viable combination for continued support of 
the cloud while adding new hardware.  This is done via apt pinning of bionic 
for the kernel packages, and, mountall notwithstanding, is working fine so far.

  
  Original description:

  Running bionic's 4.15 kernel on trusty on an HPE DL385 Gen10 results
  in a device node for the NVMe controller,
  /devices/pci:40/:40:03.1/:43:00.0/nvme/nvme0/nvme0c33n1
  which itself does not have a devname.  When mountall gets to it:

  fsck_update: updating check priorities
  try_mount: /srv/nova/instances waiting for device
  try_udev_device: ignored /dev/loop5 (not yet ready?)
  try_udev_device: ignored /dev/loop6 (not yet ready?)
  try_udev_device: ignored /dev/loop1 (not yet ready?)
  try_udev_device: ignored /dev/loop0 (not yet ready?)
  try_udev_device: block (null) (null) (null)

  and then crashes, leaving the boot at an emergency root shell.  A
  successful scan looks like this for comparison:

  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sda (null) (null)
  try_udev_device: block /dev/nvme0n1 ed56e3a9-60f7-4636-85a2-b53137b598e7 
(null)
  try_udev_device: block /dev/bcache0 756cb2c6-b999-4905-a021-c2e688e81a86 
instances

  The debdiffs check for a null devname in try_udev_device() and will
  not attempt to process it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1807077/+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 1807077] Re: [SRU] mountall crashes on udev node with missing devname

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

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

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

Title:
  [SRU] mountall crashes on udev node with missing devname

Status in mountall package in Ubuntu:
  Confirmed
Status in mountall source package in Trusty:
  Confirmed
Status in mountall source package in Xenial:
  Confirmed

Bug description:
  [Impact]

   * udev block nodes without a devname will crash mountall, resulting
  in an unbootable system (emergency root shell)

   * While this is not likely to happen in a matched distro/kernel
  environment (it was discovered while needing to run a bionic 4.15
  kernel on trusty), it is possible.

   * The code in try_udev_device() assumes a block subsystem will always
  have a devname; the SRU patches explicitly check for a devname and
  return if null.

  [Test Case]

   * HPE DL385 Gen10, Samsung a822 NVMe controller, trusty install

   * Kernels <4.15 (or possibly 4.14) do not expose nvme0c33n1 and do
  not trigger the bug.  Tested on 4.13, 4.4 and 3.13.

   * Kernel 4.15 exposes nvme0c33n1 in udev but does not have a devname,
  mountall crash ensues.

  [Regression Potential]

   * Patch might ignore legitimate block devices on existing
  installations.  Unlikely, since the logic path for null devname leads
  directly to a program crash.

  [Other Info]
   
   * Additional context for Canonical employees: PS4.5 is a trusty backend 
cloud, but we now have Gen10 hardware incoming (this was discovered while 
adding new nova-compute hardware).  Older kernels are not usable because Gen10 
requires ilorest, which requires a >4.4 kernel (at least artful 4.13 is known 
good).  So trusty+4.15 is the only viable combination for continued support of 
the cloud while adding new hardware.  This is done via apt pinning of bionic 
for the kernel packages, and, mountall notwithstanding, is working fine so far.

  
  Original description:

  Running bionic's 4.15 kernel on trusty on an HPE DL385 Gen10 results
  in a device node for the NVMe controller,
  /devices/pci:40/:40:03.1/:43:00.0/nvme/nvme0/nvme0c33n1
  which itself does not have a devname.  When mountall gets to it:

  fsck_update: updating check priorities
  try_mount: /srv/nova/instances waiting for device
  try_udev_device: ignored /dev/loop5 (not yet ready?)
  try_udev_device: ignored /dev/loop6 (not yet ready?)
  try_udev_device: ignored /dev/loop1 (not yet ready?)
  try_udev_device: ignored /dev/loop0 (not yet ready?)
  try_udev_device: block (null) (null) (null)

  and then crashes, leaving the boot at an emergency root shell.  A
  successful scan looks like this for comparison:

  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sda (null) (null)
  try_udev_device: block /dev/nvme0n1 ed56e3a9-60f7-4636-85a2-b53137b598e7 
(null)
  try_udev_device: block /dev/bcache0 756cb2c6-b999-4905-a021-c2e688e81a86 
instances

  The debdiffs check for a null devname in try_udev_device() and will
  not attempt to process it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1807077/+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 1807077] Re: [SRU] mountall crashes on udev node with missing devname

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

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

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

Title:
  [SRU] mountall crashes on udev node with missing devname

Status in mountall package in Ubuntu:
  Confirmed
Status in mountall source package in Trusty:
  Confirmed
Status in mountall source package in Xenial:
  Confirmed

Bug description:
  [Impact]

   * udev block nodes without a devname will crash mountall, resulting
  in an unbootable system (emergency root shell)

   * While this is not likely to happen in a matched distro/kernel
  environment (it was discovered while needing to run a bionic 4.15
  kernel on trusty), it is possible.

   * The code in try_udev_device() assumes a block subsystem will always
  have a devname; the SRU patches explicitly check for a devname and
  return if null.

  [Test Case]

   * HPE DL385 Gen10, Samsung a822 NVMe controller, trusty install

   * Kernels <4.15 (or possibly 4.14) do not expose nvme0c33n1 and do
  not trigger the bug.  Tested on 4.13, 4.4 and 3.13.

   * Kernel 4.15 exposes nvme0c33n1 in udev but does not have a devname,
  mountall crash ensues.

  [Regression Potential]

   * Patch might ignore legitimate block devices on existing
  installations.  Unlikely, since the logic path for null devname leads
  directly to a program crash.

  [Other Info]
   
   * Additional context for Canonical employees: PS4.5 is a trusty backend 
cloud, but we now have Gen10 hardware incoming (this was discovered while 
adding new nova-compute hardware).  Older kernels are not usable because Gen10 
requires ilorest, which requires a >4.4 kernel (at least artful 4.13 is known 
good).  So trusty+4.15 is the only viable combination for continued support of 
the cloud while adding new hardware.  This is done via apt pinning of bionic 
for the kernel packages, and, mountall notwithstanding, is working fine so far.

  
  Original description:

  Running bionic's 4.15 kernel on trusty on an HPE DL385 Gen10 results
  in a device node for the NVMe controller,
  /devices/pci:40/:40:03.1/:43:00.0/nvme/nvme0/nvme0c33n1
  which itself does not have a devname.  When mountall gets to it:

  fsck_update: updating check priorities
  try_mount: /srv/nova/instances waiting for device
  try_udev_device: ignored /dev/loop5 (not yet ready?)
  try_udev_device: ignored /dev/loop6 (not yet ready?)
  try_udev_device: ignored /dev/loop1 (not yet ready?)
  try_udev_device: ignored /dev/loop0 (not yet ready?)
  try_udev_device: block (null) (null) (null)

  and then crashes, leaving the boot at an emergency root shell.  A
  successful scan looks like this for comparison:

  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sdb (null) (null)
  try_udev_device: block /dev/sda (null) (null)
  try_udev_device: block /dev/nvme0n1 ed56e3a9-60f7-4636-85a2-b53137b598e7 
(null)
  try_udev_device: block /dev/bcache0 756cb2c6-b999-4905-a021-c2e688e81a86 
instances

  The debdiffs check for a null devname in try_udev_device() and will
  not attempt to process it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1807077/+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 1806848] Re: not sure

2018-12-06 Thread Juhani Numminen

Thank you for taking the time to report this bug and helping to make
Ubuntu better. Unfortunately, we cannot work on this bug because your
description didn't include enough information. You may find it helpful
to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem.

We have instructions on debugging some types of problems at
http://wiki.ubuntu.com/DebuggingProcedures.

At a minimum, we need:
1. The specific steps or actions you took that caused you to encounter the 
problem.
2. The behavior you expected.
3. The behavior you actually encountered (in as much detail as possible).
Thanks! 

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

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

Title:
  not sure

Status in debconf package in Ubuntu:
  Incomplete

Bug description:
  it gave me a error but did not give detailed info

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1806848/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

imagetopdf filter wrapper I've used for the reproducer:
#!/usr/bin/env python

import sys
import time
import subprocess

def main():
time.sleep(5)
args = ["/usr/lib/cups/filter/imagetopdf.bkp"] + sys.argv[1:]
subprocess.call(args, stdin=sys.stdin, stdout=sys.stdout, stderr=sys.stderr)

if __name__ == "__main__":
main()

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  Confirmed
Status in cups source package in Xenial:
  New
Status in cups source package in Bionic:
  New
Status in cups source package in Cosmic:
  New

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no 
   difference in behavior except for the special value of MaxJobTime=0.
   

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1799111] Re: lots of Classes missing from docs (e.g. QFileInfo)

2018-12-06 Thread Dmitry Shachnev

The packages are waiting in the review queue since November 27th:
https://launchpad.net/ubuntu/cosmic/+queue?queue_state=1. Now it’s up to
SRU team to review them.

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

Title:
  lots of Classes missing from docs (e.g. QFileInfo)

Status in qtbase-opensource-src package in Ubuntu:
  Fix Released
Status in qtdeclarative-opensource-src package in Ubuntu:
  Fix Released
Status in qttools-opensource-src package in Ubuntu:
  Fix Released
Status in qtbase-opensource-src source package in Cosmic:
  Confirmed
Status in qtdeclarative-opensource-src source package in Cosmic:
  Confirmed
Status in qttools-opensource-src source package in Cosmic:
  Confirmed
Status in qtbase-opensource-src package in Debian:
  Fix Released

Bug description:
  [Impact]
  The packaged Qt documentation, which can be viewed in browser (qt*-doc-html 
packages) or in Qt Assistant (qt*-doc packages) is missing all documentation 
generated from C++ files. Only the static text is present.

  Qt is split by many modules (qtbase, qtdeclarative, qtwebengine,
  etc.).

  To properly fix this bug, we need changes in qtbase and qttools
  modules. In addition, I will be uploading a no-change rebuild of
  qtdeclarative module to demonstrate that the fixes work.

  If requested, I can also upload no-change rebuilds of some other
  modules to get their -doc packages properly regenerated.

  [Test Case]
  For qtbase5-doc-html:
  1. Install qtbase5-doc-html package.
  2. Make sure /usr/share/qt5/doc/qtcore/qobject.html is present.

  For qtdeclarative5-doc-html:
  1. Install qtdeclarative5-doc-html package.
  2. Make sure /usr/share/qt5/doc/qtquick/qquickwidget.html is present.

  [Regression Potential]
  The proposed change in qtbase is affecting only builds of Qt modules 
documentation. So the worst thing it can do is breaking the build of -doc 
packages in other Qt modules. However, as confirmed by qtdeclarative example, 
it makes things only better, not worse.

  The proposed change in qttools can affect more packages. It can result
  in qdoc passing more -isystem flags to clang code analyzer. I am not
  aware of negative consequences of this, but if they happen, these
  consequences will be limited to potential build failures or wrong
  documentation contents.

  [Other Info]
  Description of the fix:

  qdoc is a tool that parses C++ source files and generates
  documentation from them. Recently, qdoc began using clang instead of
  its own C++ parser. Clang needs the C++ standard library to work.
  Starting with llvm-toolchain 1:7~+rc1-1~exp2, the GCC C++ standard
  library is no longer on clang’s default search paths, so we need to
  pass it explicitly as -I flag. The proposed qtbase patch
  (qdoc_default_incdirs.diff) does that.

  That patch fixes documentation build for qtbase, but for other modules
  there is another problem. The Qt headers are installed into
  /usr/include//qt5 directory, but it is also not on Clang
  default search path. qmake passes these directories as -isystem flags,
  but qdoc ignores -isystem by default, unless it is built with
  QDOC_PASS_ISYSTEM defined. So the proposed change in qttools is
  building with this define.

  [Original Description]
  The Qt offline documentation for cosmic is incomplete. In fact there's 
virtually no content what so ever. It would be easier I think to list what 
actually got picked up that what was missed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1799111/+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 1768230] Re: Long time booting : Failed to connect to lvmetad. Falling back to device scanning.

2018-12-06 Thread fen rice

System: Ubuntu 18.04 4.15.0-42-generic #45-Ubuntu SMP

I also was able to fix it with the "=none" and then running update-
initramfs -u

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

Title:
  Long time booting : Failed to connect to lvmetad. Falling back to
  device scanning.

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in ubiquity package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  Confirmed

Bug description:
  [SRU Justification]
  A regression in initramfs-tools causes it to autogenerate config in the 
initramfs saying to resume from any available swap devices, but references the 
swap device by UUID, which is not a canonical form for referring to LVM volumes 
(because of snapshotting, they are not unique).  Ubiquity also generates a file 
in /etc at install time which references the swap partition in the same way.  
Since the lvm2 initramfs hooks also only activate precisely those LVs that are 
detected as needed at boot, this adds an inappropriate 30-second boot delay to 
any system with swap on LVM, which includes any desktop system that was 
configured with LVM (but not full-disk encryption) at install time.

  [Test case]
  1. Install using the "Use LVM" option in the desktop installer.
  4. Reboot.
  5. Verify that dmesg shows a 30-second delay before mounting the root 
filesystem.
  6. Install initramfs-tools from bionic-proposed.
  7. Reboot.
  8. Verify that dmesg no longer shows a 30-second delay before mounting the 
root filesystem.
  9. Install using the bionic daily image that contains the ubiquity from 
bionic-proposed.
  10. Reboot.
  11. Verify that /etc/initramfs-tools/conf.d/resume is not present and that 
there is no delay before mounting the root filesystem.

  [Regression potential]
  This makes changes to shell scripts, and shell is a perilous language. An 
unnoticed bug could cause all initramfs generation, and thus all kernel 
installation, to fail for some users. A regression could also cause a user to 
lose hiberation support that they currently have.

  [Original description]
  After choosing "Erase disk and install ubuntu" + "Use LVM with the new Ubuntu 
installation", the
  system is very slow to reboot.

  It shows the message : "WARNING:Failed to connect to lvmetad. Falling back to 
device scanning.",
  then waits 32 seconds, then continues as it should.

  I think this is a ubiquity bug, since the d-i based installer is not affected.
   - ubuntu-18.04-desktop-amd64.iso 
(a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34) : affected
   - xubuntu-18.04-desktop-amd64.iso 
(7c24318d3b1de1efd584b5aea034ce1aafd2d0f06c59812d989a5fc95bf947e3) : affected
   - ubuntu-18.04-server-amd64.iso 
(a7f5c7b0cdd0e9560d78f1e47660e066353bb8a79eb78d1fc3f4ea62a07e6cbc) : not 
affected

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1768230/+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 1806860] PulseList.txt

apport information

** Attachment added: "PulseList.txt"
   
https://bugs.launchpad.net/bugs/1806860/+attachment/5219679/+files/PulseList.txt

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

Title:
  Pulseaudio module-jack-source unable to connect to jackd2

Status in jackd2 package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  When installing jackd2 in ubuntu 18.04, i am unable to load the
  module-jack-source.

  Syslog gives me:

  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >attempt to connect to 
server failed<
  Dec  5 11:49:45 nvidion pulseaudio[7905]: jack_client_open() failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: Failed to load module 
"module-jack-source" (argument: ""): initialization failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >connect(2) call to 
/dev/shm/jack-1000/default/jack_0 failed (err=Datei oder Verzeichnis nicht 
gefunden)<
  Dec  5 11:49:50 nvidion pulseaudio[7905]: message repeated 5 times: [ JACK 
error >connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=Datei 
oder Verzeichnis nicht gefunden)<]
  Dec  5 11:49:51 nvidio

  So the path to the shared memory location is not as expected.

  When jackd2 is running i have:

  hcw@nvidion:$ cd /dev/shm/
  hcw@nvidion:/dev/shm$ ls
  jack-1000-0  jack_sem.1000_default_1000_0_system  
jack_sem.1000_default_jack_rack  jack_sem.1000_jack_default_1000_0_system
  jack-1000-1  jack_sem.1000_default_freewheel  
jack_sem.1000_default_qjackctl   jack-shm-registry
  jack_default_1000_0  jack_sem.1000_default_jack_mixer 
jack_sem.1000_default_system

  
  So it seems module-jack-source / sink are guessing the wrong shared memory 
paths to the jackd2 server..

  Versions:
  jackd2 1.9.12~dfsg-2 
  pulseaudio-module-jack 1:11.1-1ubuntu7.1
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: GNOME
  DistroRelease: Ubuntu 18.04
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: pulseaudio 1:11.1-1ubuntu7.1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-39.42-lowlatency 4.15.18
  Tags:  bionic
  Uname: Linux 4.15.0-39-lowlatency x86_64
  UpgradeStatus: Upgraded to bionic on 2018-08-16 (111 days ago)
  UserGroups: adm audio dialout disk docker kvm libvirt mythtv tracing video 
wireshark
  _MarkForUpload: True
  dmi.bios.date: 12/05/2017
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.2.1
  dmi.board.name: 042NDD
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.2.1:bd12/05/2017:svnDellInc.:pnInspiron7566:pvr:rvnDellInc.:rn042NDD:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: Inspiron
  dmi.product.name: Inspiron 7566
  dmi.sys.vendor: Dell Inc.
  modified.conffile..etc.pulse.daemon.conf: [modified]
  modified.conffile..etc.pulse.default.pa: [modified]
  mtime.conffile..etc.pulse.daemon.conf: 2018-12-04T10:32:39.961952
  mtime.conffile..etc.pulse.default.pa: 2018-12-03T11:18:37.948772

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/1806860/+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 1806860] ProcEnviron.txt

apport information

** Attachment added: "ProcEnviron.txt"
   
https://bugs.launchpad.net/bugs/1806860/+attachment/5219678/+files/ProcEnviron.txt

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

Title:
  Pulseaudio module-jack-source unable to connect to jackd2

Status in jackd2 package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  When installing jackd2 in ubuntu 18.04, i am unable to load the
  module-jack-source.

  Syslog gives me:

  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >attempt to connect to 
server failed<
  Dec  5 11:49:45 nvidion pulseaudio[7905]: jack_client_open() failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: Failed to load module 
"module-jack-source" (argument: ""): initialization failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >connect(2) call to 
/dev/shm/jack-1000/default/jack_0 failed (err=Datei oder Verzeichnis nicht 
gefunden)<
  Dec  5 11:49:50 nvidion pulseaudio[7905]: message repeated 5 times: [ JACK 
error >connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=Datei 
oder Verzeichnis nicht gefunden)<]
  Dec  5 11:49:51 nvidio

  So the path to the shared memory location is not as expected.

  When jackd2 is running i have:

  hcw@nvidion:$ cd /dev/shm/
  hcw@nvidion:/dev/shm$ ls
  jack-1000-0  jack_sem.1000_default_1000_0_system  
jack_sem.1000_default_jack_rack  jack_sem.1000_jack_default_1000_0_system
  jack-1000-1  jack_sem.1000_default_freewheel  
jack_sem.1000_default_qjackctl   jack-shm-registry
  jack_default_1000_0  jack_sem.1000_default_jack_mixer 
jack_sem.1000_default_system

  
  So it seems module-jack-source / sink are guessing the wrong shared memory 
paths to the jackd2 server..

  Versions:
  jackd2 1.9.12~dfsg-2 
  pulseaudio-module-jack 1:11.1-1ubuntu7.1
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: GNOME
  DistroRelease: Ubuntu 18.04
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: pulseaudio 1:11.1-1ubuntu7.1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-39.42-lowlatency 4.15.18
  Tags:  bionic
  Uname: Linux 4.15.0-39-lowlatency x86_64
  UpgradeStatus: Upgraded to bionic on 2018-08-16 (111 days ago)
  UserGroups: adm audio dialout disk docker kvm libvirt mythtv tracing video 
wireshark
  _MarkForUpload: True
  dmi.bios.date: 12/05/2017
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.2.1
  dmi.board.name: 042NDD
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.2.1:bd12/05/2017:svnDellInc.:pnInspiron7566:pvr:rvnDellInc.:rn042NDD:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: Inspiron
  dmi.product.name: Inspiron 7566
  dmi.sys.vendor: Dell Inc.
  modified.conffile..etc.pulse.daemon.conf: [modified]
  modified.conffile..etc.pulse.default.pa: [modified]
  mtime.conffile..etc.pulse.daemon.conf: 2018-12-04T10:32:39.961952
  mtime.conffile..etc.pulse.default.pa: 2018-12-03T11:18:37.948772

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/1806860/+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 1806860] ProcCpuinfoMinimal.txt

apport information

** Attachment added: "ProcCpuinfoMinimal.txt"
   
https://bugs.launchpad.net/bugs/1806860/+attachment/5219677/+files/ProcCpuinfoMinimal.txt

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

Title:
  Pulseaudio module-jack-source unable to connect to jackd2

Status in jackd2 package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  When installing jackd2 in ubuntu 18.04, i am unable to load the
  module-jack-source.

  Syslog gives me:

  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >attempt to connect to 
server failed<
  Dec  5 11:49:45 nvidion pulseaudio[7905]: jack_client_open() failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: Failed to load module 
"module-jack-source" (argument: ""): initialization failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >connect(2) call to 
/dev/shm/jack-1000/default/jack_0 failed (err=Datei oder Verzeichnis nicht 
gefunden)<
  Dec  5 11:49:50 nvidion pulseaudio[7905]: message repeated 5 times: [ JACK 
error >connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=Datei 
oder Verzeichnis nicht gefunden)<]
  Dec  5 11:49:51 nvidio

  So the path to the shared memory location is not as expected.

  When jackd2 is running i have:

  hcw@nvidion:$ cd /dev/shm/
  hcw@nvidion:/dev/shm$ ls
  jack-1000-0  jack_sem.1000_default_1000_0_system  
jack_sem.1000_default_jack_rack  jack_sem.1000_jack_default_1000_0_system
  jack-1000-1  jack_sem.1000_default_freewheel  
jack_sem.1000_default_qjackctl   jack-shm-registry
  jack_default_1000_0  jack_sem.1000_default_jack_mixer 
jack_sem.1000_default_system

  
  So it seems module-jack-source / sink are guessing the wrong shared memory 
paths to the jackd2 server..

  Versions:
  jackd2 1.9.12~dfsg-2 
  pulseaudio-module-jack 1:11.1-1ubuntu7.1
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: GNOME
  DistroRelease: Ubuntu 18.04
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: pulseaudio 1:11.1-1ubuntu7.1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-39.42-lowlatency 4.15.18
  Tags:  bionic
  Uname: Linux 4.15.0-39-lowlatency x86_64
  UpgradeStatus: Upgraded to bionic on 2018-08-16 (111 days ago)
  UserGroups: adm audio dialout disk docker kvm libvirt mythtv tracing video 
wireshark
  _MarkForUpload: True
  dmi.bios.date: 12/05/2017
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.2.1
  dmi.board.name: 042NDD
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.2.1:bd12/05/2017:svnDellInc.:pnInspiron7566:pvr:rvnDellInc.:rn042NDD:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: Inspiron
  dmi.product.name: Inspiron 7566
  dmi.sys.vendor: Dell Inc.
  modified.conffile..etc.pulse.daemon.conf: [modified]
  modified.conffile..etc.pulse.default.pa: [modified]
  mtime.conffile..etc.pulse.daemon.conf: 2018-12-04T10:32:39.961952
  mtime.conffile..etc.pulse.default.pa: 2018-12-03T11:18:37.948772

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/1806860/+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 1806860] Dependencies.txt

apport information

** Attachment added: "Dependencies.txt"
   
https://bugs.launchpad.net/bugs/1806860/+attachment/5219676/+files/Dependencies.txt

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

Title:
  Pulseaudio module-jack-source unable to connect to jackd2

Status in jackd2 package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  When installing jackd2 in ubuntu 18.04, i am unable to load the
  module-jack-source.

  Syslog gives me:

  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >attempt to connect to 
server failed<
  Dec  5 11:49:45 nvidion pulseaudio[7905]: jack_client_open() failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: Failed to load module 
"module-jack-source" (argument: ""): initialization failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >connect(2) call to 
/dev/shm/jack-1000/default/jack_0 failed (err=Datei oder Verzeichnis nicht 
gefunden)<
  Dec  5 11:49:50 nvidion pulseaudio[7905]: message repeated 5 times: [ JACK 
error >connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=Datei 
oder Verzeichnis nicht gefunden)<]
  Dec  5 11:49:51 nvidio

  So the path to the shared memory location is not as expected.

  When jackd2 is running i have:

  hcw@nvidion:$ cd /dev/shm/
  hcw@nvidion:/dev/shm$ ls
  jack-1000-0  jack_sem.1000_default_1000_0_system  
jack_sem.1000_default_jack_rack  jack_sem.1000_jack_default_1000_0_system
  jack-1000-1  jack_sem.1000_default_freewheel  
jack_sem.1000_default_qjackctl   jack-shm-registry
  jack_default_1000_0  jack_sem.1000_default_jack_mixer 
jack_sem.1000_default_system

  
  So it seems module-jack-source / sink are guessing the wrong shared memory 
paths to the jackd2 server..

  Versions:
  jackd2 1.9.12~dfsg-2 
  pulseaudio-module-jack 1:11.1-1ubuntu7.1
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: GNOME
  DistroRelease: Ubuntu 18.04
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: pulseaudio 1:11.1-1ubuntu7.1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-39.42-lowlatency 4.15.18
  Tags:  bionic
  Uname: Linux 4.15.0-39-lowlatency x86_64
  UpgradeStatus: Upgraded to bionic on 2018-08-16 (111 days ago)
  UserGroups: adm audio dialout disk docker kvm libvirt mythtv tracing video 
wireshark
  _MarkForUpload: True
  dmi.bios.date: 12/05/2017
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.2.1
  dmi.board.name: 042NDD
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.2.1:bd12/05/2017:svnDellInc.:pnInspiron7566:pvr:rvnDellInc.:rn042NDD:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: Inspiron
  dmi.product.name: Inspiron 7566
  dmi.sys.vendor: Dell Inc.
  modified.conffile..etc.pulse.daemon.conf: [modified]
  modified.conffile..etc.pulse.default.pa: [modified]
  mtime.conffile..etc.pulse.daemon.conf: 2018-12-04T10:32:39.961952
  mtime.conffile..etc.pulse.default.pa: 2018-12-03T11:18:37.948772

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/1806860/+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 1806860] AudioDevicesInUse.txt

apport information

** Attachment added: "AudioDevicesInUse.txt"
   
https://bugs.launchpad.net/bugs/1806860/+attachment/5219674/+files/AudioDevicesInUse.txt

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

Title:
  Pulseaudio module-jack-source unable to connect to jackd2

Status in jackd2 package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  When installing jackd2 in ubuntu 18.04, i am unable to load the
  module-jack-source.

  Syslog gives me:

  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >attempt to connect to 
server failed<
  Dec  5 11:49:45 nvidion pulseaudio[7905]: jack_client_open() failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: Failed to load module 
"module-jack-source" (argument: ""): initialization failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >connect(2) call to 
/dev/shm/jack-1000/default/jack_0 failed (err=Datei oder Verzeichnis nicht 
gefunden)<
  Dec  5 11:49:50 nvidion pulseaudio[7905]: message repeated 5 times: [ JACK 
error >connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=Datei 
oder Verzeichnis nicht gefunden)<]
  Dec  5 11:49:51 nvidio

  So the path to the shared memory location is not as expected.

  When jackd2 is running i have:

  hcw@nvidion:$ cd /dev/shm/
  hcw@nvidion:/dev/shm$ ls
  jack-1000-0  jack_sem.1000_default_1000_0_system  
jack_sem.1000_default_jack_rack  jack_sem.1000_jack_default_1000_0_system
  jack-1000-1  jack_sem.1000_default_freewheel  
jack_sem.1000_default_qjackctl   jack-shm-registry
  jack_default_1000_0  jack_sem.1000_default_jack_mixer 
jack_sem.1000_default_system

  
  So it seems module-jack-source / sink are guessing the wrong shared memory 
paths to the jackd2 server..

  Versions:
  jackd2 1.9.12~dfsg-2 
  pulseaudio-module-jack 1:11.1-1ubuntu7.1
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: GNOME
  DistroRelease: Ubuntu 18.04
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: pulseaudio 1:11.1-1ubuntu7.1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-39.42-lowlatency 4.15.18
  Tags:  bionic
  Uname: Linux 4.15.0-39-lowlatency x86_64
  UpgradeStatus: Upgraded to bionic on 2018-08-16 (111 days ago)
  UserGroups: adm audio dialout disk docker kvm libvirt mythtv tracing video 
wireshark
  _MarkForUpload: True
  dmi.bios.date: 12/05/2017
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.2.1
  dmi.board.name: 042NDD
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.2.1:bd12/05/2017:svnDellInc.:pnInspiron7566:pvr:rvnDellInc.:rn042NDD:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: Inspiron
  dmi.product.name: Inspiron 7566
  dmi.sys.vendor: Dell Inc.
  modified.conffile..etc.pulse.daemon.conf: [modified]
  modified.conffile..etc.pulse.default.pa: [modified]
  mtime.conffile..etc.pulse.daemon.conf: 2018-12-04T10:32:39.961952
  mtime.conffile..etc.pulse.default.pa: 2018-12-03T11:18:37.948772

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/1806860/+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 1806860] Re: Pulseaudio module-jack-source unable to connect to jackd2

apport information

** Tags added: apport-collected

** Description changed:

  When installing jackd2 in ubuntu 18.04, i am unable to load the module-
  jack-source.
  
  Syslog gives me:
  
  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >attempt to connect to 
server failed<
  Dec  5 11:49:45 nvidion pulseaudio[7905]: jack_client_open() failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: Failed to load module 
"module-jack-source" (argument: ""): initialization failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >connect(2) call to 
/dev/shm/jack-1000/default/jack_0 failed (err=Datei oder Verzeichnis nicht 
gefunden)<
  Dec  5 11:49:50 nvidion pulseaudio[7905]: message repeated 5 times: [ JACK 
error >connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=Datei 
oder Verzeichnis nicht gefunden)<]
  Dec  5 11:49:51 nvidio
  
  So the path to the shared memory location is not as expected.
  
  When jackd2 is running i have:
  
  hcw@nvidion:$ cd /dev/shm/
  hcw@nvidion:/dev/shm$ ls
  jack-1000-0  jack_sem.1000_default_1000_0_system  
jack_sem.1000_default_jack_rack  jack_sem.1000_jack_default_1000_0_system
  jack-1000-1  jack_sem.1000_default_freewheel  
jack_sem.1000_default_qjackctl   jack-shm-registry
  jack_default_1000_0  jack_sem.1000_default_jack_mixer 
jack_sem.1000_default_system
  
  
  So it seems module-jack-source / sink are guessing the wrong shared memory 
paths to the jackd2 server..
  
  Versions:
  jackd2 1.9.12~dfsg-2 
  pulseaudio-module-jack 1:11.1-1ubuntu7.1
+ --- 
+ ProblemType: Bug
+ ApportVersion: 2.20.9-0ubuntu7.5
+ Architecture: amd64
+ CurrentDesktop: GNOME
+ DistroRelease: Ubuntu 18.04
+ NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
+ Package: pulseaudio 1:11.1-1ubuntu7.1
+ PackageArchitecture: amd64
+ ProcVersionSignature: Ubuntu 4.15.0-39.42-lowlatency 4.15.18
+ Tags:  bionic
+ Uname: Linux 4.15.0-39-lowlatency x86_64
+ UpgradeStatus: Upgraded to bionic on 2018-08-16 (111 days ago)
+ UserGroups: adm audio dialout disk docker kvm libvirt mythtv tracing video 
wireshark
+ _MarkForUpload: True
+ dmi.bios.date: 12/05/2017
+ dmi.bios.vendor: Dell Inc.
+ dmi.bios.version: 1.2.1
+ dmi.board.name: 042NDD
+ dmi.board.vendor: Dell Inc.
+ dmi.board.version: A00
+ dmi.chassis.type: 9
+ dmi.chassis.vendor: Dell Inc.
+ dmi.modalias: 
dmi:bvnDellInc.:bvr1.2.1:bd12/05/2017:svnDellInc.:pnInspiron7566:pvr:rvnDellInc.:rn042NDD:rvrA00:cvnDellInc.:ct9:cvr:
+ dmi.product.family: Inspiron
+ dmi.product.name: Inspiron 7566
+ dmi.sys.vendor: Dell Inc.
+ modified.conffile..etc.pulse.daemon.conf: [modified]
+ modified.conffile..etc.pulse.default.pa: [modified]
+ mtime.conffile..etc.pulse.daemon.conf: 2018-12-04T10:32:39.961952
+ mtime.conffile..etc.pulse.default.pa: 2018-12-03T11:18:37.948772

** Attachment added: "AlsaInfo.txt"
   
https://bugs.launchpad.net/bugs/1806860/+attachment/5219673/+files/AlsaInfo.txt

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

Title:
  Pulseaudio module-jack-source unable to connect to jackd2

Status in jackd2 package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  When installing jackd2 in ubuntu 18.04, i am unable to load the
  module-jack-source.

  Syslog gives me:

  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >attempt to connect to 
server failed<
  Dec  5 11:49:45 nvidion pulseaudio[7905]: jack_client_open() failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: Failed to load module 
"module-jack-source" (argument: ""): initialization failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >connect(2) call to 
/dev/shm/jack-1000/default/jack_0 failed (err=Datei oder Verzeichnis nicht 
gefunden)<
  Dec  5 11:49:50 nvidion pulseaudio[7905]: message repeated 5 times: [ JACK 
error >connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=Datei 
oder Verzeichnis nicht gefunden)<]
  Dec  5 11:49:51 nvidio

  So the path to the shared memory location is not as expected.

  When jackd2 is running i have:

  hcw@nvidion:$ cd /dev/shm/
  hcw@nvidion:/dev/shm$ ls
  jack-1000-0  jack_sem.1000_default_1000_0_system  
jack_sem.1000_default_jack_rack  jack_sem.1000_jack_default_1000_0_system
  jack-1000-1  jack_sem.1000_default_freewheel  
jack_sem.1000_default_qjackctl   jack-shm-registry
  jack_default_1000_0  jack_sem.1000_default_jack_mixer 
jack_sem.1000_default_system

  
  So it seems module-jack-source / sink are guessing the wrong shared memory 
paths to the jackd2 server..

  Versions:
  jackd2 1.9.12~dfsg-2 
  pulseaudio-module-jack 1:11.1-1ubuntu7.1
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: GNOME
  DistroRelease: Ubuntu 18.04
  NonfreeKernelModules: zfs

[Touch-packages] [Bug 1806860] CurrentDmesg.txt

apport information

** Attachment added: "CurrentDmesg.txt"
   
https://bugs.launchpad.net/bugs/1806860/+attachment/5219675/+files/CurrentDmesg.txt

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

Title:
  Pulseaudio module-jack-source unable to connect to jackd2

Status in jackd2 package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Incomplete

Bug description:
  When installing jackd2 in ubuntu 18.04, i am unable to load the
  module-jack-source.

  Syslog gives me:

  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >attempt to connect to 
server failed<
  Dec  5 11:49:45 nvidion pulseaudio[7905]: jack_client_open() failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: Failed to load module 
"module-jack-source" (argument: ""): initialization failed.
  Dec  5 11:49:45 nvidion pulseaudio[7905]: JACK error >connect(2) call to 
/dev/shm/jack-1000/default/jack_0 failed (err=Datei oder Verzeichnis nicht 
gefunden)<
  Dec  5 11:49:50 nvidion pulseaudio[7905]: message repeated 5 times: [ JACK 
error >connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=Datei 
oder Verzeichnis nicht gefunden)<]
  Dec  5 11:49:51 nvidio

  So the path to the shared memory location is not as expected.

  When jackd2 is running i have:

  hcw@nvidion:$ cd /dev/shm/
  hcw@nvidion:/dev/shm$ ls
  jack-1000-0  jack_sem.1000_default_1000_0_system  
jack_sem.1000_default_jack_rack  jack_sem.1000_jack_default_1000_0_system
  jack-1000-1  jack_sem.1000_default_freewheel  
jack_sem.1000_default_qjackctl   jack-shm-registry
  jack_default_1000_0  jack_sem.1000_default_jack_mixer 
jack_sem.1000_default_system

  
  So it seems module-jack-source / sink are guessing the wrong shared memory 
paths to the jackd2 server..

  Versions:
  jackd2 1.9.12~dfsg-2 
  pulseaudio-module-jack 1:11.1-1ubuntu7.1
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CurrentDesktop: GNOME
  DistroRelease: Ubuntu 18.04
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: pulseaudio 1:11.1-1ubuntu7.1
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-39.42-lowlatency 4.15.18
  Tags:  bionic
  Uname: Linux 4.15.0-39-lowlatency x86_64
  UpgradeStatus: Upgraded to bionic on 2018-08-16 (111 days ago)
  UserGroups: adm audio dialout disk docker kvm libvirt mythtv tracing video 
wireshark
  _MarkForUpload: True
  dmi.bios.date: 12/05/2017
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.2.1
  dmi.board.name: 042NDD
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.2.1:bd12/05/2017:svnDellInc.:pnInspiron7566:pvr:rvnDellInc.:rn042NDD:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: Inspiron
  dmi.product.name: Inspiron 7566
  dmi.sys.vendor: Dell Inc.
  modified.conffile..etc.pulse.daemon.conf: [modified]
  modified.conffile..etc.pulse.default.pa: [modified]
  mtime.conffile..etc.pulse.daemon.conf: 2018-12-04T10:32:39.961952
  mtime.conffile..etc.pulse.default.pa: 2018-12-03T11:18:37.948772

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/1806860/+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 1806382] Re: merge 1:4.2.8p12+dfsg-3

This bug was fixed in the package ntp - 1:4.2.8p12+dfsg-3ubuntu1

---
ntp (1:4.2.8p12+dfsg-3ubuntu1) disco; urgency=medium

  * Merge with Debian unstable (LP: #1806382). Remaining changes:
- d/ntp.conf, d/ntpdate.default: Change default server to ntp.ubuntu.com.
- add support for parsing systemd networkd lease files LP: 1717983
  + d/ntp.dhcp add support for parsing systemd networkd lease files
  + d/ntp-systemd-netif.service: service to call hook
  + d/ntp-systemd-netif.path: respond to lease changes
  * Dropped Changes (accepted in Debian)
- Add PPS support (this is accepted in Debian and only had some readme
  and example entries left):

ntp (1:4.2.8p12+dfsg-3) unstable; urgency=low

  * Treat testsuite errors as non-fatal on some architectures
Fixes FTBFS on ppc64el, ia64, powerpc, ppc64

ntp (1:4.2.8p12+dfsg-2) unstable; urgency=low

  * Drop ntpdate ifupdown hooks (Closes: #908286)
These have been a constant source of problems and one-shot syncs
are not a proper solution for timekeeping. See ntpdate.NEWS for
details
  * Do not install /var/lib/ntpdate, not used anymore
  * Drop maintscript snippets for upgrading from versions prior to Jessie
  * Reenable unittest
- disable always failing test-decodenetnum with a patch
  * Set Rules-Requires-Root: no

ntp (1:4.2.8p12+dfsg-1) unstable; urgency=medium

  [ Bernhard Schmidt ]
  * New upstream version 4.2.8p12
  * Update Maintainer address to n...@packages.debian.org (Closes: #899940)
  * Update ntpdate.8 from ntpdate.html (Closes: #476491, #515246)

  [ Peter Eisentraut ]
  * Remove Peter Eisentraut from Uploaders

 -- Christian Ehrhardt   Mon, 03 Dec
2018 13:05:00 +0100

** Changed in: ntp (Ubuntu)
   Status: In Progress => Fix Released

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

Title:
  merge 1:4.2.8p12+dfsg-3

Status in ntp package in Ubuntu:
  Fix Released

Bug description:
  This merge is a a bit more special than usual.

  NTP is no more in Main since 18.04 and also gladly the issues with it
  dropped to almost none (by not being used). Chrony (its replacement)
  OTOH has way less issues and also is easier to support upstream.

  We have upstreamed or debianized most of our changes, but on this
  merge want to -intentionally- drop some delta that is not.

  We have three main delta elements left:
  a) set ubuntu time servers
  b) some tweaks on pps documentaiton
  c) dhclient integration to read systemd-leasefile

  
  Of these:
  a) we want to keep just this as only there we can guarantee the servers are 
working
  b) we want to drop as it just isn't important to adapt that on merges (people 
should use chrony/gpsd for that anyway)
  c) we want to avoid the maintenance of this on a non main package. Therefore 
keep this as-is as long as it merges easily, but in case of any trouble drop it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1806382/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

2018-12-06 Thread Till Kamppeter

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

** Also affects: cups (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: cups (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

Title:
  MaxJobTime=0 results in jobs being cancelled immediately instead of
  never

Status in CUPS:
  New
Status in cups package in Ubuntu:
  Confirmed
Status in cups source package in Xenial:
  New
Status in cups source package in Bionic:
  New
Status in cups source package in Cosmic:
  New

Bug description:
  [Impact]

   Setting the cupsd option MaxJobTime to 0 should make the server wait 
indefinitely for the job to be ready for print. Instead, after updating 
job-cancel-after option with MaxJobTime=0 value it results in immediate 
cancelling.
  This leads to problems with using filters that take some time to process - 
the user needs to set MaxJobTime to a ridiculously high value to ensure the job 
is not going to get cancelled instead of just disabling the cancelling timeout.

  [Test Case]

   1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
   2. Setup a filter that takes at least several seconds to process.
  (please find a sample imagetopdf wrapper introducing 5s delay)
   3. Submit a print job matching the filter, e.g.
  lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

  Expected result:
  The job is printed after the 5s delay.

  Actual result:
  The job is cancelled.

  [Regression Potential]

   The scope of the change is limited to fixing the MaxJobTime handling
   in scheduler/job.c and scheduler/printers.c. There should be no 
   difference in behavior except for the special value of MaxJobTime=0.
   

  [Other Info]
  Original bug description:

  When using CUPS filters, these filters can take a few seconds to
  complete.

  In this case no documents are allowed to be lost on printing failures,
  so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
  14.04.

  With cups on 18.04, you get the following message in /var/log/cups/error_log 
whenever the filter takes a little longer:
  I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

  Then, the job is deleted and lost.

  "MaxJobTime 0" is documented as "indefinite wait", but apparently cups
  treats is as "wait almost not at all".

  This issue appears to have also been filed upstream:
  https://github.com/apple/cups/issues/5438

  Temporary workaround is to set the MaxJobTime to a very large value
  instead (e.g. 3 years)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

SRU proposal for bionic.

** Patch added: "bionic_cups_2.2.7-1ubuntu2.2.debdiff"

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219666/+files/bionic_cups_2.2.7-1ubuntu2.2.debdiff

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

Title:
MaxJobTime=0 results in jobs being cancelled immediately instead of
never

Status in CUPS:
New
Status in cups package in Ubuntu:
Confirmed

Bug description:
[Impact]

Setting the cupsd option MaxJobTime to 0 should make the server wait
indefinitely for the job to be ready for print. Instead, after updating
job-cancel-after option with MaxJobTime=0 value it results in immediate
cancelling.
This leads to problems with using filters that take some time to process -
the user needs to set MaxJobTime to a ridiculously high value to ensure the job
is not going to get cancelled instead of just disabling the cancelling timeout.

[Test Case]

1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
2. Setup a filter that takes at least several seconds to process.
(please find a sample imagetopdf wrapper introducing 5s delay)
3. Submit a print job matching the filter, e.g.
lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper

Expected result:
The job is printed after the 5s delay.

Actual result:
The job is cancelled.

[Regression Potential]

The scope of the change is limited to fixing the MaxJobTime handling
in scheduler/job.c and scheduler/printers.c. There should be no
difference in behavior except for the special value of MaxJobTime=0.

[Other Info]
Original bug description:

When using CUPS filters, these filters can take a few seconds to
complete.

In this case no documents are allowed to be lost on printing failures,
so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
14.04.

With cups on 18.04, you get the following message in /var/log/cups/error_log
whenever the filter takes a little longer:
I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

Then, the job is deleted and lost.

"MaxJobTime 0" is documented as "indefinite wait", but apparently cups
treats is as "wait almost not at all".

This issue appears to have also been filed upstream:
https://github.com/apple/cups/issues/5438

Temporary workaround is to set the MaxJobTime to a very large value
instead (e.g. 3 years)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

SRU proposal for disco.

** Description changed:

+ [Impact]
+
+ Setting the cupsd option MaxJobTime to 0 should make the server wait
indefinitely for the job to be ready for print. Instead, after updating
job-cancel-after option with MaxJobTime=0 value it results in immediate
cancelling.
+ This leads to problems with using filters that take some time to process -
the user needs to set MaxJobTime to a ridiculously high value to ensure the job
is not going to get cancelled instead of just disabling the cancelling timeout.
+
+ [Test Case]
+
+ 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf.
+ 2. Setup a filter that takes at least several seconds to process.
+ (please find a sample imagetopdf wrapper introducing 5s delay)
+ 3. Submit a print job matching the filter, e.g.
+ lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper
+
+ Expected result:
+ The job is printed after the 5s delay.
+
+ Actual result:
+ The job is cancelled.
+
+ [Regression Potential]
+
+ The scope of the change is limited to fixing the MaxJobTime handling
+ in scheduler/job.c and scheduler/printers.c. There should be no
+ difference in behavior except for the special value of MaxJobTime=0.
+
+
+ [Other Info]
+ Original bug description:
+
When using CUPS filters, these filters can take a few seconds to
complete.

In this case no documents are allowed to be lost on printing failures,
so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
14.04.

With cups on 18.04, you get the following message in /var/log/cups/error_log
whenever the filter takes a little longer:
I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

Then, the job is deleted and lost.

"MaxJobTime 0" is documented as "indefinite wait", but apparently cups
treats is as "wait almost not at all".

This issue appears to have also been filed upstream:
https://github.com/apple/cups/issues/5438

Temporary workaround is to set the MaxJobTime to a very large value
instead (e.g. 3 years)

** Tags added: sts

** Patch added: "disco_cups_2.2.9-3ubuntu1.debdiff"

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219664/+files/disco_cups_2.2.9-3ubuntu1.debdiff

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

Title:
MaxJobTime=0 results in jobs being cancelled immediately instead of
never

Status in CUPS:
New
Status in cups package in Ubuntu:
Confirmed

Bug description:
[Impact]

[Test Case]

Expected result:
The job is printed after the 5s delay.

Actual result:
The job is cancelled.

[Regression Potential]

[Other Info]
Original bug description:

When using CUPS filters, these filters can take a few seconds to
complete.

In this case no documents are allowed to be lost on printing failures,
so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
14.04.

With cups on 18.04, you get the following message in /var/log/cups/error_log
whenever the filter takes a little longer:
I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

Then, the job is deleted and lost.

"MaxJobTime 0" is documented as "indefinite wait", but apparently cups
treats is as "wait almost not at all".

This issue appears to have also been filed upstream:
https://github.com/apple/cups/issues/5438

Temporary workaround is to set the MaxJobTime to a very large value
instead (e.g. 3 years)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never

SRU proposal for xenial.

** Patch added: "xenial_cups_2.1.3-4ubuntu0.6.debdiff"

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219667/+files/xenial_cups_2.1.3-4ubuntu0.6.debdiff

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

Title:
MaxJobTime=0 results in jobs being cancelled immediately instead of
never

Status in CUPS:
New
Status in cups package in Ubuntu:
Confirmed

Bug description:
[Impact]

[Test Case]

Expected result:
The job is printed after the 5s delay.

Actual result:
The job is cancelled.

[Regression Potential]

[Other Info]
Original bug description:

When using CUPS filters, these filters can take a few seconds to
complete.

In this case no documents are allowed to be lost on printing failures,
so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
14.04.

With cups on 18.04, you get the following message in /var/log/cups/error_log
whenever the filter takes a little longer:
I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds.

Then, the job is deleted and lost.

"MaxJobTime 0" is documented as "indefinite wait", but apparently cups
treats is as "wait almost not at all".

This issue appears to have also been filed upstream:
https://github.com/apple/cups/issues/5438

Temporary workaround is to set the MaxJobTime to a very large value
instead (e.g. 3 years)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1804576/+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 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never