[Touch-packages] [Bug 942856] Re: NetworkManager does not support AES-encrypted private keys for WPA 802.1x authentication

[Bug Watch Updater]

Launchpad has imported 2 comments from the remote bug at
https://bugzilla.gnome.org/show_bug.cgi?id=670999.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.


On 2012-02-28T19:55:16+00:00 Walter Mundt wrote:

NetworkManager does not appear to support private keys encrypted with
AES. At the very least, it will not validate such a key in nm-util when
setting up a WPA 802.1x TLS wifi connection.

To test via nm-applet:

1. Start with a working (cleartext or DES-3) private key/cert for a network. 
Set up a connection and verify that everything works.
2. Re-encrypt the key with AES-256 with this command: "openssl rsa -in 
working-key.pem -out aes-key.pem -aes256" (the output should have a line 
starting with "DEK-Info: AES-256-CBC,")
3. Delete the settings for the test network and attempt to reconnect using the 
new key. Even with the correct passphrase, the "Connect" button will remain 
disabled; debugging output will show that nm-util is failing to validate the 
private key.

Workaround for anyone running into this issue: Re-encrypt your key with
DES-3.  The incantation is "openssl rsa -in aes-key.pem -out working-
key.pem -des3".

Reply at: https://bugs.launchpad.net/ubuntu/+source/network-
manager/+bug/942856/comments/1


On 2012-02-29T19:04:00+00:00 Walter Mundt wrote:

Specific version information, as requested on the Ubuntu bug at
https://bugs.launchpad.net/network-manager/+bug/942856 and added here in
case it's useful upstream:

Ubuntu Release: 11.10
network-manager version: 0.9.1.90-0ubuntu5.1
network-manager-gnome version: 0.9.1.90-0ubuntu6

FWIW, based on my cursory examination of the code, the issue does not
appear to be introduced by any Ubuntu packages.

This may be classifiable as "enhancement" or "wishlist" depending on
whether feature parity with openssl is part of the "current feature set"
of the application.  Based on my searches today, there's no common
standard for specifying anything more elaborate than a DES cipher in the
DEK-Info header of a PEM file.

Still, it would be nice to at least have some kind of error message
about the key format being unsupported instead of this case just getting
treated as if the key passphrase is always incorrect by the UI.

Reply at: https://bugs.launchpad.net/ubuntu/+source/network-
manager/+bug/942856/comments/4


** Changed in: network-manager
   Status: Unknown => Confirmed

** Changed in: network-manager
   Importance: Unknown => Wishlist

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

Title:
  NetworkManager does not support AES-encrypted private keys for WPA
  802.1x authentication

Status in NetworkManager:
  Confirmed
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  In Progress

Bug description:
  * Impact

  Selecting AES-{192,256}-CBC keys to connect isn't working

  * Test case

  1. Start with a working (cleartext or DES-3) private key/cert for a network.  
Set up a connection and verify that everything works.
  2. Re-encrypt the key with AES-256 with this command: "openssl rsa -in 
working-key.pem -out aes-key.pem -aes256" (the output should have a line 
starting with "DEK-Info: AES-256-CBC,")
  3. Delete the settings for the test network and attempt to reconnect using 
the new key. 

  That should work

  * Regression potential

  That's new code for an extra type of keys, it shouldn't impact
  existing options

  --

  NetworkManager does not appear to support private keys encrypted with
  AES.  At the very least, it will not validate such a key in nm-util
  when setting up a WPA 802.1x TLS wifi connection.

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/942856/+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 942856] Re: NetworkManager does not support AES-encrypted private keys for WPA 802.1x authentication

[Mathew Hodson]

** Bug watch added: bugzilla.gnome.org/ #670999
   https://bugzilla.gnome.org/show_bug.cgi?id=670999

** Changed in: network-manager
   Importance: Wishlist => Unknown

** Changed in: network-manager
   Status: Confirmed => Unknown

** Changed in: network-manager
 Remote watch: GNOME Bug Tracker #670999 => bugzilla.gnome.org/ #670999

** Bug watch removed: GNOME Bug Tracker #670999
   https://gitlab.gnome.org/670999

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

Title:
  NetworkManager does not support AES-encrypted private keys for WPA
  802.1x authentication

Status in NetworkManager:
  Unknown
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  In Progress

Bug description:
  * Impact

  Selecting AES-{192,256}-CBC keys to connect isn't working

  * Test case

  1. Start with a working (cleartext or DES-3) private key/cert for a network.  
Set up a connection and verify that everything works.
  2. Re-encrypt the key with AES-256 with this command: "openssl rsa -in 
working-key.pem -out aes-key.pem -aes256" (the output should have a line 
starting with "DEK-Info: AES-256-CBC,")
  3. Delete the settings for the test network and attempt to reconnect using 
the new key. 

  That should work

  * Regression potential

  That's new code for an extra type of keys, it shouldn't impact
  existing options

  --

  NetworkManager does not appear to support private keys encrypted with
  AES.  At the very least, it will not validate such a key in nm-util
  when setting up a WPA 802.1x TLS wifi connection.

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/942856/+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 1638395] Re: Unable to locate remote printer when printing

[allenstif]

Very often the users are coming across this common Printing error as
they are not able to locate a Remote Printer at the time of running a
printing process. I have a blog https://printerssupport.co/canon-
printer-not-responding/ along with such Printing solutions which will
help them surely.

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

Title:
  Unable to locate remote printer when printing

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  My printer (EPSON Stylus Photo RX520) is connected to a  Yakkety station 
called "paris" which is the printing server. 
  Printing is fine from the server.

  When i configure another Yakkety station to print via this server, the 
printer is detected OK via dnssd, the driver is installed OK. But i can't 
print. 
  I get the following message "Unable to locate printer "paris.local"."

  I used to work on xenial but the connection was through ipps. I tried
  to configure the connection as in xenial, to no avail ...

  What i did: 
  add "192.168.1.4 paris.local" in /etc/hosts
  remove printer from cups, reinstalled it and i finally was able to print on 
the remote printer!

  Don't know if this problem is related to cups or avahi ...

  Ubuntu 16.10
  cups 2.2.0-2

  What i expected to happen: printing successful
  What happened: client cannot locate remote printer, add to add a line in 
/etc/hosts to make it work

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1638395/+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 1844853] Re: IBus no longer works in Qt applications after upgrade

[Bug Watch Updater]

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

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

Title:
  IBus no longer works in Qt applications after upgrade

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

Bug description:
  Kubuntu Release 18.04.3 LTS

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

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

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

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

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

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

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

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

[Touch-packages] [Bug 1845190]

[Marc-herbert+sourceware]

Impressively quick fix indeed, thanks!

I haven't seen any test added though. While such ELF files shouldn't be common, 
it's a fairly basic feature and doesn't seem like requiring any complex test 
fixture, does it?
Relying on diffoscope's test suite doesn't feel right.

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

Title:
  binutils nm wrong output format breaks i386 nm work

Status in binutils:
  Fix Released
Status in binutils package in Ubuntu:
  Confirmed

Bug description:
  discovered with diffoscope autopkgregression, looks like a real bug, based on
  https://salsa.debian.org/reproducible-builds/diffoscope/issues/69

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1845190/+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 1839290] Re: systemd doesn't restart a service after crashes

[Brian Murray]

** Tags removed: rls-xx-incoming
** Tags added: rls-x-incoming

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

Title:
  systemd doesn't restart a service after crashes

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Xenial:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  Affected versions of OS and systemd:
  $ cat /etc/issue
  Ubuntu 16.04.6 LTS \n \l
  $ systemd --version
  systemd 229
  +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN

  Affected packages:
  systemd 229-4ubuntu21.22 and previous versions.

  Expected behaviour you didn't see:
  Scheduling restart of failed service.
  A process crashed by sigabrt and didn't restart.

  Description:
  The bug was reported to a systemd upstream repository: 
https://github.com/systemd/systemd/issues/11456
  The bug was fixed and accepted to the master branch: 
https://github.com/systemd/systemd/pull/11467/files

  Action:
  Include this patch to Ubuntu 16.04 and other version of Ubuntu which are 
supported.

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

Re: [Touch-packages] [Bug 1843381] Re: Dell system takes a long time to connect network with external dock

[Dimitri John Ledkov]

On Thu, 26 Sep 2019 at 20:11, Dan Streetman  wrote:
>
> So, am I understanding right that such a system will have two ethernet
> interfaces with identical mac addresses?  Isn't that an obvious problem
> that should be fixed instead?

Digging into this, It seems that it is an explicitly supported
configuration that was added in 2016
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579984

Ie. the dock copies the MAC address of the laptop, such that the same
lease is still usable.

Thus the timeouts now observed, are a regression of said feature.

-- 
Regards,

Dimitri.

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

Title:
  Dell system takes a long time to connect network with external dock

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  This is a bug reopen from
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700
  The original one caused systemd regressed.
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651

  This issue needs an alternative solution.
  

  Dell has a feature called MAC addrss passthrough[1] that would force usb 
ethernet adapters to be assigned with a predefined MAC address stored in BIOS 
or so. This feature has been landed to mainline kernel in driver r8152[2]. So 
whenever a r8152 managed device is plugged into Dell devices with MAC addrss 
passthrough enabled, this driver will set NIC MAC to a predefined one.

  And some Dell devices have already one built-in r8152 NIC port. On
  these devices, when a second r8152 NIC is plugged in, a Debian
  originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev
  built-in command `net_id` to give a persistent name, and that will be
  based on MAC address. However, since the system has already
  initialized the built-in r8152 NIC with that name, renaming the second
  interface with this name will always fail.

  While Debian still carries a patch called "Revert-udev-network-device-
  renaming-immediately-give.patch"[4] that tries to keep support of
  already deprecated "75-persistent-net-generator.rules" based interface
  renaming mechanism, this patch also propagated into Ubuntu[5]. This
  patch will retry renaming with a 90 seconds timeout when the error
  code is -EEXIST, so the uevent processing will always be blocked in
  the last ifrename step in the victim system.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules 
lib/udev/rules.d/50-udev-default.rules 
lib/udev/rules.d/73-special-net-names.rules 
lib/udev/rules.d/73-usb-net-by-mac.rules]
  ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18
  Uname: Linux 4.15.0-1043-oem x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules
  Date: Wed Jul 24 15:30:59 2019
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90
  InstallationDate: Installed on 2019-07-03 (20 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  MachineType: Dell Inc. Latitude 7424 Rugged Extreme
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed 
root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet 
splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M 
vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/27/2019
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.5.0
  dmi.board.name: 0Y7FK3
  dmi.board.vendor: Dell Inc.
  dmi.board.version: X03
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.5.0:bd05/27/2019:svnDellInc.:pnLatitude7424RuggedExtreme:pvr:rvnDellInc.:rn0Y7FK3:rvrX03:cvnDellInc.:ct10:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 7424 Rugged Extreme
  dmi.sys.vendor: Dell Inc.

  [1]: 
https://www.dell.com/support/article/tw/zh/twdhs1/sln301147/what-is-mac-address-pass-through?lang=en
  [2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/r8152.c
  [3]: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/extra/rules/73-usb-net-by-mac.rules
  [4]: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch
  [5]: 
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/tree/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give

[Touch-packages] [Bug 1619753] Re: systemd-fsck does not show results of rootfs filesystem check in logs or journald

[Ivan Baldo]

But it should be persisted by default in /var/log, so there should be a
unit somewhere that if the log has information then it appends it in a
file and gets logrotated.

That way, if a server or PC is acting strange, one could look there to
see if something strange happened to the filesystem and when it
happened.

The log shouldn't be lost...

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

Title:
  systemd-fsck does not show results of rootfs filesystem check in logs
  or journald

Status in initramfs-tools package in Ubuntu:
  Invalid

Bug description:
  Prior to the systemd paradigm shift, Ubuntu versions provided
  mechanisms to be able to see the results of a filesystem check
  performed on the root filesystem either in boot.log in 12.04 or in
  mountall.log in 14.04.

  As of 16.04, there is no way to see the output of systemd-fsck when it
  is run on the root filesystem.

  root@ubuntu-16-04-1:~# lsb_release -rd
  Description:Ubuntu 16.04.1 LTS
  Release:16.04

  root@ubuntu-16-04-1:~# apt-cache policy systemd
  systemd:
Installed: 229-4ubuntu7
Candidate: 229-4ubuntu7
Version table:
   *** 229-4ubuntu7 500
  500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   229-4ubuntu4 500
  500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  
  Steps to reproduce:

  1) Force fsck on next reboot by altering linux boot commandline:
 Edit /etc/default/grub and add "fsck.mode=force" to the GRUB_CMDLINE_LINUX 
variable. 
 If you also want to force repair behavior, also add "fsck.repair=yes" to 
the same variable. 

  # example: 
  GRUB_CMDLINE_LINUX="fsck.mode=force fsck.repair=yes" 

  Once the changes have been made, run "sudo update-grub" to update the
  boot info, then reboot.

  2) After boot, journalctl does not report any filesystem repair
  details for the root fs, only for secondary filesystems such as /boot
  or others designated in /etc/fstab.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1619753/+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 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

