[Touch-packages] [Bug 1928973] Re: Please merge lvm2 2.03.11-2.1 from Debian unstable

[Dave Jones]

Attaching patch against Debian unstable. For ease of review, I've also
pushed relevant commits and tags to the following repository:

  https://code.launchpad.net/~waveform/ubuntu/+source/lvm2/+git/lvm2

Specifically:

* logical/2.03.11-2ubuntu4 represents our split-out delta on top of old/debian 
(2.03.11-2)
* logical/2.03.11-2.1ubuntu1 represents our rebased delta on top of new/debian 
(2.03.11-2.1)
* merge/2.03.11-2.1ubuntu1 just adds the changelog and maintainer changes on 
top of logical/2.03.11-2.1ubuntu1

Hence, the following command may produce output useful to the purposes
of review:

  git range-diff old/debian..logical/2.03.11-2ubuntu4
new/debian..logical/2.03.11-2.1ubuntu1

A test package has been built in the following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/lvm2

** Patch added: "1-1928973.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1928973/+attachment/5498796/+files/1-1928973.debdiff

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

Title:
  Please merge lvm2 2.03.11-2.1 from Debian unstable

Status in lvm2 package in Ubuntu:
  New

Bug description:
  Please merge lvm2 2.03.11-2.1 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  below.

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

-- 
Mailing list: https://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 1928973] [NEW] Please merge lvm2 2.03.11-2.1 from Debian unstable

[Dave Jones]

Public bug reported:

Please merge lvm2 2.03.11-2.1 from Debian unstable.

Updated changelog and diff against Debian unstable to be attached below.

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

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

Title:
  Please merge lvm2 2.03.11-2.1 from Debian unstable

Status in lvm2 package in Ubuntu:
  New

Bug description:
  Please merge lvm2 2.03.11-2.1 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  below.

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

-- 
Mailing list: https://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 1927978] [NEW] Please merge db5.3 5.3.28+dfsg1-0.8 from Debian unstable

[Dave Jones]

Public bug reported:

Please merge db5.3 5.3.28+dfsg1-0.8 from Debian unstable.

Updated changelog and diff against Debian unstable to be attached below.

