I was able to reproduce on Ubuntu 20.04 too (by switching the active
network interface), so this may not be a recent regression.
--
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/bug
I split the "Current DNS Server" issue into bug #2008964.
--
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/2007728
Title:
resolved results differ from those from its current
Public bug reported:
This is split from bug #2007728.
On a network with multiple DNS servers provided by DHCP, the "Current
DNS Server" shown by `resolvectl status` is sometimes not the first
server or even the second server, even when those servers appear to be
working (and other hosts continue
Alright. The failure on a specific .local domain is consistent. I have
not tested adding a non-".local" domain to the preferred name server,
but your explanation that resolved now fully excludes .local from DNS
queries makes sense. I still think that this is undesirable behavior
since it breaks com
@Jeremy: I figured out the nature of the issue you originally reported
in this bug. With this combo:
$ dpkg-query -W libglib2.0-0 gnome-settings-daemon
gnome-settings-daemon 44~beta-1ubuntu1
libglib2.0-0:amd64 2.75.3-3
and as long as no IBus IM has been added to the list of input sources,
** Description changed:
+ [Impact]
+
+ The ActivationPolicy property in .network files is ignored for VLANs.
+
+ [Test Plan]
+
+ * On a Jammy machine with an interface named ens3, create the following
+ configs:
+
+ $ cat > /etc/systemd/network/10-vlan18.netdev << EOF
+ [NetDev]
+ Name=vlan18
** Description changed:
+ [Impact]
+
+ If a DHCP server pushes down a local subnet route with a null gateway,
+ the systemd-networkd DHCP client does not correctly install the route.
+ Instead, the route is ignored.
+
+ [Test Plan]
+
+ Taken from
+ https://bugs.launchpad.net/ubuntu/+source/syst
** Tags added: server-triage-discuss
--
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/2008465
Title:
apt repository broken when having only jammy and jammy-security apt-
Removing the systemd jammy task, it's unlikely such a change would be
SRUed.
** Changed in: systemd (Ubuntu Jammy)
Status: Confirmed => Won't Fix
** Tags removed: server-todo
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscrib
** Also affects: openldap (Ubuntu Kinetic)
Importance: Undecided
Status: New
** Changed in: openldap (Ubuntu Kinetic)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
** Changed in: openldap (Ubuntu Kinetic)
Importance: Undecided => High
--
You received this bug noti
Thanks for the heads up, Simon. I talked to Marc and he confirmed that
he intends to MRE rsync, so I reassigned this bug to him.
** Changed in: rsync (Ubuntu Jammy)
Assignee: Sergio Durigan Junior (sergiodj) => Marc Deslauriers (mdeslaur)
** Tags removed: server-todo
--
You received this
Yes, I plan on releasing 3.2.7 to jammy and kinetic as a security update
possibly next week, so that should take care of this issue at the same
time.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bug
Now that you mention it, I'm not sure. Something was definitely
inconsistent, but the inconsistency may have been across different
internal names rather than across requests on the same name, and it did
not occur to me at the time that the .local names were in a different
category. I will check tom
I am referring to the section of [1] that states that "lookups for
domains with the ".local" suffix are not routed to DNS servers, unless
the domain is specified explicitly as routing or search domain for the
DNS server and interface." But now I am confused by what you are saying.
Initially you sai
ibus in lunar-release was built against glib2.0 2.74.5-1. I tried a no-
change rebuild of ibus against glib2.0 2.75.3-3, but it didn't help.
(Such a rebuild may still be motivated later.)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is sub
Would you describe the "as documented" behavior? It still seems wacky to
me that resolved returns the DNS result the majority of the time but not
all of the time. If the design intent is to use only mDNS for .local
domains, it ought to ignore DNS entirely for those domains. Inconsistent
behavior me
I /think/ there is work being done by security to land a MRE for rsync,
you might want to sync with @mdeslaur.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/2007837
Title:
I guess you are talking abut two separate issues here. I was addressing
the "fails to resolve .local domains" issue. Please open a separate bug
report, including debug-level logs from systemd-resolved, for the
"inconsistent DNS server selection" issue. Generally, once a DNS server
fails in some way
** Changed in: rsync (Ubuntu Jammy)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/2007837
Title:
Regression
The first two servers do indeed provide the .local domains. The possible
violation of RFC 6762 does not explain the inconsistency of the results
or the regression from Ubuntu 18.04 and Ubuntu 20.04. There is no case
in which the correct behavior for a single configuration is to query the
"Current D
I believe this is because you are defining ".local" domains in your DNS
server. According to [1], "lookups for domains with the ".local" suffix
are not routed to DNS servers, unless the domain is specified explicitly
as routing or search domain for the DNS server and interface. This means
that on n
Want to mention that the issue is not present with glib2.0 2.75.3-3 if
fcitx5 is used instead of ibus. :/
** Also affects: ibus (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
With glib2.0 2.75.3-3 installed and when starting the Firefox snap from
terminal I see these warning messages:
[Parent 3792, Main Thread] WARNING: Unable to connect to ibus: Could not
connect: Permission denied: 'glib warning', file
/build/firefox/parts/firefox/build/toolkit/xre/nsSigHandlers.cpp:
The below two patches in Description could cause the screencast
regression, so they were reverted, if we want add them again we need two
gstreamer's patches in comment #51.
* d/p/0001-buffers-ensure-buffer-size-does-not-exceed-maxsize.patch
d/p/0002-gst-dequeue-a-shared-buffer-instead-of-ori
** Changed in: openldap (Ubuntu Jammy)
Status: New => In Progress
** Changed in: openldap (Ubuntu Kinetic)
Status: New => In Progress
** Changed in: openldap (Ubuntu Jammy)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Changed in: openldap (Ubuntu Kinetic)
Ass
For comment #38, currently it sounds good, if we upgrade the gstreamer
to 1.20.4, we need backport below patch.
commit d7b443197bcc0789305d6a8722bca1fdd182070b
Author: Sebastian Keller
Date: Thu Oct 6 00:20:16 2022 +0200
screencast: Don't force buffer copies on recent gstreamer versions
@seb128,
I went through this issue again.
On 22.04.2, it works fine. With pipewire 0.3.48-1ubuntu3, because it
revert the patches for Bug #1985057 , so currently we don't need to do
SRU for this issue.
To make this issue clear, let's focus on the SRU process on Bug
#1985057.
--
You received th
** Summary changed:
- xsettings ibus commit broke text input for Firefox & Chromium snaps
+ glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps
** No longer affects: gnome-settings-daemon (Ubuntu)
** Changed in: glib2.0 (Ubuntu)
Importance: Undecided => High
** Tags added: rls-ll
Hmm.. Suddenly I could no longer type in the address bar of the Firefox
snap. But I think the culprit is glib2.0 2.75.3-3, which I installed
from -proposed yesterday in order to test build g-c-c from
ubuntu/master. After having downgraded glib2.0 to 2.74.5-1 the issue is
no longer present.
** Also
29 matches
Mail list logo