[Mauricio Faria de Oliveira]

Eric, thanks!  Really appreciate your help debugging this issue.

Per Colin's comment, he mentions on #launchpad-ops (internal)
when there are launchpad chroot changes -- so we can confirm
it's been updated after the package becomes Fix Released.

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

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+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 1759950] Re: Lid-close suspend: blank screen when switching to user session

[Dave York]

** Information type changed from Public to Public Security

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

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

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

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

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

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

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

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

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

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

  I've created an issue upstream for this at

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/light-locker/+bug/1759950/+subscriptions

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

[Touch-packages] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

[Eric Desrochers]

@mfo,

I will gladly resume the sponsoring as soon as LP: #1844504 is "Fix
Released" and util-linux builds fine.

Thanks for your good work on this Mauricio !

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

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+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 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

[Mauricio Faria de Oliveira]

The real fix for the openpty() problem on Launchpad xenial buildd
is in livecd-rootfs currently in xenial-proposed, and is verified.
(LP 1844504 comment 15)

Once the Launchpad builders are updated with that, we can proceed
with another build attempt, and hopefully move this SRU forward.

Thanks to Colin Watson (cjwatson) for quickly fixing livecd-rootfs.

cheers,
Mauricio

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

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+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 1845332] Re: Compose key does not create strings

[Gunnar Hjalmarsson]

On 2019-09-26 18:51, Oryganum wrote:
>> That wiki page you referred  to was last edited 11 years ago and is
>> obsolete to a large extent.
> 
> Is it possible to contact someone to ask to update this page?

The simple answer to that question is no.

There is a similar page which is somewhat less obsolete, even if also
that one needs to be updated:

https://help.ubuntu.com/community/ComposeKey

But such tutorials are user contributions, and there is no team or
individual who is responsible for maintaining them. So what you can do
is applying to get edit access and try to improve them yourself.

https://help.ubuntu.com/community/WikiGuide#Contributing

I'm inclined to think that  should
be deleted and the other page updated.

> On my Ubuntu 18.04 "Keyboard input method system" gives me options
> IBus, XIM and none.
> 
> Is there any known advantage of choosing IBus there?
> (I am trying to understand why XIM is not a default.)

Given that Ubuntu is now on GNOME, which relies on IBus to a large
extent, IBus will keep being default.

XIM is old, sometimes problematic (see e.g. bug #1573755), and will
probably be dropped completely if/when Ubuntu switches from X to
Wayland.

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

Title:
  Compose key does not create strings

Status in ibus package in Ubuntu:
  Invalid

Bug description:
  According to manual https://wiki.ubuntu.com/ComposeKey it is possible to 
define sequences to type characters and strings with Compose key.
  In Ubuntu 18.04 sequences work for characters but not for strings, line like 
this:
 : "by the way" # Compose b t w
  seems to be ignored.

  $ apt-cache policy ibus
  ibus:
Installed: 1.5.17-3ubuntu5.2
Candidate: 1.5.17-3ubuntu5.2
Version table:
   *** 1.5.17-3ubuntu5.2 500
  500 http://mirror.isoc.org.il/pub/ubuntu bionic-updates/main amd64 
Packages
  500 http://mirror.isoc.org.il/pub/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1.5.17-3ubuntu4 500
  500 http://mirror.isoc.org.il/pub/ubuntu bionic/main amd64 Packages
  500 http://cz.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  This problem first reported at Dec 11 '18 and also exists in Kubuntu
  18.04 (see https://askubuntu.com/questions/1099947/how-to-use-
  xcompose-to-produce-snippets).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1845332/+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 1845532] Re: power icon does not indicate charging if booted without power connected

[Heather Ellsworth]

In 19.10, with the error state, restarting upower fixes the issue. So if
you've booted without power connected, then connect power and don't see
the charging icon, execute `sudo systemctl restart upower` and see the
charging symbol.

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

Title:
  power icon does not indicate charging if booted without power
  connected

Status in upower package in Ubuntu:
  New

Bug description:
  Hardware: Lenovo T590
  OS: 19.10

  When the power is not connected when the laptop boots, and then
  connected, the power icon in the top bar does not change to indicate
  that the laptop is now charging.

  $ upower -d
  Device: /org/freedesktop/UPower/devices/line_power_AC 

 
native-path:  AC

 
power supply: yes   

 
updated:  Thu 26 Sep 2019 08:53:40 AM MDT (2107 seconds ago)
has history:  no
has statistics:   no
line-power
  warning-level:   none
  online:  no
  icon-name:  'ac-adapter-symbolic'

  Device: /org/freedesktop/UPower/devices/battery_BAT0 
native-path:  BAT0
vendor:   SMP
model:02DL012
serial:   1417
power supply: yes
updated:  Thu 26 Sep 2019 09:28:33 AM MDT (14 seconds ago)
has history:  yes
has statistics:   yes
battery
  present: yes
  rechargeable:yes
  state:   discharging
  warning-level:   none
  energy:  55.53 Wh
  energy-empty:0 Wh
  energy-full: 57.21 Wh
  energy-full-design:  57.02 Wh
  energy-rate: 0.319173 W
  voltage: 12.932 V
  time to empty:   7.2 days
  percentage:  97%
  capacity:100%
  technology:  lithium-polymer
  icon-name:  'battery-full-symbolic'

  Device: /org/freedesktop/UPower/devices/DisplayDevice
power supply: yes
updated:  Thu 26 Sep 2019 09:22:33 AM MDT (374 seconds ago)
has history:  no
has statistics:   no
battery
  present: yes
  state:   discharging
  warning-level:   none
  energy:  55.53 Wh
  energy-full: 57.21 Wh
  energy-rate: 0.319173 W
  time to empty:   7.2 days
  percentage:  97%
  icon-name:  'battery-full-symbolic'

  Daemon:
daemon-version:  0.99.11
on-battery:  yes
lid-is-closed:   no
lid-is-present:  yes
critical-action: PowerOff

  $ cat /sys/class/power_supply/BAT0/status 
  Unknown

  However, if the laptop is booted with the power connected, then the
  battery icon in the top bar shows that it's charging and at 100%. If I
  unplug the power, it correctly shows that it is no longer charging but
  it goes back to saying I'm at 97% (the last reported state when booted
  without power).

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: upower 0.99.11-1
  ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8
  Uname: Linux 5.3.0-10-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Sep 26 10:24:38 2019
  InstallationDate: Installed on 2019-09-13 (12 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: upower
  UpgradeStatus: Upgraded to eoan on 2019-09-19 (7 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1845532/+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 1845532] Re: power icon does not indicate charging if booted without power connected

[Heather Ellsworth]

I tried this in a 19.04 live boot from a usb stick and the behavior was
correct: if the system was booted without power, the charging symbol was
not there. Then when I connected the power, the charging symbol
appeared.

Also, when booting 19.04 without power connected, there is only the one 
dbus-daemon line in journalctl:
Sep 26 18:55:04 ubuntu dbus-daemon[1097]: [system] Activating via systemd: 
service name='org.freedesktop.UPower' unit='upower.service' requested by 
':1.38' (uid=999 pid=1761 comm="/usr/bin/gnome-shell " label="u
nconfined")

So there is some regression between 19.04 and current 19.10.

19.04 kernel: 5.0.0.-13.14
19.10 kernel: 5.3.0-10.11

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

Title:
  power icon does not indicate charging if booted without power
  connected

Status in upower package in Ubuntu:
  New

Bug description:
  Hardware: Lenovo T590
  OS: 19.10

  When the power is not connected when the laptop boots, and then
  connected, the power icon in the top bar does not change to indicate
  that the laptop is now charging.

  $ upower -d
  Device: /org/freedesktop/UPower/devices/line_power_AC 

 
native-path:  AC

 
power supply: yes   

 
updated:  Thu 26 Sep 2019 08:53:40 AM MDT (2107 seconds ago)
has history:  no
has statistics:   no
line-power
  warning-level:   none
  online:  no
  icon-name:  'ac-adapter-symbolic'

  Device: /org/freedesktop/UPower/devices/battery_BAT0 
native-path:  BAT0
vendor:   SMP
model:02DL012
serial:   1417
power supply: yes
updated:  Thu 26 Sep 2019 09:28:33 AM MDT (14 seconds ago)
has history:  yes
has statistics:   yes
battery
  present: yes
  rechargeable:yes
  state:   discharging
  warning-level:   none
  energy:  55.53 Wh
  energy-empty:0 Wh
  energy-full: 57.21 Wh
  energy-full-design:  57.02 Wh
  energy-rate: 0.319173 W
  voltage: 12.932 V
  time to empty:   7.2 days
  percentage:  97%
  capacity:100%
  technology:  lithium-polymer
  icon-name:  'battery-full-symbolic'

  Device: /org/freedesktop/UPower/devices/DisplayDevice
power supply: yes
updated:  Thu 26 Sep 2019 09:22:33 AM MDT (374 seconds ago)
has history:  no
has statistics:   no
battery
  present: yes
  state:   discharging
  warning-level:   none
  energy:  55.53 Wh
  energy-full: 57.21 Wh
  energy-rate: 0.319173 W
  time to empty:   7.2 days
  percentage:  97%
  icon-name:  'battery-full-symbolic'

  Daemon:
daemon-version:  0.99.11
on-battery:  yes
lid-is-closed:   no
lid-is-present:  yes
critical-action: PowerOff

  $ cat /sys/class/power_supply/BAT0/status 
  Unknown

  However, if the laptop is booted with the power connected, then the
  battery icon in the top bar shows that it's charging and at 100%. If I
  unplug the power, it correctly shows that it is no longer charging but
  it goes back to saying I'm at 97% (the last reported state when booted
  without power).

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: upower 0.99.11-1
  ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8
  Uname: Linux 5.3.0-10-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Sep 26 10:24:38 2019
  InstallationDate: Installed on 2019-09-13 (12 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: upower
  UpgradeStatus: Upgraded to eoan on 2019-09-19 (7 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1845532/+subscriptions

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

[Touch-packages] [Bug 1843352] Re: systemd package version 237-3ubuntu10.28 breaks local network DNS resolution

[Dan Streetman]

Do you have DNSSEC enabled?  There is a known bug 1796501 that may be
causing your problem.

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

Title:
  systemd package version 237-3ubuntu10.28 breaks local network DNS
  resolution

Status in systemd package in Ubuntu:
  New

Bug description:
  After upgrading to the latest package the systemd-resolved service
  fails to resolve names for local network.Manually invoking nslookup
  works fine.

  The only suspicious output from journalctl seems:
  systemd-resolved[858]: Server returned error NXDOMAIN, mitigating potential 
DNS violation DVE-2018-0001, retrying transaction with reduced feature level 
UDP.

  The latest change in that package is:
   * SECURITY UPDATE: Unprivileged users are granted access to privileged
  systemd-resolved D-Bus methods
  - d/p/0001-shared-but-util-drop-trusted-annotation-from-bus_ope.patch:
drop trusted annotation from bus_open_system_watch_bind()
  - CVE-2019-15718

   -- Chris Coulson   Thu, 29 Aug 2019
  23:30:33 +0100

  Please revert this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1843352/+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 1843381] Re: Dell system takes a long time to connect network with external dock

[Dan Streetman]

So, am I understanding right that such a system will have two ethernet
interfaces with identical mac addresses?  Isn't that an obvious problem
that should be fixed instead?

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

Title:
  Dell system takes a long time to connect network with external dock

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  This is a bug reopen from
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700
  The original one caused systemd regressed.
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651

  This issue needs an alternative solution.
  

  Dell has a feature called MAC addrss passthrough[1] that would force usb 
ethernet adapters to be assigned with a predefined MAC address stored in BIOS 
or so. This feature has been landed to mainline kernel in driver r8152[2]. So 
whenever a r8152 managed device is plugged into Dell devices with MAC addrss 
passthrough enabled, this driver will set NIC MAC to a predefined one.

  And some Dell devices have already one built-in r8152 NIC port. On
  these devices, when a second r8152 NIC is plugged in, a Debian
  originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev
  built-in command `net_id` to give a persistent name, and that will be
  based on MAC address. However, since the system has already
  initialized the built-in r8152 NIC with that name, renaming the second
  interface with this name will always fail.

  While Debian still carries a patch called "Revert-udev-network-device-
  renaming-immediately-give.patch"[4] that tries to keep support of
  already deprecated "75-persistent-net-generator.rules" based interface
  renaming mechanism, this patch also propagated into Ubuntu[5]. This
  patch will retry renaming with a 90 seconds timeout when the error
  code is -EEXIST, so the uevent processing will always be blocked in
  the last ifrename step in the victim system.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules 
lib/udev/rules.d/50-udev-default.rules 
lib/udev/rules.d/73-special-net-names.rules 
lib/udev/rules.d/73-usb-net-by-mac.rules]
  ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18
  Uname: Linux 4.15.0-1043-oem x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules
  Date: Wed Jul 24 15:30:59 2019
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90
  InstallationDate: Installed on 2019-07-03 (20 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  MachineType: Dell Inc. Latitude 7424 Rugged Extreme
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed 
root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet 
splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M 
vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/27/2019
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.5.0
  dmi.board.name: 0Y7FK3
  dmi.board.vendor: Dell Inc.
  dmi.board.version: X03
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.5.0:bd05/27/2019:svnDellInc.:pnLatitude7424RuggedExtreme:pvr:rvnDellInc.:rn0Y7FK3:rvrX03:cvnDellInc.:ct10:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 7424 Rugged Extreme
  dmi.sys.vendor: Dell Inc.

  [1]: 
https://www.dell.com/support/article/tw/zh/twdhs1/sln301147/what-is-mac-address-pass-through?lang=en
  [2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/r8152.c
  [3]: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/extra/rules/73-usb-net-by-mac.rules
  [4]: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch
  [5]: 
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/tree/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch?h=ubuntu-bionic

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1843381/+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 1843857] Re: IPMasquerade=yes -> ignored on eoan

[Dan Streetman]

iptables was reverted back to using iptables-legacy by default in bug
1843468 so this should not be an issue (by default) in Eoan, though it
might be in the future when iptables does default to iptables-nft.

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

Title:
  IPMasquerade=yes -> ignored on eoan

Status in systemd package in Ubuntu:
  New

Bug description:
  I'm testing out eoan, I have a [Network] section with IPMasquerade=yes.
  The system starts without complaint from systemd in the logs, but I see no 
evidence of source natting going on.
  I'm not sure of sub-dependencies, but I think source natting depends on 
libiptc-dev, which I don't see among the listings in eoan.

  I found Systemd-networkd updates 'iptables-legacy' with the source 
natting/masquerade detail -- which is disused by default.

  So it has no effect and doesn't throw an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1843857/+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 1845337] Re: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service

[Dan Streetman]

** Tags added: next-ddstreet systemd

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

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in qemu source package in Disco:
  New
Status in systemd source package in Disco:
  New

Bug description:
  Since the recent few weeks systemd autopkgtest @ armhf @ disco fail
  [1].

  The log is very (very) long and partially interwoven due to concurrent 
execution.
  Somewhere in between we see this subcase is the one failing: root-unittests
  Of this test (which again has many subtests) it is: test-execute
  And of this again it is (always):

  I'll attach bad and good case full and stripped logs.

  
  The diff of those comes down to just:
  1. execute a find in a shell
  2. shell exits
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=0/SUCCESS
  vs
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=1/FAILURE
  4. in the bad case that triggers an assertion
  The find that fails is:

  find / -path /var/tmp -o -path /tmp -o -path /proc -o -path
  /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf

  Good and bad case are the same most recent version
  systemd/240-6ubuntu5.7.

  Maybe something is bad in the containers we have for armhf in regard to these 
paths?
  Was there any change we'd know of?

  If there is nothing known, could we force-badtest it to get it out of
  the way of ongoing migrations?

  [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+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 1845190] Re: binutils nm wrong output format breaks i386 nm work

[Brian Murray]

** Tags removed: rls-ee-incoming
** Tags added: rls-ee-notfixing

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

Title:
  binutils nm wrong output format breaks i386 nm work

Status in binutils:
  Fix Released
Status in binutils package in Ubuntu:
  Confirmed

Bug description:
  discovered with diffoscope autopkgregression, looks like a real bug, based on
  https://salsa.debian.org/reproducible-builds/diffoscope/issues/69

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1845190/+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 1845532] Re: power icon does not indicate charging if booted without power connected

[Heather Ellsworth]

The following is the output of `journalctl | grep -i power` that covers
the duration between the reboot command and login times.

** Attachment added: "journal-power-keyword_with-power-connected-on-boot.out"
   
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1845532/+attachment/5291525/+files/journal-power-keyword_with-power-connected-on-boot.out

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

Title:
  power icon does not indicate charging if booted without power
  connected

Status in upower package in Ubuntu:
  New

Bug description:
  Hardware: Lenovo T590
  OS: 19.10

  When the power is not connected when the laptop boots, and then
  connected, the power icon in the top bar does not change to indicate
  that the laptop is now charging.

  $ upower -d
  Device: /org/freedesktop/UPower/devices/line_power_AC 

 
native-path:  AC

 
power supply: yes   

 
updated:  Thu 26 Sep 2019 08:53:40 AM MDT (2107 seconds ago)
has history:  no
has statistics:   no
line-power
  warning-level:   none
  online:  no
  icon-name:  'ac-adapter-symbolic'

  Device: /org/freedesktop/UPower/devices/battery_BAT0 
native-path:  BAT0
vendor:   SMP
model:02DL012
serial:   1417
power supply: yes
updated:  Thu 26 Sep 2019 09:28:33 AM MDT (14 seconds ago)
has history:  yes
has statistics:   yes
battery
  present: yes
  rechargeable:yes
  state:   discharging
  warning-level:   none
  energy:  55.53 Wh
  energy-empty:0 Wh
  energy-full: 57.21 Wh
  energy-full-design:  57.02 Wh
  energy-rate: 0.319173 W
  voltage: 12.932 V
  time to empty:   7.2 days
  percentage:  97%
  capacity:100%
  technology:  lithium-polymer
  icon-name:  'battery-full-symbolic'

  Device: /org/freedesktop/UPower/devices/DisplayDevice
power supply: yes
updated:  Thu 26 Sep 2019 09:22:33 AM MDT (374 seconds ago)
has history:  no
has statistics:   no
battery
  present: yes
  state:   discharging
  warning-level:   none
  energy:  55.53 Wh
  energy-full: 57.21 Wh
  energy-rate: 0.319173 W
  time to empty:   7.2 days
  percentage:  97%
  icon-name:  'battery-full-symbolic'

  Daemon:
daemon-version:  0.99.11
on-battery:  yes
lid-is-closed:   no
lid-is-present:  yes
critical-action: PowerOff

  $ cat /sys/class/power_supply/BAT0/status 
  Unknown

  However, if the laptop is booted with the power connected, then the
  battery icon in the top bar shows that it's charging and at 100%. If I
  unplug the power, it correctly shows that it is no longer charging but
  it goes back to saying I'm at 97% (the last reported state when booted
  without power).

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: upower 0.99.11-1
  ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8
  Uname: Linux 5.3.0-10-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Sep 26 10:24:38 2019
  InstallationDate: Installed on 2019-09-13 (12 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: upower
  UpgradeStatus: Upgraded to eoan on 2019-09-19 (7 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1845532/+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 1845532] Re: power icon does not indicate charging if booted without power connected

[Heather Ellsworth]

The following is the output of `journalctl | grep -i power` that covers
the duration between the reboot command and login times.

** Attachment added: "journal-power-keyword_no-power-connected-on-boot.out"
   
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1845532/+attachment/5291524/+files/journal-power-keyword_no-power-connected-on-boot.out

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

Title:
  power icon does not indicate charging if booted without power
  connected

Status in upower package in Ubuntu:
  New

Bug description:
  Hardware: Lenovo T590
  OS: 19.10

  When the power is not connected when the laptop boots, and then
  connected, the power icon in the top bar does not change to indicate
  that the laptop is now charging.

  $ upower -d
  Device: /org/freedesktop/UPower/devices/line_power_AC 

 
native-path:  AC

 
power supply: yes   

 
updated:  Thu 26 Sep 2019 08:53:40 AM MDT (2107 seconds ago)
has history:  no
has statistics:   no
line-power
  warning-level:   none
  online:  no
  icon-name:  'ac-adapter-symbolic'

  Device: /org/freedesktop/UPower/devices/battery_BAT0 
native-path:  BAT0
vendor:   SMP
model:02DL012
serial:   1417
power supply: yes
updated:  Thu 26 Sep 2019 09:28:33 AM MDT (14 seconds ago)
has history:  yes
has statistics:   yes
battery
  present: yes
  rechargeable:yes
  state:   discharging
  warning-level:   none
  energy:  55.53 Wh
  energy-empty:0 Wh
  energy-full: 57.21 Wh
  energy-full-design:  57.02 Wh
  energy-rate: 0.319173 W
  voltage: 12.932 V
  time to empty:   7.2 days
  percentage:  97%
  capacity:100%
  technology:  lithium-polymer
  icon-name:  'battery-full-symbolic'

  Device: /org/freedesktop/UPower/devices/DisplayDevice
power supply: yes
updated:  Thu 26 Sep 2019 09:22:33 AM MDT (374 seconds ago)
has history:  no
has statistics:   no
battery
  present: yes
  state:   discharging
  warning-level:   none
  energy:  55.53 Wh
  energy-full: 57.21 Wh
  energy-rate: 0.319173 W
  time to empty:   7.2 days
  percentage:  97%
  icon-name:  'battery-full-symbolic'

  Daemon:
daemon-version:  0.99.11
on-battery:  yes
lid-is-closed:   no
lid-is-present:  yes
critical-action: PowerOff

  $ cat /sys/class/power_supply/BAT0/status 
  Unknown

  However, if the laptop is booted with the power connected, then the
  battery icon in the top bar shows that it's charging and at 100%. If I
  unplug the power, it correctly shows that it is no longer charging but
  it goes back to saying I'm at 97% (the last reported state when booted
  without power).

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: upower 0.99.11-1
  ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8
  Uname: Linux 5.3.0-10-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Sep 26 10:24:38 2019
  InstallationDate: Installed on 2019-09-13 (12 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: upower
  UpgradeStatus: Upgraded to eoan on 2019-09-19 (7 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1845532/+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 1845532] Re: power icon does not indicate charging if booted without power connected

[Heather Ellsworth]

The only difference in journalctl between when the system boots with
power and without is that when the system boots without power, I see two
journalctl messages:

Sep 26 10:53:27 fenrir dbus-daemon[793]: [system] Activating via systemd: 
service name='org.freedesktop.UPower' unit='upower.service' requested by 
':1.37' (uid=123 pid=1052 comm="/usr/bin/gnome-shell " label="unconfined")
Sep 26 10:54:31 fenrir dbus-daemon[844]: [system] Activating via systemd: 
service name='org.freedesktop.UPower' unit='upower.service' requested by 
':1.38' (uid=123 pid= comm="/usr/bin/gnome-shell " label="unconfined")

When the system boots with power, I see only one similar journalctl message:
Sep 26 11:22:26 fenrir dbus-daemon[835]: [system] Activating via systemd: 
service name='org.freedesktop.UPower' unit='upower.service' requested by 
':1.38' (uid=123 pid=1090 comm="/usr/bin/gnome-shell " label="unconfined")

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

Title:
  power icon does not indicate charging if booted without power
  connected

Status in upower package in Ubuntu:
  New

Bug description:
  Hardware: Lenovo T590
  OS: 19.10

  When the power is not connected when the laptop boots, and then
  connected, the power icon in the top bar does not change to indicate
  that the laptop is now charging.

  $ upower -d
  Device: /org/freedesktop/UPower/devices/line_power_AC 

 
native-path:  AC

 
power supply: yes   

 
updated:  Thu 26 Sep 2019 08:53:40 AM MDT (2107 seconds ago)
has history:  no
has statistics:   no
line-power
  warning-level:   none
  online:  no
  icon-name:  'ac-adapter-symbolic'

  Device: /org/freedesktop/UPower/devices/battery_BAT0 
native-path:  BAT0
vendor:   SMP
model:02DL012
serial:   1417
power supply: yes
updated:  Thu 26 Sep 2019 09:28:33 AM MDT (14 seconds ago)
has history:  yes
has statistics:   yes
battery
  present: yes
  rechargeable:yes
  state:   discharging
  warning-level:   none
  energy:  55.53 Wh
  energy-empty:0 Wh
  energy-full: 57.21 Wh
  energy-full-design:  57.02 Wh
  energy-rate: 0.319173 W
  voltage: 12.932 V
  time to empty:   7.2 days
  percentage:  97%
  capacity:100%
  technology:  lithium-polymer
  icon-name:  'battery-full-symbolic'

  Device: /org/freedesktop/UPower/devices/DisplayDevice
power supply: yes
updated:  Thu 26 Sep 2019 09:22:33 AM MDT (374 seconds ago)
has history:  no
has statistics:   no
battery
  present: yes
  state:   discharging
  warning-level:   none
  energy:  55.53 Wh
  energy-full: 57.21 Wh
  energy-rate: 0.319173 W
  time to empty:   7.2 days
  percentage:  97%
  icon-name:  'battery-full-symbolic'

  Daemon:
daemon-version:  0.99.11
on-battery:  yes
lid-is-closed:   no
lid-is-present:  yes
critical-action: PowerOff

  $ cat /sys/class/power_supply/BAT0/status 
  Unknown

  However, if the laptop is booted with the power connected, then the
  battery icon in the top bar shows that it's charging and at 100%. If I
  unplug the power, it correctly shows that it is no longer charging but
  it goes back to saying I'm at 97% (the last reported state when booted
  without power).

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: upower 0.99.11-1
  ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8
  Uname: Linux 5.3.0-10-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Sep 26 10:24:38 2019
  InstallationDate: Installed on 2019-09-13 (12 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: upower
  UpgradeStatus: Upgraded to eoan on 2019-09-19 (7 days ago)

To manage notificati

[Touch-packages] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time

[Dan Streetman]

** Tags removed: sts-sponsor

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

Title:
  [SRU] systemd-resolved negative caching for extended period of time

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

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache 
hit for  www.no-record.cl IN A
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < 
www.no-record.cl IN A> on scope dns on ens3/* now complete with  scope dns on ens3/.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP 
for transaction 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet 
with id 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming 
packet on transaction 22382 (rcode=SERVFAIL).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: 
SERVFAIL
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative 
entry for: www.metaklass.org IN A, cache mode set to no-negative
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for 
 on scope dns on ens3/ now complete with from network 
(unsigned).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet 
with id 31060 on interface 1/AF_INET.

  The following patch https://github.com/systemd/systemd/pull/13047
  implements the required changes.

  [Other Info]

  Note that systemd in Eoan is being upgraded to upstream 242, so I am
  not adding this to Eoan now, as I don't want to disturb the merge. If
  needed after the merge, I'll add to Eoan.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1831468] Re: 'upstream' tests fail, usually TEST-18, TEST-19, TEST-25, and/or TEST-27

[Dan Streetman]

There is various expansive work I'm doing upstream on the entire test
framework, so I'll eventually get to cleaning up all the tests in our
sru releases.  Closing this as I don't need it to track any failures
currently, I'll open new sru bugs when ready to fix tests.

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

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

** Changed in: systemd (Ubuntu Eoan)
   Status: In Progress => Won't Fix

** Changed in: systemd (Ubuntu Disco)
   Status: In Progress => Won't Fix

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

Title:
  'upstream' tests fail, usually TEST-18, TEST-19, TEST-25, and/or
  TEST-27

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Won't Fix

Bug description:
  [impact]

  some tests in the 'upstream' test suite fail on disco for ppc64el, e.g.:
  FAILED TESTS:  test/TEST-18-FAILUREACTION test/TEST-19-DELEGATE 
test/TEST-25-IMPORT test/TEST-27-STDOUTFILE

  [test case]

  check autopkgtest logs, e.g.:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/ppc64el/s/systemd/20190601_160043_a5281@/log.gz

  [regression potential]

  TBD

  [other info]

  this appears to fail only on ppc64el on disco and eoan, not cosmic or
  earlier or any other archs, but that is only from checking a few logs
  from other releases/archs, and without any investigation into the
  problem yet, so could be incorrect.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831468/+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 1845532] Re: power icon does not indicate charging if booted without power connected

[Heather Ellsworth]

This issue is completely reproducible for me. Digging into the
journalctl logs around when the system is rebooting without power
plugged in, here are some lines that stand out and might be useful:

Note that the system was sent to reboot at 10:53:00

...
Sep 26 10:53:37 fenrir systemd[2088]: Started GNOME Power management handling.
Sep 26 10:53:37 fenrir systemd[2088]: Reached target GNOME Power management 
handling.
...
Sep 26 10:54:28 fenrir kernel: ACPI: Power Resource [PUBS] (on)
Sep 26 10:54:28 fenrir kernel: ACPI: Power Resource [USBC] (on)
Sep 26 10:54:28 fenrir kernel: ACPI: Power Resource [PXP] (on)
Sep 26 10:54:28 fenrir kernel: ACPI: Power Resource [PXP] (off)
Sep 26 10:54:28 fenrir kernel: ACPI: Power Resource [V0PR] (on)
Sep 26 10:54:28 fenrir kernel: ACPI: Power Resource [V1PR] (on)
Sep 26 10:54:28 fenrir kernel: ACPI: Power Resource [V2PR] (on)
Sep 26 10:54:28 fenrir kernel: ACPI: Power Resource [WRST] (on)
Sep 26 10:54:28 fenrir kernel: ACPI: Power Resource [PIN] (off)
Sep 26 10:54:28 fenrir kernel: ACPI: Power Resource [PINP] (off)
...
Sep 26 10:54:28 fenrir kernel: usb: port power management may be unreliable
...
Sep 26 10:54:29 fenrir dbus-daemon[844]: dbus[844]: Unknown group "power" in 
message bus configuration file
...
Sep 26 10:54:29 fenrir boltd[842]: journal: opened for 'c003-0082'; size: 0 
bytes
Sep 26 10:54:29 fenrir boltd[842]: [c003-0082-domain?] 
domain: registered (bootacl: 16/16)
Sep 26 10:54:29 fenrir boltd[842]: store: loading devices
Sep 26 10:54:29 fenrir boltd[842]: power: state located at: /run/boltd/power
Sep 26 10:54:29 fenrir systemd[1]: Starting Hold until boot process finishes 
up...
...
Sep 26 10:54:31 fenrir dbus-daemon[844]: [system] Activating via systemd: 
service name='org.freedesktop.UPower' unit='upower.service' requested by 
':1.38' (uid=123 pid= comm="/usr/bin/gnome-shell " label="unconfined")
Sep 26 10:54:31 fenrir systemd[1]: Starting Daemon for power management...
...
Sep 26 10:54:31 fenrir gnome-shell[]: Getting invalid resource scale 
property
Sep 26 10:54:31 fenrir gnome-shell[]: ibus_bus_hello: assertion 
'ibus_bus_is_connected (bus)' failed
Sep 26 10:54:31 fenrir gnome-shell[]: Error while sending AddMatch() 
message: The connection is closed
Sep 26 10:54:31 fenrir gnome-shell[]: ibus_bus_call_async: assertion 
'ibus_bus_is_connected (bus)' failed
Sep 26 10:54:31 fenrir gnome-shell[]: ibus_bus_call_async: assertion 
'ibus_bus_is_connected (bus)' failed
Sep 26 10:54:31 fenrir gnome-shell[]: JS ERROR: Gio.IOErrorEnum: The 
connection is closed
  
_setContext@resource:///org/gnome/shell/misc/inputMethod.js:63:25
Sep 26 10:54:31 fenrir upowerd[1760]: energy_full (57.18) is greater than 
energy_full_design (57.02)
Sep 26 10:54:31 fenrir gnome-shell[]: Error looking up permission: 
GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation
Sep 26 10:54:31 fenrir systemd[1062]: Started GNOME XSettings.
Sep 26 10:54:31 fenrir dbus-daemon[844]: [system] Successfully activated 
service 'org.freedesktop.UPower'
Sep 26 10:54:31 fenrir systemd[1]: Started Daemon for power management.
...
Sep 26 10:54:36 fenrir gnome-session-binary[2271]: DEBUG(+): GsmManager: read 
/etc/xdg/autostart/org.gnome.SettingsDaemon.Power.desktop
Sep 26 10:54:36 fenrir gnome-session-binary[2271]: DEBUG(+): GsmManager: not 
adding app: app-id 'org.gnome.SettingsDaemon.Power.desktop' already exists
...
Sep 26 10:54:36 fenrir gnome-session-binary[2271]: DEBUG(+): GsmManager:
ID: /org/gnome/SessionManager/App8
app-id:org.gnome.SettingsDaemon.Power.desktopis-disabled:1
is-conditionally-disabled:0is-delayed:0
...
Sep 26 10:54:36 fenrir systemd[1958]: Started GNOME Power management handling.
Sep 26 10:54:36 fenrir systemd[1958]: Reached target GNOME Power management 
handling.

A full journalctl log is available but it is 46Mb so I didn't attach it
here.

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

Title:
  power icon does not indicate charging if booted without power
  connected

Status in upower package in Ubuntu:
  New

Bug description:
  Hardware: Lenovo T590
  OS: 19.10

  When the power is not connected when the laptop boots, and then
  connected, the power icon in the top bar does not change to indicate
  that the laptop is now charging.

  $ upower -d
  Device: /org/freedesktop/UPower/devices/line_power_AC 

 
native-path:  AC

 
power s

[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez

[Dan Streetman]

@yura9, @mauromol, or anyone experiencing this, if you are running
Bionic or Disco, can you please test with the 'bluez' package currently
in -proposed?  See the previous 2 comments for instructions how.

This bug does need someone affected by this bug (i.e. with the affected
hardware) to verify it before it's released.

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

Title:
  systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez

Status in linux:
  Confirmed
Status in The Ubuntu Power Consumption Project:
  New
Status in bluez package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in bluez source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Invalid
Status in systemd source package in Bionic:
  Invalid
Status in bluez source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Invalid
Status in systemd source package in Disco:
  Invalid
Status in bluez source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Invalid
Status in systemd source package in Eoan:
  Invalid
Status in bluez package in Debian:
  New

Bug description:
  [impact]

  on specific Dell systems, with a specific usb bluetooth device built-
  in, the udev rule 'hid2hci' provided by the 'bluez' package causes an
  endless loop of uevents resulting from 'bind' or 'unbind' kernel
  uevents.  These new events were added to the kernel after the
  'hid2hci' udev rule was written.

  [test case]

  the specific Dell system is required to be able to reproduce this, or
  at least the specific usb bluetooth hardware included in that system.

  Reproducing this is reportedly easy, for example comment 75 indicates
  it happens on every boot.

  When this happens, any process monitor (e.g. ps, top, etc) will show
  the 'udevd' process using 100% of a cpu, and 'udevadm monitor' should
  show repeated 'bind' and 'unbind' events as mentioned in comment 39.

  [regression potential]

  as this alters what kernel uevents the 'hid2hci' udev rule processes,
  regressions would involve the affected usb bluetooth device failing to
  be set up, or otherwise not processing the uevents correctly.

  [other info]

  this is not fixed yet upstream, as of my last check, but has been
  submitted upstream as mentioned in comment 95.

  
  original description:

  --

  
  The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not 
noticing any difference in my computer.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu6
  ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
  Uname: Linux 4.15.0-13-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.9-0ubuntu2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Mar 29 08:52:54 2018
  InstallationDate: Installed on 2018-03-05 (23 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304)
  MachineType: Dell Inc. Inspiron N5010
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic 
root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf

   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/25/2011
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A12
  dmi.board.name: 08R0GW
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A12
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: A12
  dmi.modalias: 
dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12:
  dmi.product.name: Inspiron N5010
  dmi.product.version: A12
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel/+bug/1759836/+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 1845332] Re: Compose key does not create strings

[Oryganum]

Thank you so much for the quick response!

I switched "Keyboard input method system" to "XIM" as you suggested and
now everything works fine.

However, I have a few questions about it.

>> That wiki page you referred  to was last edited 11 years ago and is
obsolete to a large extent.

Is it possible to contact someone to ask to update this page?

>> Today, on an Ubuntu system, it's normally GTK (not IBus, so I'm
closing this bug report) which deals with rules in the ~/.XCompose file.

On my Ubuntu 18.04 "Keyboard input method system" gives me options IBus,
XIM and none.

Is there any known advantage of choosing IBus there? 
(I am trying to understand why XIM is not a default.)

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

Title:
  Compose key does not create strings

Status in ibus package in Ubuntu:
  Invalid

Bug description:
  According to manual https://wiki.ubuntu.com/ComposeKey it is possible to 
define sequences to type characters and strings with Compose key.
  In Ubuntu 18.04 sequences work for characters but not for strings, line like 
this:
 : "by the way" # Compose b t w
  seems to be ignored.

  $ apt-cache policy ibus
  ibus:
Installed: 1.5.17-3ubuntu5.2
Candidate: 1.5.17-3ubuntu5.2
Version table:
   *** 1.5.17-3ubuntu5.2 500
  500 http://mirror.isoc.org.il/pub/ubuntu bionic-updates/main amd64 
Packages
  500 http://mirror.isoc.org.il/pub/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1.5.17-3ubuntu4 500
  500 http://mirror.isoc.org.il/pub/ubuntu bionic/main amd64 Packages
  500 http://cz.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  This problem first reported at Dec 11 '18 and also exists in Kubuntu
  18.04 (see https://askubuntu.com/questions/1099947/how-to-use-
  xcompose-to-produce-snippets).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1845332/+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 1845532] [NEW] power icon does not indicate charging if booted without power connected

[Heather Ellsworth]

Public bug reported:

Hardware: Lenovo T590
OS: 19.10

When the power is not connected when the laptop boots, and then
connected, the power icon in the top bar does not change to indicate
that the laptop is now charging.

$ upower -d
Device: /org/freedesktop/UPower/devices/line_power_AC   

   
  native-path:  AC  

   
  power supply: yes 

   
  updated:  Thu 26 Sep 2019 08:53:40 AM MDT (2107 seconds ago)
  has history:  no
  has statistics:   no
  line-power
warning-level:   none
online:  no
icon-name:  'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/battery_BAT0 
  native-path:  BAT0
  vendor:   SMP
  model:02DL012
  serial:   1417
  power supply: yes
  updated:  Thu 26 Sep 2019 09:28:33 AM MDT (14 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   discharging
warning-level:   none
energy:  55.53 Wh
energy-empty:0 Wh
energy-full: 57.21 Wh
energy-full-design:  57.02 Wh
energy-rate: 0.319173 W
voltage: 12.932 V
time to empty:   7.2 days
percentage:  97%
capacity:100%
technology:  lithium-polymer
icon-name:  'battery-full-symbolic'

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply: yes
  updated:  Thu 26 Sep 2019 09:22:33 AM MDT (374 seconds ago)
  has history:  no
  has statistics:   no
  battery
present: yes
state:   discharging
warning-level:   none
energy:  55.53 Wh
energy-full: 57.21 Wh
energy-rate: 0.319173 W
time to empty:   7.2 days
percentage:  97%
icon-name:  'battery-full-symbolic'

Daemon:
  daemon-version:  0.99.11
  on-battery:  yes
  lid-is-closed:   no
  lid-is-present:  yes
  critical-action: PowerOff

$ cat /sys/class/power_supply/BAT0/status 
Unknown

However, if the laptop is booted with the power connected, then the
battery icon in the top bar shows that it's charging and at 100%. If I
unplug the power, it correctly shows that it is no longer charging but
it goes back to saying I'm at 97% (the last reported state when booted
without power).

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: upower 0.99.11-1
ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8
Uname: Linux 5.3.0-10-generic x86_64
ApportVersion: 2.20.11-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Sep 26 10:24:38 2019
InstallationDate: Installed on 2019-09-13 (12 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: upower
UpgradeStatus: Upgraded to eoan on 2019-09-19 (7 days ago)

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


** Tags: amd64 apport-bug eoan

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

Title:
  power icon does not indicate charging if booted without power
  connected

Status in upower package in Ubuntu:
  New

Bug description:
  Hardware: Lenovo T590
  OS: 19.10

  When the power is not connected when the laptop boots, and then
  connected, the power icon in the top bar does not change to indicate
  that the laptop is now charging.

  $ upower -d
  Device: /org/freedesktop/UPower/devices/line_power_AC 

 
native-path:  AC

 
power supply: yes   

 
updated:  Thu 26 Sep 2019 08:53:40 AM MDT (2107 seconds ago)
has history:  no
 

[Touch-packages] [Bug 1769297] Re: resume from hibernation broken when resume image is autodetected

[Dimitri John Ledkov]

** Changed in: initramfs-tools (Ubuntu)
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

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

Title:
  resume from hibernation broken when resume image is autodetected

Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  I found a reason of non-functioning resume from hibernation when
  resume partition/file is autodetected by intiramfs hook /usr/share
  /initramfs-tools/hooks/resume.

  Here is the scenario:
  1) hook /usr/share/initramfs-tools/hooks/resume creates config 
conf/conf.d/zz-resume-auto saved in initrd image, containing one variable: 
RESUME=UUID=106238b0-707d-4422-866d-a7534da50702 in my case

  2) during boot init script sets 'resume' variable to 'RESUME' value
  from conf/conf.d/zz-resume-auto, then it executes local-premount
  scripts including local-premount/resume

  3) resuming script local-premount/resume 
(/usr/share/initramfs-tools/scripts/local-premount/resume) tries to get resume 
device major-minor numbers by these lines:
  DEV=$(readlink ${resume})
  DEV=/sys/class/block/${DEV##*/}/dev
  if [ -r "$DEV" ]; then
  read MAJMIN < "$DEV"
  fi

  4) next check fails and resume process silently aborts:
  if [ -z "$MAJMIN" ]; then
  exit 1
  fi

  Resuming script fails to get device major-minor because
  resume=UUID=106238b0-707d-4422-866d-a7534da50702 -- it's not resolved
  into device path in init script.

  Commonly mentioned workaround is to explicitly specify kernel
  parameter resume=UUID=106238b0-707d-4422-866d-a7534da50702 -- only in
  this case init script resolves it to device path.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: initramfs-tools 0.130ubuntu3
  Uname: Linux 4.16.6-041606-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat May  5 11:32:31 2018
  InstallationDate: Installed on 2018-03-27 (38 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180327)
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1769297/+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 1779767] Re: Default cron PATH does not include /snap/bin