** Affects: db5.3 (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  Please merge db5.3 5.3.28+dfsg1-0.8 from Debian unstable

Status in db5.3 package in Ubuntu:
  New

Bug description:
  Please merge db5.3 5.3.28+dfsg1-0.8 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  below.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/db5.3/+bug/1927978/+subscriptions

-- 
Mailing list: https://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 1927978] Re: Please merge db5.3 5.3.28+dfsg1-0.8 from Debian unstable

[Dave Jones]

Attaching patch against Debian unstable. Test builds available from the
following PPA:

https://launchpad.net/~waveform/+archive/ubuntu/db/+packages

** Patch added: "1-1927978.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/db5.3/+bug/1927978/+attachment/5496169/+files/1-1927978.debdiff

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

Title:
  Please merge db5.3 5.3.28+dfsg1-0.8 from Debian unstable

Status in db5.3 package in Ubuntu:
  New

Bug description:
  Please merge db5.3 5.3.28+dfsg1-0.8 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  below.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/db5.3/+bug/1927978/+subscriptions

-- 
Mailing list: https://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 1922792] Re: Bluez should notify users when they need to reboot to apply changes on Raspberry Pi

[Dave Jones]

> Thanks for the details. You did address the part about upstreaming the
change to Debian. How important is that notification in practice? If
feels like we should have bluez preinstall on the raspi images if that's
not the case, and if it's pre-install is that really worth the packaging
overhead to have to carry a delta over Debian?

Just to give a bit of context here, the bluetooth situation on the pi is
somewhat complicated and there's compromises that we make between the
desktop and server images:

The bluetooth module on the Pi is controlled via a UART. Two UARTs are
available on the Pi (there's more on the Pi 4, but it's the same
situation for the bits we're talking about here):

* the PL011 which is full featured (buffers, flow-control, etc.), and

* the mini-UART which is ... not. Furthermore, the mini-UART's baud rate
is tied to the GPU's clock, so if that floats then the mini-UART's baud
rate floats too

On models of Pi with a bluetooth module (everything except the Pi 2, the
CM3/3+ and some models of the CM4), the PL011 is used to talk to the
bluetooth module and by default the mini-UART is disabled. This is the
configuration we use on the desktop images as we make the assumption a
serial console is less important on something which almost certainly has
a monitor, and this configuration permits the GPU clock to float
(important for something relying upon graphical acceleration).

On the server images, we assume that the serial console *is* important,
and so this is enabled by default. We don't *disable* the bluetooth
module, but we don't pre-install the packages for it either. This means
that the PL011 is tied to the bluetooth module by default (but unused),
and the mini-UART to the serial console. Because the mini-UART is in
use, the GPU's clock is locked to the base speed. This is a compromise
because all the alternatives are nastier in some way for some of the
typical use cases:

* If the server image is used without a graphical environment, and
without bluetooth, this is fine (this is the default). The GPU's clock
doesn't really matter in this scenario and the serial console will still
work reliably.

* If the server image is used without a graphical environment, but with
bluetooth, all the user needs to do is install pi-bluetooth and reboot
(personally I don't think the reboot warning is terribly necessary; like
knowing to install pi-bluetooth in the first place, it's fairly
widespread knowledge and tends to be part of first-time setup steps
anyway). This again leaves the GPU's clock locked (but without a
graphical environment that doesn't really matter), the serial console
still works, and bluetooth works.

* If the server image is used with a graphical environment, without
bluetooth, the user needs to either disable the serial console (if they
don't want it, this is a one-line change in the boot configuration), or
alternatively add the line "dtoverlay=disable-bt" to the boot
configuration which disables the bluetooth module entirely, allowing the
serial console to use the "full" PL011 UART. Either option unlocks the
GPU's clock.

* If the server image is used with a graphical environment, with
bluetooth, that's effectively the same as the desktop setup and we
assume that in this scenario the user would disable the serial console
(which means the mini-UART is no longer used and the GPU's clock can
float again); again, a one-line change in the boot configuration.

So the compromise is to ship an image which, with either zero steps or
one step can be moved to one of the scenarios above, with hardware
working acceptably for that scenario. We could default to, for example,
shipping the server image with both serial console *and* bluetooth
enabled, but that complicates moving to a GPU clock unlocked scenario as
it involves either disabling the serial console (easy) or removing
bluetooth (quite a bit harder, especially if the pi-bluetooth package is
now depended on by a meta-package, and also still involves disabling the
hardware module with the dtoverlay).

Anyway, for the above reasons I don't foresee that we're likely to ship
bluetooth enabled server images anytime soon. As to how necessary a
reboot warning is -- I'd consider it "nice to have but by no means
critical" (it's not hardware enablement after all). If we want to keep
the delta minimal, I've no objections.

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

Title:
  Bluez should notify users when they need to reboot to apply changes on
  Raspberry Pi

Status in bluez package in Ubuntu:
  In Progress
Status in bluez package in Debian:
  New

Bug description:
  In the case of upgrading or installing bluez for the first time on
  certain raspberry pi devices, a reboot may be required to apply the
  changes. We should add a check for this scenario in the postinst
  script.

To manage notifications about this bug 

[Touch-packages] [Bug 1922266] Re: eth0 interface name change fails on Pi 3/3+

[Dave Jones]

Attaching debdiff; test builds are available from the following PPA:

https://launchpad.net/~waveform/+archive/ubuntu/ubuntu-
settings/+packages

** Patch added: "1-1922266.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1922266/+attachment/5488517/+files/1-1922266.debdiff

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

Title:
  eth0 interface name change fails on Pi 3/3+

Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntu-settings package in Ubuntu:
  New

Bug description:
  The netplan configuration in ubuntu-raspi-settings (and more widely,
  the network-config in the gadget used on the server images) fails to
  rename the internal ethernet interface on Pi 3B and 3B+ models from
  "en" to "eth0". In the netplan case this is because the
  driver matching logic doesn't handle space-separate driver matches
  (although the underlying networkd system does); in the cloud-init case
  it simply refuses to rename interfaces that aren't matched by full MAC
  address.

  The intended fix is to stop attempting to do this via netplan or
  cloud-init, and simply handle this via a networkd .link file in
  ubuntu-raspi-settings. This will require an update to the relevant
  seeds as this package is currently only pulled into ubuntu-desktop-
  raspi, not ubuntu-server-raspi.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1922266/+subscriptions

-- 
Mailing list: https://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 1922266] Re: eth0 interface name change fails on Pi 3/3+

[Dave Jones]

It's still necessary; I've got the changes ready but was holding off as
there's possibly another fix that may need to go into this package too
(LP: #1900904). But it's getting close to release so I'll push it anyway
and deal with the other ticket separately.

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

Title:
  eth0 interface name change fails on Pi 3/3+

Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntu-settings package in Ubuntu:
  New

Bug description:
  The netplan configuration in ubuntu-raspi-settings (and more widely,
  the network-config in the gadget used on the server images) fails to
  rename the internal ethernet interface on Pi 3B and 3B+ models from
  "en" to "eth0". In the netplan case this is because the
  driver matching logic doesn't handle space-separate driver matches
  (although the underlying networkd system does); in the cloud-init case
  it simply refuses to rename interfaces that aren't matched by full MAC
  address.

  The intended fix is to stop attempting to do this via netplan or
  cloud-init, and simply handle this via a networkd .link file in
  ubuntu-raspi-settings. This will require an update to the relevant
  seeds as this package is currently only pulled into ubuntu-desktop-
  raspi, not ubuntu-server-raspi.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1922266/+subscriptions

-- 
Mailing list: https://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 1922266] Re: eth0 interface name change fails on Pi 3/3+

[Dave Jones]

Seeds have now been updated:

https://code.launchpad.net/~waveform/ubuntu-seeds/+git/ubuntu-seeds/+merge/400932
https://code.launchpad.net/~waveform/ubuntu-seeds/+git/ubuntu-seeds/+merge/400933

And the meta package has been updated to incorporate these changes in
1.467

** Also affects: ubuntu-settings (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: ubuntu-meta (Ubuntu)
   Status: New => Fix Released

** Changed in: ubuntu-settings (Ubuntu)
Milestone: None => ubuntu-21.04

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

Title:
  eth0 interface name change fails on Pi 3/3+

Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntu-settings package in Ubuntu:
  New

Bug description:
  The netplan configuration in ubuntu-raspi-settings (and more widely,
  the network-config in the gadget used on the server images) fails to
  rename the internal ethernet interface on Pi 3B and 3B+ models from
  "en" to "eth0". In the netplan case this is because the
  driver matching logic doesn't handle space-separate driver matches
  (although the underlying networkd system does); in the cloud-init case
  it simply refuses to rename interfaces that aren't matched by full MAC
  address.

  The intended fix is to stop attempting to do this via netplan or
  cloud-init, and simply handle this via a networkd .link file in
  ubuntu-raspi-settings. This will require an update to the relevant
  seeds as this package is currently only pulled into ubuntu-desktop-
  raspi, not ubuntu-server-raspi.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1922266/+subscriptions

-- 
Mailing list: https://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 1923672] [NEW] [FFe] Provide access to GPIO to default user

[Dave Jones]

Public bug reported:

At present, access to the GPIO pins is provided to the dialout group by
the udev rules from the rpi.gpio-common package. However, rpi.gpio is a
single GPIO library, and the device(s) it provides access to are not
specific to it. Moreover, the interface used is deprecated and the
/dev/gpiochip* interface is now the favoured mechanism for controlling
the GPIO pins.

The choice of the dialout group appears reasonable (historically it's
used to provide access to the serial ports, and indeed the serial ports
are part of the GPIO header on Raspberry Pi devices), but the rules
should be extended to cover the modern /dev/gpiochip* devices, the
related /dev/spidev* and /dev/i2c-* devices, and should be placed in a
central location (i.e. ubuntu-raspi-settings) rather than in a specific
GPIO library (like rpi.gpio).

Related to this is LP: #1923363 which seeks to ensure equal access
across images (the default user is currently granted "dialout" group
membership on the pi server images, but not the desktop ones).

** Affects: ubuntu-settings (Ubuntu)
 Importance: Undecided
 Status: New

** Summary changed:

- Provide access to GPIO to default user
+ [FFe] Provide access to GPIO to default user

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

Title:
  [FFe] Provide access to GPIO to default user

Status in ubuntu-settings package in Ubuntu:
  New

Bug description:
  At present, access to the GPIO pins is provided to the dialout group
  by the udev rules from the rpi.gpio-common package. However, rpi.gpio
  is a single GPIO library, and the device(s) it provides access to are
  not specific to it. Moreover, the interface used is deprecated and the
  /dev/gpiochip* interface is now the favoured mechanism for controlling
  the GPIO pins.

  The choice of the dialout group appears reasonable (historically it's
  used to provide access to the serial ports, and indeed the serial
  ports are part of the GPIO header on Raspberry Pi devices), but the
  rules should be extended to cover the modern /dev/gpiochip* devices,
  the related /dev/spidev* and /dev/i2c-* devices, and should be placed
  in a central location (i.e. ubuntu-raspi-settings) rather than in a
  specific GPIO library (like rpi.gpio).

  Related to this is LP: #1923363 which seeks to ensure equal access
  across images (the default user is currently granted "dialout" group
  membership on the pi server images, but not the desktop ones).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-settings/+bug/1923672/+subscriptions

-- 
Mailing list: https://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 1920837] Re: apport bugs from official raspi or riscv images are not identified

[Dave Jones]

The most reliable means I know of at the moment for detecting Raspberry
Pi hardware at runtime  is to query the device-tree.

For example, flash-kernel determines the type of board it is running on,
by matching the content of /proc/device-tree/model (e.g. "Raspberry Pi
400 Rev 1.0") against a pre-determined list of strings in its database.
Personally I don't much like matching fixed strings -- new board
revisions frequently come out and then f-k needs patching to add them,
but last cycle I did add the ability to match the "Raspberry Pi *" glob
as an attempt to support new boards even if they come out mid-cycle.
Something similar could be accomplished with some Python like so:

try:
with open('/proc/device-tree/model', 'r', encoding='ascii') as f:
is_a_pi = f.read().startswith('Raspberry Pi ')
except FileNotFoundError:
is_a_pi = False

That seems to work reliably (even on compute modules where the model is
"Raspberry Pi Compute Module 4 Rev 1.0"), but I've no idea if the /proc
/device-tree/model file *always* exists or whether other boards publish
useful information in there.

Another possibility is to look at /proc/device-tree/compatible which I
*think* should always exist assuming a device-tree is in use on the
system. This is a binary file containing a sequence of NUL-terminated
strings, each of which is of the form "vendor,model" and is intended for
kernel driver matching. For example, on the Pi 400 it contains:

raspberrypi,400\0brcm,bcm2711\0

(where \0 is the NUL character). And on a 3B+ contains:

raspberrypi,3-model-b-plus\0brcm,bcm2837\0

My understanding is there's no strict requirement that these strings
appear in any particular order so simple prefix matching is potentially
unreliable. However, it's trivial enough to parse and extract the
"raspberrypi" vendor from this with some Python like:

try:
with open('/proc/device-tree/compatible', 'rb') as f:
is_a_pi = any(vendor == 'raspberrypi'
  for s in f.read().split(b'\0') if s
  for vendor, model in (s.decode('ascii').split(',', 1),))
except FileNotFoundError:
is_a_pi = False

Something similar *should* be reasonably useful with just about any
board that uses a device tree (but obviously PCs don't have device-trees
so we still need the file-not-found check).

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

Title:
  apport bugs from official raspi or riscv images are not identified

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Focal:
  In Progress
Status in apport source package in Groovy:
  In Progress

Bug description:
  It would be helpful if bugs reported from images for Raspberry Pi's or
  RISCV systems were tagged so that one could search for bugs from
  systems running those images e.g. 'raspi-image'.

  [Test Case]
  After installing a preinstalled image of Ubuntu for Raspberry Pi do the 
following:
  1) run 'ubuntu-bug apport'
  2) view the bug report and check the Tags field

  With the current version of apport you will not see the tag 'raspi-image'.
  With the version of apport in -proposed you will see the tag 'raspi-image'.

  [Where problems could occur]
  If the code being added is syntactically incorrect then we'd see a Traceback 
which would be bad as it could affect all bug / crash reports.

  [Other Info]
  Since there aren't any Groovy images for RISC-V there will be nothing to test 
there.

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

-- 
Mailing list: https://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 1922266] [NEW] eth0 interface name change fails on Pi 3/3+

[Dave Jones]

Public bug reported:

The netplan configuration in ubuntu-raspi-settings (and more widely, the
network-config in the gadget used on the server images) fails to rename
the internal ethernet interface on Pi 3B and 3B+ models from "en" to "eth0". In the netplan case this is because the driver
matching logic doesn't handle space-separate driver matches (although
the underlying networkd system does); in the cloud-init case it simply
refuses to rename interfaces that aren't matched by full MAC address.

The intended fix is to stop attempting to do this via netplan or cloud-
init, and simply handle this via a networkd .link file in ubuntu-raspi-
settings. This will require an update to the relevant seeds as this
package is currently only pulled into ubuntu-desktop-raspi, not ubuntu-
server-raspi.

** Affects: ubuntu-meta (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  eth0 interface name change fails on Pi 3/3+

Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  The netplan configuration in ubuntu-raspi-settings (and more widely,
  the network-config in the gadget used on the server images) fails to
  rename the internal ethernet interface on Pi 3B and 3B+ models from
  "en" to "eth0". In the netplan case this is because the
  driver matching logic doesn't handle space-separate driver matches
  (although the underlying networkd system does); in the cloud-init case
  it simply refuses to rename interfaces that aren't matched by full MAC
  address.

  The intended fix is to stop attempting to do this via netplan or
  cloud-init, and simply handle this via a networkd .link file in
  ubuntu-raspi-settings. This will require an update to the relevant
  seeds as this package is currently only pulled into ubuntu-desktop-
  raspi, not ubuntu-server-raspi.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1922266/+subscriptions

-- 
Mailing list: https://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 1915966] Re: Please merge initramfs-tools 0.139 from Debian unstable

[Dave Jones]

Attaching revised patch with needs-root added to the new qemu-related
tests (to work around build failure:
https://launchpad.net/ubuntu/+source/initramfs-
tools/0.139ubuntu1/+build/21138158)

** Patch added: "2-1915966.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1915966/+attachment/5475404/+files/2-1915966.debdiff

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

Title:
  Please merge initramfs-tools 0.139 from Debian unstable

Status in initramfs-tools package in Ubuntu:
  Fix Committed

Bug description:
  Please merge initramfs-tools 0.139 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  shortly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1915966/+subscriptions

-- 
Mailing list: https://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 1915966] Re: Please merge initramfs-tools 0.139 from Debian unstable

[Dave Jones]

Attaching patch against Debian unstable. For ease of review, I've also
pushed relevant commits and tags to the following repository:

  https://code.launchpad.net/~waveform/ubuntu/+source/initramfs-
tools/+git/initramfs-tools

Specifically:

* The logical/0.137ubuntu12 tag represents our split-out delta on top of 
old/debian (0.137)
* The merge/0.139ubuntu1 tag represents the rebased delta on top of new/debian 
(0.139)

Hence, the following command may produce output useful to the purposes
of review:

  git range-diff old/debian..logical/0.137ubuntu12
new/debian..merge/0.139ubuntu1

A test package has been built in the following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/initramfs-tools

** Patch added: "1-1915966.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1915966/+attachment/5464675/+files/1-1915966.debdiff

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

Title:
  Please merge initramfs-tools 0.139 from Debian unstable

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  Please merge initramfs-tools 0.139 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  shortly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1915966/+subscriptions

-- 
Mailing list: https://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 1915966] [NEW] Please merge initramfs-tools 0.139 from Debian unstable

[Dave Jones]

Public bug reported:

Please merge initramfs-tools 0.139 from Debian unstable.

Updated changelog and diff against Debian unstable to be attached
shortly.

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  Please merge initramfs-tools 0.139 from Debian unstable

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  Please merge initramfs-tools 0.139 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  shortly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1915966/+subscriptions

-- 
Mailing list: https://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 1571506] Re: update-initramfs should include firmware from /lib/firmware/updates

[Dave Jones]

** Changed in: initramfs-tools (Ubuntu Hirsute)
 Assignee: (unassigned) => Dave Jones (waveform)

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

Title:
  update-initramfs should include firmware from /lib/firmware/updates

Status in initramfs-tools package in Ubuntu:
  Triaged
Status in initramfs-tools source package in Focal:
  New
Status in initramfs-tools source package in Groovy:
  New
Status in initramfs-tools source package in Hirsute:
  Triaged

Bug description:
  according to the kernel doc
  
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/firmware_class/README

  Linux kernel will search firmware from
  "/lib/firmware/updates/" UTS_RELEASE,
  "/lib/firmware/updates",
  "/lib/firmware/" UTS_RELEASE,
  "/lib/firmware"

  But the add module function in initramfs-tools won't search the
  "/lib/firmware/updates".

  This problem applies to all Ubuntu releases.

  Attach patch to fix this.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: initramfs-tools 0.103ubuntu4.2
  ProcVersionSignature: Ubuntu 4.2.0-30.36~14.04.1-generic 4.2.8-ckt3
  Uname: Linux 4.2.0-30-generic i686
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: i386
  CurrentDesktop: Unity
  Date: Mon Apr 18 14:24:29 2016
  InstallationDate: Installed on 2014-04-23 (725 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release i386 (20140417)
  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/1571506/+subscriptions

-- 
Mailing list: https://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 1915005] Re: Please merge findutils 4.8.0 from Debian unstable

[Dave Jones]

Attaching patch against Debian unstable.

** Patch added: "1-1915005.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1915005/+attachment/5461235/+files/1-1915005.debdiff

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

Title:
  Please merge findutils 4.8.0 from Debian unstable

Status in findutils package in Ubuntu:
  New

Bug description:
  Please merge findutils 4.8.0-1 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  shortly.

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

-- 
Mailing list: https://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 1915005] [NEW] Please merge findutils 4.8.0 from Debian unstable

[Dave Jones]

Public bug reported:

Please merge findutils 4.8.0-1 from Debian unstable.

Updated changelog and diff against Debian unstable to be attached
shortly.

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

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

Title:
  Please merge findutils 4.8.0 from Debian unstable

Status in findutils package in Ubuntu:
  New

Bug description:
  Please merge findutils 4.8.0-1 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  shortly.

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

-- 
Mailing list: https://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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400

[Dave Jones]

There's a version of bluez with the patches that I've submitted upstream
built in the following PPA against the hirsute branch (the patch changes
are pretty minimal; basically amounts to removal of the arbitrary
sleep(1) as during December's tests I couldn't find a single platform
that actually required that, even amongst the Pi's we don't support like
the zero):

https://launchpad.net/~waveform/+archive/ubuntu/bluez

I'm happy to convert that to a git-ubuntu branch if that's preferable.
Once sponsored, we should consider SRU'ing to focal given that Pi400
support is now being SRU'd there generally.

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

Title:
  [SRU] Bluetooth won't activate on the pi 400

Status in bluez package in Ubuntu:
  Triaged
Status in bluez source package in Groovy:
  Fix Released
Status in bluez source package in Hirsute:
  Triaged

Bug description:
  [Impact]

  Without these patches, Bluetooth is inoperable on the recently
  released Raspberry Pi 400.

  [Test Case]

  * Boot the Ubuntu Desktop for Pi image on a Pi 400.
  * Start the Settings application and switch to the Bluetooth tab
  * Verify that Bluetooth is not enabled and attempting to activate it fails
  * Enable the -proposed repository for the release (groovy)
  * sudo apt update
  * sudo apt install bluez
  * sudo reboot
  * Start the Settings application and switch to the Bluetooth tab
  * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, 
mobile phones, headphones, etc.) can connect and operate correctly

  [Regression Potential]

  Extremely low (on groovy in particular, this has the same version of
  bluez as hirsute). The only significant risk is to non-Pi platforms or
  dongles which also use the Broadcom 43xx (or Cypress 305) chips for
  Bluetooth which might be inadvertently affected by these patches.

  [Original Description]

  The new Pi 400 has a slightly different Wifi/BT chip to the Pi4.
  Whilst wifi works happily, Bluetooth fails to operate. This doesn't
  appear to be an issue with either the firmware (the latest versions
  from upstream Raspbian have been tried), or the kernel (a known-good
  raspi kernel has been tested under Ubuntu), but with Bluez itself.
  Specifically, tracing the initialization with btmon on Raspbian and
  Ubuntu, the stack consistently fails when attempting to "Set Default
  PHY" on the latter. Curiously, under Ubuntu the adapter also appears
  to lack a MAC address.

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

-- 
Mailing list: https://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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400

[Dave Jones]

@hujq is there anything unusual about your bluetooth setup? miniuart-bt
overlay or anything like that? I'm unable to replicate the failure here
on a Pi 4 8GB

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

Title:
  [SRU] Bluetooth won't activate on the pi 400

Status in bluez package in Ubuntu:
  Triaged
Status in bluez source package in Groovy:
  Fix Released
Status in bluez source package in Hirsute:
  Triaged

Bug description:
  [Impact]

  Without these patches, Bluetooth is inoperable on the recently
  released Raspberry Pi 400.

  [Test Case]

  * Boot the Ubuntu Desktop for Pi image on a Pi 400.
  * Start the Settings application and switch to the Bluetooth tab
  * Verify that Bluetooth is not enabled and attempting to activate it fails
  * Enable the -proposed repository for the release (groovy)
  * sudo apt update
  * sudo apt install bluez
  * sudo reboot
  * Start the Settings application and switch to the Bluetooth tab
  * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, 
mobile phones, headphones, etc.) can connect and operate correctly

  [Regression Potential]

  Extremely low (on groovy in particular, this has the same version of
  bluez as hirsute). The only significant risk is to non-Pi platforms or
  dongles which also use the Broadcom 43xx (or Cypress 305) chips for
  Bluetooth which might be inadvertently affected by these patches.

  [Original Description]

  The new Pi 400 has a slightly different Wifi/BT chip to the Pi4.
  Whilst wifi works happily, Bluetooth fails to operate. This doesn't
  appear to be an issue with either the firmware (the latest versions
  from upstream Raspbian have been tried), or the kernel (a known-good
  raspi kernel has been tested under Ubuntu), but with Bluez itself.
  Specifically, tracing the initialization with btmon on Raspbian and
  Ubuntu, the stack consistently fails when attempting to "Set Default
  PHY" on the latter. Curiously, under Ubuntu the adapter also appears
  to lack a MAC address.

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

-- 
Mailing list: https://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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400

[Dave Jones]

On Fri, Nov 13, 2020 at 09:37:34AM -, Sebastien Bacher wrote:
>@Matthieu, @Dave, thanks for the comments and details.
>
>I'm not blocking work to land, the 20.10 SRU could be accepted now and I 
>didn't revert in that serie.
>The SRU team tries to ensure the fix is in the new serie so it doesn't get 
>forgotten/regress when next version is out but I think it's pretty clear we 
>are going to sort out the review details, that's not a blocker and SRU team 
>has been happy in the past to let things in with the understand than $newserie 
>is being sorted out

Ah, my apologies - I had mis-interpreted the reversion as applying to 
the SRU. I've no issue with a reversion in hirsute, provided it doesn't 
delay existing users from using their Bluetooth hardware.

>> If upstream say "yes" to the patches, without further discussion: that's
>> great, but there'd presumably still be some delay before another version
>> makes its way down to us, so we'd be applying *some* patch to make it work 
>> in the interim.
>
>Again I'm not asking for the patches to be reviewed or accepted upstream
>before they are uploaded to Ubuntu, I'm just asking for them to be sent
>upstream and the reference to the email/report/merge request to be added
>to the patches. It would probably have been less work to just do it
>rather than type a long explanation here on why we need to distro patch
>in any case (which I never  disagreed with)

I estimate, as I think several others do judging by various comments, 
that the patches in their current state don't stand much chance of 
passing muster upstream, and I have no desire to waste their time with a 
premature submission. At the very least, some justification needs adding 
to the 1 second sleep: either a datasheet reference, which I've so far 
failed to find, or some empirical measurements that it's actually 
required (which I'm in the process of gathering; I've verified *a* delay 
is required but not the minimum, or whether it can be combined with the 
post-load nanosleep), along with evidence it doesn't break any existing 
platforms (I've found a datasheet reference to back that bit up, but 
tests are good too).

Anyway, sorry I mis-interpreted the release your action applied to; I 
look forward to seeing the SRU land.

In the meantime, rest assured a submission will be made upstream as soon 
as I think I've got a faint hope of it passing!

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

Title:
  [SRU] Bluetooth won't activate on the pi 400

Status in bluez package in Ubuntu:
  Triaged
Status in bluez source package in Hirsute:
  Triaged

Bug description:
  [Impact]

  Without these patches, Bluetooth is inoperable on the recently
  released Raspberry Pi 400.

  [Test Case]

  * Boot the Ubuntu Desktop for Pi image on a Pi 400.
  * Start the Settings application and switch to the Bluetooth tab
  * Verify that Bluetooth is not enabled and attempting to activate it fails
  * sudo add-apt-repository ppa:waveform/pi-bluetooth
  * sudo apt update
  * sudo apt install bluez
  * sudo reboot
  * Start the Settings application and switch to the Bluetooth tab
  * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, 
mobile phones, headphones, etc.) can connect and operate correctly 

  [Regression Potential]

  Extremely low (on groovy in particular, this has the same version of
  bluez as hirsute). The only significant risk is to non-Pi platforms or
  dongles which also use the Broadcom 43xx (or Cypress 305) chips for
  Bluetooth which might be inadvertently affected by these patches.

  [Original Description]

  The new Pi 400 has a slightly different Wifi/BT chip to the Pi4.
  Whilst wifi works happily, Bluetooth fails to operate. This doesn't
  appear to be an issue with either the firmware (the latest versions
  from upstream Raspbian have been tried), or the kernel (a known-good
  raspi kernel has been tested under Ubuntu), but with Bluez itself.
  Specifically, tracing the initialization with btmon on Raspbian and
  Ubuntu, the stack consistently fails when attempting to "Set Default
  PHY" on the latter. Curiously, under Ubuntu the adapter also appears
  to lack a MAC address.

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

-- 
Mailing list: https://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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400

[Dave Jones]

On Thu, Nov 12, 2020 at 11:11:23AM -, Sebastien Bacher wrote:
>Sorry but I'm reverting that upload for now until the patches are
>properly upstreamed. We have been bitten too often by unforwarded
>changes that create issues or create maintainance burden over the years
>and we currently don't have the team capacity to deal with extra cost.
>If foundations would like to step up and take over bluez though that's a
>discussion we could have...

My apologies; I omitted to note in the patch that the Pi 400 is a 
certified platform, i.e. we're effectively committed to making it work 
as best we can, which makes the status of whether upstream accept the 
patches or not rather moot:

If upstream say "yes" to the patches, without further discussion: that's 
great, but there'd presumably still be some delay before another version 
makes its way down to us, so we'd be applying *some* patch to make it 
work in the interim.

If upstream say "with these changes" to the patches: again great, but in 
the interim, we'd again be applying *some* patch to make things work on 
a certified platform while working through changes upstream.

If upstream say "not in a month of Sundays" to these patches: we'd be 
left carrying *some* patch, and we'd do it because it's a certified 
platform and we're committed to making it work.

 From our end user's perspective therefore, the application of this 
patch-set, whether via upstream or not, and whether in this form or not, 
is not a matter of "if", but "when". Given we have in our possession a 
patch-set that fixes the problem, I at least don't have a good answer to 
the hypothetical user's obvious follow-up question: "why not now?"

Anyway, onto technical matters:

>I'm not asking for the patches to be merged upstream but at least to be
>sent there for review and have the appropriate tagging, it's easy to
>unblock from your side. Also I would like to see if we can get for a
>better way to probe for the system to be ready rather than relying on a
>random sleep

The following involves a certain amount of educated guessing. I haven't 
dug into this extensively, but I can offer some reasons for why sleep(1) 
is being used (and how this could be refined a bit, but not much):

Consider the bcm43xx_load_firmware routine in hciattach_bcm43xx.c [1] 
which is being called prior to the apparently arbitrarily inserted 
sleep(1) line in the patch. It's a fairly typical firmware load routine 
by all accounts:

1. Calls write() with a command (0x2e 0xfc) to place the device into a 
state where it's read to receive new firmware

2. Calls read_hci_event() to check the device responded "okay!"

3. Calls nanosleep() to wait a short while (50ms) for the device to be 
ready

4. Calls read() and write() repeatedly to write the firmware blob from a 
file to the UART

5. Calls nanosleep() again to wait another short while (200ms) after the 
firmware load

So the existing (pre-patch) firmware load routine already has a 
seemingly arbitrary post-firmware-load delay of 200ms. If we have a look 
at the BCM4334 datasheet [2], p.159 we can see "wait at least 150ms 
after [power on] before initiating SDIO accesses" (SDIO being one of 
several interfaces for this particular module). However, that's just for 
the BCM4334. There's also the BCM4330, BCM4329, and the Cypress 305 (on 
the Pi 400, which uses the BCM43xx interface; Cypress, incidentally, 
acquired Broadcom's wireless business which explains why their chips 
suddenly have Broadcom's interfaces).

The bluez interface *could* presumably check precisely which device it 
was dealing with and adjust its post-firmware-load delay accordingly. Or 
it could simply go with a delay that's "long enough" to cover all the 
supported chipsets, and avoid all that logic (which appears to be what's 
favoured in the original code). Given it's a one-time setup delay, and 
it's likely to occur during boot-up (or system wake-up) when half a 
dozen other things are happening in parallel, it's unlikely the user 
will notice a difference between a 150ms, 200ms, or even 1.2s delay to 
their Bluetooth module becoming available.

Hence one possibility for the sleep(1) delay is that the Cypress 305, 
being a later and more feature-rich device, requires a longer delay. I 
can't confirm that as I can't find the datasheet online; sadly, this 
isn't remotely surprising, but I could reasonably assume that the Pi 
Foundation *do* have access to it and thus the 1 second delay isn't 
*entirely* arbitrary.

In some of the BCM43xx modules it does appear that the UART CTS line is 
asserted to indicate the device is "ready" (e.g. the BCM4330 datasheet 
mentions this under the Bluetooth PMU section). However, one of the 
configurations (not the default, but a supported configuration 
nonetheless) for the Bluetooth module on all Pi models is to be operated 
via the mini-UART instead of the PL011. The mini-UART, as noted 
previously, explicitly lacks any hardware flow-control ([3], 

Re: [Touch-packages] [Bug 1903048] Re: [SRU] Bluetooth won't activate on the pi 400

[Dave Jones]

On Tue, Nov 10, 2020 at 03:12:30PM -, Sebastien Bacher wrote:
>Thanks for the work but it there any work to upstream those changes? I'm
>not happy to carry a sleep(1) hack in our package unless there is a
>strong reason and we are working on a way to replace it by a better
>solution

The changes come from the Pi Foundation originally (though I've tidied 
them up a tiny bit). They're not interested in upstreaming them 
themselves, though they expressed no objections to my attempting to do 
so when I raised the question.

I realize I'll probably have a bit of a battle on my hands with 
something like the patch involving sleep(1), but I would note that the 
sleep(1) hack is in the hciattach_bcm43xx module so it is not something 
that would be applied to every single Bluetooth module, only to those 
compatible with the BCM43xx line.

While 1 second is obviously a suspiciously round number for the delay, I 
would further note that it's immediately after a firmware load over the 
controlling UART and that that UART can (in certain configurations) be 
the Pi's mini-UART which has some (minimal) buffering, but lacks any 
hardware flow control. Finally, these patches were also intended to work 
on the relatively slow, single core Pi Zero.

Obviously we don't support the Zero, and thus it's possible *we* might
be able to either do away with that sleep, or at least reduce the delay 
required, but given this is one-off initialization, and the delay is all 
of 1 second, I'm not convinced it's worth investing the time required to 
figure out the minimum. Also, I would assume in the interests of 
upstreaming the patch, the delay should be as widely applicable as 
possible.

Anyway, I'll upstream what I can and we'll have to carry whatever's left 
over.

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

Title:
  [SRU] Bluetooth won't activate on the pi 400

Status in bluez package in Ubuntu:
  Fix Released
Status in bluez source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

  Without these patches, Bluetooth is inoperable on the recently
  released Raspberry Pi 400.

  [Test Case]

  * Boot the Ubuntu Desktop for Pi image on a Pi 400.
  * Start the Settings application and switch to the Bluetooth tab
  * Verify that Bluetooth is not enabled and attempting to activate it fails
  * sudo add-apt-repository ppa:waveform/pi-bluetooth
  * sudo apt update
  * sudo apt install bluez
  * sudo reboot
  * Start the Settings application and switch to the Bluetooth tab
  * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, 
mobile phones, headphones, etc.) can connect and operate correctly 

  [Regression Potential]

  Extremely low (on groovy in particular, this has the same version of
  bluez as hirsute). The only significant risk is to non-Pi platforms or
  dongles which also use the Broadcom 43xx (or Cypress 305) chips for
  Bluetooth which might be inadvertently affected by these patches.

  [Original Description]

  The new Pi 400 has a slightly different Wifi/BT chip to the Pi4.
  Whilst wifi works happily, Bluetooth fails to operate. This doesn't
  appear to be an issue with either the firmware (the latest versions
  from upstream Raspbian have been tried), or the kernel (a known-good
  raspi kernel has been tested under Ubuntu), but with Bluez itself.
  Specifically, tracing the initialization with btmon on Raspbian and
  Ubuntu, the stack consistently fails when attempting to "Set Default
  PHY" on the latter. Curiously, under Ubuntu the adapter also appears
  to lack a MAC address.

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

-- 
Mailing list: https://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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400

[Dave Jones]

** Description changed:

+ [Impact]
+ 
+ Without these patches, Bluetooth is inoperable on the recently released
+ Raspberry Pi 400.
+ 
+ [Test Case]
+ 
+ * Boot the Ubuntu Desktop for Pi image on a Pi 400.
+ * Start the Settings application and switch to the Bluetooth tab
+ * Verify that Bluetooth is not enabled and attempting to activate it fails
+ * sudo add-apt-repository ppa:waveform/pi-bluetooth
+ * sudo apt update
+ * sudo apt install bluez
+ * sudo reboot
+ * Start the Settings application and switch to the Bluetooth tab
+ * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, 
mobile phones, headphones, etc.) can connect and operate correctly 
+ 
+ [Regression Potential]
+ 
+ Extremely low (on groovy in particular, this has the same version of
+ bluez as hirsute). The only significant risk is to non-Pi platforms or
+ dongles which also use the Broadcom 43xx (or Cypress 305) chips for
+ Bluetooth which might be inadvertently affected by these patches.
+ 
+ [Original Description]
+ 
  The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst
  wifi works happily, Bluetooth fails to operate. This doesn't appear to
  be an issue with either the firmware (the latest versions from upstream
  Raspbian have been tried), or the kernel (a known-good raspi kernel has
  been tested under Ubuntu), but with Bluez itself. Specifically, tracing
  the initialization with btmon on Raspbian and Ubuntu, the stack
  consistently fails when attempting to "Set Default PHY" on the latter.
  Curiously, under Ubuntu the adapter also appears to lack a MAC address.

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

