[Touch-packages] [Bug 1805978] Re: ubuntu_lxc test is failed with lxc-utils package not installed
This system is using a mix of -proposed and non-proposed packages, this isn't going to work and isn't supported, marking invalid. ** Changed in: lxc (Ubuntu) Status: New => Invalid -- 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: Invalid 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 1733002] Re: Google Online Account Two Factor with hardware key fails immediately
** Changed in: gnome-online-accounts Status: Confirmed => Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-online-accounts in Ubuntu. https://bugs.launchpad.net/bugs/1733002 Title: Google Online Account Two Factor with hardware key fails immediately Status in gnome-online-accounts: Unknown Status in gnome-online-accounts package in Ubuntu: New Bug description: The hardware key authentication two factor fails immediately with a web based retry dialogue when connecting a Google account to the online accounts in settings using a hardware key second factor. Steps to reproduce: 1. Set Google Account to default to a hardware security key like a Yubikey or other FIDO standard key after having two factor authentication enabled on your Google Account. 2. Open Online accounts 3. Add a Google Account 4. Enter google email address 5. Enter google password 6. (this is the login flow of two factor, if default is the hardware key the error should appear). Work around: Choose use another method to authenticate: enter the authentication code and you will proceed. Expectations were: The ability to use the hardware key to authenticate as the second factor. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: gnome-control-center 1:3.26.1-0ubuntu5 ProcVersionSignature: Ubuntu 4.13.0-16.19-lowlatency 4.13.4 Uname: Linux 4.13.0-16-lowlatency x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.7-0ubuntu3.4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Nov 17 16:01:11 2017 EcryptfsInUse: Yes ExecutablePath: /usr/bin/gnome-control-center ProcEnviron: XDG_RUNTIME_DIR= SHELL=/bin/bash PATH=(custom, user) LANG=en_US.UTF-8 SourcePackage: gnome-control-center UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-online-accounts/+bug/1733002/+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 1795921] Re: Out-of-Bounds write in systemd-networkd dhcpv6 option handling
** 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, &addr->iaaddr, sizeof(addr->iaaddr)); *buf += sizeof(addr->iaaddr); *buflen -= sizeof(addr->iaaddr); ia_addrlen += sizeof(DHCP6Option) + sizeof(addr->iaaddr); } r = option_append_hdr(&ia_hdr, &ia_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(&opt, &optlen, 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(&opt, &optlen, &client->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 corr
[Touch-packages] [Bug 1807262] Re: stein unit tests fail with sqlalchemy.exc.NoSuchTableError: migration_tmp
** 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 dmi.c
[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 n
[Touch-packages] [Bug 1807288] Re: mkfs.ext4 -d $directory_with_acls leads to EINVAL
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
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
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
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
** 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
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
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
** 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
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
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
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: ''
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
@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
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
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.
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
** 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
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
** 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
** 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
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
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. stat(
[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- htt
[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- h
[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 -O-
[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 ~ # w
[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) stat("/usr
[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: (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
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
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&p=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&p=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
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
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
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
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 ...
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
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
** 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
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 4.15.0-42.45-generic
[Touch-packages] [Bug 1807138] Re: [HDA-Intel - HDA Intel PCH, playback] Headphones not automatically detected
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 the
[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
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
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
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
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
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)
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.
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 zun
[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
** 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] 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 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] 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 Cosmic. ** Patch added: "cosmic_cups_2.2.8-5ubuntu2.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219665/+files/cosmic_cups_2.2.8-5ubuntu2.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 1807077] Re: mountall crashes on udev node with missing devname
** Tags added: patch trusty xenial ** Also affects: mountall (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: mountall (Ubuntu Xenial) Importance: Undecided Status: New ** Summary changed: - mountall crashes on udev node with missing devname + [SRU] mountall crashes on udev node with missing devname -- 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: New Status in mountall source package in Xenial: New 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