python-oauth is significantly broken in Focal due to trying to import
cgi.parse_qs which moved for Python3.8. This breaks the MAAS CLI.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1118815
Title:
Public bug reported:
graphite-web fails on focal with python3.8 (the default) due to the
following error:
File "/usr/lib/python3/dist-packages/graphite/render/urls.py", line 16, in
from . import views
File "/usr/lib/python3/dist-packages/graphite/render/views.py", line 23, in
from cgi
** Changed in: npm (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1216465
Title:
[saucy] npm refuses to run with current nodejs version
The bug was marked invalid for *Avahi* but Confirmed for network-manager
-- because the bug exists not in Avahi (it simply logs the message you
see as a result of the IP address being removed). So the bug is still
valid and confirmed, just for network-manager instead.
--
You received this bug
*** This bug is a duplicate of bug 1823281 ***
https://bugs.launchpad.net/bugs/1823281
** This bug has been marked a duplicate of bug 1823281
perf-archive is not shipped in the linux-tools package
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
At a super basic level I can't reproduce this. With an eoan container on
an eoan host I don't get a segfault from ceph-bluestore-tool.
I'd suggest we may need to look at getting
(1) a coredump
(2) the somewhat unlikely but not impossible chance that it's CPU-dependent
for some kind of
When I say bind, I actually meant to bind the outgoing connection from
Pidgin (not related to Avahi). So when creating the socket, specify the
source IP address.
The problem is that when you connect (without specifying a source) then
at least for IPv6 due to the routing table specification of the
Part of the reason this behavior exists in Avahi is that many
applications do not correctly retrieve the scope ID (interface index)
when doing hostname resolution, and if not supplied then connection to
such a link local address will fail. Applications are likely to receive
such an address at
Part of the reason this behavior exists in Avahi is that many
applications do not correctly retrieve the scope ID (interface index)
when doing hostname resolution, and if not supplied then connection to
such a link local address will fail. Applications are likely to receive
such an address at
Public bug reported:
Upgrading python3-cinderclient from 1:4.1.0-0ubuntu1 to 2:4.2.1-0ubuntu2
fails on Eoan due to a conflicting file between the two packages.
It seems there is no equivalent 4.2 upgrade for python-cinderclient so
anyone who previously had both versions installed now meet the
** Changed in: python3.7 (Ubuntu)
Assignee: Trent Lloyd (lathiat) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1818778
Title:
Python should be compiled with USDT/dtrace u
The following bug (included in 12.2.12) adds back a lot of log messages
to the monitor log that help with debugging cluster performance
problems. Not having this is causing difficulty supporting a number of
sites recently. This functionality existed in jewel, was removed (and
re-added) in
This prevents compilation of NVIDIA drivers (DKMS) also.
I *suspect* (but am not at all authoritative or knowledgeable enough to
say so) that the fix here will actually be to change the build flags
used by the kernel set in /usr/src/linux-headers-$(uname -r)/Makefile
--
You received this bug
Reproduced on bionic with 13.2.4+dfsg1-0ubuntu2~cloud0 from the stein
cloud-archive
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1833191
Title:
UnicodeEncodeError from logging code during
['ceph-volume', 'lvm', 'create', '--osd-fsid',
'234af60b-d880-4dbb-89dd-658b1412f360', '--bluestore', '--data',
'ceph-234af60b-d880-4dbb-89dd-658b1412f360/osd-block-234af60b-d880-4dbb-89dd-658b1412f360',
'--block.db',
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1829716
Title:
[SRU] ceph 12.2.12
To manage notifications about this bug go to:
I stopped systemd-resolved, disabled it, restarted docker, no change.
I then removed /etc/resolv.conf's symlink and placed my own file there,
restarted docker, still no change.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I ran into this on upgrade today.
>From reading above, I think the root of the problem is that I am using a
>system upgraded from Xenial to Bionic, so I am still using ifupdown and
>resolvconf (and not netplan)
ifupdown doesn't update systemd-resoved, resolvconf/ifupdown updated
The most likely cause for this is that you have packets outbound on port
5353 firewalled either locally or on your network device. When another
host pings the address, the responses are sent via multicast and Avahi
caches that response, and so can then use it without having to transmit
a packet.
This is a bug in CUPS ultimately, it's driving Avahi using the D-BUS API
(as opposed to manual service files in /etc/avahi/services, this is only
really used for a sysadmin to manually add services, most other types of
advertisements such as printers are expected to use the API to advertise
it).
Hi Markos,
After creating this service file, if you check the contents of
/var/log/syslog, you will see that Avahi gave an error parsing the file:
May 10 16:01:30 optane avahi-daemon[1260]: Loading service file
/services/test.service.
May 10 16:01:30 optane avahi-daemon[1260]:
I have been running into this (curtin 18.1-17-gae48e86f-
0ubuntu1~16.04.1)
I think this commit basically agrees with my thoughts but I just wanted
to share them explicitly in case they are interesting
(1) If you *unregister* the cache device from the backing device, it
first has to purge all
** Changed in: avahi (Ubuntu)
Assignee: (unassigned) => Trent Lloyd (lathiat)
** Changed in: avahi (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
Potential upstream fix for backport, may be relevant to MAAS:
https://github.com/lathiat/avahi/pull/206
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1752737
Title:
[2.3.0-6434] mDNS observer
Mario advised me that he tested the latest upstream Percona XtraDB
Cluster 5.6 release (5.6.43-28.32) against his reproducer (using
openstack rally) which causes foreign key violations even with
wsrep_slave_threads=1 that it does not reproduce on the latest upstream
release.
There is no clear
Setting Invalid for Xenial, as by policy Ubuntu updates do not generally
update software from one major version to another.
Bug was originally for OpenStack, on Bionic we now have PXC 5.7
** Changed in: percona-xtradb-cluster-5.6 (Ubuntu)
Status: Confirmed => Invalid
--
You received
A degraded array used for the root filesystem DOES boot as expected on
Bionic. My guess is that during boot the "poor-mans mdadm-last-
resort@.timer" code from debian/initramfs/script.local-block is executed
where as with non-root devices that is not the case and it potentially
should use the
Public bug reported:
When booting a Bionic system where an MDADM RAID device is degraded
(e.g. 1 of 2 disks appear) and that device is for a non-root filesystem
(e.g. /home) the boot enters emergency mode and the MD device stays
inactive.
This can be reproduced using the live server installation
Setting Confirmed because this is replicating an issue reporting in the
community, and I was able to reproduce the issue:
https://utcc.utoronto.ca/~cks/space/blog/linux/SoftwareRaidAssemblySystemd
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Attachment added: "sosreport-ubuntu-raid.lp1825075-20190417024226.tar.xz"
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1825075/+attachment/5256442/+files/sosreport-ubuntu-raid.lp1825075-20190417024226.tar.xz
--
You received this bug notification because you are a member of Ubuntu
Made some progress on the test suite, but many tests already fail in the
relevant upstream branch:
sudo apt-get install percona-server-server-5.6
lathiat@xenial:~/percona-toolkit$ PERCONA_TOOLKIT_BRANCH=$HOME/percona-
toolkit PERCONA_TOOLKIT_SANDBOX=/usr ./sandbox/test-env start
(edit Makefile,
** Description changed:
- On Xenial, various tools fail because of warnings from sprintf that are
- generated on the new Perl version in Xenial.
+ [Impact]
+
+ On Xenial, various tools from percona-toolkit fail because of new
+ warnings from sprintf that are generated by the new Perl version in
Attaching patch for the issue.
The way the upstream percona-toolkit repository works is they have these
perl modules that are statically "compiled in" to the various tool perl
scripts, with both the source libraries and that resulting static tool
committed to git.
They do not always update every
ny errors.
This issue was fixed upstream:
https://github.com/percona/percona-toolkit/pull/73/
** Affects: percona-toolkit (Ubuntu)
Importance: High
Assignee: Trent Lloyd (lathiat)
Status: Confirmed
** Affects: percona-toolkit (Ubuntu Xenial)
Importance: High
Assignee: Tren
Setting Invalid as this no longer occurs in a supported release
** Changed in: percona-toolkit (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1011302
Title:
** Changed in: percona-toolkit (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1758397
Title:
pt-online-schema-change fails to change data-dir
To manage
** Changed in: percona-xtradb-cluster-5.6 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1823850
Title:
wsrep_slave_threads >1 causes foreign key constraint
Public bug reported:
When running OpenStack against Percona XtraDB 5.6 (Xenial) we observe
foreign key violation crashes on the slave servers when using
wsrep_slave_threads > 1. This happens semi-regularly every few days in
at least 1 production environment.
Unfortunately it is not straight
** Tags added: sts
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1823281
Title:
perf-archive is not shipped in the linux-tools
Public bug reported:
The perf-archive tool is not shipped in the linux-tools package. This
causes the command 'perf archive' to fail despite there being a manpage
for it.
This tool is used to help ship debug info to analyse perf data remotely.
This is a shell script in the kernel tree
On the previously mentioned HP server today I was able to get closer to
reproducing the situation by testing with bionic (4.15.0-47-generic)
instead of xenial (4.4)
On bionic, unlike xenial, even with the BIOS set to "BIOS controlled
dynamic" mode, the intel_pstate driver is loaded instead of
This is a bug in CUPS, CUPS needs to remember the address family of the
advertised service (and preferably the interface ID). Avahi does know
this interface and does provide it in the API responses to CUPS, but
it's currently not using it.
For more detailed information please refer to here:
Confirmed that pcc-cpufreq *can* be used in preference to intel_pstate
even on a CPU that supports intel_pstate if the firmware tables are
setup to request such. One such server is an E5-2630 v3 HP DL360 G9
(shuckle).
On the default "dynamic" firmware setting you get driver=pcc-cpufreq +
(as context to this information, apparently this particularly bad
performance experienced with 'powersave' happens when the BIOS power
control is set to the default, and goes away when in the BIOS you set
power management to 'os control' - so there is some additional
information needed to
Something I was not previously aware of that informs this a bit more, is
that in some BIOS modes (apparently HP uses this extensively, unsure
about Dell and others) you get a "Collaborative Power Control" mode,
which sets the scaling_driver to pcc-cpufreq (as opposed to cpufreq) and
is some weird
** Changed in: passenger (Debian)
Importance: Unknown => Undecided
** Changed in: passenger (Debian)
Remote watch: Debian Bug tracker #812103 => None
** Changed in: passenger (Debian)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Looks like this was fixed for gnome-shell-extension-*ubuntu-dock* in
upload 64ubuntu5 (March 7).
However gnome-shell-extension-*dashtodock* appears unfixed in the Ubuntu
package
This issue is fixed upstream in git master, however, it appears it has not been
released to extensions.gnome.org or
*** This bug is a duplicate of bug 1819086 ***
https://bugs.launchpad.net/bugs/1819086
** This bug has been marked a duplicate of bug 1819086
Ubuntu 19.04: Some gnome-shell extensions no longer work since updating to
gnome-shell 3.31/3.32
--
You received this bug notification because
This issue is affecting a fairly large number of extensions. The cause
is an intentional breaking change in GNOME Shell 3.32 to move from
Lang.class to ES6 classes.
The following change in gnome-shell 3.32 is the cause:
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
Upstream fix
The following change in gnome-shell 3.32 looks like the cause:
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/350
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
Upstream fix in dash-to-dock here:
https://github.com/micheleg/dash-to-dock/pull/881
This issue is affecting
You can unsubscribe ubuntu-sponsors from this
** Tags removed: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1818778
Title:
Python should be compiled with USDT/dtrace user-space probes
To
** Also affects: python3.7 (Ubuntu)
Importance: Undecided
Status: New
** Changed in: python3.7 (Ubuntu)
Status: New => Confirmed
** Changed in: python3.7 (Ubuntu)
Importance: Undecided => Wishlist
** Changed in: python3.7 (Ubuntu)
Assignee: (unassigned) => Tr
Adding patch (git format-patch) against upstream Debian cpython-
team/python3 git repository (canonical home of debian/ for python3
packages)
** Patch added: "Patch against cpython-team/python3 upstream git repository"
Attaching debdiff showing how to enable build-time support.
debian/control is generated for the python version by debian/control.in
so we patch both files, then enable --with-dtrace in the rules.
At this stage this patch is blocked by the MIR for systemtap-sdt-dev,
and I will also file this
Assignee: Trent Lloyd (lathiat)
Status: Confirmed
** Changed in: python3.8 (Ubuntu)
Status: New => Confirmed
** Changed in: python3.8 (Ubuntu)
Importance: Undecided => Wishlist
** Changed in: python3.8 (Ubuntu)
Assignee: (unassigned) => Trent Lloyd (lathiat)
Can we get confirmation that this won't be fixed in terms of fixing
older images, and that the correct solution (as suggested by Adam
Conrad) is to update to the latest 'xenial-updates' netboot image?
And if so, change the bug status from Confirmed to something else (not
sure if Fix Released or
draft patch (not well tested yet), but I am having trouble because
several of the tests (unrelated to this patch, they fail with the
current git master) fail on disco, but not bionic.
Some of the tests fail when you run them a second time without opening a new
terminal (even on bionic), I've
Public bug reported:
NetworkManager 1.15.2 or later (as included first in Ubuntu 19.04 Disco Dingo)
now requires that files in /{etc,run}/NetworkManager/system-connections end in
the suffix '.nmconnection' as per the following commit:
Forgot to comment: This issue was resolved by the Mirror team shortly
after
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1814105
Title:
random 404s on security.ubuntu.com for libavahi packages
To
reproduction
(4) Can you give me a full run down of the steps to get into this state, e.g.
the machine was deployed with a specific Ubuntu ISO and then the full list of
commands used to that time, etc.
** Changed in: avahi (Ubuntu)
Assignee: (unassigned) => Trent Lloyd (lathiat)
** Changed in: av
I was able to reproduce this issue, I have forwarded it onto the
relevant team to look into.
** Changed in: avahi (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Marking invalid as it's not technically a bug against avahi, but as
above, have arranged to have the issue looked at.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1814105
Title:
random 404s on
** Changed in: avahi (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/652870
Title:
Avahi update causes internet connetions to fail
To manage notifications
** Bug watch added: github.com/lathiat/avahi/issues #2
https://github.com/lathiat/avahi/issues/2
** Also affects: avahi via
https://github.com/lathiat/avahi/issues/2
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
** Changed in: avahi (Ubuntu)
Status: Incomplete => Triaged
** Changed in: avahi (Ubuntu)
Assignee: (unassigned) => Trent Lloyd (lathiat)
** Bug watch added: github.com/lathiat/avahi/issues #210
https://github.com/lathiat/avahi/issues/210
** Also affects: avahi via
** Bug watch added: github.com/apple/cups/issues #5438
https://github.com/apple/cups/issues/5438
** Also affects: cups via
https://github.com/apple/cups/issues/5438
Importance: Unknown
Status: Unknown
** Description changed:
When using CUPS filters, these filters can take a
I enabled "debug2" log level and tested again. I found the following entries in
the log:
d [20/Nov/2018:08:22:25 +0100] cupsdCheckJobs: 1 active jobs, sleeping=0,
ac-power=-1, reload=0, curtime=1542698545
d [20/Nov/2018:08:22:25 +0100] cupsdCheckJobs: Job 75 - dest="hvitcpdf",
printer=(nil),
Public bug reported:
When using CUPS filters, these filters can take a few seconds to
complete.
In this case no documents are allowed to be lost on printing failures,
so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu
14.04.
With cups on 18.04, you get the following message
If restarting memcached fixes the issue, perhaps this is another
instance of the fact the memcache caches are not shared.
Refer to existing bug for keystone:
https://bugs.launchpad.net/charm-keystone/+bug/1771114
--
You received this bug notification because you are a member of Ubuntu
Bugs,
*** This bug is a duplicate of bug 1687607 ***
https://bugs.launchpad.net/bugs/1687607
** Changed in: python-os-brick (Ubuntu)
Status: New => Incomplete
** Changed in: python-os-brick (Ubuntu)
Status: Incomplete => Invalid
** Changed in: cloud-archive
Status: New =>
** Patch added: "lp1799648-fix-fc-scanning.patch"
https://bugs.launchpad.net/cloud-archive/+bug/1799648/+attachment/5204798/+files/lp1799648-fix-fc-scanning.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
Attaching Fibre Channel disks fails in python-os-brick
1.15.2-0ubuntu1~cloud0 (xenial-pike) because it searches for the local
WWN instead of the remote WWN.
This has been fixed upstream:
https://review.openstack.org/#/c/520052/
Instructions fixed to work with the 80 column limit of comments:
echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe
multiverse" | \
sudo tee -a /etc/apt/sources.list.d/ddebs.list
sudo apt update
sudo apt install linux-tools-generic ubuntu-dbgsym-keyring \
Hi Matt,
Thanks for the report. I'd like to profile avahi using perf to get
information on what functions are being executed. Could you run the
following commands to generate such data?
If you are unsure about any of this feel free to ask.
echo "deb http://ddebs.ubuntu.com $(lsb_release -cs)
Hi Nim (nimpetro),
You've added a comment to an existing bug, which dopes not appear to be
related to the problem you are having. This bug is about network issues
with CUPS connecting to printers and not related to the page print
formatting being incorrect.
Please either open a new bug for your
Looks like the recent astroid rebuild/changes removed the file, but it's
still present in alembic
** Changed in: alembic (Ubuntu)
Importance: Critical => High
** Changed in: astroid (Ubuntu)
Importance: Critical => High
** Changed in: dh-python (Ubuntu)
Importance: Critical => High
**
It appears these packages are in main but mainly pulled in (at least on
my system) by 'devscripts'. This affects cosmic.
** Also affects: alembic (Ubuntu)
Importance: Undecided
Status: New
** Also affects: astroid (Ubuntu)
Importance: Undecided
Status: New
** Changed in:
Public bug reported:
Python packages should not ship /usr/lib/python3/dist-
packages/.pytest_cache
Recently, two packages python3-alembic and python3-astroid both shipped
these files which collided on package install
dh-python has been improved upstream to stream all hidden "dot"
directories in
Telstra DNS serversr are hijacking the DNS for launchpadlibrarian.net
and then transparently proxying it. They aren't intercepting the SSL,
but without SNI it fails to pass the connection through.
Seems suspiciously similar to the URL filtering used for thepiratebay
and various other piracy
Public bug reported:
pull-lp-source fails to download packages on xenial and bionic due to a
non-descript SSL error
lathiat@optane ~$ pull-lp-source percona-toolkit xenial
pull-lp-source: Downloading percona-toolkit version 2.2.16-1
pull-lp-source: Error: Failed to download: [SSL] unknown error
Workaround: pip install httplib2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790574
Title:
pull-lp-source fails due to SSL error - pull-lp-source: Error: Failed
to download: [SSL] unknown
ged in: avahi (Ubuntu Bionic)
Assignee: (unassigned) => Trent Lloyd (lathiat)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1752411
Title:
bind9-host, avahi-daemon-check-dns.sh hang forever
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1752411
Title:
bind9-host, avahi-daemon-check-dns.sh hang forever
> When host call fails (even with timeout), it returns "1" claiming
"dns_has_local()=true".
0 = true, 1 = false (you implied the opposite)
What may add confusion here is the grep -vq check is like an extra check
to make sure host didn't return 0 (success = we found .local) but then
say 'not
I agree with the sentiment that 5 seconds feels too long, however as a
workaround I decided I would just copy the existing timeout. I certainly
would not want to make it longer since this is in the critical boot
path.
I would generally agree that in general a DNS request should fail faster
Request sponsorship of this upload for cosmic and then SRU to bionic
- New debdiff uploaded for both bionic and cosmic
- Fixed the SRU version for bionic
- Added a comment about the workaround to the script
- Updated bug description with SRU template
Tested patch working on bionic with my
** Patch added: "lp1752411-avahi-host-timeout-cosmic.patch"
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411/+attachment/5178710/+files/lp1752411-avahi-host-timeout-cosmic.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Description changed:
+ [Impact]
+
+ * Network connections for some users fail (in some cases a direct
+ interface, in others when connecting a VPN) because the 'host' command
+ to check for .local in DNS called by /usr/lib/avahi/avahi-daemon-check-
+ dns.sh never times out like it should -
** Patch added: "lp1752411-avahi-host-timeout-bionic.patch"
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411/+attachment/5178693/+files/lp1752411-avahi-host-timeout-bionic.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Patch added: "lp1752411-avahi-host-timeout-cosmic.patch"
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411/+attachment/5178692/+files/lp1752411-avahi-host-timeout-cosmic.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Hoping to get attention to this again. Since 18.04.1 is out now, more
and more users are likely to hit this issue as more users will be
upgrading. This issue applies equally to desktop and server scenarios.
I would like to get lp1752411-avahi-host-timeout.diff sponsored for
upload please
--
You
Public bug reported:
Upgrading the systemd package, which contains systemd-networkd, appears
to restart networkd and subsequently reconfigure network interfaces
causing a brief connectivity outage.
This is a bionic system which has a network bridge as it's primary
interface through netplan.
You
** Attachment added: "netplan config"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1783272/+attachment/5167024/+files/01-netcfg.yaml
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1783272
** Attachment added: "syslog"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1783272/+attachment/5167022/+files/syslog
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1783272
Title:
** Attachment added: "log of terminal session during upgrade"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1783272/+attachment/5167023/+files/apt-upgrade-console-log.txt
** Description changed:
Upgrading the systemd package, which contains systemd-networkd, appears
to restart
I identified that most likely there was minimal security impact, however
I reported the issue upstream via the security contact anyway. They
generally agreed exploit-ability didn't seem likely and so have simply
applied a patch to stop using the bad RNG.
** Changed in: avahi (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1586528
Title:
Avahi-daemon withdraws address record
To manage notifications about
Sponsors: Can we get this debdiff uploaded now? We've had a few more
reports and I'd like to get this workaround in place.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1752411
Title:
bind9-host,
Thanks for the note ronny, that is a really helpful note. That may well
be the cause for many of these cases.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1586528
Title:
Avahi-daemon withdraws
Verified on xenial-queens; fresh nova-lxd install from conjure-up was
exhibiting the behavior, restarting the service did not help. Upgraded
package from queens-proposed and the issue no longer occurs.
** Tags removed: verification-queens-needed
** Tags added: verification-queens-done
--
You
101 - 200 of 487 matches
Mail list logo