Title:
  [SRU] Bluetooth won't activate on the pi 400

Status in bluez package in Ubuntu:
  Confirmed

Bug description:
  [Impact]

  Without these patches, Bluetooth is inoperable on the recently
  released Raspberry Pi 400.

  [Test Case]

  * Boot the Ubuntu Desktop for Pi image on a Pi 400.
  * Start the Settings application and switch to the Bluetooth tab
  * Verify that Bluetooth is not enabled and attempting to activate it fails
  * sudo add-apt-repository ppa:waveform/pi-bluetooth
  * sudo apt update
  * sudo apt install bluez
  * sudo reboot
  * Start the Settings application and switch to the Bluetooth tab
  * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, 
mobile phones, headphones, etc.) can connect and operate correctly 

  [Regression Potential]

  Extremely low (on groovy in particular, this has the same version of
  bluez as hirsute). The only significant risk is to non-Pi platforms or
  dongles which also use the Broadcom 43xx (or Cypress 305) chips for
  Bluetooth which might be inadvertently affected by these patches.

  [Original Description]

  The new Pi 400 has a slightly different Wifi/BT chip to the Pi4.
  Whilst wifi works happily, Bluetooth fails to operate. This doesn't
  appear to be an issue with either the firmware (the latest versions
  from upstream Raspbian have been tried), or the kernel (a known-good
  raspi kernel has been tested under Ubuntu), but with Bluez itself.
  Specifically, tracing the initialization with btmon on Raspbian and
  Ubuntu, the stack consistently fails when attempting to "Set Default
  PHY" on the latter. Curiously, under Ubuntu the adapter also appears
  to lack a MAC address.

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

-- 
Mailing list: https://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 1903048] Re: [SRU] Bluetooth won't activate on the pi 400

[Dave Jones]

** Summary changed:

- Bluetooth won't activate on the pi 400
+ [SRU] Bluetooth won't activate on the pi 400

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

Title:
  [SRU] Bluetooth won't activate on the pi 400

Status in bluez package in Ubuntu:
  Confirmed

Bug description:
  The new Pi 400 has a slightly different Wifi/BT chip to the Pi4.
  Whilst wifi works happily, Bluetooth fails to operate. This doesn't
  appear to be an issue with either the firmware (the latest versions
  from upstream Raspbian have been tried), or the kernel (a known-good
  raspi kernel has been tested under Ubuntu), but with Bluez itself.
  Specifically, tracing the initialization with btmon on Raspbian and
  Ubuntu, the stack consistently fails when attempting to "Set Default
  PHY" on the latter. Curiously, under Ubuntu the adapter also appears
  to lack a MAC address.

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

-- 
Mailing list: https://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 1903614] Re: Please merge kbd 2.3.0-3 from Debian unstable

[Dave Jones]

Ooops - left a redundant file in the diff; revised patch attached below

** Patch added: "2-2.3.0-3ubuntu1.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/1903614/+attachment/5432819/+files/2-2.3.0-3ubuntu1.debdiff

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

Title:
  Please merge kbd 2.3.0-3 from Debian unstable

Status in kbd package in Ubuntu:
  New

Bug description:
  Please merge kbd 2.3.0-3 from Debian unstable.

  Updated changelog and diff against Debian unstable is attached below.
  Test build available from
  https://launchpad.net/~waveform/+archive/ubuntu/kbd/+packages

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

-- 
Mailing list: https://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 1903614] [NEW] Please merge kbd 2.3.0-3 from Debian unstable

[Dave Jones]

Public bug reported:

Please merge kbd 2.3.0-3 from Debian unstable.

Updated changelog and diff against Debian unstable is attached below.
Test build available from
https://launchpad.net/~waveform/+archive/ubuntu/kbd/+packages

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

** Patch added: "1-2.3.0-3ubuntu1.debdiff"
   
https://bugs.launchpad.net/bugs/1903614/+attachment/5432816/+files/1-2.3.0-3ubuntu1.debdiff

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

Title:
  Please merge kbd 2.3.0-3 from Debian unstable

Status in kbd package in Ubuntu:
  New

Bug description:
  Please merge kbd 2.3.0-3 from Debian unstable.

  Updated changelog and diff against Debian unstable is attached below.
  Test build available from
  https://launchpad.net/~waveform/+archive/ubuntu/kbd/+packages

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

-- 
Mailing list: https://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 789196] Re: resizecons missing

[Dave Jones]

This was fixed by the merge from debian back in yakkety