[Dimitri John Ledkov]

I believe this will be fixed in v2.41 snapd.

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

Title:
  Default cron PATH does not include /snap/bin

Status in cron package in Ubuntu:
  Confirmed

Bug description:
  I recently changed from a .deb install of LXD to a snap, and was
  surprised that one of my crontab scripts stopped working.

  I see that $PATH in a cron script only contains "/usr/bin:/bin",
  whereas my default shell also includes "/snap/bin".

  It seems to me that for the best user experience with snaps,
  "/snap/bin" should be part of the default $PATH in cron.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cron 3.0pl1-128.1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_40 
kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_39 
livepatch_livepatch_Ubuntu_4_15_0_20_21_generic_ zfs zunicode zavl icp zcommon 
znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Jul  2 14:30:06 2018
  InstallationDate: Installed on 2017-12-20 (194 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171219)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: cron
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1779767/+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 1779767] Re: Default cron PATH does not include /snap/bin

[Brian Murray]

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

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

Title:
  Default cron PATH does not include /snap/bin

Status in cron package in Ubuntu:
  Confirmed

Bug description:
  I recently changed from a .deb install of LXD to a snap, and was
  surprised that one of my crontab scripts stopped working.

  I see that $PATH in a cron script only contains "/usr/bin:/bin",
  whereas my default shell also includes "/snap/bin".

  It seems to me that for the best user experience with snaps,
  "/snap/bin" should be part of the default $PATH in cron.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cron 3.0pl1-128.1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_40 
kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_39 
livepatch_livepatch_Ubuntu_4_15_0_20_21_generic_ zfs zunicode zavl icp zcommon 
znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Jul  2 14:30:06 2018
  InstallationDate: Installed on 2017-12-20 (194 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171219)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: cron
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1779767/+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 1845190] Re: binutils nm wrong output format breaks i386 nm work

[Dimitri John Ledkov]

I think this should land in Ubuntu as part of a regular snapshot upload
of binutils. I.e. without any special cherrypicking.

This may or might not be fixed in Eoan or f-cycle.

** Changed in: binutils (Ubuntu)
   Importance: High => Wishlist

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

Title:
  binutils nm wrong output format breaks i386 nm work

Status in binutils:
  Fix Released
Status in binutils package in Ubuntu:
  Confirmed

Bug description:
  discovered with diffoscope autopkgregression, looks like a real bug, based on
  https://salsa.debian.org/reproducible-builds/diffoscope/issues/69

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1845190/+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 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

[Colin Ian King]

See: https://github.com/lxc/lxd/issues/4656#issuecomment-535531229

In https://github.com/lxc/lxd/blob/master/lxd/storage_zfs_utils.go#L255
the umount is done by

err := unix.Unmount(mountpoint, unix.MNT_DETACH)

The umount2(2) manpage writes about MNT_DETACH:

Perform a lazy unmount: make the mount point unavailable for new
accesses, immediately disconnect the filesystem and all filesystems
mounted below it from each other and from the mount table, and actually
perform the unmount when the mount point ceases to be busy.

Could this be it? The MNT_DETACH umount looks partially asynchronous.
All the subsequent destroy commands may fail because they keep the mount
point busy. Finally the retry loop ends, the umount happens for real and
the following destroy succeeds.

—

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

Title:
  lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

Status in linux package in Ubuntu:
  Triaged
Status in lxc package in Ubuntu:
  Confirmed
Status in linux source package in Cosmic:
  Triaged
Status in lxc source package in Cosmic:
  Confirmed
Status in linux source package in Disco:
  New
Status in lxc source package in Disco:
  New
Status in linux source package in Eoan:
  Triaged
Status in lxc source package in Eoan:
  Confirmed

Bug description:
  I'm not sure exactly what got me into this state, but I have several
  lxc containers that cannot be deleted.

  $ lxc info
  
  api_status: stable
  api_version: "1.0"
  auth: trusted
  public: false
  auth_methods:
  - tls
  environment:
addresses: []
architectures:
- x86_64
- i686
certificate: |
  -BEGIN CERTIFICATE-
  
  -END CERTIFICATE-
certificate_fingerprint: 
3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb
driver: lxc
driver_version: 3.0.1
kernel: Linux
kernel_architecture: x86_64
kernel_version: 4.15.0-23-generic
server: lxd
server_pid: 15123
server_version: "3.2"
storage: zfs
storage_version: 0.7.5-1ubuntu15
server_clustered: false
server_name: milhouse

  $ lxc delete --force b1
  Error: Failed to destroy ZFS filesystem: cannot destroy 