** Changed in: kbd (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  resizecons missing

Status in kbd package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: kbd

  The manual page for resizecons is included in this package but not the
  utility itself.

  dpkg --listfiles kbd | fgrep -i resize
  /usr/share/man/man8/resizecons.8.gz

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: kbd 1.15-1ubuntu5
  ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
  Uname: Linux 2.6.38-8-generic x86_64
  NonfreeKernelModules: fglrx
  Architecture: amd64
  CheckboxSubmission: 1e1a99f31ec2933306456e1f141c45d8
  CheckboxSystem: edda5d4f616ca792bf437989cb597002
  Date: Fri May 27 11:58:37 2011
  InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
  ProcEnviron:
   LANGUAGE=en_US:en
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: kbd
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://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 1901272] Re: Can't connect Bluetooth devices after reboot - Ubuntu 20.10 on Raspberry Pi 4

[Dave Jones]

@Daniel could you try out the bluez package from the following PPA:
https://launchpad.net/~waveform/+archive/ubuntu/pi-bluetooth/+packages ?

Should be as simple as doing:

  sudo add-apt-repository ppa:waveform/pi-bluetooth
  sudo apt update
  sudo apt upgrade

The version in that PPA contains the pi foundation's patches to bluez
which were necessary to enable bluetooth on the pi400 (LP: #1903048),
but they also alter some of the general initialization of the bluetooth
module on all pis (amongst other things). A (slightly tidied up) variant
of this is currently intended for hirsute, to be SRU'd to groovy and
focal, so I'd be interested to hear if it also fixes this issue.

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

Title:
  Can't connect Bluetooth devices after reboot - Ubuntu 20.10 on
  Raspberry Pi 4

Status in bluez package in Ubuntu:
  Incomplete
Status in linux-raspi package in Ubuntu:
  Incomplete
Status in pi-bluetooth package in Ubuntu:
  Confirmed
Status in bluez source package in Groovy:
  Incomplete
Status in linux-raspi source package in Groovy:
  Incomplete
Status in pi-bluetooth source package in Groovy:
  New

Bug description:
  Raspberry pi 4 4Gb ram
  Ubuntu desktop 20.10 64 bit
  After reboot no Bluetooth devices connect, scanning Bluetooth devices works, 
results with same device name (duplicated and with not set up status).
  Sometimes after several reboots it works.
  If I use power off and cycle power then it works fine each time.

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

-- 
Mailing list: https://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 1903048] Re: Bluetooth won't activate on the pi 400

[Dave Jones]

@henry-sprog yup, that looks like the same

Attached a patch to fix this in hirsute; once landed will SRU this to
groovy and earlier.

** Patch added: "lp1903048.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+attachment/5431962/+files/lp1903048.debdiff

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

Title:
  Bluetooth won't activate on the pi 400

Status in bluez package in Ubuntu:
  New

Bug description:
  The new Pi 400 has a slightly different Wifi/BT chip to the Pi4.
  Whilst wifi works happily, Bluetooth fails to operate. This doesn't
  appear to be an issue with either the firmware (the latest versions
  from upstream Raspbian have been tried), or the kernel (a known-good
  raspi kernel has been tested under Ubuntu), but with Bluez itself.
  Specifically, tracing the initialization with btmon on Raspbian and
  Ubuntu, the stack consistently fails when attempting to "Set Default
  PHY" on the latter. Curiously, under Ubuntu the adapter also appears
  to lack a MAC address.

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

-- 
Mailing list: https://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 1903048] [NEW] Bluetooth won't activate on the pi 400

[Dave Jones]

Public bug reported:

The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst
wifi works happily, Bluetooth fails to operate. This doesn't appear to
be an issue with either the firmware (the latest versions from upstream
Raspbian have been tried), or the kernel (a known-good raspi kernel has
been tested under Ubuntu), but with Bluez itself. Specifically, tracing
the initialization with btmon on Raspbian and Ubuntu, the stack
consistently fails when attempting to "Set Default PHY" on the latter.
Curiously, under Ubuntu the adapter also appears to lack a MAC address.

** Affects: bluez (Ubuntu)
 Importance: Undecided
 Assignee: Dave Jones (waveform)
 Status: New

** Changed in: bluez (Ubuntu)
 Assignee: (unassigned) => Dave Jones (waveform)

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

Title:
  Bluetooth won't activate on the pi 400

Status in bluez package in Ubuntu:
  New

Bug description:
  The new Pi 400 has a slightly different Wifi/BT chip to the Pi4.
  Whilst wifi works happily, Bluetooth fails to operate. This doesn't
  appear to be an issue with either the firmware (the latest versions
  from upstream Raspbian have been tried), or the kernel (a known-good
  raspi kernel has been tested under Ubuntu), but with Bluez itself.
  Specifically, tracing the initialization with btmon on Raspbian and
  Ubuntu, the stack consistently fails when attempting to "Set Default
  PHY" on the latter. Curiously, under Ubuntu the adapter also appears
  to lack a MAC address.

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

-- 
Mailing list: https://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 1899953] Re: Crackling audio on Raspberry Pi Desktop

[Dave Jones]

Hmm, this looks like someone reported exactly this about a year ago:

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/762

Unfortunately it's closed with "approach the driver maintainer".

** Bug watch added: gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues #762
   https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/762

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

Title:
  Crackling audio on Raspberry Pi Desktop

Status in pulseaudio package in Ubuntu:
  New

Bug description:
  Attempting to play audio (e.g. from rhythmbox) on the raspberry pi
  desktop image, results in broken up / crackling audio. The "tsched=0"
  workaround noted in
  
https://wiki.ubuntu.com/Audio/PositionReporting#Turning_off_PulseAudio_timer_scheduling
  successfully avoids the issue.

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

-- 
Mailing list: https://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 1899962] [NEW] Wrong audio output device selected on Raspberry Pi Desktop

[Dave Jones]

Public bug reported:

On each boot, an incorrect audio output device is selected, at least
when HDMI audio output is in use (still need to test the TV/aux output;
will update the bug when done).

Specifically, the settings application lists "Multichannel Output -
Built-in Audio" as the selected output device. However, for audio to
play through the connected HDMI device, "Analog Output - Built-in Audio"
must be selected instead. Unfortunately, this setting will be lost on
subsequent boots. A workaround is to remove the following lines from
/etc/pulse/default.pa:

### Use hot-plugged devices like Bluetooth or USB automatically (LP: 
#1702794)
.ifexists module-switch-on-connect.so
load-module module-switch-on-connect
.endif

However, removal of these lines will (as the comment suggests) result in
hot-plugged USB devices *not* being automatically selected.

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

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

Title:
  Wrong audio output device selected on Raspberry Pi Desktop

Status in pulseaudio package in Ubuntu:
  New

Bug description:
  On each boot, an incorrect audio output device is selected, at least
  when HDMI audio output is in use (still need to test the TV/aux
  output; will update the bug when done).

  Specifically, the settings application lists "Multichannel Output -
  Built-in Audio" as the selected output device. However, for audio to
  play through the connected HDMI device, "Analog Output - Built-in
  Audio" must be selected instead. Unfortunately, this setting will be
  lost on subsequent boots. A workaround is to remove the following
  lines from /etc/pulse/default.pa:

  ### Use hot-plugged devices like Bluetooth or USB automatically (LP: 
#1702794)
  .ifexists module-switch-on-connect.so
  load-module module-switch-on-connect
  .endif

  However, removal of these lines will (as the comment suggests) result
  in hot-plugged USB devices *not* being automatically selected.

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

-- 
Mailing list: https://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 1899953] [NEW] Crackling audio on Raspberry Pi Desktop

[Dave Jones]

Public bug reported:

Attempting to play audio (e.g. from rhythmbox) on the raspberry pi
desktop image, results in broken up / crackling audio. The "tsched=0"
workaround noted in
https://wiki.ubuntu.com/Audio/PositionReporting#Turning_off_PulseAudio_timer_scheduling
successfully avoids the issue.

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

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

Title:
  Crackling audio on Raspberry Pi Desktop

Status in pulseaudio package in Ubuntu:
  New

Bug description:
  Attempting to play audio (e.g. from rhythmbox) on the raspberry pi
  desktop image, results in broken up / crackling audio. The "tsched=0"
  workaround noted in
  
https://wiki.ubuntu.com/Audio/PositionReporting#Turning_off_PulseAudio_timer_scheduling
  successfully avoids the issue.

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

-- 
Mailing list: https://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 1891316] Re: duplicate "progname" under gcc-10

[Dave Jones]

** Description changed:

  Under gcc-10's linker an error occurs wherein "progname" appears to be
  included from multiple locations (as it's defined in version.h rather
  than merely declared).
+ 
+ A trivial patch is available from the following branch:
+ 
+ https://code.launchpad.net/~waveform/ubuntu/+source/kbd/+git/kbd/+ref
+ /fix-duplicate-progname
+ 
+ With test builds in the following PPA:
+ 
+ https://launchpad.net/~waveform/+archive/ubuntu/kbd

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

Title:
  duplicate "progname" under gcc-10

Status in kbd package in Ubuntu:
  New

Bug description:
  Under gcc-10's linker an error occurs wherein "progname" appears to be
  included from multiple locations (as it's defined in version.h rather
  than merely declared).

  A trivial patch is available from the following branch:

  https://code.launchpad.net/~waveform/ubuntu/+source/kbd/+git/kbd/+ref
  /fix-duplicate-progname

  With test builds in the following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/kbd

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

-- 
Mailing list: https://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 1891316] [NEW] duplicate "progname" under gcc-10

[Dave Jones]

Public bug reported:

Under gcc-10's linker an error occurs wherein "progname" appears to be
included from multiple locations (as it's defined in version.h rather
than merely declared).

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

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

Title:
  duplicate "progname" under gcc-10

Status in kbd package in Ubuntu:
  New

Bug description:
  Under gcc-10's linker an error occurs wherein "progname" appears to be
  included from multiple locations (as it's defined in version.h rather
  than merely declared).

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

-- 
Mailing list: https://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 1311056] Re: [SRU] apt-add-repository adds duplicate commented/disabled source lines

[Dave Jones]

All regressions now cleared after a re-run (thanks!), and verifications
done.

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

Title:
  [SRU] apt-add-repository adds duplicate commented/disabled source
  lines

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  Fix Committed
Status in python-apt source package in Bionic:
  Fix Committed
Status in python-apt source package in Eoan:
  Fix Committed

Bug description:
  Impact
  ==

  Under most circumstances, the impact is minimal (a few extra redundant
  comment lines in apt sources. However, if users are automating source
  removal / addition on a machine (as in comment 11), there is the
  potential to wind up with an excessively large (and thus slow to
  parse) apt sources configuration.

  Test packages for the supported releases are available from the
  following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/python-apt

  Built from the source which can be found in the following branches:

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-xenial

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-bionic

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-eoan

  Test Case
  =

  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the presence of one uncommented "deb" line, and one commented 
"deb-src" line
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the uncommented "deb" line is still there but the commented "deb-src" 
line has now been duplicated
  * sudo add-apt-repository ppa:waveform/python-apt
  * sudo apt upgrade  # update python-apt to fixed version
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note there has been no further duplication of the commented "deb-src" line

  Regression Potential
  

  Minimal; test cases have been added to cover the duplication case, and
  to cover the enabling of sources (which was not covered by existing
  tests, but was part of the code altered to fix the duplication case),
  and insertion of sources at a position (again, not covered by existing
  tests but modified as part of the fix). The test case has been used
  successfully on all targeted releases (xenial, bionic, and eoan).

  Original Description
  

  Trusty Tahr 14.04

  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list
  deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y 
ppa:aims/aims-desktop
  gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created
  gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created
  gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com
  gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created
  gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported
  gpg: Total number processed: 1
  gpg:   imported: 1  (RSA: 1)
  OK
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb 
http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#

  That deb-src line should have stayed commented out, and not been
  duplicated. (Commented deb lines should of course be uncommented, as
  already fixed per https://bugs.launchpad.net/ubuntu/+source/python-
  apt/+bug/1042916 .)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1311056/+subscriptions

-- 
Mailing list: https://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 1311056] Re: [SRU] apt-add-repository adds duplicate commented/disabled source lines

[Dave Jones]

Successfully verified fixes on xenial, bionic, and eoan. The autopkgtest
regressions on xenial were due to flaky tests on i386 and armhf; these
have been re-run successfully. The regressions on bionic look like a
transient network failure (would be grateful if someone could attempt a
re-run on those). The same is true of one of the regressions on eoan;
the other *may* be (would be grateful if someone could attempt a re-run
of those too).

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

Title:
  [SRU] apt-add-repository adds duplicate commented/disabled source
  lines

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  Fix Committed
Status in python-apt source package in Bionic:
  Fix Committed
Status in python-apt source package in Eoan:
  Fix Committed

Bug description:
  Impact
  ==

  Under most circumstances, the impact is minimal (a few extra redundant
  comment lines in apt sources. However, if users are automating source
  removal / addition on a machine (as in comment 11), there is the
  potential to wind up with an excessively large (and thus slow to
  parse) apt sources configuration.

  Test packages for the supported releases are available from the
  following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/python-apt

  Built from the source which can be found in the following branches:

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-xenial

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-bionic

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-eoan

  Test Case
  =

  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the presence of one uncommented "deb" line, and one commented 
"deb-src" line
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the uncommented "deb" line is still there but the commented "deb-src" 
line has now been duplicated
  * sudo add-apt-repository ppa:waveform/python-apt
  * sudo apt upgrade  # update python-apt to fixed version
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note there has been no further duplication of the commented "deb-src" line

  Regression Potential
  

  Minimal; test cases have been added to cover the duplication case, and
  to cover the enabling of sources (which was not covered by existing
  tests, but was part of the code altered to fix the duplication case),
  and insertion of sources at a position (again, not covered by existing
  tests but modified as part of the fix). The test case has been used
  successfully on all targeted releases (xenial, bionic, and eoan).

  Original Description
  

  Trusty Tahr 14.04

  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list
  deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y 
ppa:aims/aims-desktop
  gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created
  gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created
  gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com
  gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created
  gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported
  gpg: Total number processed: 1
  gpg:   imported: 1  (RSA: 1)
  OK
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb 
http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#

  That deb-src line should have stayed commented out, and not been
  duplicated. (Commented deb lines should of course be uncommented, as
  already fixed per https://bugs.launchpad.net/ubuntu/+source/python-
  apt/+bug/1042916 .)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1311056/+subscriptions

-- 
Mailing list: https://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 1311056] Re: [SRU] apt-add-repository adds duplicate commented/disabled source lines

[Dave Jones]

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

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

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

Title:
  [SRU] apt-add-repository adds duplicate commented/disabled source
  lines

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  Fix Committed
Status in python-apt source package in Bionic:
  Fix Committed
Status in python-apt source package in Eoan:
  Fix Committed

Bug description:
  Impact
  ==

  Under most circumstances, the impact is minimal (a few extra redundant
  comment lines in apt sources. However, if users are automating source
  removal / addition on a machine (as in comment 11), there is the
  potential to wind up with an excessively large (and thus slow to
  parse) apt sources configuration.

  Test packages for the supported releases are available from the
  following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/python-apt

  Built from the source which can be found in the following branches:

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-xenial

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-bionic

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-eoan

  Test Case
  =

  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the presence of one uncommented "deb" line, and one commented 
"deb-src" line
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the uncommented "deb" line is still there but the commented "deb-src" 
line has now been duplicated
  * sudo add-apt-repository ppa:waveform/python-apt
  * sudo apt upgrade  # update python-apt to fixed version
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note there has been no further duplication of the commented "deb-src" line

  Regression Potential
  

  Minimal; test cases have been added to cover the duplication case, and
  to cover the enabling of sources (which was not covered by existing
  tests, but was part of the code altered to fix the duplication case),
  and insertion of sources at a position (again, not covered by existing
  tests but modified as part of the fix). The test case has been used
  successfully on all targeted releases (xenial, bionic, and eoan).

  Original Description
  

  Trusty Tahr 14.04

  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list
  deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y 
ppa:aims/aims-desktop
  gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created
  gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created
  gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com
  gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created
  gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported
  gpg: Total number processed: 1
  gpg:   imported: 1  (RSA: 1)
  OK
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb 
http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#

  That deb-src line should have stayed commented out, and not been
  duplicated. (Commented deb lines should of course be uncommented, as
  already fixed per https://bugs.launchpad.net/ubuntu/+source/python-
  apt/+bug/1042916 .)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1311056/+subscriptions

-- 
Mailing list: https://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 1311056] Re: [SRU] apt-add-repository adds duplicate commented/disabled source lines

[Dave Jones]

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

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

Title:
  [SRU] apt-add-repository adds duplicate commented/disabled source
  lines

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  Fix Committed
Status in python-apt source package in Bionic:
  Fix Committed
Status in python-apt source package in Eoan:
  Fix Committed

Bug description:
  Impact
  ==

  Under most circumstances, the impact is minimal (a few extra redundant
  comment lines in apt sources. However, if users are automating source
  removal / addition on a machine (as in comment 11), there is the
  potential to wind up with an excessively large (and thus slow to
  parse) apt sources configuration.

  Test packages for the supported releases are available from the
  following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/python-apt

  Built from the source which can be found in the following branches:

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-xenial

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-bionic

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-eoan

  Test Case
  =

  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the presence of one uncommented "deb" line, and one commented 
"deb-src" line
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the uncommented "deb" line is still there but the commented "deb-src" 
line has now been duplicated
  * sudo add-apt-repository ppa:waveform/python-apt
  * sudo apt upgrade  # update python-apt to fixed version
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note there has been no further duplication of the commented "deb-src" line

  Regression Potential
  

  Minimal; test cases have been added to cover the duplication case, and
  to cover the enabling of sources (which was not covered by existing
  tests, but was part of the code altered to fix the duplication case),
  and insertion of sources at a position (again, not covered by existing
  tests but modified as part of the fix). The test case has been used
  successfully on all targeted releases (xenial, bionic, and eoan).

  Original Description
  

  Trusty Tahr 14.04

  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list
  deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y 
ppa:aims/aims-desktop
  gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created
  gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created
  gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com
  gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created
  gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported
  gpg: Total number processed: 1
  gpg:   imported: 1  (RSA: 1)
  OK
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb 
http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#

  That deb-src line should have stayed commented out, and not been
  duplicated. (Commented deb lines should of course be uncommented, as
  already fixed per https://bugs.launchpad.net/ubuntu/+source/python-
  apt/+bug/1042916 .)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1311056/+subscriptions

-- 
Mailing list: https://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 1870410] Re: wireless does not work on boot on RPi 3s

[Dave Jones]

Confirmed test build in the PPA in comment 13 (245.4-4ubuntu3) fixes the
issue on both archs (armhf and arm64) on the Pi 3B, 3A+, and 3B+ (re-
tested 4B as well to ensure nothing broken, and it's still working).

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

Title:
  wireless does not work on boot on RPi 3s

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Focal:
  In Progress

Bug description:
  I've setup a wireless config in /etc/netplan/config.yaml and it does
  not activate on boot. I have to run 'sudo netplan apply' to get my
  wireless connected. This works fine on an RPi4 but not an RPi3B.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.2-1ubuntu2
  ProcVersionSignature: User Name 5.4.0-1006.6-raspi2 5.4.24
  Uname: Linux 5.4.0-1006-raspi2 armv7l
  ApportVersion: 2.20.11-0ubuntu21
  Architecture: armhf
  Date: Thu Apr  2 19:02:27 2020
  Lspci:
   
  Lsusb:
   Bus 001 Device 007: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) 
SMSC9512/9514 Fast Ethernet Adapter
   Bus 001 Device 006: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) 
SMC9514 Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
   |__ Port 1: Dev 6, If 0, Class=Hub, Driver=hub/5p, 480M
   |__ Port 1: Dev 7, If 0, Class=Vendor Specific Class, 
Driver=smsc95xx, 480M
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=656 
bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:FF:6B:0F 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  net.ifnames=0 
dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=LABEL=writable 
rootfstype=ext4 elevator=deadline rootwait fixrtc quiet splash
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://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 1870410] Re: wireless does not work on boot on RPi 3s

[Dave Jones]

I can confirm the behaviour Brian's seeing on the Pi 3B on armhf and
arm64 with systemd 245.4-2 from the PPA Balint mentioned (and the same
error message which appears to be from a chunk of code slightly beyond
where we were last time - so we're moving forward at least :).

As before, wifi is working fine on the Pi 4B under armhf and arm64.
Interestingly however, the Pi 3B+ (which shares the wifi chip with the
4B but is only slighter faster than the 3B) now has working wifi under
armhf, but not arm64 (same error as the 3B on arm64). I was slightly
surprised at this, so I double checked it with a couple of reboots -
same results each time.

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

Title:
  wireless does not work on boot on RPi 3s

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Focal:
  In Progress

Bug description:
  I've setup a wireless config in /etc/netplan/config.yaml and it does
  not activate on boot. I have to run 'sudo netplan apply' to get my
  wireless connected. This works fine on an RPi4 but not an RPi3B.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.2-1ubuntu2
  ProcVersionSignature: User Name 5.4.0-1006.6-raspi2 5.4.24
  Uname: Linux 5.4.0-1006-raspi2 armv7l
  ApportVersion: 2.20.11-0ubuntu21
  Architecture: armhf
  Date: Thu Apr  2 19:02:27 2020
  Lspci:
   
  Lsusb:
   Bus 001 Device 007: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) 
SMSC9512/9514 Fast Ethernet Adapter
   Bus 001 Device 006: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) 
SMC9514 Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
   |__ Port 1: Dev 6, If 0, Class=Hub, Driver=hub/5p, 480M
   |__ Port 1: Dev 7, If 0, Class=Vendor Specific Class, 
Driver=smsc95xx, 480M
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=656 
bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:FF:6B:0F 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  net.ifnames=0 
dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=LABEL=writable 
rootfstype=ext4 elevator=deadline rootwait fixrtc quiet splash
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://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 1870410] Re: wireless does not work on boot

[Dave Jones]

Also tested under armhf and arm64 on Raspberry Pi models 3B, 3A+, and
3B+. Results are the same as for bdmurray's tests with armhf on the 3B
above.

My initial suspicion was that this was related to the wifi chipset used
on the 3B (the BCM43430) to the 4B (the BCM43455). However, given the
3A+ and 3B+ also use the BCM43455 (same as the 4B) it's definitely not
that.

Given that the only error ("DHCP4 CLIENT: Failed to attach event...")
occurred in systemd-networkd I attempted to downgrade from version 245.2
to 244.3 (the prior release on Ubuntu). This fixes the issue on the 3B
and 3A+ under armhf and arm64 (I skipped checking the 3B+ for time at
this point).

At this point I'm reasonably confident it's an issue in systemd
introduced sometime between 244.3 and 245.2 - and that it may be timing
sensitive given that the 4B (which is significantly faster than the 3,
3A+ or 3B+) doesn't show the same symptoms but shares a wifi chipset
with the 3A+ and 3B+.

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

Title:
  wireless does not work on boot

Status in systemd package in Ubuntu:
  New

Bug description:
  I've setup a wireless config in /etc/netplan/config.yaml and it does
  not activate on boot. I have to run 'sudo netplan apply' to get my
  wireless connected. This works fine on an RPi4 but not an RPi3B.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.2-1ubuntu2
  ProcVersionSignature: User Name 5.4.0-1006.6-raspi2 5.4.24
  Uname: Linux 5.4.0-1006-raspi2 armv7l
  ApportVersion: 2.20.11-0ubuntu21
  Architecture: armhf
  Date: Thu Apr  2 19:02:27 2020
  Lspci:
   
  Lsusb:
   Bus 001 Device 007: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) 
SMSC9512/9514 Fast Ethernet Adapter
   Bus 001 Device 006: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) 
SMC9514 Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
   |__ Port 1: Dev 6, If 0, Class=Hub, Driver=hub/5p, 480M
   |__ Port 1: Dev 7, If 0, Class=Vendor Specific Class, 
Driver=smsc95xx, 480M
  ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=656 
bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:FF:6B:0F 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  net.ifnames=0 
dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=LABEL=writable 
rootfstype=ext4 elevator=deadline rootwait fixrtc quiet splash
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://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 1311056] Re: [SRU] apt-add-repository adds duplicate commented/disabled source lines

[Dave Jones]

** Changed in: python-apt (Ubuntu Eoan)
 Assignee: (unassigned) => Dave Jones (waveform)

** Changed in: python-apt (Ubuntu Xenial)
 Assignee: (unassigned) => Dave Jones (waveform)

** Changed in: python-apt (Ubuntu Bionic)
 Assignee: (unassigned) => Dave Jones (waveform)

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

Title:
  [SRU] apt-add-repository adds duplicate commented/disabled source
  lines

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  New
Status in python-apt source package in Bionic:
  New
Status in python-apt source package in Eoan:
  New

Bug description:
  Impact
  ==

  Under most circumstances, the impact is minimal (a few extra redundant
  comment lines in apt sources. However, if users are automating source
  removal / addition on a machine (as in comment 11), there is the
  potential to wind up with an excessively large (and thus slow to
  parse) apt sources configuration.

  Test packages for the supported releases are available from the
  following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/python-apt

  Built from the source which can be found in the following branches:

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-xenial

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-bionic

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-eoan

  Test Case
  =

  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the presence of one uncommented "deb" line, and one commented 
"deb-src" line
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the uncommented "deb" line is still there but the commented "deb-src" 
line has now been duplicated
  * sudo add-apt-repository ppa:waveform/python-apt
  * sudo apt upgrade  # update python-apt to fixed version
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note there has been no further duplication of the commented "deb-src" line

  Regression Potential
  

  Minimal; test cases have been added to cover the duplication case, and
  to cover the enabling of sources (which was not covered by existing
  tests, but was part of the code altered to fix the duplication case),
  and insertion of sources at a position (again, not covered by existing
  tests but modified as part of the fix). The test case has been used
  successfully on all targeted releases (xenial, bionic, and eoan).

  Original Description
  

  Trusty Tahr 14.04

  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list
  deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y 
ppa:aims/aims-desktop
  gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created
  gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created
  gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com
  gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created
  gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported
  gpg: Total number processed: 1
  gpg:   imported: 1  (RSA: 1)
  OK
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb 
http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#

  That deb-src line should have stayed commented out, and not been
  duplicated. (Commented deb lines should of course be uncommented, as
  already fixed per https://bugs.launchpad.net/ubuntu/+source/python-
  apt/+bug/1042916 .)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1311056/+subscriptions

-- 
Mailing list: https://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 1311056] Re: [SRU] apt-add-repository adds duplicate commented/disabled source lines

[Dave Jones]

** Description changed:

  Impact
  ==
  
  Under most circumstances, the impact is minimal (a few extra redundant
  comment lines in apt sources. However, if users are automating source
  removal / addition on a machine (as in comment 11), there is the
  potential to wind up with an excessively large (and thus slow to parse)
  apt sources configuration.
+ 
+ Test packages for the supported releases are available from the
+ following PPA:
+ 
+ https://launchpad.net/~waveform/+archive/ubuntu/python-apt
+ 
+ Built from the source which can be found in the following branches:
+ 
+ https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
+ /python-apt/+ref/sru-dupe-ppa-xenial
+ 
+ https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
+ /python-apt/+ref/sru-dupe-ppa-bionic
+ 
+ https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
+ /python-apt/+ref/sru-dupe-ppa-eoan
  
  Test Case
  =
  
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the presence of one uncommented "deb" line, and one commented 
"deb-src" line
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the uncommented "deb" line is still there but the commented "deb-src" 
line has now been duplicated
  * sudo add-apt-repository ppa:waveform/python-apt
  * sudo apt upgrade  # update python-apt to fixed version
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note there has been no further duplication of the commented "deb-src" line
  
  Regression Potential
  
  
  Minimal; test cases have been added to cover the duplication case, and
  to cover the enabling of sources (which was not covered by existing
  tests, but was part of the code altered to fix the duplication case),
  and insertion of sources at a position (again, not covered by existing
  tests but modified as part of the fix). The test case has been used
  successfully on all targeted releases (xenial, bionic, and eoan).
  
  Original Description
  
  
  Trusty Tahr 14.04
  
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list
  deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y 
ppa:aims/aims-desktop
  gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created
  gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created
  gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com
  gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created
  gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported
  gpg: Total number processed: 1
  gpg:   imported: 1  (RSA: 1)
  OK
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb 
http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#
  
  That deb-src line should have stayed commented out, and not been
  duplicated. (Commented deb lines should of course be uncommented, as
  already fixed per https://bugs.launchpad.net/ubuntu/+source/python-
  apt/+bug/1042916 .)

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

Title:
  [SRU] apt-add-repository adds duplicate commented/disabled source
  lines

Status in python-apt package in Ubuntu:
  Fix Released
Status in python-apt source package in Xenial:
  New
Status in python-apt source package in Bionic:
  New
Status in python-apt source package in Eoan:
  New

Bug description:
  Impact
  ==

  Under most circumstances, the impact is minimal (a few extra redundant
  comment lines in apt sources. However, if users are automating source
  removal / addition on a machine (as in comment 11), there is the
  potential to wind up with an excessively large (and thus slow to
  parse) apt sources configuration.

  Test packages for the supported releases are available from the
  following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/python-apt

  Built from the source which can be found in the following branches:

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-xenial

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-bionic

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
  /python-apt/+ref/sru-dupe-ppa-eoan

  Test Case
  =

  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the presence of one uncommented "deb" line, and one commented 

[Touch-packages] [Bug 1311056] Re: apt-add-repository adds duplicate commented/disabled source lines

[Dave Jones]

** Description changed:

+ Impact
+ ==
+ 
+ Under most circumstances, the impact is minimal (a few extra redundant
+ comment lines in apt sources. However, if users are automating source
+ removal / addition on a machine (as in comment 11), there is the
+ potential to wind up with an excessively large (and thus slow to parse)
+ apt sources configuration.
+ 
+ Test Case
+ =
+ 
+ * sudo add-apt-repository -y ppa:deadsnakes/ppa
+ * cat /etc/apt/sources.list.d/deadsnakes*.list
+ * Note the presence of one uncommented "deb" line, and one commented 
"deb-src" line
+ * sudo add-apt-repository -y ppa:deadsnakes/ppa
+ * cat /etc/apt/sources.list.d/deadsnakes*.list
+ * Note the uncommented "deb" line is still there but the commented "deb-src" 
line has now been duplicated
+ * Upgrade python-apt to 1.9.3ubuntu2 (or later)
+ * sudo add-apt-repository -y ppa:deadsnakes/ppa
+ * cat /etc/apt/sources.list.d/deadsnakes*.list
+ * Note there has been no further duplication of the commented "deb-src" line
+ 
+ Regression Potential
+ 
+ 
+ Minimal; test cases have been added to cover the duplication case, and
+ to cover the enabling of sources (which was not covered by existing
+ tests, but was part of the code altered to fix the duplication case),
+ and insertion of sources at a position (again, not covered by existing
+ tests but modified as part of the fix). The test case has been used
+ successfully on all targeted releases (xenial, bionic, and eoan).
+ 
+ Original Description
+ 
+ 
  Trusty Tahr 14.04
  
- 0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list 
+ 0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list
  deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y 
ppa:aims/aims-desktop
  gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created
  gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created
  gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com
  gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created
  gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported
  gpg: Total number processed: 1
  gpg:   imported: 1  (RSA: 1)
  OK
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb 
http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#
  
  That deb-src line should have stayed commented out, and not been
  duplicated. (Commented deb lines should of course be uncommented, as
  already fixed per https://bugs.launchpad.net/ubuntu/+source/python-
  apt/+bug/1042916 .)

** Summary changed:

- apt-add-repository adds duplicate commented/disabled source lines
+ [SRU] apt-add-repository adds duplicate commented/disabled source lines

** Description changed:

  Impact
  ==
  
  Under most circumstances, the impact is minimal (a few extra redundant
  comment lines in apt sources. However, if users are automating source
  removal / addition on a machine (as in comment 11), there is the
  potential to wind up with an excessively large (and thus slow to parse)
  apt sources configuration.
  
  Test Case
  =
  
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the presence of one uncommented "deb" line, and one commented 
"deb-src" line
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note the uncommented "deb" line is still there but the commented "deb-src" 
line has now been duplicated
- * Upgrade python-apt to 1.9.3ubuntu2 (or later)
+ * sudo add-apt-repository ppa:waveform/python-apt
+ * sudo apt upgrade  # update python-apt to fixed version
  * sudo add-apt-repository -y ppa:deadsnakes/ppa
  * cat /etc/apt/sources.list.d/deadsnakes*.list
  * Note there has been no further duplication of the commented "deb-src" line
  
  Regression Potential
  
  
  Minimal; test cases have been added to cover the duplication case, and
  to cover the enabling of sources (which was not covered by existing
  tests, but was part of the code altered to fix the duplication case),
  and insertion of sources at a position (again, not covered by existing
  tests but modified as part of the fix). The test case has been used
  successfully on all targeted releases (xenial, bionic, and eoan).
  
  Original Description
  
  
  Trusty Tahr 14.04
  
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list
  deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#apt-add-repository 

[Touch-packages] [Bug 1859610] Re: python-gi/arm64 segfaults with the focal-proposed libffi version

[Dave Jones]

> so this is not completely updated to focal-proposed?

No, that was just certain focal-proposed packages on a focal image (on a
pi4). Have now re-run with a full focal-proposed chroot (under the same
focal image), and that doesn't reproduce the issue:

(focal-arm64)root@ubuntu:~# cat /etc/apt/sources.list
deb http://ports.ubuntu.com/ubuntu-ports focal main restricted universe 
multiverse
deb-src http://ports.ubuntu.com/ubuntu-ports focal main restricted universe 
multiverse
deb http://ports.ubuntu.com/ubuntu-ports focal-updates main restricted universe 
multiverse
deb-src http://ports.ubuntu.com/ubuntu-ports focal-updates main restricted 
universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports focal-proposed main restricted 
universe multiverse
deb-src http://ports.ubuntu.com/ubuntu-ports focal-proposed main restricted 
universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports focal-security main restricted 
universe multiverse
deb-src http://ports.ubuntu.com/ubuntu-ports focal-security main restricted 
universe multiverse
(focal-arm64)root@ubuntu:~# dpkg -l | grep -e "libffi" -e "python3"
ii  libffi6:arm64 3.2.1-9 arm64
Foreign Function Interface library runtime
ii  libffi7:arm64 3.3-3   arm64
Foreign Function Interface library runtime
ii  libpython3-stdlib:arm64   3.7.5-1ubuntu1  arm64
interactive high-level object-oriented language (default python3 version)
ii  libpython3.7-minimal:arm643.7.6-1ubuntu2  arm64
Minimal subset of the Python language (version 3.7)
ii  libpython3.7-stdlib:arm64 3.7.6-1ubuntu2  arm64
Interactive high-level object-oriented language (standard library, version 3.7)
ii  python3   3.7.5-1ubuntu1  arm64
interactive high-level object-oriented language (default python3 version)
ii  python3-cairo:arm64   1.16.2-2ubuntu1 arm64
Python3 bindings for the Cairo vector graphics library
ii  python3-gi3.34.0-3build2  arm64
Python 3 bindings for gobject-introspection libraries
ii  python3-gi-cairo  3.34.0-3build2  arm64
Python 3 Cairo bindings for the GObject library
ii  python3-goocalendar   0.5-1   all  
Calendar widget for GTK+ using PyGoocanvas (Python 3)
ii  python3-minimal   3.7.5-1ubuntu1  arm64
minimal subset of the Python language (default python3 version)
ii  python3-pkg-resources 44.0.0-1all  
Package Discovery and Resource Access using pkg_resources
ii  python3.7 3.7.6-1ubuntu2  arm64
Interactive high-level object-oriented language (version 3.7)
ii  python3.7-minimal 3.7.6-1ubuntu2  arm64
Minimal subset of the Python language (version 3.7)
(focal-arm64)root@ubuntu:~# python3 -c "import goocalendar; 
print(goocalendar.__version__)"
Unable to init server: Could not connect: Connection refused
Unable to init server: Could not connect: Connection refused
0.5

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

Title:
  python-gi/arm64 segfaults with the focal-proposed libffi version

Status in libffi package in Ubuntu:
  Fix Committed
Status in pygobject package in Ubuntu:
  New
Status in libffi source package in Focal:
  Fix Committed
Status in pygobject source package in Focal:
  New

Bug description:
  Testcase, on focal/arm64

  $ sudo apt install python3-goocalendar
  $ python3 -c "import goocalendar ; print(goocalendar.__version__)"

  -> works fine

  install the python3-gi package from focal-proposed it segfaults in
  libffi

  Program received signal SIGSEGV, Segmentation fault.
  0x in ?? ()
  (gdb) bt
  #0  0x in ?? ()
  #1  0xf7390ff8 in ffi_call_SYSV () at ../src/aarch64/sysv.S:114
  #2  0xf7390634 in ffi_call_int (cif=0xa12d78, fn=, 
  orig_rvalue=, avalue=0x0, closure=)

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

-- 
Mailing list: https://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 1859610] Re: python-gi/arm64 segfaults with the focal-proposed libffi version

[Dave Jones]

> Do you have the new python3.7 installed from focal-proposed?

> note, i was running everything from proposed. Since libffi6 & 7 might
> be used by python3.7.

Ah, no I didn't. However, doesn't seem like it makes much difference:

ubuntu@ubuntu:~$ sudo apt install -t focal-proposed python3.7
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libpython3.7 libpython3.7-dbg libpython3.7-minimal libpython3.7-stdlib 
python3.7-dbg python3.7-minimal
Suggested packages:
  python3.7-venv python3.7-doc python3-gdbm-dbg python3-tk-dbg binfmt-support
The following packages will be upgraded:
  libpython3.7 libpython3.7-dbg libpython3.7-minimal libpython3.7-stdlib 
python3.7 python3.7-dbg
  python3.7-minimal
7 upgraded, 0 newly installed, 0 to remove and 72 not upgraded.
Need to get 32.9 MB of archives.
After this operation, 26.6 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 
python3.7-dbg arm64 3.7.6-1ubuntu2 [15.9 MB]
Get:2 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 python3.7 
arm64 3.7.6-1ubuntu2 [304 kB]
Get:3 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 
libpython3.7 arm64 3.7.6-1ubuntu2 [1373 kB]
Get:4 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 
libpython3.7-dbg arm64 3.7.6-1ubuntu2 [11.4 MB]
Get:5 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 
libpython3.7-stdlib arm64 3.7.6-1ubuntu2 [1717 kB]
Get:6 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 
python3.7-minimal arm64 3.7.6-1ubuntu2 [1723 kB]
Get:7 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 
libpython3.7-minimal arm64 3.7.6-1ubuntu2 [547 kB]
Fetched 32.9 MB in 25s (1316 kB/s)
(Reading database ... 80531 files and directories currently installed.)
Preparing to unpack .../0-python3.7-dbg_3.7.6-1ubuntu2_arm64.deb ...
Unpacking python3.7-dbg (3.7.6-1ubuntu2) over (3.7.6-1) ...
Preparing to unpack .../1-python3.7_3.7.6-1ubuntu2_arm64.deb ...
Unpacking python3.7 (3.7.6-1ubuntu2) over (3.7.6-1) ...
Preparing to unpack .../2-libpython3.7_3.7.6-1ubuntu2_arm64.deb ...
Unpacking libpython3.7:arm64 (3.7.6-1ubuntu2) over (3.7.6-1) ...
Preparing to unpack .../3-libpython3.7-dbg_3.7.6-1ubuntu2_arm64.deb ...
Unpacking libpython3.7-dbg:arm64 (3.7.6-1ubuntu2) over (3.7.6-1) ...
Preparing to unpack .../4-libpython3.7-stdlib_3.7.6-1ubuntu2_arm64.deb ...
Unpacking libpython3.7-stdlib:arm64 (3.7.6-1ubuntu2) over (3.7.6-1) ...
Preparing to unpack .../5-python3.7-minimal_3.7.6-1ubuntu2_arm64.deb ...
Unpacking python3.7-minimal (3.7.6-1ubuntu2) over (3.7.6-1) ...
Preparing to unpack .../6-libpython3.7-minimal_3.7.6-1ubuntu2_arm64.deb ...
Unpacking libpython3.7-minimal:arm64 (3.7.6-1ubuntu2) over (3.7.6-1) ...
Setting up libpython3.7-minimal:arm64 (3.7.6-1ubuntu2) ...
Setting up python3.7-minimal (3.7.6-1ubuntu2) ...
Setting up libpython3.7-stdlib:arm64 (3.7.6-1ubuntu2) ...
Setting up libpython3.7:arm64 (3.7.6-1ubuntu2) ...
Setting up libpython3.7-dbg:arm64 (3.7.6-1ubuntu2) ...
Setting up python3.7 (3.7.6-1ubuntu2) ...
Setting up python3.7-dbg (3.7.6-1ubuntu2) ...
Processing triggers for libc-bin (2.30-0ubuntu3) ...
Processing triggers for man-db (2.9.0-2) ...
Processing triggers for mime-support (3.64ubuntu1) ...
ubuntu@ubuntu:~$ python3 -c "import goocalendar; print(goocalendar.__version__)"
Segmentation fault (core dumped)

I'll keep the SD card around for a few days if you want me to dig into
this any further.

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

Title:
  python-gi/arm64 segfaults with the focal-proposed libffi version

Status in libffi package in Ubuntu:
  Incomplete
Status in libffi source package in Focal:
  Incomplete

Bug description:
  Testcase, on focal/arm64

  $ sudo apt install python3-goocalendar
  $ python3 -c "import goocalendar ; print(goocalendar.__version__)"

  -> works fine

  install the python3-gi package from focal-proposed it segfaults in
  libffi

  Program received signal SIGSEGV, Segmentation fault.
  0x in ?? ()
  (gdb) bt
  #0  0x in ?? ()
  #1  0xf7390ff8 in ffi_call_SYSV () at ../src/aarch64/sysv.S:114
  #2  0xf7390634 in ffi_call_int (cif=0xa12d78, fn=, 
  orig_rvalue=, avalue=0x0, closure=)

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

-- 
Mailing list: https://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 1859610] Re: python-gi/arm64 segfaults with the focal-proposed libffi version

[Dave Jones]

Reproduced on a Pi4 running the current focal daily:

ubuntu@ubuntu:~$ python3 -c "import goocalendar; 
print(goocalendar.__version__)" 
  
Unable to init server: Could not connect: Connection refused
Unable to init server: Could not connect: Connection refused
0.5
ubuntu@ubuntu:~$ sudo apt install -t focal-proposed python3-gi
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  libffi7 python3-gi-cairo
The following NEW packages will be installed:
  libffi7
The following packages will be upgraded:
  python3-gi python3-gi-cairo
2 upgraded, 1 newly installed, 0 to remove and 85 not upgraded.
Need to get 220 kB of archives.
After this operation, 60.4 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 
python3-gi-cairo arm64 3.34.0-3build2 [8336 B]
Get:2 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 libffi7 
arm64 3.3-2.3build1 [17.1 kB]
Get:3 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 python3-gi 
arm64 3.34.0-3build2 [195 kB]
Fetched 220 kB in 2s (114 kB/s)  
(Reading database ... 79794 files and directories currently installed.)
Preparing to unpack .../python3-gi-cairo_3.34.0-3build2_arm64.deb ...
Unpacking python3-gi-cairo (3.34.0-3build2) over (3.34.0-3) ...
Selecting previously unselected package libffi7:arm64.
Preparing to unpack .../libffi7_3.3-2.3build1_arm64.deb ...
Unpacking libffi7:arm64 (3.3-2.3build1) ...
Preparing to unpack .../python3-gi_3.34.0-3build2_arm64.deb ...
Unpacking python3-gi (3.34.0-3build2) over (3.34.0-3) ...
Setting up libffi7:arm64 (3.3-2.3build1) ...
Setting up python3-gi (3.34.0-3build2) ...
Setting up python3-gi-cairo (3.34.0-3build2) ...
Processing triggers for libc-bin (2.30-0ubuntu3) ...
ubuntu@ubuntu:~$ python3 -c "import goocalendar; print(goocalendar.__version__)"
Segmentation fault (core dumped)

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

Title:
  python-gi/arm64 segfaults with the focal-proposed libffi version

Status in libffi package in Ubuntu:
  Incomplete
Status in libffi source package in Focal:
  Incomplete

Bug description:
  Testcase, on focal/arm64

  $ sudo apt install python3-goocalendar
  $ python3 -c "import goocalendar ; print(goocalendar.__version__)"

  -> works fine

  install the python3-gi package from focal-proposed it segfaults in
  libffi

  Program received signal SIGSEGV, Segmentation fault.
  0x in ?? ()
  (gdb) bt
  #0  0x in ?? ()
  #1  0xf7390ff8 in ffi_call_SYSV () at ../src/aarch64/sysv.S:114
  #2  0xf7390634 in ffi_call_int (cif=0xa12d78, fn=, 
  orig_rvalue=, avalue=0x0, closure=)

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

-- 
Mailing list: https://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 1311056] Re: apt-add-repository adds duplicate commented/disabled source lines

[Dave Jones]

I have an updated patch available from the following branch for focal:

https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
/python-apt/+ref/fix-dupe-ppa


Currently building a test package in the following PPA:

https://launchpad.net/~waveform/+archive/ubuntu/python-apt/+packages

I realize most of the people affected by this are on older
distributions, so I'm just in the process of back-porting the patch to
bionic, xenial, and trusty, and will provide test builds in the same PPA
once that's done.

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

Title:
  apt-add-repository adds duplicate commented/disabled source lines

Status in python-apt package in Ubuntu:
  Triaged
Status in software-properties package in Ubuntu:
  Triaged

Bug description:
  Trusty Tahr 14.04

  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list 
  deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y 
ppa:aims/aims-desktop
  gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created
  gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created
  gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com
  gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created
  gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported
  gpg: Total number processed: 1
  gpg:   imported: 1  (RSA: 1)
  OK
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb 
http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#

  That deb-src line should have stayed commented out, and not been
  duplicated. (Commented deb lines should of course be uncommented, as
  already fixed per https://bugs.launchpad.net/ubuntu/+source/python-
  apt/+bug/1042916 .)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1311056/+subscriptions

-- 
Mailing list: https://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 90085] Re: When /tmp is mounted noexec, preconfigure fails

[Dave Jones]

@jblainemitre indeed - but presumably one can pick any directory? I'm
assuming there's no particular requirement that the selected dir is
world-writeable like /tmp and /var/tmp (or at least there doesn't seem
to be in my setup?)

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

Title:
  When /tmp is mounted noexec, preconfigure fails

Status in debconf package in Ubuntu:
  Triaged
Status in debconf package in Debian:
  Confirmed

Bug description:
  Binary package hint: mysql-server

  
  /tmp mounted noexec, this ensues:

  
  Preconfiguring packages ...
  Can't exec "/tmp/mysql-server-5.0.config.89611": Permission denied at 
/usr/share/perl/5.8/IPC/Open3.pm line 168.
  open2: exec of /tmp/mysql-server-5.0.config.89611 configure  failed at 
/usr/share/perl5/Debconf/ConfModule.pm line 57
  mysql-server-5.0 failed to preconfigure, with exit status 2

  ace

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

-- 
Mailing list: https://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 1849435] Re: could not find a distribution template for Ubuntu/focal

[Dave Jones]

Please note for testing:

add-apt-repository does not operate without the updated package either,
so just download the relevant .debs and install manually with "sudo dpkg
-i" for testing. The package that's really needed is python-apt-common
(which contains the updated template output), but you may as well update
python3-apt as well for the sake of testing.

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

Title:
  could not find a distribution template for Ubuntu/focal

Status in python-apt package in Ubuntu:
  In Progress

Bug description:
  software-properties-gtk crashed with
  aptsources.distro.NoDistroTemplateException in get_sources():

  Click on software-properties-gtk icon: I have a message about crash,
  click on 'send' nothing happen.

  I attached crash file

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1849435/+subscriptions

-- 
Mailing list: https://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 1849435] Re: could not find a distribution template for Ubuntu/focal

[Dave Jones]

Updated python-apt package available in the following PPA:

  https://launchpad.net/~waveform/+archive/ubuntu/pkg

Branch from which the package was built:

  https://code.launchpad.net/~waveform/ubuntu/+source/python-apt/+git
/python-apt/+ref/focal-entry

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

Title:
  could not find a distribution template for Ubuntu/focal

Status in python-apt package in Ubuntu:
  In Progress

Bug description:
  software-properties-gtk crashed with
  aptsources.distro.NoDistroTemplateException in get_sources():

  Click on software-properties-gtk icon: I have a message about crash,
  click on 'send' nothing happen.

  I attached crash file

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1849435/+subscriptions

-- 
Mailing list: https://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 1849435] Re: could not find a distribution template for Ubuntu/focal

[Dave Jones]

** Changed in: python-apt (Ubuntu)
 Assignee: (unassigned) => Dave Jones (waveform)

** Changed in: python-apt (Ubuntu)
   Status: New => In Progress

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

Title:
  could not find a distribution template for Ubuntu/focal

Status in python-apt package in Ubuntu:
  In Progress

Bug description:
  software-properties-gtk crashed with
  aptsources.distro.NoDistroTemplateException in get_sources():

  Click on software-properties-gtk icon: I have a message about crash,
  click on 'send' nothing happen.

  I attached crash file

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1849435/+subscriptions

-- 
Mailing list: https://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 1832414] Re: Removing document files spam from cups

[Dave Jones]

For anyone else that encounters this, running "cancel -x -a" to delete
everything from the queue (including historical control files) seems to
have cured the problem. Sorry for not keeping the evidence around, but
I'm afraid after it generated 70Mb of logs in two days I needed to fix
it :)

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

Title:
  Removing document files spam from cups

Status in cups package in Ubuntu:
  New

Bug description:
  Since my server (running xenial) updated to cups 2.1.3-4ubuntu0.9 last
  night the CUPS logs have had a considerable number of messages from
  cupsd stating "Removing document files" - about 3 or 4 a second
  constantly. Stopping the cups service stops the log-spam, and starting
  it again immediately resumes it (after a few hundred "Loading from
  cache..." messages). I've tried removing document files from the cache
  (there were a couple of ancient ones lying around - it's not a heavily
  used printer), but this made little difference to the symptoms.

  I'm pretty confident this is due to the upgrade as:

  1. the spam in the logs starts immediately after CUPS reloads (after
  the upgrade)

  2. looking at the diff for 2.1.3-4ubuntu0.9 it does seem to be
  fiddling with things related to job clean-up (e.g. cupsdUpdateJobs and
  cupsdCleanJobs in scheduler/job.c)

  If I can provide any further information, do let me know!

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

-- 
Mailing list: https://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 1832414] [NEW] Removing document files spam from cups

[Dave Jones]

Public bug reported:

Since my server (running xenial) updated to cups 2.1.3-4ubuntu0.9 last
night the CUPS logs have had a considerable number of messages from
cupsd stating "Removing document files" - about 3 or 4 a second
constantly. Stopping the cups service stops the log-spam, and starting
it again immediately resumes it (after a few hundred "Loading from
cache..." messages). I've tried removing document files from the cache
(there were a couple of ancient ones lying around - it's not a heavily
used printer), but this made little difference to the symptoms.

I'm pretty confident this is due to the upgrade as:

1. the spam in the logs starts immediately after CUPS reloads (after the
upgrade)

2. looking at the diff for 2.1.3-4ubuntu0.9 it does seem to be fiddling
with things related to job clean-up (e.g. cupsdUpdateJobs and
cupsdCleanJobs in scheduler/job.c)

If I can provide any further information, do let me know!

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

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

Title:
  Removing document files spam from cups

Status in cups package in Ubuntu:
  New

Bug description:
  Since my server (running xenial) updated to cups 2.1.3-4ubuntu0.9 last
  night the CUPS logs have had a considerable number of messages from
  cupsd stating "Removing document files" - about 3 or 4 a second
  constantly. Stopping the cups service stops the log-spam, and starting
  it again immediately resumes it (after a few hundred "Loading from
  cache..." messages). I've tried removing document files from the cache
  (there were a couple of ancient ones lying around - it's not a heavily
  used printer), but this made little difference to the symptoms.

  I'm pretty confident this is due to the upgrade as:

  1. the spam in the logs starts immediately after CUPS reloads (after
  the upgrade)

  2. looking at the diff for 2.1.3-4ubuntu0.9 it does seem to be
  fiddling with things related to job clean-up (e.g. cupsdUpdateJobs and
  cupsdCleanJobs in scheduler/job.c)

  If I can provide any further information, do let me know!

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

-- 
Mailing list: https://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 1670291] Re: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

[Dave Jones]

> /sbin/shutdown, post upgrade not working, imho is a severe bug

I suspect no-one's bothered to report it because as soon as the machine
is (somehow) rebooted, the issue goes away (and reproduction then
involves the pain of going through a trusty install + xenial upgrade
cycle). Still, I'm not entirely convinced this *is* a bug; I'll come
back to this in a bit below...

> I guess the scheduling of timeout is failing, but /sbin/shutdown now
works?

I thought I'd tested this and concluded it didn't, but it turns out I
just didn't wait long enough. When trying "shutdown -r now" there's a
fair delay, then it complains about a connection time out, exits with an
error, and the system reboots anyway!

ubuntu@client1:~$ sudo shutdown -r now
Failed to start reboot.target: Connection timed out
See system logs and 'systemctl status reboot.target' for details.
ubuntu@client1:~$ packet_write_wait: Connection to 10.123.236.170 port 22: 
Broken pipe

So, it is mostly likely the scheduling portion that's failing, and if
given an immediate request the operation does still work. I haven't got
time to test the -h switch as well, but I'd assume it's probably a
similar story.

Now consider those two cases from the perspective of a human
administrator:

If you've typed "shutdown -r now" you're expecting an immediate reboot.
Even if some bits of the shutdown command fail, you still expect it to
do what you asked: reboot immediately. However, if you've just typed
"shutdown -r +5" you're expecting a 5 minute delay before reboot. If it
can't schedule that delay would you rather it exit with an error and
tell you, or just immediately reboot the system? Probably the former
given you're not expecting an immediate reboot.

The issue in this case was that it isn't a human scheduling the reboot
(directly) and the only reason landscape uses the schedule at all is to
determine whether the shutdown command has (likely) worked. Which is a
bit of an abuse of the shutdown command's scheduling facility, but I
can't think of a better way off the top of my head (that'll reliably
work in all implementations).

Anyway, in landscape's case we *would* rather the system immediately
reboots when shutdown fails because the delay's only there for the
Landscape client's benefit, and we can't guarantee the administrator has
any other means of accessing the system for the purpose of rebooting it.
So in a sense we're dealing with an interface mismatch: shutdown is
(understandably) written for the (direct) use of a human administrator,
and landscape is (ab)using it to provide reboot/poweroff facilities on
(indirect) behalf of a human administrator.

So we come back to "I can't think of a better way of doing it" (that'll
reliably work in all our aforementioned scenarios of upstart, systemd,
and post-upgrade-almost-sort-of-systemd).

> Re differences between halt & poweroff, in systemd, eventually it results in:
> [snip]

Yes, but have a look at the arg parsing earlier on
(https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c#L8069):

case 'h':
if (arg_action != ACTION_HALT)
arg_action = ACTION_POWEROFF;
break;

In systemd, the -H and --halt options mean halt, but -h is just an alias
for -P and --poweroff (unless -H or --halt also appear in the argument
list ... which looks a bit weird to me, but it is what their man-page
states as well, so I guess it's intentional?). I haven't dug into
upstart's implementation but I assume from your comments that it's
different, and that -h actually means halt.

Thanks for the link on the differences between halt and power-off - I'd
not seen that before!

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

Title:
  Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

Status in landscape-client package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Incomplete
Status in landscape-client source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Incomplete

Bug description:
  Used Landscape (Paid Canonical Subscription) to upgrade one of my
  machines.

  Landscape only shows "In Progress" for more than 8 hours now and asked
  for a reboot of the machine in a second alert.

  In the reboot attempt I get the message:
  =
  Failed to set wall message, ignoring: Method "SetWallMessage" with signature 
"sb" on interface "org.freedesktop.login1.Manager" doesn't exist
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Method "ScheduleShutdown" with signature "st" on interface 
"org.freedesktop.login1.Manager" doesn't exist
  =

  Steps to reproduce:
  * Fully updated 14.04.5 machine
  * Open Landscape
  * Choose the machine
  * Choose Packages
  * This computer can be upgraded to a newer release
  

[Touch-packages] [Bug 1670291] Re: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

[Dave Jones]

@xnox Scheduling with /sbin/shutdown normally does work ... however,
what we're dealing with here is the anomalous situation of an instance
which starts off as trusty and is upgraded to xenial. During the upgrade
process, the /sbin/shutdown implementation is changed from the upstart
one to the systemd one. At the end of the process, /sbin/shutdown is
(unsurprisingly) a link to systemctl ... but it doesn't work because
it's expecting to be able to talk to systemd which isn't fully
operational until a reboot. As Landscape is expecting to be able to
reboot via /sbin/shutdown the user relying on Landscape in such a
scenario finds themselves in a bit of a bind (having to have some other
means of dealing with the server, like SSH).

However, /sbin/reboot and /sbin/poweroff *do* work in this (admittedly
rare) scenario, hence the patches committed for this issue leave the
system using /sbin/shutdown by default but if/when it fails, they fall
back to trying /sbin/reboot or /sbin/poweroff (as appropriate) instead.

As to why -h is used instead of -P, in systemd's implementation of
/sbin/shutdown they're exactly the same thing. In the upstart
implementation it's more vague; quoting from the man-page: "Requests
that the system be either halted or powered off after it has been
brought down, with the choice as to which left up to the system". I'm
not sure what that means in practice though!

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

Title:
  Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

Status in landscape-client package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Incomplete
Status in landscape-client source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Incomplete

Bug description:
  Used Landscape (Paid Canonical Subscription) to upgrade one of my
  machines.

  Landscape only shows "In Progress" for more than 8 hours now and asked
  for a reboot of the machine in a second alert.

  In the reboot attempt I get the message:
  =
  Failed to set wall message, ignoring: Method "SetWallMessage" with signature 
"sb" on interface "org.freedesktop.login1.Manager" doesn't exist
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Method "ScheduleShutdown" with signature "st" on interface 
"org.freedesktop.login1.Manager" doesn't exist
  =

  Steps to reproduce:
  * Fully updated 14.04.5 machine
  * Open Landscape
  * Choose the machine
  * Choose Packages
  * This computer can be upgraded to a newer release
  * Apply
  * Wait 2 hours
  * Alert comes in a seperate Landscape message Machine is ready for reboot
  * Choose Info... Power
  * Deliver to selected computers as soon as possible
  * Error message

  I found this thread on reddit about this issue maybe the solution can be 
built into the upgrade script
  
https://www.reddit.com/r/linuxquestions/comments/4wy3go/trying_to_run_as_user_instance_but_the_system_has/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1670291/+subscriptions

-- 
Mailing list: https://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 1670291] Re: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

[Dave Jones]

** Changed in: landscape-client (Ubuntu)
   Status: In Progress => Fix Committed

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

Title:
  Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

Status in landscape-client package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Incomplete
Status in landscape-client source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Incomplete

Bug description:
  Used Landscape (Paid Canonical Subscription) to upgrade one of my
  machines.

  Landscape only shows "In Progress" for more than 8 hours now and asked
  for a reboot of the machine in a second alert.

  In the reboot attempt I get the message:
  =
  Failed to set wall message, ignoring: Method "SetWallMessage" with signature 
"sb" on interface "org.freedesktop.login1.Manager" doesn't exist
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Method "ScheduleShutdown" with signature "st" on interface 
"org.freedesktop.login1.Manager" doesn't exist
  =

  Steps to reproduce:
  * Fully updated 14.04.5 machine
  * Open Landscape
  * Choose the machine
  * Choose Packages
  * This computer can be upgraded to a newer release
  * Apply
  * Wait 2 hours
  * Alert comes in a seperate Landscape message Machine is ready for reboot
  * Choose Info... Power
  * Deliver to selected computers as soon as possible
  * Error message

  I found this thread on reddit about this issue maybe the solution can be 
built into the upgrade script
  
https://www.reddit.com/r/linuxquestions/comments/4wy3go/trying_to_run_as_user_instance_but_the_system_has/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1670291/+subscriptions

-- 
Mailing list: https://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 1670291] Re: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

[Dave Jones]

I've now pushed a PR which should alleviate the reboot issue
*partially*. The complexity in fixing this arises from the differing
behaviours of implementations of the shutdown, poweroff, and reboot
commands; upstart's poweroff & reboot commands for example, immediately
return (briefly) permitting the caller to query their exit codes. In
contrast, systemd's don't return at all unless the poweroff or reboot
fails. None of the reboot or poweroff implementations provide a
scheduling facility like the /sbin/shutdown implementation
(unsurprisingly), but systemd's poweroff and reboot commands *do* work
even in the post-trusty upgrade environment (even though systemd's
shutdown command doesn't).

The quandry is as follows: we can reliably detect when the shutdown
command fails (it exits with an exit code and some error messages), and
when it succeeds ... sort of. We currently schedule the shutdown for 4
minutes time and if it hasn't died within 10 seconds we assume it's
going to work; this assumes that the implementation won't fail at the
end of the schedule but so far that seems a reliable assumption under
both upstart and systemd. We cannot *reliably* detect when the poweroff
or reboot commands either succeed or fail, but they do seem reliable in
practice even in aberrant environments like the post-trusty upgrade.

So, the method I've chosen is as follows: treat shutdown and restart
requests as we presently do (schedule /bin/shutdown for 4 minutes time,
monitor for 10 seconds). If it succeeds, nothing changes. If it fails,
report the failure with an extra message indicating we are going to
attempt to force the procedure, then run /sbin/poweroff or /sbin/reboot
as appropriate. The result is that in the post-trusty environment
(testing on containers and VMs) a reboot request does succeed, but is
still reported as failing (albeit with an extended message explaining
we're going to try and force it).

We *could* report it as succeeding, but frankly there's no guarantees so
it's a choice between giving the user bad news ("sorry your reboot
request failed ...") with a possible silver lining ("... but we're going
to try another way which *might* work, however we won't be able to
tell"), or giving the user good news ("your reboot request worked after
we forced it") and hoping we're not lying! The former sounds like the
more sensible approach to me, and hence is what is in the PR
(https://github.com/CanonicalLtd/landscape-client/pull/55).

** Changed in: landscape-client (Ubuntu)
     Assignee: (unassigned) => Dave Jones (waveform)

** Changed in: landscape-client (Ubuntu)
   Status: Confirmed => In Progress

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

Title:
  Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

Status in landscape-client package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Incomplete
Status in landscape-client source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Incomplete

Bug description:
  Used Landscape (Paid Canonical Subscription) to upgrade one of my
  machines.

  Landscape only shows "In Progress" for more than 8 hours now and asked
  for a reboot of the machine in a second alert.

  In the reboot attempt I get the message:
  =
  Failed to set wall message, ignoring: Method "SetWallMessage" with signature 
"sb" on interface "org.freedesktop.login1.Manager" doesn't exist
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Method "ScheduleShutdown" with signature "st" on interface 
"org.freedesktop.login1.Manager" doesn't exist
  =

  Steps to reproduce:
  * Fully updated 14.04.5 machine
  * Open Landscape
  * Choose the machine
  * Choose Packages
  * This computer can be upgraded to a newer release
  * Apply
  * Wait 2 hours
  * Alert comes in a seperate Landscape message Machine is ready for reboot
  * Choose Info... Power
  * Deliver to selected computers as soon as possible
  * Error message

  I found this thread on reddit about this issue maybe the solution can be 
built into the upgrade script
  
https://www.reddit.com/r/linuxquestions/comments/4wy3go/trying_to_run_as_user_instance_but_the_system_has/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1670291/+subscriptions

-- 
Mailing list: https://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 1670291] Re: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

[Dave Jones]

Seems like there's two issues here which I'll address in separate PRs to
the landscape-client:

First is the issue that the landscape-client fails to report the
completion (or failure) of the release upgrade process. This turns out
to be due to a delayed import in the version of twisted distributed with
trusty. Because the import (of twisted.internet.unix) is delayed, by the
time we *do* import it (implicitly by calling another twisted method),
the twisted version on disk has been replaced with the xenial version
and things (unsurprisingly) break. The trivial fix is to pre-emptively
import the module prior to starting the release upgrade; I'll push a PR
for this in a moment.

The second issue is that landscape-client fails to reboot (or shutdown)
the machine immediately following the release upgrade procedure. This is
due to the fact landscape-client currently relies upon /sbin/shutdown to
handle reboot or shutdown requests. This utility operates happily in its
upstart variant (in trusty), and systemd variant (in xenial and beyond),
but fails in the post-trusty-to-xenial upgrade environment when the
system on disk is effectively xenial (so /sbin/shutdown is a link to
systemctl), but the running environment is still partially trusty. It
transpires that systemctl (without the double --force --force option)
requires both systemd and dbus to be operational in order to
successfully (and cleanly) shutdown or restart.

The fix for this is a little more complex as the landscape-client relies
upon the scheduling function of /sbin/shutdown to ensure it can request
a shutdown and still report back to the server before the machine
actually goes down. I'm still investigating the best method which will
work reliably in all potential environments.

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

Title:
  Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot

Status in landscape-client package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Incomplete
Status in landscape-client source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Incomplete

Bug description:
  Used Landscape (Paid Canonical Subscription) to upgrade one of my
  machines.

  Landscape only shows "In Progress" for more than 8 hours now and asked
  for a reboot of the machine in a second alert.

  In the reboot attempt I get the message:
  =
  Failed to set wall message, ignoring: Method "SetWallMessage" with signature 
"sb" on interface "org.freedesktop.login1.Manager" doesn't exist
  Failed to call ScheduleShutdown in logind, proceeding with immediate 
shutdown: Method "ScheduleShutdown" with signature "st" on interface 
"org.freedesktop.login1.Manager" doesn't exist
  =

  Steps to reproduce:
  * Fully updated 14.04.5 machine
  * Open Landscape
  * Choose the machine
  * Choose Packages
  * This computer can be upgraded to a newer release
  * Apply
  * Wait 2 hours
  * Alert comes in a seperate Landscape message Machine is ready for reboot
  * Choose Info... Power
  * Deliver to selected computers as soon as possible
  * Error message

  I found this thread on reddit about this issue maybe the solution can be 
built into the upgrade script
  
https://www.reddit.com/r/linuxquestions/comments/4wy3go/trying_to_run_as_user_instance_but_the_system_has/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1670291/+subscriptions

-- 
Mailing list: https://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 1003854] Re: Database upgrade/migration fails with nested db directories (lucid to precise)

[Dave Jones]

My backup was indeed slapcat / slapadd (for both the main directory and
the cn=config stuff). I'd *guess* that if the package state is "ii" you
may not need the patch (incidentally the patch is in bug description at
the top), particularly if the server's starting fine and everything
queries happily. Mine didn't start after the upgrade so I definitely
needed the patch, but I wouldn't like to guess about other situations
(given how variable LDAP setups can be).

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

Title:
  Database upgrade/migration fails with nested db directories (lucid to
  precise)

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Precise:
  Confirmed
Status in openldap package in Debian:
  Fix Released

Bug description:
  Hi,

  I've just performed an upgrade of our LDAP server on Ubuntu 10.04.4
  LTS to Ubuntu 12.04 (I acknowledge this upgrade path is not officially
  supported yet).

  The incompatible database upgrading process in the preinst/postinst
  files failed in the following scenario.

  We have two suffixes/databases at the following paths:-

   * /var/lib/ldap
   * /var/lib/ldap/accesslog

  The preinst database dumping part of the process worked just fine and
  created the appropriate LDIF files under
  /var/backup/slapd-2.4.21-0ubuntu5.7, however the restore failed
  stating:-

  """
    Loading from /var/backups/slapd-2.4.21-0ubuntu5.7:
    - directory dc=REDACTEDs,dc=co,dc=uk... failed.

  Loading the database from the LDIF dump failed with the following
  error while running slapadd:
  4fbdfebf olcDbDirectory: value #0: invalid path: No such file or directory
  4fbdfebf config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
  slapadd: bad configuration directory!
  """

  This is because when move_incompatible_databases_away() runs it finds
  the main database first (/var/lib/ldap) and moves all top level
  entries (find -mindepth 1 -maxdepth 1 ...) into the backup directory
  and this includes the accesslog subdirectory which then no longer
  exists. When slapadd runs it checks config specifying that directory
  and bails with the above error given it is indeed missing.

  I've tested a tentative fix and that's to patch the two find commands
  (one in is_empty_dir() one in move_old_database_away to also specify
  -type f so that the directory structure is preserved when moving the
  old database away (accesslog will be backed up separately when its
  suffx is iterated over in move_incompatible_databases_away()).

  The simple and very tentative patch for this is:-

  """
  # diff -u slapd.scripts-common.old slapd.scripts-common
  --- slapd.scripts-common.old  2012-05-24 10:33:01.746206585 +0100
  +++ slapd.scripts-common  2012-05-24 10:33:23.967902747 +0100
  @@ -391,7 +391,7 @@
     echo -n "  - directory $suffix... " >&2
     mkdir -p "$backupdir"
     find "$databasedir" -mindepth 1 -maxdepth 1\
  - -exec mv {} "$backupdir" \;
  + -type f -exec mv {} "$backupdir" \;
     echo done. >&2
    else
     cat >&2 /dev/null`
    if [ -n "$output" ]; then
     return 1
    else
  """

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

-- 
Mailing list: https://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 1003854] Re: Database upgrade/migration fails with nested db directories (lucid to precise)

[Dave Jones]

Hi Andre - I did take a backup of the LDAP directory prior to "do-
release-upgrade" (actually I had nightly backups running so I just
grabbed a copy of the last one of those). That's what I was referring to
when I stated "restore the old-version backup...". It's been a few
months now but I vaguely recall that the upgrade procedure needs the
state of the database prior to the (failed) upgrade in order to succeed
after patching.

Hence, if my recollection is accurate, my procedure was:

1. Patch the slapd.postinst script
2. Restore the database to its state prior to the (failed) upgrade
3. Run "dpkg --configure -a" to cause the slapd postinst script to upgrade the 
database successfully

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

Title:
  Database upgrade/migration fails with nested db directories (lucid to
  precise)

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Precise:
  Confirmed
Status in openldap package in Debian:
  Fix Released

Bug description:
  Hi,

  I've just performed an upgrade of our LDAP server on Ubuntu 10.04.4
  LTS to Ubuntu 12.04 (I acknowledge this upgrade path is not officially
  supported yet).

  The incompatible database upgrading process in the preinst/postinst
  files failed in the following scenario.

  We have two suffixes/databases at the following paths:-

   * /var/lib/ldap
   * /var/lib/ldap/accesslog

  The preinst database dumping part of the process worked just fine and
  created the appropriate LDIF files under
  /var/backup/slapd-2.4.21-0ubuntu5.7, however the restore failed
  stating:-

  """
    Loading from /var/backups/slapd-2.4.21-0ubuntu5.7:
    - directory dc=REDACTEDs,dc=co,dc=uk... failed.

  Loading the database from the LDIF dump failed with the following
  error while running slapadd:
  4fbdfebf olcDbDirectory: value #0: invalid path: No such file or directory
  4fbdfebf config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
  slapadd: bad configuration directory!
  """

  This is because when move_incompatible_databases_away() runs it finds
  the main database first (/var/lib/ldap) and moves all top level
  entries (find -mindepth 1 -maxdepth 1 ...) into the backup directory
  and this includes the accesslog subdirectory which then no longer
  exists. When slapadd runs it checks config specifying that directory
  and bails with the above error given it is indeed missing.

  I've tested a tentative fix and that's to patch the two find commands
  (one in is_empty_dir() one in move_old_database_away to also specify
  -type f so that the directory structure is preserved when moving the
  old database away (accesslog will be backed up separately when its
  suffx is iterated over in move_incompatible_databases_away()).

  The simple and very tentative patch for this is:-

  """
  # diff -u slapd.scripts-common.old slapd.scripts-common
  --- slapd.scripts-common.old  2012-05-24 10:33:01.746206585 +0100
  +++ slapd.scripts-common  2012-05-24 10:33:23.967902747 +0100
  @@ -391,7 +391,7 @@
     echo -n "  - directory $suffix... " >&2
     mkdir -p "$backupdir"
     find "$databasedir" -mindepth 1 -maxdepth 1\
  - -exec mv {} "$backupdir" \;
  + -type f -exec mv {} "$backupdir" \;
     echo done. >&2
    else
     cat >&2 /dev/null`
    if [ -n "$output" ]; then
     return 1
    else
  """

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

-- 
Mailing list: https://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 1003854] Re: Database upgrade/migration fails with nested db directories (lucid to precise)

[Dave Jones]

Ah, no worries - finally figured it out. Needed to apply the patch to
/var/lib/dpkg/info/slapd.postinst (rather than slapd.config - was
confused over package's half-configured state) and restore the old-
version backup prior to retrying "dpkg --configure -a". All good now!

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

Title:
  Database upgrade/migration fails with nested db directories (lucid to
  precise)

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Precise:
  Confirmed
Status in openldap package in Debian:
  Fix Released

Bug description:
  Hi,

  I've just performed an upgrade of our LDAP server on Ubuntu 10.04.4
  LTS to Ubuntu 12.04 (I acknowledge this upgrade path is not officially
  supported yet).

  The incompatible database upgrading process in the preinst/postinst
  files failed in the following scenario.

  We have two suffixes/databases at the following paths:-

   * /var/lib/ldap
   * /var/lib/ldap/accesslog

  The preinst database dumping part of the process worked just fine and
  created the appropriate LDIF files under
  /var/backup/slapd-2.4.21-0ubuntu5.7, however the restore failed
  stating:-

  """
    Loading from /var/backups/slapd-2.4.21-0ubuntu5.7:
    - directory dc=REDACTEDs,dc=co,dc=uk... failed.

  Loading the database from the LDIF dump failed with the following
  error while running slapadd:
  4fbdfebf olcDbDirectory: value #0: invalid path: No such file or directory
  4fbdfebf config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
  slapadd: bad configuration directory!
  """

  This is because when move_incompatible_databases_away() runs it finds
  the main database first (/var/lib/ldap) and moves all top level
  entries (find -mindepth 1 -maxdepth 1 ...) into the backup directory
  and this includes the accesslog subdirectory which then no longer
  exists. When slapadd runs it checks config specifying that directory
  and bails with the above error given it is indeed missing.

  I've tested a tentative fix and that's to patch the two find commands
  (one in is_empty_dir() one in move_old_database_away to also specify
  -type f so that the directory structure is preserved when moving the
  old database away (accesslog will be backed up separately when its
  suffx is iterated over in move_incompatible_databases_away()).

  The simple and very tentative patch for this is:-

  """
  # diff -u slapd.scripts-common.old slapd.scripts-common
  --- slapd.scripts-common.old  2012-05-24 10:33:01.746206585 +0100
  +++ slapd.scripts-common  2012-05-24 10:33:23.967902747 +0100
  @@ -391,7 +391,7 @@
     echo -n "  - directory $suffix... " >&2
     mkdir -p "$backupdir"
     find "$databasedir" -mindepth 1 -maxdepth 1\
  - -exec mv {} "$backupdir" \;
  + -type f -exec mv {} "$backupdir" \;
     echo done. >&2
    else
     cat >&2 /dev/null`
    if [ -n "$output" ]; then
     return 1
    else
  """

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

-- 
Mailing list: https://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 1003854] Re: Database upgrade/migration fails with nested db directories (lucid to precise)

[Dave Jones]

Also encountered this when upgrading a server from 12.04 to 14.04 (for
reference, wound up filing duplicate bug #1579566). Managed to get slapd
restored happily by creating the accesslog directory (then slapadd to
restore).

Unfortunately as I restored the database, rather than apt handling it,
the slapd package is now in "iF" state (according to dpkg -l).
Attempting to fix this with "apt-get -f install" leads to the original
situation: the package attempts to backup and restore the database
unsuccessfully presumably because the slapd package it's attempting to
update to is 2.4.31 (the current version in trusty) while the fixed
version is the later 2.4.40.

Any hints on how to resolve the situation (e.g. by simply marking the
package "installed"? slapd does appear to be working happily with the
manually restored database)

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

Title:
  Database upgrade/migration fails with nested db directories (lucid to
  precise)

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Precise:
  Confirmed
Status in openldap package in Debian:
  Fix Released

Bug description:
  Hi,

  I've just performed an upgrade of our LDAP server on Ubuntu 10.04.4
  LTS to Ubuntu 12.04 (I acknowledge this upgrade path is not officially
  supported yet).

  The incompatible database upgrading process in the preinst/postinst
  files failed in the following scenario.

  We have two suffixes/databases at the following paths:-

   * /var/lib/ldap
   * /var/lib/ldap/accesslog

  The preinst database dumping part of the process worked just fine and
  created the appropriate LDIF files under
  /var/backup/slapd-2.4.21-0ubuntu5.7, however the restore failed
  stating:-

  """
    Loading from /var/backups/slapd-2.4.21-0ubuntu5.7:
    - directory dc=REDACTEDs,dc=co,dc=uk... failed.

  Loading the database from the LDIF dump failed with the following
  error while running slapadd:
  4fbdfebf olcDbDirectory: value #0: invalid path: No such file or directory
  4fbdfebf config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
  slapadd: bad configuration directory!
  """

  This is because when move_incompatible_databases_away() runs it finds
  the main database first (/var/lib/ldap) and moves all top level
  entries (find -mindepth 1 -maxdepth 1 ...) into the backup directory
  and this includes the accesslog subdirectory which then no longer
  exists. When slapadd runs it checks config specifying that directory
  and bails with the above error given it is indeed missing.

  I've tested a tentative fix and that's to patch the two find commands
  (one in is_empty_dir() one in move_old_database_away to also specify
  -type f so that the directory structure is preserved when moving the
  old database away (accesslog will be backed up separately when its
  suffx is iterated over in move_incompatible_databases_away()).

  The simple and very tentative patch for this is:-

  """
  # diff -u slapd.scripts-common.old slapd.scripts-common
  --- slapd.scripts-common.old  2012-05-24 10:33:01.746206585 +0100
  +++ slapd.scripts-common  2012-05-24 10:33:23.967902747 +0100
  @@ -391,7 +391,7 @@
     echo -n "  - directory $suffix... " >&2
     mkdir -p "$backupdir"
     find "$databasedir" -mindepth 1 -maxdepth 1\
  - -exec mv {} "$backupdir" \;
  + -type f -exec mv {} "$backupdir" \;
     echo done. >&2
    else
     cat >&2 /dev/null`
    if [ -n "$output" ]; then
     return 1
    else
  """

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

-- 
Mailing list: https://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 1579566] Re: Automatic openldap db migration fails on release upgrade when using nested database directories

[Dave Jones]

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

Ah, you're absolutely right - that looks like it. Sorry for the
duplicate (don't know why I didn't find that report first)!

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

Title:
  Automatic openldap db migration fails on release upgrade when using
  nested database directories

Status in openldap package in Ubuntu:
  New

Bug description:
  While attempting to perform an upgrade of my home server from Ubuntu
  12.04 to Ubuntu 14.04, I received the following error:

  
===
  Error in function: 

  
  A fatal error occurred 

  Please report this as a bug and include the files 
  /var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in 
  your report. The upgrade has aborted. 
  Your original sources.list was saved in 
  /etc/apt/sources.list.distUpgrade. 

  SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)


  Could not install the upgrades

  The upgrade has aborted. Your system could be in an unusable state. A 
  recovery will run now (dpkg --configure -a). 

  Setting up slapd (2.4.31-1+nmu2ubuntu8.2) ...
Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.28-1.1ubuntu4.6... 
done.
Moving old database directories to /var/backups:
Loading from /var/backups/slapd-2.4.28-1.1ubuntu4.6: 
- directory dc=waveform,dc=org,dc=uk... failed.

  Loading the database from the LDIF dump failed with the following
  error while running slapadd:
  572f946e olcDbDirectory: value #0: invalid path: No such file or directory
  572f946e config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
  slapadd: bad configuration directory!
  dpkg: error processing package slapd (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   slapd

  Upgrade complete

  The upgrade has completed but there were errors during the upgrade 
  process. 
  
===

  Admittedly, it's rather strange for a home server to use LDAP for
  authentication but I don't have a terribly complex setup: openldap
  with a fairly normal LDAP layout and SSSD for handling the PAM
  interface (no kerberos - I did try it in the past but quickly gave it
  up as too complex to maintain). Hence, I was rather expecting the
  upgrade to be relatively smooth (as much as server upgrades ever are
  :).

  As requested in the message I'm attaching /var/log/dist-
  upgrade/main.log and /var/log/dist-upgrade/apt.log

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

-- 
Mailing list: https://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 1579566] Re: Automatic openldap db migration fails on release upgrade when using accesslog overlay

[Dave Jones]

I should add: I think the accesslog overlay is implicit in replicated
setups (yes, I know, weird enough that a home server's using LDAP, but
replication too?! I originally set it up to learn about LDAP replication
in order to use it at work :). It seems to be used to ease the burden of
change queries from downstream servers - hence I'm guessing this bug
will apply particularly to openldap installations using syncrepl.

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

Title:
  Automatic openldap db migration fails on release upgrade when using
  accesslog overlay

Status in openldap package in Ubuntu:
  New

Bug description:
  While attempting to perform an upgrade of my home server from Ubuntu
  12.04 to Ubuntu 14.04, I received the following error:

  
===
  Error in function: 

  
  A fatal error occurred 

  Please report this as a bug and include the files 
  /var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in 
  your report. The upgrade has aborted. 
  Your original sources.list was saved in 
  /etc/apt/sources.list.distUpgrade. 

  SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)


  Could not install the upgrades

  The upgrade has aborted. Your system could be in an unusable state. A 
  recovery will run now (dpkg --configure -a). 

  Setting up slapd (2.4.31-1+nmu2ubuntu8.2) ...
Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.28-1.1ubuntu4.6... 
done.
Moving old database directories to /var/backups:
Loading from /var/backups/slapd-2.4.28-1.1ubuntu4.6: 
- directory dc=waveform,dc=org,dc=uk... failed.

  Loading the database from the LDIF dump failed with the following
  error while running slapadd:
  572f946e olcDbDirectory: value #0: invalid path: No such file or directory
  572f946e config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
  slapadd: bad configuration directory!
  dpkg: error processing package slapd (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   slapd

  Upgrade complete

  The upgrade has completed but there were errors during the upgrade 
  process. 
  
===

  Admittedly, it's rather strange for a home server to use LDAP for
  authentication but I don't have a terribly complex setup: openldap
  with a fairly normal LDAP layout and SSSD for handling the PAM
  interface (no kerberos - I did try it in the past but quickly gave it
  up as too complex to maintain). Hence, I was rather expecting the
  upgrade to be relatively smooth (as much as server upgrades ever are
  :).

  As requested in the message I'm attaching /var/log/dist-
  upgrade/main.log and /var/log/dist-upgrade/apt.log

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

-- 
Mailing list: https://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 1579566] Re: fatal error while migrating openldap during 12.04 to 14.04 upgrade

[Dave Jones]

After a bit of playing around, it appears the root cause was that I'm
using the accesslog overlay which necessitates having another database
under /var/lib/ldap/accesslog. The migration process backed up
everything under /var/lib/ldap to /var/backups then re-created
/var/lib/ldap - but didn't created the "accesslog" directory under it.
As a result the attempt to restore the database (presumably with
slapadd) failed. After I recreated the /var/lib/ldap/accesslog directory
(with appropriate ownership of openldap:openldap), the database restored
successfully.

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

Title:
  fatal error while migrating openldap during 12.04 to 14.04 upgrade

Status in openldap package in Ubuntu:
  New

Bug description:
  While attempting to perform an upgrade of my home server from Ubuntu
  12.04 to Ubuntu 14.04, I received the following error:

  
===
  Error in function: 

  
  A fatal error occurred 

  Please report this as a bug and include the files 
  /var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in 
  your report. The upgrade has aborted. 
  Your original sources.list was saved in 
  /etc/apt/sources.list.distUpgrade. 

  SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)


  Could not install the upgrades

  The upgrade has aborted. Your system could be in an unusable state. A 
  recovery will run now (dpkg --configure -a). 

  Setting up slapd (2.4.31-1+nmu2ubuntu8.2) ...
Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.28-1.1ubuntu4.6... 
done.
Moving old database directories to /var/backups:
Loading from /var/backups/slapd-2.4.28-1.1ubuntu4.6: 
- directory dc=waveform,dc=org,dc=uk... failed.

  Loading the database from the LDIF dump failed with the following
  error while running slapadd:
  572f946e olcDbDirectory: value #0: invalid path: No such file or directory
  572f946e config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
  slapadd: bad configuration directory!
  dpkg: error processing package slapd (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   slapd

  Upgrade complete

  The upgrade has completed but there were errors during the upgrade 
  process. 
  
===

  Admittedly, it's rather strange for a home server to use LDAP for
  authentication but I don't have a terribly complex setup: openldap
  with a fairly normal LDAP layout and SSSD for handling the PAM
  interface (no kerberos - I did try it in the past but quickly gave it
  up as too complex to maintain). Hence, I was rather expecting the
  upgrade to be relatively smooth (as much as server upgrades ever are
  :).

  As requested in the message I'm attaching /var/log/dist-
  upgrade/main.log and /var/log/dist-upgrade/apt.log

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

-- 
Mailing list: https://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 1579566] [NEW] fatal error while migrating openldap during 12.04 to 14.04 upgrade

[Dave Jones]

Public bug reported:

While attempting to perform an upgrade of my home server from Ubuntu
12.04 to Ubuntu 14.04, I received the following error:

===
Error in function: 


A fatal error occurred 

Please report this as a bug and include the files 
/var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in 
your report. The upgrade has aborted. 
Your original sources.list was saved in 
/etc/apt/sources.list.distUpgrade. 

SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)


Could not install the upgrades

The upgrade has aborted. Your system could be in an unusable state. A 
recovery will run now (dpkg --configure -a). 

Setting up slapd (2.4.31-1+nmu2ubuntu8.2) ...
  Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.28-1.1ubuntu4.6... 
done.
  Moving old database directories to /var/backups:
  Loading from /var/backups/slapd-2.4.28-1.1ubuntu4.6: 
  - directory dc=waveform,dc=org,dc=uk... failed.

Loading the database from the LDIF dump failed with the following
error while running slapadd:
572f946e olcDbDirectory: value #0: invalid path: No such file or directory
572f946e config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
slapadd: bad configuration directory!
dpkg: error processing package slapd (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 slapd

Upgrade complete

The upgrade has completed but there were errors during the upgrade 
process. 
===

Admittedly, it's rather strange for a home server to use LDAP for
authentication but I don't have a terribly complex setup: openldap with
a fairly normal LDAP layout and SSSD for handling the PAM interface (no
kerberos - I did try it in the past but quickly gave it up as too
complex to maintain). Hence, I was rather expecting the upgrade to be
relatively smooth (as much as server upgrades ever are :).

As requested in the message I'm attaching /var/log/dist-upgrade/main.log
and /var/log/dist-upgrade/apt.log

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

** Attachment added: "main log from server upgrade"
   https://bugs.launchpad.net/bugs/1579566/+attachment/4658825/+files/main.log

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

Title:
  fatal error while migrating openldap during 12.04 to 14.04 upgrade

Status in openldap package in Ubuntu:
  New

Bug description:
  While attempting to perform an upgrade of my home server from Ubuntu
  12.04 to Ubuntu 14.04, I received the following error:

  
===
  Error in function: 

  
  A fatal error occurred 

  Please report this as a bug and include the files 
  /var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in 
  your report. The upgrade has aborted. 
  Your original sources.list was saved in 
  /etc/apt/sources.list.distUpgrade. 

  SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)


  Could not install the upgrades

  The upgrade has aborted. Your system could be in an unusable state. A 
  recovery will run now (dpkg --configure -a). 

  Setting up slapd (2.4.31-1+nmu2ubuntu8.2) ...
Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.28-1.1ubuntu4.6... 
done.
Moving old database directories to /var/backups:
Loading from /var/backups/slapd-2.4.28-1.1ubuntu4.6: 
- directory dc=waveform,dc=org,dc=uk... failed.

  Loading the database from the LDIF dump failed with the following
  error while running slapadd:
  572f946e olcDbDirectory: value #0: invalid path: No such file or directory
  572f946e config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
  slapadd: bad configuration directory!
  dpkg: error processing package slapd (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   slapd

  Upgrade complete

  The upgrade has completed but there were errors during the upgrade 
  process. 
  
===

  Admittedly, it's rather strange for a home server to use LDAP for
  authentication but I don't have a terribly complex setup: openldap
  with a fairly normal LDAP layout and SSSD for handling the PAM
  interface (no kerberos - I did try it in the past but quickly gave it
  up as too complex to maintain). Hence, I was rather expecting the
  upgrade to be relatively smooth (as much as server upgrades ever are
  :).

  As requested in the 

[Touch-packages] [Bug 1579566] Re: fatal error while migrating openldap during 12.04 to 14.04 upgrade

[Dave Jones]

** Attachment added: "apt log from server upgrade"
   
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1579566/+attachment/4658826/+files/apt.log

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

Title:
  fatal error while migrating openldap during 12.04 to 14.04 upgrade

Status in openldap package in Ubuntu:
  New

Bug description:
  While attempting to perform an upgrade of my home server from Ubuntu
  12.04 to Ubuntu 14.04, I received the following error:

  
===
  Error in function: 

  
  A fatal error occurred 

  Please report this as a bug and include the files 
  /var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in 
  your report. The upgrade has aborted. 
  Your original sources.list was saved in 
  /etc/apt/sources.list.distUpgrade. 

  SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)


  Could not install the upgrades

  The upgrade has aborted. Your system could be in an unusable state. A 
  recovery will run now (dpkg --configure -a). 

  Setting up slapd (2.4.31-1+nmu2ubuntu8.2) ...
Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.28-1.1ubuntu4.6... 
done.
Moving old database directories to /var/backups:
Loading from /var/backups/slapd-2.4.28-1.1ubuntu4.6: 
- directory dc=waveform,dc=org,dc=uk... failed.

  Loading the database from the LDIF dump failed with the following
  error while running slapadd:
  572f946e olcDbDirectory: value #0: invalid path: No such file or directory
  572f946e config error processing olcDatabase={2}hdb,cn=config: 
olcDbDirectory: value #0: invalid path: No such file or directory
  slapadd: bad configuration directory!
  dpkg: error processing package slapd (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   slapd

  Upgrade complete

  The upgrade has completed but there were errors during the upgrade 
  process. 
  
===

  Admittedly, it's rather strange for a home server to use LDAP for
  authentication but I don't have a terribly complex setup: openldap
  with a fairly normal LDAP layout and SSSD for handling the PAM
  interface (no kerberos - I did try it in the past but quickly gave it
  up as too complex to maintain). Hence, I was rather expecting the
  upgrade to be relatively smooth (as much as server upgrades ever are
  :).

  As requested in the message I'm attaching /var/log/dist-
  upgrade/main.log and /var/log/dist-upgrade/apt.log

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

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