'default/containers/b1': dataset is busy

  Talking in #lxc-dev, stgraber and sforeshee provided diagnosis:

   | short version is that something unshared a mount namespace causing
   | them to get a copy of the mount table at the time that dataset was
   | mounted, which then prevents zfs from being able to destroy it)

  The work around provided was

   | you can unstick this particular issue by doing:
   |  grep default/containers/b1 /proc/*/mountinfo
   | then for any of the hits, do:
   |   nsenter -t PID -m -- umount 
/var/snap/lxd/common/lxd/storage-pools/default/containers/b1
   | then try the delete again

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: linux-image-4.15.0-23-generic 4.15.0-23.25
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  smoser31412 F pulseaudio
   /dev/snd/controlC2:  smoser31412 F pulseaudio
   /dev/snd/controlC0:  smoser31412 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 28 10:42:45 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (1071 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  MachineType: 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-23-generic N/A
   linux-backports-modules-4.15.0-23-generic  N/A
   linux-firmware 1.174
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/09/2015
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355
  dmi.board.asset.tag: �
  dmi.board.name: NUC5i5RYB
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H40999-503
  dmi.chassis.asset.tag: �
  dmi.chassis.type: 3
  dmi.chassis.vendor: �
  dmi.chassis.version: 

[Touch-packages] [Bug 1822118] Re: Kernel Panic while rebooting cloud instance

[Colin Ian King]

I kicked off another ~20K reboot tests with Standard_B2S instances and
hit hangs again:

IP addr Mac AddrKernel  Reboots
104.42.3.16100:0d:3a:37:82:ee   5.0.0-1020-azure100
13.91.5.23  00:0d:3a:5a:74:23   5.0.0-1020-azure57   [ HANG ]
13.91.5.222 00:0d:3a:5a:75:1a   5.0.0-1020-azure100
13.64.117.146   00:0d:3a:5a:74:da   5.0.0-1020-azure100
13.64.117.1700:0d:3a:37:67:0e   5.0.0-1020-azure100
13.91.6.207 00:0d:3a:3a:cc:2c   5.0.0-1020-azure100
40.78.30.12900:0d:3a:36:6e:eb   5.0.0-1020-azure100
104.210.36.238  00:0d:3a:5a:73:da   5.0.0-1020-azure100
13.91.6.143 00:0d:3a:3a:c8:ec   5.0.0-1020-azure100
40.83.249.5800:0d:3a:3a:c0:7a   5.0.0-1020-azure100
104.45.216.53   00:0d:3a:3b:8a:55   5.0.0-1020-azure100
104.210.42.18   00:0d:3a:5a:73:5c   5.0.0-1020-azure100
40.78.27.21 00:0d:3a:3a:c9:19   5.0.0-1020-azure100
40.83.252.110   00:0d:3a:5a:79:93   5.0.0-1020-azure100
13.64.119.204   00:0d:3a:5a:7e:bc   5.0.0-1020-azure100

104.210.34.400:0d:3a:31:18:ee   5.0.0-1020-azure250
138.91.197.202  00:0d:3a:31:1d:c1   5.0.0-1020-azure94   [ HANG ]
138.91.196.241  00:0d:3a:31:15:2b   5.0.0-1020-azure250
104.210.33.44   00:0d:3a:31:16:f3   5.0.0-1020-azure250
40.83.248.7600:0d:3a:32:af:a7   5.0.0-1020-azure250
40.83.253.204   00:0d:3a:32:ba:09   5.0.0-1020-azure250
168.62.202.800:0d:3a:32:a0:11   5.0.0-1020-azure250
40.83.249.8 00:0d:3a:32:bd:ce   5.0.0-1020-azure250
40.83.249.9300:0d:3a:32:b7:32   5.0.0-1020-azure250
40.83.253.187   00:0d:3a:32:b9:cd   5.0.0-1020-azure250
23.99.9.88  00:0d:3a:37:96:c9   5.0.0-1020-azure250
104.40.29.184   00:0d:3a:36:9f:e0   5.0.0-1020-azure250
137.135.40.122  00:0d:3a:36:9f:eb   5.0.0-1020-azure250
137.135.49.43   00:0d:3a:36:92:aa   5.0.0-1020-azure250
138.91.251.800:0d:3a:37:9e:ef   5.0.0-1020-azure250

13.64.146.175   00:0d:3a:31:de:ee   5.0.0-1020-azure500
104.42.23.145   00:0d:3a:31:da:d7   5.0.0-1020-azure500
104.42.29.9900:0d:3a:31:d4:4f   5.0.0-1020-azure500
40.78.106.1200:0d:3a:31:d9:8a   5.0.0-1020-azure500
138.91.233.210  00:0d:3a:31:df:84   5.0.0-1020-azure500
104.42.25.3000:0d:3a:31:c9:a4   5.0.0-1020-azure500
13.64.150.6900:0d:3a:31:dd:47   5.0.0-1020-azure321   [ HANG ]
104.42.25.2300:0d:3a:31:d3:c9   5.0.0-1020-azure500
104.42.24.176   00:0d:3a:31:d8:36   5.0.0-1020-azure500
13.64.79.13300:0d:3a:31:d5:b4   5.0.0-1020-azure500
104.42.29.146   00:0d:3a:31:de:73   5.0.0-1020-azure500
104.42.19.191   00:0d:3a:31:d4:78   5.0.0-1020-azure500
40.118.249.118  00:0d:3a:31:db:20   5.0.0-1020-azure500
40.112.219.112  00:0d:3a:31:dc:da   5.0.0-1020-azure500
104.42.17.115   00:0d:3a:31:d3:21   5.0.0-1020-azure500
40.83.212.164   00:0d:3a:5a:ab:48   5.0.0-1020-azure500
52.160.123.400:0d:3a:36:0d:6a   5.0.0-1020-azure500
52.160.83.3700:0d:3a:5a:ab:79   5.0.0-1020-azure500
52.160.122.92   00:0d:3a:36:00:4c   5.0.0-1020-azure500
52.160.122.71   00:0d:3a:36:0f:bd   5.0.0-1020-azure500
52.160.123.12   00:0d:3a:36:04:39   5.0.0-1020-azure500
104.210.60.218  00:0d:3a:36:b6:25   5.0.0-1020-azure500
52.160.123.221  00:0d:3a:5a:a9:a3   5.0.0-1020-azure500
52.160.123.234  00:0d:3a:5a:a7:1c   5.0.0-1020-azure500
104.210.61.139  00:0d:3a:37:b7:84   5.0.0-1020-azure500
104.210.61.43   00:0d:3a:36:b5:96   5.0.0-1020-azure500
40.83.212.185   00:0d:3a:5a:af:9c   5.0.0-1020-azure500
52.160.82.111   00:0d:3a:5a:a9:a9   5.0.0-1020-azure500
52.160.82.167   00:0d:3a:5a:a7:17   5.0.0-1020-azure500
104.210.61.135  00:0d:3a:36:b3:97   5.0.0-1020-azure500

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

Title:
  Kernel Panic while rebooting cloud instance

Status in linux-azure package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  Description:   In the event a particular Azure cloud instance is
  rebooted it's possible that it may never recover and the instance will
  break indefinitely.

  In My case, it was a kernel panic. See specifics below..

  
  Series: Disco
  Instance Size: Basic_A3
  Region: (Default) US-WEST-2
  Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Th

[Touch-packages] [Bug 1822118] Re: Kernel Panic while rebooting cloud instance

[Colin Ian King]

So the best way to reproduce this issue is to run ~500 reboots across
multiple instances rather than 5000-1 reboots on once instance.

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

Title:
  Kernel Panic while rebooting cloud instance

Status in linux-azure package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  Description:   In the event a particular Azure cloud instance is
  rebooted it's possible that it may never recover and the instance will
  break indefinitely.

  In My case, it was a kernel panic. See specifics below..

  
  Series: Disco
  Instance Size: Basic_A3
  Region: (Default) US-WEST-2
  Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 
x86_64 x86_64 x86_64 GNU/Linux

  
  I had a simple script to reboot an instance (X) amount of times, I chose 50, 
so the machine would power cycle by issuing a "reboot" from the terminal prompt 
just as a user would.   Once the machine came up, it captured dmesg and other 
bits then rebooted again until it reached 50. 

  After the 4th attempt, my script timed out, I took a look at the
  instance console log and the following displayed on the console.

  
  [  OK  ] Reached target Reboot.
  /shutdown: error while loading shared libra[   89.498980] Kernel panic - not 
syncing: Attempted to kill init! exitcode=0x7f00
  [   89.498980]
  [   89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure 
#13-Ubuntu
  [   89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090007  06/02/2017
  [   89.508026] Call Trace:
  [   89.508026]  dump_stack+0x63/0x8a
  [   89.508026]  panic+0xe7/0x247
  [   89.508026]  do_exit.cold.23+0x26/0x75
  [   89.508026]  do_group_exit+0x43/0xb0
  [   89.508026]  __x64_sys_exit_group+0x18/0x20
  [   89.508026]  do_syscall_64+0x5a/0x110
  [   89.508026]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [   89.508026] RIP: 0033:0x7f7bf0154d86
  [   89.508026] Code: Bad RIP value.
  [   89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 
00e7
  [   89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 
7f7bf0154d86
  [   89.508026] RDX: 007f RSI: 003c RDI: 
007f
  [   89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: 

  [   89.508026] R10: 7ffd6be6974c R11: 0206 R12: 
0018
  [   89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: 

  [   89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation 
range: 0x8000-0xbfff)
  [   89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
  [   89.508026]  ]---

  
  this only occurred once in my testing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1845494] Re: gdb 8.1-0ubuntu3.1 freezes before call main function while debugging 32bit application

[Wladyslaw Ostrowski]

Workaround is to hold previous gdb version in apt.

apt purge gdb
apt install gdb=8.1-0ubuntu3
echo "gdb hold" | sudo dpkg --set-selections

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

Title:
  gdb 8.1-0ubuntu3.1 freezes before call main function while debugging
  32bit application

Status in gdb package in Ubuntu:
  New

Bug description:
  gdb 8.1ubuntu3.1 run binary 64bit without problem.
  If compile for 32bit target (g++ -m32 ..) then it can't load libraries
  before call main(), i mean it gets frozen.
  gdb 8.1-0ubuntu3 works with 32 and 64 bit binaries without problem.

  Here is log:
  g++ -m32 -o test test.cpp
  gdb ./test

  GNU gdb (Ubuntu 8.1-0ubuntu3.1) 8.1.0.20180409-git
  Copyright (C) 2018 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./test...(no debugging symbols found)...done.
  (gdb) run
  Starting program: /tmp/test
  warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
  warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
  warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
  warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
  warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
  warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
  warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.
  exit()
  ^C
  Program received signal SIGINT, Interrupt.
  0xf7fd9be0 in ?? () from /lib/ld-linux.so.2

  lsb_release -a
  Distributor ID:   Ubuntu
  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04
  Codename: bionic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1845494/+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 1845494] [NEW] gdb 8.1-0ubuntu3.1 freezes before call main function while debugging 32bit application

[Wladyslaw Ostrowski]

Public bug reported:

gdb 8.1ubuntu3.1 run binary 64bit without problem.
If compile for 32bit target (g++ -m32 ..) then it can't load libraries
before call main(), i mean it gets frozen.
gdb 8.1-0ubuntu3 works with 32 and 64 bit binaries without problem.

Here is log:
g++ -m32 -o test test.cpp
gdb ./test

GNU gdb (Ubuntu 8.1-0ubuntu3.1) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...(no debugging symbols found)...done.
(gdb) run
Starting program: /tmp/test
warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.
exit()
^C
Program received signal SIGINT, Interrupt.
0xf7fd9be0 in ?? () from /lib/ld-linux.so.2

lsb_release -a
Distributor ID: Ubuntu
Description:Ubuntu 18.04.3 LTS
Release:18.04
Codename:   bionic

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

** Summary changed:

- 8.1-0ubuntu3.1 freezes before call main function while debugging 32bit 
application
+ gdb 8.1-0ubuntu3.1 freezes before call main function while debugging 32bit 
application

** Description changed:

  gdb 8.1ubuntu3.1 run binary 64bit without problem.
  If compile for 32bit target (g++ -m32 ..) then it can't load libraries
  before call main(), i mean it gets frozen.
+ gdb 8.1-0ubuntu3 works without problem.
+ 
  Here is log:
- 
  g++ -m32 -o test test.cpp
  gdb ./test
  
  GNU gdb (Ubuntu 8.1-0ubuntu3.1) 8.1.0.20180409-git
  Copyright (C) 2018 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./test...(no debugging symbols found)...done.
  (gdb) run
- Starting program: /tmp/test 
+ Starting program: /tmp/test
  warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
  warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
  warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
  warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
  warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
  warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
  warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.
  exit()
  ^C
  Program received signal SIGINT, Interrupt.
  0xf7fd9be0 in ?? () from /lib/ld-linux.so.2
  
  lsb_release -a
  Distributor ID:   Ubuntu
  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04
  Codename: bionic

** Description changed:

  gdb 8.1ubuntu3.1 run binary 64bit without problem.
  If compile for 32bit target (g++ -m32 ..) then it can't load libraries
  before call main(), i mean it gets frozen.
- gdb 8.1-0ubuntu3 works without problem.
+ gdb 8.1-0ubuntu3 works with 32 and 64 bit binaries without problem.
  
  Here is log:
  g++ -m32 -o test test.cpp
  gdb ./test
  
  GNU gdb (Ubuntu 8.1-0ubuntu3.1) 8.1.0.20180409-git
  Copyright (C) 2018 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-linux-gnu".
  Type "show configuration" for configurati

[Touch-packages] [Bug 1825420] Re: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to install/upgrade: triggers looping, abandoned

[Brian Murray]

I tested an upgrade from Ubuntu 18.10 to Ubuntu 19.04 today with some of
the packages from the DuplicateSignature.txt installed e.g.:

Start-Date: 2019-09-25  17:14:37
Commandline: apt-get install bamfdaemon mime-support
Requested-By: bdmurray (1000)
Install: bamfdaemon:amd64 (0.5.3+18.04.20180207.2-0ubuntu1), libbamf3-2:amd64 
(0.5.3+18.04.20180207.2-0ubuntu1, automatic)
End-Date: 2019-09-25  17:14:38

Start-Date: 2019-09-25  17:15:21
Commandline: apt-get install libvlc-bin gnome-icon-theme hicolor-icon-theme
Requested-By: bdmurray (1000)
Install: gnome-icon-theme:amd64 (3.12.0-3), libvlc5:amd64 (3.0.4-2build1, 
automatic), libvlccore9:amd64 (3.0.4-2build1, automatic), libvlc-bin:amd64 
(3.0.4-2build1), libproxy-tools:amd64 (0.4.15-2, automatic)
End-Date: 2019-09-25  17:15:29

The upgraded proceeded without issue and I did not encounter any issues
with triggers looping.

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

Title:
  package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to
  install/upgrade: triggers looping, abandoned

Status in Ubuntu MATE:
  Invalid
Status in bamf package in Ubuntu:
  Confirmed
Status in dpkg package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in linux-firmware package in Ubuntu:
  Confirmed
Status in mime-support package in Ubuntu:
  Confirmed

Bug description:
  Steps to reproduce:
  1. Have Ubuntu 18.10 installed
  2. Install all updates to it
  3. Switch to Main server
  4. Launch update-manager
  5. Confirm upgrading to 19.04
  6. Wait for upgrade process to finish

  Expected results:
  * upgrade process ended without errors

  Actual results:
  * upgrade process ended with warning message:

  Could not install 'linux-image-5.0.0-13-generic'
  The upgrade will continue but the 'linux-image-5.0.0-13-generic' package 
may not be in a working state. Please consider submitting a bug report about it.

  triggers looping, abandoned

  Workaround:

Run recommended `dpkg --configure -a` before actual reboot.

  System info: running VirtualBox guest with virtualbox-guest-x11
  (6.0.6-dfsg-1) inside VirtualBox 5.1.38 host.

  ProblemType: Package
  DistroRelease: Ubuntu 19.04
  Package: linux-image-5.0.0-13-generic 5.0.0-13.14
  ProcVersionSignature: Ubuntu 4.18.0-17.18-generic 4.18.20
  Uname: Linux 4.18.0-17-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  mate   1542 F pulseaudio
  Date: Thu Apr 18 22:56:56 2019
  ErrorMessage: triggers looping, abandoned
  InstallationDate: Installed on 2019-02-17 (60 days ago)
  InstallationMedia: Ubuntu-MATE 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.2)
  IwConfig:
   lono wireless extensions.
   
   enp0s3no wireless extensions.
  Lsusb:
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet
   Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  MachineType: innotek GmbH VirtualBox
  ProcFB: 0 vboxdrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-17-generic 
root=UUID=01417e27-d554-4ce8-91bc-1dda8392c976 ro quiet splash
  PulseList:
   Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not 
accessible: Permission denied
   No PulseAudio daemon running, or not running as session daemon.
  Python3Details: /usr/bin/python3.7, Python 3.7.3, python3-minimal, 3.7.3-1
  PythonDetails: /usr/bin/python2.7, Python 2.7.16, python-minimal, 2.7.16-1
  RelatedPackageVersions: grub-pc 2.02+dfsg1-12ubuntu2
  RfKill:
   
  SourcePackage: linux
  StagingDrivers: vboxvideo
  Title: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to 
install/upgrade: triggers looping, abandoned
  UpgradeStatus: Upgraded to disco on 2019-04-18 (0 days ago)
  dmi.bios.date: 12/01/2006
  dmi.bios.vendor: innotek GmbH
  dmi.bios.version: VirtualBox
  dmi.board.name: VirtualBox
  dmi.board.vendor: Oracle Corporation
  dmi.board.version: 1.2
  dmi.chassis.type: 1
  dmi.chassis.vendor: Oracle Corporation
  dmi.modalias: 
dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:
  dmi.product.family: Virtual Machine
  dmi.product.name: VirtualBox
  dmi.product.version: 1.2
  dmi.sys.vendor: innotek GmbH

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-mate/+bug/1825420/+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 1845337] Re: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service

[Christian Ehrhardt ]

Great, thanks Stephane for confirming that.

@Rbalinx / @xnox - would you want to fix that up as part of the next
systemd upload to Disco then?

Until then we could mark it badtest on armhf as that reflects the
current state correctly and unblocks others until fixed.

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

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in qemu source package in Disco:
  New
Status in systemd source package in Disco:
  New

Bug description:
  Since the recent few weeks systemd autopkgtest @ armhf @ disco fail
  [1].

  The log is very (very) long and partially interwoven due to concurrent 
execution.
  Somewhere in between we see this subcase is the one failing: root-unittests
  Of this test (which again has many subtests) it is: test-execute
  And of this again it is (always):

  I'll attach bad and good case full and stripped logs.

  
  The diff of those comes down to just:
  1. execute a find in a shell
  2. shell exits
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=0/SUCCESS
  vs
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=1/FAILURE
  4. in the bad case that triggers an assertion
  The find that fails is:

  find / -path /var/tmp -o -path /tmp -o -path /proc -o -path
  /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf

  Good and bad case are the same most recent version
  systemd/240-6ubuntu5.7.

  Maybe something is bad in the containers we have for armhf in regard to these 
paths?
  Was there any change we'd know of?

  If there is nothing known, could we force-badtest it to get it out of
  the way of ongoing migrations?

  [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+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 1845337] Re: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service

[Stéphane Graber]

/dev/.lxc/* shows up when nesting is enabled, so that's indeed related
to the change Adam did.

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

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in qemu source package in Disco:
  New
Status in systemd source package in Disco:
  New

Bug description:
  Since the recent few weeks systemd autopkgtest @ armhf @ disco fail
  [1].

  The log is very (very) long and partially interwoven due to concurrent 
execution.
  Somewhere in between we see this subcase is the one failing: root-unittests
  Of this test (which again has many subtests) it is: test-execute
  And of this again it is (always):

  I'll attach bad and good case full and stripped logs.

  
  The diff of those comes down to just:
  1. execute a find in a shell
  2. shell exits
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=0/SUCCESS
  vs
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=1/FAILURE
  4. in the bad case that triggers an assertion
  The find that fails is:

  find / -path /var/tmp -o -path /tmp -o -path /proc -o -path
  /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf

  Good and bad case are the same most recent version
  systemd/240-6ubuntu5.7.

  Maybe something is bad in the containers we have for armhf in regard to these 
paths?
  Was there any change we'd know of?

  If there is nothing known, could we force-badtest it to get it out of
  the way of ongoing migrations?

  [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+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 1842643] Re: [ffe] Update to 1.44.6

[Sebastien Bacher]

(re-opening and tagging as blocked by ff for our tracking script)

** Changed in: pango1.0 (Ubuntu)
   Status: Won't Fix => Triaged

** Summary changed:

- [ffe] Update to 1.44.6
+ Don't update to 1.44.6 this cycle

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

Title:
  Don't update to 1.44.6 this cycle

Status in pango1.0 package in Ubuntu:
  Triaged

Bug description:
  There are a lot of changes in pango1.0 since the version we currently
  have in eoan. We held off updating because there was a test failure.
  This has been resolved in the latest release, so we'd like to go for
  the update now.

  Overview of changes in 1.44.6
  =
  - docs: Fix symbol indices
  - Fix Thai line breaking
  - Re-add symbols needed by some bindings
  - Don't insert hyphens for some languages
  - Fix a crash with hyphenation

  Overview of changes in 1.44.5
  =
  - Revert a broken change (causing crashes on OS X)

  Overview of changes in 1.44.4
  =
  - Add an insert-hyphens attribute
  - Reinstate the return type of pango_fc_font_lock_face
  - Fix a problem with ellipses getting the wrong font
  - fc: Improve filtering by font format
  - Re-add PangoFcFont to public headers
  - Install PangoFc and PangoOT introspection files
  - Fix ink rectangles to have positive height
  - Fix mark positioning
  - Switch to using harfbuzz for metrics

  Overview of changes in 1.44.3
  =
  - Install pango-ot headers
  - Make subpixel positioning optional
  - fc: Ignore fonts with unsupported formats

  Overview of changes in 1.44.2
  =
  - Disable ligatures when letterspacing
  - Set design coords on hb_font_t
  - Expose more font options in pango-view
  - OS X: Make 'system-ui' font work
  - Keep deprecated pango-fc apis in headers
  - Make hex boxes work, always
  - introspection: Various build fixes
  - introspection: Add PangoPT, PangoFT2 namespaces
  - layout: Make the new line-spacing opt-in

  Overview of changes in 1.44.1
  =
  - Fix a crash with allow_break attributes
  - Fix Emoji spacing
  - Fix up includes and pkg-config requires
  - Correct some cases for hyphen insertion

  Overview of changes in 1.44.0
  =
  - Use harfbuzz for shaping on all platforms
  - Stop using freetype for font loading; this
  drops support for type1 and bitmap fonts
  - Add a getter for hb_font_t
  - Make PangoCoverage a GObject
  - Add a pango_tailor_break api
  - font metrics: Add line height
  - layout: Support line spacing
  - layout: Draw hyphens for line breaks
  - Add an attribute to suppress line breaking
  - cairo: Don't render hex boxes for space
  - Add an attribute to show invisible characters
  - Stop quantizing glyph positions
  - Add tests for itemization and line breaking
  - Remove language and shape engine remnants
  - Rename meson options: gtk_doc, introspection
  - Require GLib 2.59.2
  - Require Harfbuzz 2.0

  Overview of changes in 1.43.0
  =
  - Drop autotools
  - Drop Visual Studio build
  - Build with meson everywhere
  - Update Emoji tables for Unicode 11
  - Update test data for Unicode 11
  - Fix a crash with Thai breaking
  - Fix a crash with font variations
  - Deprecate bidi apis in favor of fribidi
  - Add a variable font family api
  - Improve font fallback handling on win32

  And see posts from upstream

  https://blogs.gnome.org/mclasen/2019/07/19/pango-updates/
  https://blogs.gnome.org/mclasen/2019/07/27/more-text-rendering-updates/
  https://blogs.gnome.org/mclasen/2019/08/07/pango-1-44-wrap-up/

  for the new features.

  We'd like to update to it, if possible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/1842643/+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 1559245] Re: Pulseaudio selects HSP instead of A2DP and no way to set default action

[Launchpad Bug Tracker]

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

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

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

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

Title:
  Pulseaudio selects HSP instead of A2DP and no way to set default
  action

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  I am trying to use a bluetooth headphone with ubuntu 14.04 and system
  defaults to using HSP. The problem is that Once it connects, it should
  use A2DP and become default device because I am using it from KODI and
  it is very inconvenient to set it from command line. Otherwise HSP is
  providing very bad quality audio. There is no way to set a default
  action, and system does not retain the last set setting. Eg. I can go
  and set the headphones to use A2DP but when I connect next time, it
  switches back to HSP. (I believe it could remember the device from the
  device id at least!)

  I asked about this on launchpad answers and somebody closed it and said I 
should report it as a bug. If you think this shouldn't have been reported as a 
bug, blame the person who closed my question at launchpad answers :) Below is 
the link to it and more information and the ugly workaround I implemented in my 
system:
  https://answers.launchpad.net/ubuntu/+question/288799

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1559245/+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 1703194] Re: package snapd 2.25~14.04 failed to install/upgrade: подпроцесс установлен сценарий post-installation возвратил код ошибки 1

[John Lenton]

I suspect you've been able to resolve this, sorry we never got back to
you about it.

I'm closing it as "Won't fix", because we didn't do anything about this,
but if you're still stuck there's probably a cause for this that isn't
necessarily snapd itself and we can probably figure it out.

Again, sorry.


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

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

Title:
  package snapd 2.25~14.04 failed to install/upgrade: подпроцесс
  установлен сценарий post-installation возвратил код ошибки 1

Status in apport package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  Won't Fix

Bug description:
  Пытался откатиться с 16.04 до 14 путём выполнения команды sudo gedit
  /etc/apt/sources.list. не вышло. как быть?

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: snapd 2.25~14.04
  ProcVersionSignature: Ubuntu 4.4.0-83.106~14.04.1-generic 4.4.70
  Uname: Linux 4.4.0-83-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  Date: Sun Jul  9 16:18:43 2017
  ErrorMessage: подпроцесс установлен сценарий post-installation возвратил код 
ошибки 1
  InstallationDate: Installed on 2017-07-09 (0 days ago)
  InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.1
   apt  1.2.19
  SourcePackage: snapd
  Title: package snapd 2.25~14.04 failed to install/upgrade: подпроцесс 
установлен сценарий post-installation возвратил код ошибки 1
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1703194/+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 1769941] Re: grep fails to match an empty line using perl regexp if it's the last line in a file

[Andrew McCarthy]

I can't identify when it was fixed, but can confirm this is not
happening any more in grep 3.1-2build1 in Ubuntu 18.04.

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

Title:
  grep fails to match an empty line using perl regexp if it's the last
  line in a file

Status in grep package in Ubuntu:
  New

Bug description:
  1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> 
About Ubuntu
  Description:  Ubuntu 16.04.4 LTS
  Release:  16.04

  2) The version of the package you are using, via 'apt-cache policy pkgname' 
or by checking in Software Center
  grep:
Installed: 2.25-1~16.04.1
Candidate: 2.25-1~16.04.1
Version table:
   *** 2.25-1~16.04.1 500
  500 http://ru.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.24-1 500
  500 http://ru.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  3) What you expected to happen
  (echo 123; echo; ) | grep -P '^$'
  $ # output contains one empty line
  $ (echo 123; echo;) | grep -P '^$'

  $

  4) What happened instead
  $ # output contains no line
  $ (echo 123; echo;) | grep -P '^$'
  $

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: grep 2.25-1~16.04.1
  ProcVersionSignature: Ubuntu 4.13.0-38.43~16.04.1-generic 4.13.16
  Uname: Linux 4.13.0-38-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.16
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue May  8 18:49:45 2018
  InstallationDate: Installed on 2018-02-13 (83 days ago)
  InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 
(20170801)
  SourcePackage: grep
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1769941/+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 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)

[Christian Ehrhardt ]

If you are lazy to look for these commits, feel free to use these links
https://github.com/systemd/systemd/commit/7da377ef16a2112a673247b39041a180b07e973a
https://github.com/systemd/systemd/commit/95355a281c06c5970b7355c38b066910c3be4958
https://github.com/systemd/systemd/commit/db51778f85cb076e9ed1fe7f7e29cc740365c245
https://github.com/systemd/systemd/commit/c98d78d32abba6aadbe89eece7acf0742f59047c
https://github.com/systemd/systemd/commit/1e498853a39b46155cb89b5c9e74ecb27aaba3ed

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

Title:
  [master] Restarting systemd-networkd breaks keepalived, heartbeat,
  corosync, pacemaker (interface aliases are restarted)

Status in netplan:
  Confirmed
Status in heartbeat package in Ubuntu:
  Triaged
Status in keepalived package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  In Progress
Status in heartbeat source package in Bionic:
  Triaged
Status in keepalived source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in heartbeat source package in Disco:
  Triaged
Status in keepalived source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in heartbeat source package in Eoan:
  Triaged
Status in keepalived source package in Eoan:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth2:
  addresses:
- 12.13.14.18/29
- 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  version: 2

  Configure keepalived (again, a working config with IP addresses
  obfuscated)

  global_defs   # Block id
  {
  notification_email {
  sysadm...@blah.com
  }
  notification_email_from keepali...@system3.hq.blah.com
  smtp_server 10.22.11.7 # IP
  smtp_connect_timeout 30  # integer, seconds
  router_id system3  # string identifying the machine,
   # (doesn't have to be hostname).
  vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
  vrrp_mcast_group6 ff02::12   # optional, default ff02::12
  enable_traps # enable SNMP traps
  }
  vrrp_sync_group collection {
  group {
  wan
  lan
  phone
  }
  vrrp_instance wan {
  state MASTER
  interface eth2
  virtual_router_id 77
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass BlahBlah
  }
  virtual_ipaddress {
  12.13.14.20
  }
  }
  vrrp_instance lan {
  state MASTER
  interface eth3
  virtual_router_id 78
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass MoreBlah
  }
  virtual_ipaddress {
  10.22.11.13/24
  }
  }
  vrrp_instance phone {
  state MASTER
  interface eth4
  virtual_router_id 79
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass MostBlah
  }
  virtual_ipaddress {
  10.22.14.3/24
  }
  }

  At boot the affected interfaces have:
  5: eth4:  mtu 1500 qdisc mq state UP group 
default qlen 1000
  link/ethe

[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)

[Rafael David Tinoco]

The commits bellow implement support to "keep configuration":

commit 1e498853a39b46155cb89b5c9e74ecb27aaba3ed
Author: Yu Watanabe 
Date:   Mon Jun 3 01:21:13 2019

test-network: add tests for KeepConfiguration=

commit c98d78d32abba6aadbe89eece7acf0742f59047c
Author: Yu Watanabe 
Date:   Mon Jun 3 03:37:25 2019

man: add documentation about KeepConfiguration

commit db51778f85cb076e9ed1fe7f7e29cc740365c245
Author: Yu Watanabe 
Date:   Mon Jun 3 00:33:13 2019

network: make KeepConfiguration=static drop DHCP addresses and routes

Also, KeepConfiguration=dhcp drops static foreign addresses and routes.

commit 95355a281c06c5970b7355c38b066910c3be4958
Author: Yu Watanabe 
Date:   Mon Jun 3 14:05:26 2019

network: add KeepConfiguration=dhcp-on-stop

The option prevents to drop lease address on stop.
By setting this, we can safely restart networkd.

commit 7da377ef16a2112a673247b39041a180b07e973a
Author: Susant Sahani 
Date:   Mon Jun 3 00:31:13 2019

networkd: add support to keep configuration

for systemd-networkd.

IMO, we should rely in setting the keep configuration flag for the
interfaes to be managed by 3rd part software (adding/removing aliases
for virtual networks, VRRP interfaces, etc).

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

Title:
  [master] Restarting systemd-networkd breaks keepalived, heartbeat,
  corosync, pacemaker (interface aliases are restarted)

Status in netplan:
  Confirmed
Status in heartbeat package in Ubuntu:
  Triaged
Status in keepalived package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  In Progress
Status in heartbeat source package in Bionic:
  Triaged
Status in keepalived source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in heartbeat source package in Disco:
  Triaged
Status in keepalived source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in heartbeat source package in Eoan:
  Triaged
Status in keepalived source package in Eoan:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth2:
  addresses:
- 12.13.14.18/29
- 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  version: 2

  Configure keepalived (again, a working config with IP addresses
  obfuscated)

  global_defs   # Block id
  {
  notification_email {
  sysadm...@blah.com
  }
  notification_email_from keepali...@system3.hq.blah.com
  smtp_server 10.22.11.7 # IP
  smtp_connect_timeout 30  # integer, seconds
  router_id system3  # string identifying the machine,
   # (doesn't have to be hostname).
  vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
  vrrp_mcast_group6 ff02::12   # optional, default ff02::12
  enable_traps # enable SNMP traps
  }
  vrrp_sync_group collection {
  group {
  wan
  lan
  phone
  }
  vrrp_instance wan {
  state MASTER
  interface eth2
  virtual_router_id 77
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass BlahBlah
  }
  virtual_ipaddress {
  12.13.14.20
  }
  }
  vrrp_instance lan {
  state MASTER
  interface eth3

[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)

[Rafael David Tinoco]

** Summary changed:

- [master] Restarting systemd-networkd breaks keepalived clusters
+ [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, 
pacemaker (interface aliases are restarted)

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

Title:
  [master] Restarting systemd-networkd breaks keepalived, heartbeat,
  corosync, pacemaker (interface aliases are restarted)

Status in netplan:
  Confirmed
Status in heartbeat package in Ubuntu:
  Triaged
Status in keepalived package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  In Progress
Status in heartbeat source package in Bionic:
  Triaged
Status in keepalived source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed
Status in heartbeat source package in Disco:
  Triaged
Status in keepalived source package in Disco:
  Confirmed
Status in systemd source package in Disco:
  Confirmed
Status in heartbeat source package in Eoan:
  Triaged
Status in keepalived source package in Eoan:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth2:
  addresses:
- 12.13.14.18/29
- 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  version: 2

  Configure keepalived (again, a working config with IP addresses
  obfuscated)

  global_defs   # Block id
  {
  notification_email {
  sysadm...@blah.com
  }
  notification_email_from keepali...@system3.hq.blah.com
  smtp_server 10.22.11.7 # IP
  smtp_connect_timeout 30  # integer, seconds
  router_id system3  # string identifying the machine,
   # (doesn't have to be hostname).
  vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
  vrrp_mcast_group6 ff02::12   # optional, default ff02::12
  enable_traps # enable SNMP traps
  }
  vrrp_sync_group collection {
  group {
  wan
  lan
  phone
  }
  vrrp_instance wan {
  state MASTER
  interface eth2
  virtual_router_id 77
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass BlahBlah
  }
  virtual_ipaddress {
  12.13.14.20
  }
  }
  vrrp_instance lan {
  state MASTER
  interface eth3
  virtual_router_id 78
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass MoreBlah
  }
  virtual_ipaddress {
  10.22.11.13/24
  }
  }
  vrrp_instance phone {
  state MASTER
  interface eth4
  virtual_router_id 79
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass MostBlah
  }
  virtual_ipaddress {
  10.22.14.3/24
  }
  }

  At boot the affected interfaces have:
  5: eth4:  mtu 1500 qdisc mq state UP group 
default qlen 1000
  link/ether ab:cd:ef:90:c0:e3 brd ff:ff:ff:ff:ff:ff
  inet 10.22.14.6/24 brd 10.22.14.255 scope global eth4
 valid_lft forever preferred_lft forever
  inet 10.22.14.3/24 scope global secondary eth4
 valid_lft forever preferred_lft forever
  inet6 fe80::ae1f:

[Touch-packages] [Bug 1845337] Re: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service

[Christian Ehrhardt ]

Thanks Dan for going deeper on these logs - interesting path differences
that you have spotted!

Thanks Laney for the info on recent changes!

I subscribed stgraber and will give him and the other LXD folks a ping
to chime in here if the mentioned configs/updates ring a bell in regard
to the paths that were identified to be changing between good/bad case.

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

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in qemu source package in Disco:
  New
Status in systemd source package in Disco:
  New

Bug description:
  Since the recent few weeks systemd autopkgtest @ armhf @ disco fail
  [1].

  The log is very (very) long and partially interwoven due to concurrent 
execution.
  Somewhere in between we see this subcase is the one failing: root-unittests
  Of this test (which again has many subtests) it is: test-execute
  And of this again it is (always):

  I'll attach bad and good case full and stripped logs.

  
  The diff of those comes down to just:
  1. execute a find in a shell
  2. shell exits
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=0/SUCCESS
  vs
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=1/FAILURE
  4. in the bad case that triggers an assertion
  The find that fails is:

  find / -path /var/tmp -o -path /tmp -o -path /proc -o -path
  /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf

  Good and bad case are the same most recent version
  systemd/240-6ubuntu5.7.

  Maybe something is bad in the containers we have for armhf in regard to these 
paths?
  Was there any change we'd know of?

  If there is nothing known, could we force-badtest it to get it out of
  the way of ongoing migrations?

  [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+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 1845337] Re: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service

[Iain Lane]

Hey thanks for subscribing me!

We haven't had an LXD update recently (the instances are using LXD from
bionic-updates and that's not been changed for a long time). The only
things I can think of is that Adam recently deployed a config change to
set 'security.nesting=true' on our instances (https://git.launchpad.net
/autopkgtest-cloud/commit/?id=b8c9165686c7598b3f1a68aa4684e7f382ad935c),
and we recently (last week, while in Paris) dist-upgraded and rebooted
them all to pick up a newer kernel (4.15.0-62-generic).

I'm not sure if either of these changes might relate to what you're
seeing here - my first suggestion would be talk to the LXD team? If you
need help connecting with them, please let me know. Hope that helps.

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

Title:
  Disco autopkgtest @ armhf fails root-unittests -> test-execute ->
  exec-dynamicuser-statedir.service

Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in qemu source package in Disco:
  New
Status in systemd source package in Disco:
  New

Bug description:
  Since the recent few weeks systemd autopkgtest @ armhf @ disco fail
  [1].

  The log is very (very) long and partially interwoven due to concurrent 
execution.
  Somewhere in between we see this subcase is the one failing: root-unittests
  Of this test (which again has many subtests) it is: test-execute
  And of this again it is (always):

  I'll attach bad and good case full and stripped logs.

  
  The diff of those comes down to just:
  1. execute a find in a shell
  2. shell exits
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=0/SUCCESS
  vs
  3. exec-dynamicuser-statedir.service: Main process exited, code=exited, 
status=1/FAILURE
  4. in the bad case that triggers an assertion
  The find that fails is:

  find / -path /var/tmp -o -path /tmp -o -path /proc -o -path
  /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf

  Good and bad case are the same most recent version
  systemd/240-6ubuntu5.7.

  Maybe something is bad in the containers we have for armhf in regard to these 
paths?
  Was there any change we'd know of?

  If there is nothing known, could we force-badtest it to get it out of
  the way of ongoing migrations?

  [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+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 1222602] Re: [regression] [gen3] Mesa 9.2 makes Unity unusable on Atom class hardware and 943/945 graphics controllers

[Bug Watch Updater]

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

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

Title:
  [regression] [gen3] Mesa 9.2 makes Unity unusable on Atom class
  hardware and 943/945 graphics controllers

Status in Mesa:
  New
Status in Nux:
  Fix Released
Status in Release Notes for Ubuntu:
  Invalid
Status in mesa package in Ubuntu:
  Fix Released
Status in nux package in Ubuntu:
  Fix Released
Status in unity package in Ubuntu:
  Invalid

Bug description:
  After the upgrade to Mesa 9.2.0 unity is barely usable.
  Dash, Alt+Tab switcher and Alt+F2 command line shows in more than 1 minute, 
using 100% cpu.

  A downgrade to mesa 9.1.6-2ubuntu2 restores full performance.

  ProblemType: Bug
  DistroRelease: Ubuntu 13.10
  Package: libgl1-mesa-glx 9.2-1ubuntu1
  ProcVersionSignature: Ubuntu 3.11.0-5.11-generic 3.11.0
  Uname: Linux 3.11.0-5-generic i686
  .tmp.unity.support.test.0:
   
  ApportVersion: 2.12.1-0ubuntu3
  Architecture: i386
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: compiz
  CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
  CompositorUnredirectFSW: true
  Date: Mon Sep  9 01:51:45 2013
  DistUpgraded: 2013-09-08 20:36:47,811 DEBUG enabling apt cron job
  DistroCodename: saucy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Intel Corporation Mobile 945GSE Express Integrated Graphics Controller 
[8086:27ae] (rev 03) (prog-if 00 [VGA controller])
 Subsystem: Micro-Star International Co., Ltd. Device [1462:0110]
 Subsystem: Micro-Star International Co., Ltd. Device [1462:0110]
  InstallationDate: Installed on 2013-09-07 (1 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release i386 (20130424)
  MachineType: MICRO-STAR INTERNATIONAL CO., LTD U90/U100
  MarkForUpload: True
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=it_IT.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-5-generic 
root=UUID=674329c8-d0a6-4954-89c0-72821cfa0ba8 ro quiet splash vt.handoff=7
  SourcePackage: mesa
  UpgradeStatus: Upgraded to saucy on 2013-09-08 (0 days ago)
  dmi.bios.date: 12/01/2009
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.3
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: U90/U100
  dmi.board.vendor: MICRO-STAR INTERNATIONAL CO., LTD
  dmi.board.version: Ver.001
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 10
  dmi.chassis.vendor: MICRO-STAR INTERNATIONAL CO., LTD
  dmi.chassis.version: Ver.001
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.3:bd12/01/2009:svnMICRO-STARINTERNATIONALCO.,LTD:pnU90/U100:pvrVer.001:rvnMICRO-STARINTERNATIONALCO.,LTD:rnU90/U100:rvrVer.001:cvnMICRO-STARINTERNATIONALCO.,LTD:ct10:cvrVer.001:
  dmi.product.name: U90/U100
  dmi.product.version: Ver.001
  dmi.sys.vendor: MICRO-STAR INTERNATIONAL CO., LTD
  version.compiz: compiz 1:0.9.10+13.10.20130828.2-0ubuntu1
  version.libdrm2: libdrm2 2.4.46-1
  version.libgl1-mesa-dri: libgl1-mesa-dri 9.2-1ubuntu1
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 9.2-1ubuntu1
  version.xserver-xorg-core: xserver-xorg-core 2:1.14.2.901-2ubuntu4
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu3.1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.2.0-0ubuntu6
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.21.14-4ubuntu3
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.9-2ubuntu1
  xserver.bootTime: Mon Sep  9 01:46:55 2013
  xserver.configfile: default
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.outputs:
   product id1001 
   vendor HSD
  xserver.version: 2:1.14.2.901-2ubuntu4

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