date:20230301

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/bugs/2008964

Title:
  resolved falls back to a non-preferred name server when the preferred
  name server appears to be working.

Status in systemd package in Ubuntu:
  New

Bug description:
  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 to use them). This appears to occur
  on Ubuntu 22.04 but not on Ubuntu 20.04, Ubuntu 18.04, or Windows 10.

  RFC 2132 section 3.8 provides that servers are listed in order of
  preference.

  It seems that the correct behavior is that resolved picks as its
  "Current DNS Server" the first reachable server in the list provided
  by the DHCP server. The observed behavior is that resolved sometimes
  picks as its "Current DNS Server" some server other than the first
  reachable server in the list.

  My hypothesis is that there is some name server availability check
  that is too stringent and that there is no mechanism to retry the
  preferred server after that check fails. I have not looked at the code
  or captured packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2008964/+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 2007728] Re: resolved results differ from those from its current upstream server.

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 upstream server.

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On a network with multiple DNS servers provided by DHCP, only the
  first two of which cover local names, resolved returns universally
  known names but fails to return the special names even when the
  "Current DNS Server" shown by `resolvectl status` returns the special
  names.

  Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS
  servers with the local names. Windows servers with Active Directory
  enabled in this case. The DHCP server (a Cisco 4451 in this case)
  provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and
  8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and
  172.16.9.5 as the "Current DNS Server".

  `host localdomain.local` returns SRVFAIL, and `host localdomain.local
  127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
  returns the correct result. This all happens regardless of the
  "Current DNS Server".

  Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons
  that are not clear even when the other servers are working properly,
  which seems to violate the principle of RFC 2132 section 3.8 that
  servers are listed in order of preference.

  So, in short, it seems that the correct behavior is that (1) resolved
  returns results consistent with its "Current DNS Server" and (2)
  resolved picks as its "Current DNS Server" the first reachable server
  in the list. The current behavior is that (1) resolved returns results
  sometimes inconsistent with its "Current DNS Server" and (2) resolved
  sometimes picks as its "Current DNS Server" some server other than the
  first reachable server in the list. The first issue is consistently
  reproducible, and the second is readily reproducible in a short period
  of time.

  The problem appears on Ubuntu 22.04 and seems not to be present on
  Ubuntu 18.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2008964] [NEW] resolved falls back to a non-preferred name server when the preferred name server appears to be working.

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 to use them). This appears to occur on
Ubuntu 22.04 but not on Ubuntu 20.04, Ubuntu 18.04, or Windows 10.

RFC 2132 section 3.8 provides that servers are listed in order of
preference.

It seems that the correct behavior is that resolved picks as its
"Current DNS Server" the first reachable server in the list provided by
the DHCP server. The observed behavior is that resolved sometimes picks
as its "Current DNS Server" some server other than the first reachable
server in the list.

My hypothesis is that there is some name server availability check that
is too stringent and that there is no mechanism to retry the preferred
server after that check fails. I have not looked at the code or captured
packets.

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

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

Title:
  resolved falls back to a non-preferred name server when the preferred
  name server appears to be working.

Status in systemd package in Ubuntu:
  New

Bug description:
  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 to use them). This appears to occur
  on Ubuntu 22.04 but not on Ubuntu 20.04, Ubuntu 18.04, or Windows 10.

  RFC 2132 section 3.8 provides that servers are listed in order of
  preference.

  It seems that the correct behavior is that resolved picks as its
  "Current DNS Server" the first reachable server in the list provided
  by the DHCP server. The observed behavior is that resolved sometimes
  picks as its "Current DNS Server" some server other than the first
  reachable server in the list.

  My hypothesis is that there is some name server availability check
  that is too stringent and that there is no mechanism to retry the
  preferred server after that check fails. I have not looked at the code
  or captured packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2008964/+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 2007728] Re: resolved results differ from those from its current upstream server.

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 common legacy configurations without a clear indication
of what the issue is and without an easy fix even for those who know
what is broken.

-- 
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 upstream server.

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On a network with multiple DNS servers provided by DHCP, only the
  first two of which cover local names, resolved returns universally
  known names but fails to return the special names even when the
  "Current DNS Server" shown by `resolvectl status` returns the special
  names.

  Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS
  servers with the local names. Windows servers with Active Directory
  enabled in this case. The DHCP server (a Cisco 4451 in this case)
  provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and
  8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and
  172.16.9.5 as the "Current DNS Server".

  `host localdomain.local` returns SRVFAIL, and `host localdomain.local
  127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
  returns the correct result. This all happens regardless of the
  "Current DNS Server".

  Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons
  that are not clear even when the other servers are working properly,
  which seems to violate the principle of RFC 2132 section 3.8 that
  servers are listed in order of preference.

  So, in short, it seems that the correct behavior is that (1) resolved
  returns results consistent with its "Current DNS Server" and (2)
  resolved picks as its "Current DNS Server" the first reachable server
  in the list. The current behavior is that (1) resolved returns results
  sometimes inconsistent with its "Current DNS Server" and (2) resolved
  sometimes picks as its "Current DNS Server" some server other than the
  first reachable server in the list. The first issue is consistently
  reproducible, and the second is readily reproducible in a short period
  of time.

  The problem appears on Ubuntu 22.04 and seems not to be present on
  Ubuntu 18.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2008279] Re: glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps

@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,
you can successfully run the Firefox snap in a wayland session. I.e.
with that upstream gnome-settings-daemon commit reverted.

If you had tried an x11 session, you'd have found that the reversal
didn't help (because of im-config 0.55-1).

And if you had added some IBus IM (and re-logged in), you'd likewise
have found that the reversal didn't help.

What does help in all cases ATM is to downgrade the glib2.0 packages to
2.74. So somehow the snaps need to be able to talk with ibus also when
glib2.0 2.75 is present.

** Tags removed: update-excuse

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

Title:
  glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps

Status in glib2.0 package in Ubuntu:
  New
Status in ibus package in Ubuntu:
  New

Bug description:
  While preparing the gnome-settings-daemon 44 Beta update for Ubuntu
  23.04, I noticed that I could no longer enter text in the address bars
  for the Chromium or Firefox snaps.

  Therefore, I reverted https://gitlab.gnome.org/GNOME/gnome-settings-
  daemon/-/commit/27bc0889c so that we could continue with the update.
  See https://salsa.debian.org/gnome-team/gnome-settings-
  daemon/-/commit/baeeed93

  Before I did that, I tested disabling our patches but it didn't make a
  difference.

  I was unable to reproduce the issue on Debian Testing but there may
  have been differences in how snap was configured there.

  I'm filing this bug since ideally we would not be diverging from
  upstream here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2008279/+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 2000880] Re: systemd-networkd: ActivationPolicy ignored in VLANs

** 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
+ Kind=vlan
+ 
+ [VLAN]
+ Id=18
+ EOF
+ 
+ $ cat > /etc/systemd/network/20-vlan18.network << EOF
+ [Match]
+ Name=vlan18
+ 
+ [Network]
+ Address=10.10.1.1/24
+ 
+ [Link]
+ ActivationPolicy=manual
+ EOF
+ 
+ $ cat > /etc/systemd/network/30-ens3.network << EOF
+ [Match]
+ Name=ens3
+ 
+ [Network]
+ DHCP=ipv4
+ VLAN=vlan18
+ EOF
+ 
+ * Reboot the machine
+ * On an affected machine, the vlan18@ens3 interface will have a configured IP 
at boot, despite the ActivationPolicy=manual setting in 
/etc/systemd/network/20-vlan18.network. On a patched machine, the interface 
should not have a configured IP.
+ 
+ [Where problems could occur]
+ 
+ The patch adds a condition where a netdev is not yet ready to be
+ created. Specifically, it makes sure stacked netdevs are not created
+ before their underlying link is activated. If we saw any problems, it
+ would be related to netdev creation.
+ 
+ [Original Description]
+ 
  This has been fixed upstream, see
  
  Upstream bug: https://github.com/systemd/systemd/issues/22593
  
  Any chance of a backport of the fix to 22.04?
  
  Fix: https://github.com/systemd/systemd-stable/pull/211

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

Title:
  systemd-networkd: ActivationPolicy ignored in VLANs

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Triaged
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [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
  Kind=vlan

  [VLAN]
  Id=18
  EOF

  $ cat > /etc/systemd/network/20-vlan18.network << EOF
  [Match]
  Name=vlan18

  [Network]
  Address=10.10.1.1/24

  [Link]
  ActivationPolicy=manual
  EOF

  $ cat > /etc/systemd/network/30-ens3.network << EOF
  [Match]
  Name=ens3

  [Network]
  DHCP=ipv4
  VLAN=vlan18
  EOF

  * Reboot the machine
  * On an affected machine, the vlan18@ens3 interface will have a configured IP 
at boot, despite the ActivationPolicy=manual setting in 
/etc/systemd/network/20-vlan18.network. On a patched machine, the interface 
should not have a configured IP.

  [Where problems could occur]

  The patch adds a condition where a netdev is not yet ready to be
  created. Specifically, it makes sure stacked netdevs are not created
  before their underlying link is activated. If we saw any problems, it
  would be related to netdev creation.

  [Original Description]

  This has been fixed upstream, see

  Upstream bug: https://github.com/systemd/systemd/issues/22593

  Any chance of a backport of the fix to 22.04?

  Fix: https://github.com/systemd/systemd-stable/pull/211

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000880/+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 2004478] Re: systemd-networkd's dhcp4 client ignores local subnet routes

** 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/systemd/+bug/2004478/comments/2.
+ 
+ * Start a Jammy LXD container:
+ 
+ $ lxc launch ubuntu-daily:jammy jammy
+ $ lxc exec jammy bash
+ 
+ * Create a veth pair:
+ 
+ $ ip link add veth0 up type veth peer name veth1
+ $ ip addr add 172.20.0.1/24 dev veth0
+ $ cat > /etc/netplan/60-veth1.yaml  /etc/netplan/60-veth1.yaml

[Touch-packages] [Bug 2008465] Re: apt repository broken when having only jammy and jammy-security apt-repos enabled

2023-03-01 Thread Athos Ribeiro

** 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-
  repos enabled

Status in openldap package in Ubuntu:
  New

Bug description:
  Having installed Ubuntu 22 server from server-live-cd 
https://releases.ubuntu.com/22.04/ubuntu-22.04.1-live-server-amd64.iso
  (md5sum e8d2a77c51b599c10651608a5d8c286f)

  without network connection to internet (so no connection to ubuntu apt
  repositories). After offline installation completed, we remove the
  "jammy-updates" from the /etc/apt/sources.list so it looks like so:

  # cat /etc/apt/sources.list
  deb http://de.archive.ubuntu.com/ubuntu jammy 
  main restricted universe multiverse
  deb http://de.archive.ubuntu.com/ubuntu jammy-security
  main restricted universe multiverse

  Now we give the host network access and do "apt update" to refresh the
  apt repository.

  We assume that the installed package libldap-2.5-0 version 
2.5.12+dfsg-0ubuntu0.22.04.1
  was installed from the ubuntu installer cd which is a version from 
jammy-updates.

  Now we are unable to install package "ldap-utils" because that depends
  on package libldap-2.5-0 version 2.5.11+dfsg-1~exp1ubuntu3.1 (which is
  older than the offline installed version 2.5.12+dfsg-0ubuntu0.22.04.1)

  # lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 22.04.1 LTS
  Release:22.04
  Codename:   jammy

  # apt-cache policy libldap-2.5-0
  libldap-2.5-0:
    Installed: 2.5.12+dfsg-0ubuntu0.22.04.1
    Candidate: 2.5.12+dfsg-0ubuntu0.22.04.1
    Version table:
   *** 2.5.12+dfsg-0ubuntu0.22.04.1 100
  100 /var/lib/dpkg/status
   2.5.11+dfsg-1~exp1ubuntu3.1 500
  500 http://de.archive.ubuntu.com/ubuntu jammy-security/main amd64 
Packages
   2.5.11+dfsg-1~exp1ubuntu3 500
  500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

  # apt install --simulate ldap-utils
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  The following packages have unmet dependencies:
   ldap-utils : Depends: libldap-2.5-0 (= 2.5.11+dfsg-1~exp1ubuntu3.1) but 
2.5.12+dfsg-0ubuntu0.22.04.1 is to be installed
  E: Unable to correct problems, you have held broken packages.

  --
  The problem is solved when adding line

  deb http://de.archive.ubuntu.com/ubuntu jammy-updates
  main restricted universe multiverse

  to /etc/apt/sources.list

  But we want _only_ security updates, to keep the updates minimal.

  Other workaround is "apt remove libldap-2.5-0", then when installing
  ldap-utils that fetches the older libldap-2.5-0 version
  2.5.11+dfsg-1~exp1ubuntu3.1 and repo is consistent.

  Questions:
  - Can you confirm that the package version from the server-live-cd see above 
is the version from the jammy-updates repository?
  - Do you agree that when the above question is answered yes, having 
jammy-updates apt-repository is mandatory?
  - if jammy-updates repo should be mandatory should this be documented?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2008465/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit

2023-03-01 Thread Andreas Hasenack

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 subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970634

Title:
  FTBFS: mariadb fails to start due to low MEMLOCK limit

Status in mariadb-10.6 package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in mariadb-10.6 source package in Jammy:
  Fix Released
Status in systemd source package in Jammy:
  Won't Fix

Bug description:
  [Impact]

  Jammy's MariaDB will fail to build, and also fail to start, if the
  underlying kernel is 5.4.x (focal's) and if it's running in an
  unprivileged container (lxd, docker). It will also fail to build in
  launchpad builders.

  Common scenarios where this combination exists is a focal host,
  running an unprivileged jammy container (lxd or docker), or even a
  chroot (the launchpad builders).

  Jammy's MariaDB was built with io_uring support, and it tries to
  enable it at runtime if it deems it's running on a supported kernel.
  There is a range of kernel versions it checks, but of interest for
  this SRU, the Focal (5.4.x) kernel is inside this range and io_uring
  will be enabled. The jammy kernel (5.15) is not, so io_uring will not
  be enabled there, and thus the bug is not manifested in that case.

  If io_uring is enabled, a higher MEMLOCK limit is required than what
  is set by default in focal or jammy (64Mb is what we get, 256Mb or
  more is required).

  The systemd unit file for mariadb tries to raise this limit, but in an
  unprivileged container this won't work.

  MariaDB has checks in place to catch when MEMLOCK is too low, in which
  case it will not use io_uring, but these checks are failing because of
  the LTO build flags that were used in the jammy build of mariadb. It's
  unclear if it's a bug in gcc or something else. There is more
  information in comment #1, comment #5 and later.

  The suggested fix here is to disable LTO for the jammy build. This has
  been done for kinetic already, and is also applied to the debian
  packaging (inside a distro-specific conditional).

  [Test Plan]
  The test plan is to launch mariadb in a jammy lxd container running on a 
focal host.

  lxc launch ubuntu:focal f --vm
  lxc shell f
  lxd init # just hit enter for all questions
  lxc launch ubuntu:jammy j
  lxc shell j
  ulimit -l # confirm it's less than 256
  apt update && apt install mariadb-server -y

  After the installation, mariadb will not be running, and this can be
  checked with:

  systemctl status mariadb.service

  or

  journalctl -u mariadb.server

  You will see something like this:
  Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database 
server...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
/usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be 
created!
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Compressed tables use zlib 1.2.11
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using transactional memory
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Number of pools: 1
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using crc32 + pclmulqdq instructions
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Warning] 
mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked 
limit, ulimit -l, or 
https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd 
(262144 bytes required)
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld 
got signal 6 ;

  And a crash dump.

  With the fixed version, the service will be running normally after
  installation.

  [Where problems could occur]
  The proposed fix is not a surgical strike. It's unfortunate that we didn't 
get to the bottom of why LTO is causing this behavior. Reverting it is still 
the quickest and less risky change at the moment, though. This gets us on par 
with upstream binary builds, and debian builds, and these also have wide test 
coverage and ample user base.

  The other regression possibility is that this is a rebuild of mariadb
  in the current jammy environment, and the package that is currently in
  jammy was built on March 10th, 2022. Most likely the reverse
  dependencies were updated in jammy since then.

  It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build
  logs and dep8 logs, and can't tell why the tests passed. At least the
  build log in jammy shows the

[Touch-packages] [Bug 2007625] Re: New upstream microrelease 2.5.14

2023-03-01 Thread Sergio Durigan Junior

** 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 notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/2007625

Title:
  New upstream microrelease 2.5.14

Status in openldap package in Ubuntu:
  New
Status in openldap source package in Jammy:
  In Progress
Status in openldap source package in Kinetic:
  New

Bug description:
  [ Impact ]

   * MRE for the latest stable OpenLDAP 2.5.x release, 2.5.14.

  This update includes bugfixes only following the SRU policy exception
  defined at https://wiki.ubuntu.com/OpenLDAPUpdates.

  [ Major Changes ]

   * See the list of bugs fixed in this release here:

  https://lists.openldap.org/hyperkitty/list/openldap-
  annou...@openldap.org/thread/TZQHR4SIWUA5BZTKDAKSFDOOGDVU4TU7/

  [ Test Plan ]

   * Upstream gitlab pipeline results:
  https://git.openldap.org/openldap/openldap/-/pipelines/4816

   * Upstream "call for testing":

  
https://lists.openldap.org/hyperkitty/list/openldap-techni...@openldap.org/message/ZJTFCIIY3HHUZIHENR3TUDGGFWIVJOCF/
  
https://lists.openldap.org/hyperkitty/list/openldap-techni...@openldap.org/message/XVFN3TCIDUZCWJA7RKFTZI2762UELAGM/
  
https://lists.openldap.org/hyperkitty/list/openldap-techni...@openldap.org/message/YZIFGANGSBCV2E547KS5C6DJGJ4Z4CEX/

   * As described in the MRE wiki page for OpenLDAP, the test plan is to
  build the package in bileto and make sure that (1) all build-time
  tests pass and (2) all autopkgtest runs (from reverse dependencies)
  also pass.

   * Build log (amd64) confirming that the build-time testsuite has been
  performed and completed successfully: TBD

   * Bileto ticket: https://bileto.ubuntu.com/#/ticket/4986

  [ Where problems could occur ]

   * Upstream tests are always executed during build-time. There are
  many reverse dependencies whose dep8 tests depend on OpenLDAP so the
  coverage is good. Nevertheless, there is always a risk for something
  to break since we are dealing with a microrelease upgrade. Whenever a
  test failure is detected, we will be on top of it and make sure it
  doesn't affect existing users.

  [ Other Info ]

   * This is a reoccurring MRE. See below for links to previous OpenLDAP
  MREs.

   * CVEs fixed by this release:
     - None.

  Current versions in supported releases that got updates:
   openldap | 2.5.13+dfsg-0ubuntu0.22.04.1 | jammy-updates   | source

  Special cases:
  - None.

  Previous MREs for OpenLDAP:
  - https://pad.lv/1977627
  - https://pad.lv/1983618

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2007625/+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 2007837] Re: Regression in stderr handling in 3.2.3 breaks BackupPc on 22.04; fix available in 3.2.4

2023-03-01 Thread Sergio Durigan Junior

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 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 in stderr handling in 3.2.3 breaks BackupPc on 22.04; fix
  available in 3.2.4

Status in rsync package in Ubuntu:
  Fix Released
Status in rsync source package in Jammy:
  Triaged
Status in rsync package in Debian:
  Unknown

Bug description:
  rsync 3.2.3 (packaged in Ubuntu 22.04) changes stderr handling,
  leading another bug in libfile-rsyncp-perl (in Ubuntu 18.04 and 20.04)
  to surface [1].

  It practically makes using BackupPC 3 impossible with clients using
  rsync 3.2.3, as is packaged for 22.04. The fact that BackupPC on 20.04
  can't be used to back up machines with 22.04 is rather surprising and
  has bitten other users [2].

  It's unclear whether the bug will be fixed in 18.04's and 20.04's
  libfile-rsyncp-perl package (for status, see [3]).

  Because of this, the rsync maintainer has included a patch in 3.2.4
  that fixes this regression [4] (even though not strictly an rsync
  bug). As a result, rsync 3.2.3 is the only affected version, which
  happens to be the one packaged in 22.04.

  This report is to request backporting that fix [4] to Ubuntu 22.04, so
  that things don't silently break in scenarios where the backup server
  is left at 20.04, and some backup clients happen to upgrade to 22.04.

  I'm not sure what the criteria for security releases are, but as the
  issue causes backup denial of service and has easy mitigation, I think
  it would make sense to put it through the security channel.

  [1]: https://github.com/WayneD/rsync/issues/95#issuecomment-699185358
  [2]: 
https://www.mail-archive.com/backuppc-users@lists.sourceforge.net/msg32673.html
  [3]: 
https://bugs.launchpad.net/ubuntu/+source/libfile-rsyncp-perl/+bug/2007833
  [4]: 
https://github.com/WayneD/rsync/commit/4adfdaaf12db26c348b4d6150119b377f9b622c8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/2007837/+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 2007837] Re: Regression in stderr handling in 3.2.3 breaks BackupPc on 22.04; fix available in 3.2.4

2023-03-01 Thread Marc Deslauriers

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://bugs.launchpad.net/bugs/2007837

Title:
  Regression in stderr handling in 3.2.3 breaks BackupPc on 22.04; fix
  available in 3.2.4

Status in rsync package in Ubuntu:
  Fix Released
Status in rsync source package in Jammy:
  Triaged
Status in rsync package in Debian:
  Unknown

Bug description:
  rsync 3.2.3 (packaged in Ubuntu 22.04) changes stderr handling,
  leading another bug in libfile-rsyncp-perl (in Ubuntu 18.04 and 20.04)
  to surface [1].

  It practically makes using BackupPC 3 impossible with clients using
  rsync 3.2.3, as is packaged for 22.04. The fact that BackupPC on 20.04
  can't be used to back up machines with 22.04 is rather surprising and
  has bitten other users [2].

  It's unclear whether the bug will be fixed in 18.04's and 20.04's
  libfile-rsyncp-perl package (for status, see [3]).

  Because of this, the rsync maintainer has included a patch in 3.2.4
  that fixes this regression [4] (even though not strictly an rsync
  bug). As a result, rsync 3.2.3 is the only affected version, which
  happens to be the one packaged in 22.04.

  This report is to request backporting that fix [4] to Ubuntu 22.04, so
  that things don't silently break in scenarios where the backup server
  is left at 20.04, and some backup clients happen to upgrade to 22.04.

  I'm not sure what the criteria for security releases are, but as the
  issue causes backup denial of service and has easy mitigation, I think
  it would make sense to put it through the security channel.

  [1]: https://github.com/WayneD/rsync/issues/95#issuecomment-699185358
  [2]: 
https://www.mail-archive.com/backuppc-users@lists.sourceforge.net/msg32673.html
  [3]: 
https://bugs.launchpad.net/ubuntu/+source/libfile-rsyncp-perl/+bug/2007833
  [4]: 
https://github.com/WayneD/rsync/commit/4adfdaaf12db26c348b4d6150119b377f9b622c8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/2007837/+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 2007728] Re: resolved results differ from those from its current upstream server.

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 tomorrow and report back.

-- 
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 upstream server.

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On a network with multiple DNS servers provided by DHCP, only the
  first two of which cover local names, resolved returns universally
  known names but fails to return the special names even when the
  "Current DNS Server" shown by `resolvectl status` returns the special
  names.

  Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS
  servers with the local names. Windows servers with Active Directory
  enabled in this case. The DHCP server (a Cisco 4451 in this case)
  provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and
  8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and
  172.16.9.5 as the "Current DNS Server".

  `host localdomain.local` returns SRVFAIL, and `host localdomain.local
  127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
  returns the correct result. This all happens regardless of the
  "Current DNS Server".

  Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons
  that are not clear even when the other servers are working properly,
  which seems to violate the principle of RFC 2132 section 3.8 that
  servers are listed in order of preference.

  So, in short, it seems that the correct behavior is that (1) resolved
  returns results consistent with its "Current DNS Server" and (2)
  resolved picks as its "Current DNS Server" the first reachable server
  in the list. The current behavior is that (1) resolved returns results
  sometimes inconsistent with its "Current DNS Server" and (2) resolved
  sometimes picks as its "Current DNS Server" some server other than the
  first reachable server in the list. The first issue is consistently
  reproducible, and the second is readily reproducible in a short period
  of time.

  The problem appears on Ubuntu 22.04 and seems not to be present on
  Ubuntu 18.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2007728] Re: resolved results differ from those from its current upstream server.

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 said:

> `host localdomain.local` returns SRVFAIL, and `host localdomain.local
127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
returns the correct result. This all happens regardless of the "Current
DNS Server".

But now you are saying systemd-resolved *sometimes* resolves .local
domains correctly?

[1] https://www.freedesktop.org/software/systemd/man/systemd-
resolved.service.html

-- 
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 upstream server.

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On a network with multiple DNS servers provided by DHCP, only the
  first two of which cover local names, resolved returns universally
  known names but fails to return the special names even when the
  "Current DNS Server" shown by `resolvectl status` returns the special
  names.

  Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS
  servers with the local names. Windows servers with Active Directory
  enabled in this case. The DHCP server (a Cisco 4451 in this case)
  provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and
  8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and
  172.16.9.5 as the "Current DNS Server".

  `host localdomain.local` returns SRVFAIL, and `host localdomain.local
  127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
  returns the correct result. This all happens regardless of the
  "Current DNS Server".

  Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons
  that are not clear even when the other servers are working properly,
  which seems to violate the principle of RFC 2132 section 3.8 that
  servers are listed in order of preference.

  So, in short, it seems that the correct behavior is that (1) resolved
  returns results consistent with its "Current DNS Server" and (2)
  resolved picks as its "Current DNS Server" the first reachable server
  in the list. The current behavior is that (1) resolved returns results
  sometimes inconsistent with its "Current DNS Server" and (2) resolved
  sometimes picks as its "Current DNS Server" some server other than the
  first reachable server in the list. The first issue is consistently
  reproducible, and the second is readily reproducible in a short period
  of time.

  The problem appears on Ubuntu 22.04 and seems not to be present on
  Ubuntu 18.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2008279] Re: glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps

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 subscribed to ibus in Ubuntu.
https://bugs.launchpad.net/bugs/2008279

Title:
  glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps

Status in glib2.0 package in Ubuntu:
  New
Status in ibus package in Ubuntu:
  New

Bug description:
  While preparing the gnome-settings-daemon 44 Beta update for Ubuntu
  23.04, I noticed that I could no longer enter text in the address bars
  for the Chromium or Firefox snaps.

  Therefore, I reverted https://gitlab.gnome.org/GNOME/gnome-settings-
  daemon/-/commit/27bc0889c so that we could continue with the update.
  See https://salsa.debian.org/gnome-team/gnome-settings-
  daemon/-/commit/baeeed93

  Before I did that, I tested disabling our patches but it didn't make a
  difference.

  I was unable to reproduce the issue on Debian Testing but there may
  have been differences in how snap was configured there.

  I'm filing this bug since ideally we would not be diverging from
  upstream here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2008279/+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 2007728] Re: resolved results differ from those from its current upstream server.

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 means that a configuration can test as correct, fail in the
field, fail to replicate the failure, and frustrate isolation of the
problem. I think that the earlier behavior makes a lot more sense and
would prefer to return to it.

Are you able to replicate the issue?

Given how closely the two possibly separate problems are related and
their similar effects, I am inclined to wait on filing a second bug
report on the server selection until it is clear that these are in fact
separate issues. The fact that no other hosts on the network exhibit the
problem (a highly symptomatic one since it breaks most services)
suggests that this is not an issue of both internal servers failing at
the same 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/2007728

Title:
  resolved results differ from those from its current upstream server.

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On a network with multiple DNS servers provided by DHCP, only the
  first two of which cover local names, resolved returns universally
  known names but fails to return the special names even when the
  "Current DNS Server" shown by `resolvectl status` returns the special
  names.

  Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS
  servers with the local names. Windows servers with Active Directory
  enabled in this case. The DHCP server (a Cisco 4451 in this case)
  provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and
  8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and
  172.16.9.5 as the "Current DNS Server".

  `host localdomain.local` returns SRVFAIL, and `host localdomain.local
  127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
  returns the correct result. This all happens regardless of the
  "Current DNS Server".

  Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons
  that are not clear even when the other servers are working properly,
  which seems to violate the principle of RFC 2132 section 3.8 that
  servers are listed in order of preference.

  So, in short, it seems that the correct behavior is that (1) resolved
  returns results consistent with its "Current DNS Server" and (2)
  resolved picks as its "Current DNS Server" the first reachable server
  in the list. The current behavior is that (1) resolved returns results
  sometimes inconsistent with its "Current DNS Server" and (2) resolved
  sometimes picks as its "Current DNS Server" some server other than the
  first reachable server in the list. The first issue is consistently
  reproducible, and the second is readily reproducible in a short period
  of time.

  The problem appears on Ubuntu 22.04 and seems not to be present on
  Ubuntu 18.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2007837] Re: Regression in stderr handling in 3.2.3 breaks BackupPc on 22.04; fix available in 3.2.4

2023-03-01 Thread Simon Déziel

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:
  Regression in stderr handling in 3.2.3 breaks BackupPc on 22.04; fix
  available in 3.2.4

Status in rsync package in Ubuntu:
  Fix Released
Status in rsync source package in Jammy:
  Triaged
Status in rsync package in Debian:
  Unknown

Bug description:
  rsync 3.2.3 (packaged in Ubuntu 22.04) changes stderr handling,
  leading another bug in libfile-rsyncp-perl (in Ubuntu 18.04 and 20.04)
  to surface [1].

  It practically makes using BackupPC 3 impossible with clients using
  rsync 3.2.3, as is packaged for 22.04. The fact that BackupPC on 20.04
  can't be used to back up machines with 22.04 is rather surprising and
  has bitten other users [2].

  It's unclear whether the bug will be fixed in 18.04's and 20.04's
  libfile-rsyncp-perl package (for status, see [3]).

  Because of this, the rsync maintainer has included a patch in 3.2.4
  that fixes this regression [4] (even though not strictly an rsync
  bug). As a result, rsync 3.2.3 is the only affected version, which
  happens to be the one packaged in 22.04.

  This report is to request backporting that fix [4] to Ubuntu 22.04, so
  that things don't silently break in scenarios where the backup server
  is left at 20.04, and some backup clients happen to upgrade to 22.04.

  I'm not sure what the criteria for security releases are, but as the
  issue causes backup denial of service and has easy mitigation, I think
  it would make sense to put it through the security channel.

  [1]: https://github.com/WayneD/rsync/issues/95#issuecomment-699185358
  [2]: 
https://www.mail-archive.com/backuppc-users@lists.sourceforge.net/msg32673.html
  [3]: 
https://bugs.launchpad.net/ubuntu/+source/libfile-rsyncp-perl/+bug/2007833
  [4]: 
https://github.com/WayneD/rsync/commit/4adfdaaf12db26c348b4d6150119b377f9b622c8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/2007837/+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 2007728] Re: resolved results differ from those from its current upstream server.

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, resolved will switch to the next server in the list,
and stick with that while it is working. So there may just be some
errors while using the first two servers. Hence, debug-level logs from
systemd-resolved would be helpful to diagnose that problem.

I will have to look closer at changes from 20.04 to 22.04, but at the
moment I think the behavior WRT .local domains is working as documented.

-- 
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 upstream server.

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On a network with multiple DNS servers provided by DHCP, only the
  first two of which cover local names, resolved returns universally
  known names but fails to return the special names even when the
  "Current DNS Server" shown by `resolvectl status` returns the special
  names.

  Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS
  servers with the local names. Windows servers with Active Directory
  enabled in this case. The DHCP server (a Cisco 4451 in this case)
  provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and
  8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and
  172.16.9.5 as the "Current DNS Server".

  `host localdomain.local` returns SRVFAIL, and `host localdomain.local
  127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
  returns the correct result. This all happens regardless of the
  "Current DNS Server".

  Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons
  that are not clear even when the other servers are working properly,
  which seems to violate the principle of RFC 2132 section 3.8 that
  servers are listed in order of preference.

  So, in short, it seems that the correct behavior is that (1) resolved
  returns results consistent with its "Current DNS Server" and (2)
  resolved picks as its "Current DNS Server" the first reachable server
  in the list. The current behavior is that (1) resolved returns results
  sometimes inconsistent with its "Current DNS Server" and (2) resolved
  sometimes picks as its "Current DNS Server" some server other than the
  first reachable server in the list. The first issue is consistently
  reproducible, and the second is readily reproducible in a short period
  of time.

  The problem appears on Ubuntu 22.04 and seems not to be present on
  Ubuntu 18.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2007837] Re: Regression in stderr handling in 3.2.3 breaks BackupPc on 22.04; fix available in 3.2.4

2023-03-01 Thread Christian Ehrhardt 

** 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 in stderr handling in 3.2.3 breaks BackupPc on 22.04; fix
  available in 3.2.4

Status in rsync package in Ubuntu:
  Fix Released
Status in rsync source package in Jammy:
  Triaged
Status in rsync package in Debian:
  Unknown

Bug description:
  rsync 3.2.3 (packaged in Ubuntu 22.04) changes stderr handling,
  leading another bug in libfile-rsyncp-perl (in Ubuntu 18.04 and 20.04)
  to surface [1].

  It practically makes using BackupPC 3 impossible with clients using
  rsync 3.2.3, as is packaged for 22.04. The fact that BackupPC on 20.04
  can't be used to back up machines with 22.04 is rather surprising and
  has bitten other users [2].

  It's unclear whether the bug will be fixed in 18.04's and 20.04's
  libfile-rsyncp-perl package (for status, see [3]).

  Because of this, the rsync maintainer has included a patch in 3.2.4
  that fixes this regression [4] (even though not strictly an rsync
  bug). As a result, rsync 3.2.3 is the only affected version, which
  happens to be the one packaged in 22.04.

  This report is to request backporting that fix [4] to Ubuntu 22.04, so
  that things don't silently break in scenarios where the backup server
  is left at 20.04, and some backup clients happen to upgrade to 22.04.

  I'm not sure what the criteria for security releases are, but as the
  issue causes backup denial of service and has easy mitigation, I think
  it would make sense to put it through the security channel.

  [1]: https://github.com/WayneD/rsync/issues/95#issuecomment-699185358
  [2]: 
https://www.mail-archive.com/backuppc-users@lists.sourceforge.net/msg32673.html
  [3]: 
https://bugs.launchpad.net/ubuntu/+source/libfile-rsyncp-perl/+bug/2007833
  [4]: 
https://github.com/WayneD/rsync/commit/4adfdaaf12db26c348b4d6150119b377f9b622c8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/2007837/+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 2007728] Re: resolved results differ from those from its current upstream server.

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 DNS Server" for the .local name sometimes and mDNS other times.
This also does not explain why the "Current DNS Server" selection
sometimes fails to observe the order provided in the DHCP response. If
resolved ignores the server ordering and the low-priority servers lack
the internal names, even switching the suffix of the internal names is
insufficient to provide the desired results. We have reverted the
clients in question to Ubuntu 20.04 for now, and they work correctly.

-- 
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 upstream server.

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On a network with multiple DNS servers provided by DHCP, only the
  first two of which cover local names, resolved returns universally
  known names but fails to return the special names even when the
  "Current DNS Server" shown by `resolvectl status` returns the special
  names.

  Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS
  servers with the local names. Windows servers with Active Directory
  enabled in this case. The DHCP server (a Cisco 4451 in this case)
  provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and
  8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and
  172.16.9.5 as the "Current DNS Server".

  `host localdomain.local` returns SRVFAIL, and `host localdomain.local
  127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
  returns the correct result. This all happens regardless of the
  "Current DNS Server".

  Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons
  that are not clear even when the other servers are working properly,
  which seems to violate the principle of RFC 2132 section 3.8 that
  servers are listed in order of preference.

  So, in short, it seems that the correct behavior is that (1) resolved
  returns results consistent with its "Current DNS Server" and (2)
  resolved picks as its "Current DNS Server" the first reachable server
  in the list. The current behavior is that (1) resolved returns results
  sometimes inconsistent with its "Current DNS Server" and (2) resolved
  sometimes picks as its "Current DNS Server" some server other than the
  first reachable server in the list. The first issue is consistently
  reproducible, and the second is readily reproducible in a short period
  of time.

  The problem appears on Ubuntu 22.04 and seems not to be present on
  Ubuntu 18.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2007728] Re: resolved results differ from those from its current upstream server.

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 networks where the ".local" domain is defined in a site-specific
DNS server, explicit search or routing domains need to be configured to
make lookups work within this DNS domain. Note that these days, it's
generally recommended to avoid defining ".local" in a DNS server, as
RFC6762 reserves this domain for exclusive MulticastDNS use."

In other words, I think you can either (1) choose a different domain
suffix, or (2) override the default behavior by configuring the Domains=
property in resolved.conf[2].

[1]
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Protocols%20and%20Routing

[2] https://www.freedesktop.org/software/systemd/man/resolved.conf.html#Domains=

** Changed in: systemd (Ubuntu)
Status: New => Incomplete

--
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 upstream server.

Status in systemd package in Ubuntu:
Incomplete

Bug description:
On a network with multiple DNS servers provided by DHCP, only the
first two of which cover local names, resolved returns universally
known names but fails to return the special names even when the
"Current DNS Server" shown by `resolvectl status` returns the special
names.

Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS
servers with the local names. Windows servers with Active Directory
enabled in this case. The DHCP server (a Cisco 4451 in this case)
provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and
8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and
172.16.9.5 as the "Current DNS Server".

`host localdomain.local` returns SRVFAIL, and `host localdomain.local
127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
returns the correct result. This all happens regardless of the
"Current DNS Server".

Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons
that are not clear even when the other servers are working properly,
which seems to violate the principle of RFC 2132 section 3.8 that
servers are listed in order of preference.

So, in short, it seems that the correct behavior is that (1) resolved
returns results consistent with its "Current DNS Server" and (2)
resolved picks as its "Current DNS Server" the first reachable server
in the list. The current behavior is that (1) resolved returns results
sometimes inconsistent with its "Current DNS Server" and (2) resolved
sometimes picks as its "Current DNS Server" some server other than the
first reachable server in the list. The first issue is consistently
reproducible, and the second is readily reproducible in a short period
of time.

The problem appears on Ubuntu 22.04 and seems not to be present on
Ubuntu 18.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2008279] Re: glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps

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 to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/2008279

Title:
  glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps

Status in glib2.0 package in Ubuntu:
  New
Status in ibus package in Ubuntu:
  New

Bug description:
  While preparing the gnome-settings-daemon 44 Beta update for Ubuntu
  23.04, I noticed that I could no longer enter text in the address bars
  for the Chromium or Firefox snaps.

  Therefore, I reverted https://gitlab.gnome.org/GNOME/gnome-settings-
  daemon/-/commit/27bc0889c so that we could continue with the update.
  See https://salsa.debian.org/gnome-team/gnome-settings-
  daemon/-/commit/baeeed93

  Before I did that, I tested disabling our patches but it didn't make a
  difference.

  I was unable to reproduce the issue on Debian Testing but there may
  have been differences in how snap was configured there.

  I'm filing this bug since ideally we would not be diverging from
  upstream here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2008279/+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 2008279] Re: glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps

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:167

(firefox:3792): IBUS-WARNING **: 15:23:11.814: Unable to connect to
ibus: Could not connect: Permission denied

FTR the issue is present on both wayland and x11.

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

Title:
  glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps

Status in glib2.0 package in Ubuntu:
  New

Bug description:
  While preparing the gnome-settings-daemon 44 Beta update for Ubuntu
  23.04, I noticed that I could no longer enter text in the address bars
  for the Chromium or Firefox snaps.

  Therefore, I reverted https://gitlab.gnome.org/GNOME/gnome-settings-
  daemon/-/commit/27bc0889c so that we could continue with the update.
  See https://salsa.debian.org/gnome-team/gnome-settings-
  daemon/-/commit/baeeed93

  Before I did that, I tested disabling our patches but it didn't make a
  difference.

  I was unable to reproduce the issue on Debian Testing but there may
  have been differences in how snap was configured there.

  I'm filing this bug since ideally we would not be diverging from
  upstream here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2008279/+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 1985057] Re: Camera output freeze when using pipewiresrc

2023-03-01 Thread Bin Li

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-original-pool.patch
- Camera output freeze when using pipewiresrc (LP: #1985057)

I also added another pipewire patch, d/p/0003-gst-copy-buffer-memory-in-
dequeue_buffer-using-gst_m.patch from comment #51 .

** Also affects: gst-plugins-base1.0 (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: gstreamer1.0 (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Camera output freeze when using pipewiresrc

Status in OEM Priority Project:
  New
Status in gst-plugins-base1.0 package in Ubuntu:
  New
Status in gstreamer1.0 package in Ubuntu:
  New
Status in pipewire package in Ubuntu:
  Fix Released
Status in gst-plugins-base1.0 source package in Jammy:
  New
Status in gstreamer1.0 source package in Jammy:
  New
Status in pipewire source package in Jammy:
  Triaged

Bug description:
  [Impact]
  On Dell platform with Microdia Integrated webcam, the Cheese preview is stuck 
on jammy. The gst-launch-1.0 command suggested by gst-device-monitor-1.0 can 
reproduce it too.

  [Test Plan]
  1. Install Jammy on the hardware issue reported, and hardware didn't report 
the issue to avoid the regression
     hardware list:
     a. 0bda:58ff Realtek Semiconductor Corp. Integrated_Webcam_HD
     b. 0c45:6747 Microdia Integrated_Webcam_HD
     c. 0c45:6a14 Microdia Integrated_Webcam_HD
     d. 1bcf:28d0 Sunplus Innovation Technology Inc. Integrated_Webcam_5M
     e. 04f2:b76b Chicony Electronics Co., Ltd HP HD Camera
     f. 0408:545a Quanta Computer, Inc. HP 5MP Camera
     g. 0408:5483 Quanta Computer, Inc. HP HD Camera
     h. 174f:2459 Syntek Integrated Camera (ThinkBook 14 Gen 4)
     i. 5986:116d Acer, Inc Integrated Camera (ThinkCentre Neo 50a)
     j. 0bda:5556 Realtek Semiconductor Corp. Integrated_Webcam_FHD
  2. try to install the updated pipewire packages (= 0.3.48-1ubuntu2)
  3. $ sudo reboot
  4. Check if gst-launch-1.0 work
     a. $ gst-device-monitor-1.0 Video/Source to get caps and suggest 
gst-launch-1.0 command
     b. $ gst-launch-1.0 pipewiresrc path= !  ! decodebin ! 
videoconvert ! glimagesink
     c. Check if the result ok
  5. Check the screencast function by pressing 'prt sc'
     a. the screenshot of all screen/selected region should work good
     b. the screenrecord of all screen/selected region should work good
  6. Check that video recording in gnome-shell works
     - use Ctrl+Shift+Alt+R to start a recording, stop it from the indicator, 
verify that there is a new entry in ~/Video
  7. Check that screen sharing is working
     - go to settings, screen sharing and enable the feature
     - try to connect using rdp/vnc from another client

  do those steps under wayland and unset X

  [Where problems could occur]
  The patches try to dequeue the shared buffer, instead of pool buffer to 
prevent the pool buffer being corrupted. it might cause some camera preview 
failed if shared buffer is corrupted.
  It is in upstream from 0.3.52 to 0.3.56, and there is no regression found,
  so the risk is low.

  [Other Info]
  Upstream commits:
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/7cc509b117a6db66c395fb56ac4f17fb8cbd0c92
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/a1f33a99df5756c3dedd68f5ba2690819098d14f

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1985057/+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 2000817] Re: Wrong SHA256-value computed on kinetic

2023-03-01 Thread Andreas Hasenack

** 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)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

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

Title:
  Wrong SHA256-value computed on kinetic

Status in openldap package in Ubuntu:
  In Progress
Status in openldap source package in Jammy:
  In Progress
Status in openldap source package in Kinetic:
  In Progress
Status in openldap source package in Lunar:
  In Progress
Status in openldap package in Debian:
  Unknown

Bug description:
  The OpenLDAP-contrib module sha2 (located in contrib/slapd-
  modules/passwd/sha2/) computes a wrong SHA256/SSHA256-hash on Ubuntu
  kinetic. This breaks our current password-authentication in ldap.

  
  The problematic computation:

  $ slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2
  {SHA256}WIrrpN3OjEVOUf6yrH1j+o+ODuUuNBo979Od4UXnu54=

  The (correct) reference-value on the same system (or older ubuntu
  Versions):

  $ echo -n "secret" | openssl dgst -sha256 -binary | openssl enc -base64
  K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=

  
  We nailed the problem down to a bug in the gcc-optimizer for strict-aliasing. 
so most probably the gcc-version on kinetic (v12.2.0) is the reason. The 
workaround is to compile the sha2-Module with the flag "-fno-strict-aliasing". 
Then the correct value is computed. An example taken from a git-compiled 
version of OpenLDAP 2.5.13:

  $ ./servers/slapd/slappasswd -T passwd -s secret -h '{SHA256}' -o 
module-load=pw-sha2 -o module-path=contrib/slapd-modules/passwd/sha2/.libs
  {SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=


  
  Ubuntu:

  Description:Ubuntu 22.10
  Release:22.10

  OpenLDAP-Package: 2.5.13+dfsg-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2000817/+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 1987631] Re: Screencast only records one second

2023-03-01 Thread Bin Li

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

Gstreamer 1.20.4 includes a fix in the videoconvert element that makes
it no longer necessary to always copy buffers in pipewiresrc to have
smooth recordings. This change now skips those otherwise unnecessary
copies when using a new enough videoconvert.

Related: 
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2928
Part-of: 

diff --git a/js/dbusServices/screencast/screencastService.js 
b/js/dbusServices/screencast/screencastService.js
index 5ff5aff52..bb5387428 100644
--- a/js/dbusServices/screencast/screencastService.js
+++ b/js/dbusServices/screencast/screencastService.js
@@ -231,7 +231,8 @@ var Recorder = class {
 _ensurePipeline(nodeId) {
 const framerate = this._framerate;
 const needsCopy =
-Gst.Registry.get().check_feature_version('pipewiresrc', 0, 3, 57);
+Gst.Registry.get().check_feature_version('pipewiresrc', 0, 3, 57) 
&&
+!Gst.Registry.get().check_feature_version('videoconvert', 1, 20, 
4);

** Changed in: oem-priority
   Status: In Progress => Fix Released

** Changed in: oem-priority
 Assignee: Bin Li (binli) => (unassigned)

** No longer affects: gst-plugins-base1.0 (Ubuntu)

** No longer affects: gst-plugins-base1.0 (Ubuntu Jammy)

** No longer affects: gstreamer1.0 (Ubuntu Jammy)

** No longer affects: gstreamer1.0 (Ubuntu)

** Changed in: pipewire (Ubuntu Jammy)
 Assignee: Bin Li (binli) => (unassigned)

** Changed in: pipewire (Ubuntu Jammy)
   Status: In Progress => Fix Released

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

Title:
  Screencast only records one second

Status in GNOME Shell:
  Fix Released
Status in OEM Priority Project:
  Fix Released
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in pipewire package in Ubuntu:
  Fix Released
Status in gnome-shell source package in Jammy:
  Fix Released
Status in pipewire source package in Jammy:
  Fix Released

Bug description:
  [Impact]
  When recording a screencast with gnome on kinetic the resulting video will 
play for one second and then freeze. It looks like the same bug was discussed 
upstream at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5585

  This issue is caused by the new two patches in 0.3.48-1ubuntu2 which is fixed 
the Cheese preview stuck issue on jammy
* d/p/0001-buffers-ensure-buffer-size-does-not-exceed-maxsize.patch
  d/p/0002-gst-dequeue-a-shared-buffer-instead-of-original-pool.patch
  - Camera output freeze when using pipewiresrc (LP: #1985057)

  Here is a comment from 
https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1985057/comments/51 .
  ===
  So that's a regression of one of the cherrypicked commits, details are in 
https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/d32c03488

  the issue is fixed in Kinetic through a combination of the shell fix
  and a new pipewire.

  In 22.04 the shell issue is fixed in the recent 42.5 update but we will need 
to cherrypick 
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1ea1d525 in pipewire 
to be working.
  ===

  [Test Plan]
  1. Install Jammy on the hardware issue reported, and hardware didn't report 
the issue to avoid the regression
 hardware list:
 a. 0bda:58ff Realtek Semiconductor Corp. Integrated_Webcam_HD
 b. 0c45:6747 Microdia Integrated_Webcam_HD
 c. 0c45:6a14 Microdia Integrated_Webcam_HD
 d. 1bcf:28d0 Sunplus Innovation Technology Inc. Integrated_Webcam_5M
 e. 04f2:b76b Chicony Electronics Co., Ltd HP HD Camera
 f. 0408:545a Quanta Computer, Inc. HP 5MP Camera
 g. 0408:5483 Quanta Computer, Inc. HP HD Camera
 h. 174f:2459 Syntek Integrated Camera (ThinkBook 14 Gen 4)
 i. 5986:116d Acer, Inc Integrated Camera (ThinkCentre Neo 50a)
 j. 0bda:5556 Realtek Semiconductor Corp. Integrated_Webcam_FHD
  2. try to install the updated pipewire packages (= 0.3.48-1ubuntu2)
  3. $ sudo reboot
  4. Check if gst-launch-1.0 work
 a. $ gst-device-monitor-1.0 Video/Source to get caps and suggest 
gst-launch-1.0 command
 b. $ gst-launch-1.0 pipewiresrc path= !  ! decodebin ! 
videoconvert ! glimagesink
 c. Check if the result ok
  5. Check the screencast function by pressing 'prt sc'
 a. the screenshot of all screen/selected region should work good
 b. the screenrecord of all screen/selected region should work good
  6. Check that video recording in gnome-shell works
 - use Ctrl+Shift+Alt+R to start a recording, stop it from the

[Touch-packages] [Bug 1987631] Re: Screencast only records one second

2023-03-01 Thread Bin Li

@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 this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gstreamer1.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987631

Title:
  Screencast only records one second

Status in GNOME Shell:
  Fix Released
Status in OEM Priority Project:
  In Progress
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in gst-plugins-base1.0 package in Ubuntu:
  Fix Released
Status in gstreamer1.0 package in Ubuntu:
  Fix Released
Status in pipewire package in Ubuntu:
  Fix Released
Status in gnome-shell source package in Jammy:
  Fix Released
Status in gst-plugins-base1.0 source package in Jammy:
  In Progress
Status in gstreamer1.0 source package in Jammy:
  In Progress
Status in pipewire source package in Jammy:
  In Progress

Bug description:
  [Impact]
  When recording a screencast with gnome on kinetic the resulting video will 
play for one second and then freeze. It looks like the same bug was discussed 
upstream at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5585

  This issue is caused by the new two patches in 0.3.48-1ubuntu2 which is fixed 
the Cheese preview stuck issue on jammy
* d/p/0001-buffers-ensure-buffer-size-does-not-exceed-maxsize.patch
  d/p/0002-gst-dequeue-a-shared-buffer-instead-of-original-pool.patch
  - Camera output freeze when using pipewiresrc (LP: #1985057)

  Here is a comment from 
https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1985057/comments/51 .
  ===
  So that's a regression of one of the cherrypicked commits, details are in 
https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/d32c03488

  the issue is fixed in Kinetic through a combination of the shell fix
  and a new pipewire.

  In 22.04 the shell issue is fixed in the recent 42.5 update but we will need 
to cherrypick 
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1ea1d525 in pipewire 
to be working.
  ===

  [Test Plan]
  1. Install Jammy on the hardware issue reported, and hardware didn't report 
the issue to avoid the regression
 hardware list:
 a. 0bda:58ff Realtek Semiconductor Corp. Integrated_Webcam_HD
 b. 0c45:6747 Microdia Integrated_Webcam_HD
 c. 0c45:6a14 Microdia Integrated_Webcam_HD
 d. 1bcf:28d0 Sunplus Innovation Technology Inc. Integrated_Webcam_5M
 e. 04f2:b76b Chicony Electronics Co., Ltd HP HD Camera
 f. 0408:545a Quanta Computer, Inc. HP 5MP Camera
 g. 0408:5483 Quanta Computer, Inc. HP HD Camera
 h. 174f:2459 Syntek Integrated Camera (ThinkBook 14 Gen 4)
 i. 5986:116d Acer, Inc Integrated Camera (ThinkCentre Neo 50a)
 j. 0bda:5556 Realtek Semiconductor Corp. Integrated_Webcam_FHD
  2. try to install the updated pipewire packages (= 0.3.48-1ubuntu2)
  3. $ sudo reboot
  4. Check if gst-launch-1.0 work
 a. $ gst-device-monitor-1.0 Video/Source to get caps and suggest 
gst-launch-1.0 command
 b. $ gst-launch-1.0 pipewiresrc path= !  ! decodebin ! 
videoconvert ! glimagesink
 c. Check if the result ok
  5. Check the screencast function by pressing 'prt sc'
 a. the screenshot of all screen/selected region should work good
 b. the screenrecord of all screen/selected region should work good
  6. Check that video recording in gnome-shell works
 - use Ctrl+Shift+Alt+R to start a recording, stop it from the indicator, 
verify that there is a new entry in ~/Video
  7. Check that screen sharing is working
 - go to settings, screen sharing and enable the feature
 - try to connect using rdp/vnc from another client

  do those steps under wayland and unset X

  [Where problems could occur]
  The patches try to dequeue the shared buffer, instead of pool buffer to 
prevent the pool buffer being corrupted. it might cause some camera preview 
failed if shared buffer is corrupted.
  It is from upstream and there is no regression found, so the risk is low.

  [Other Info]
  Upstream commits for pipewire:
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/7cc509b117a6db66c395fb56ac4f17fb8cbd0c92
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/a1f33a99df5756c3dedd68f5ba2690819098d14f
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1ea1d525c1ac946a915599c6bee813e88e8cee12
  Upstream commits for gstreamer:
  
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/3b900e1fa4fd888012dc005fa26ae2532a89b7a7

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1987631/+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 2008279] Re: glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps

** 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-incoming

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

Title:
  glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps

Status in glib2.0 package in Ubuntu:
  New

Bug description:
  While preparing the gnome-settings-daemon 44 Beta update for Ubuntu
  23.04, I noticed that I could no longer enter text in the address bars
  for the Chromium or Firefox snaps.

  Therefore, I reverted https://gitlab.gnome.org/GNOME/gnome-settings-
  daemon/-/commit/27bc0889c so that we could continue with the update.
  See https://salsa.debian.org/gnome-team/gnome-settings-
  daemon/-/commit/baeeed93

  Before I did that, I tested disabling our patches but it didn't make a
  difference.

  I was unable to reproduce the issue on Debian Testing but there may
  have been differences in how snap was configured there.

  I'm filing this bug since ideally we would not be diverging from
  upstream here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2008279/+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 2008279] Re: xsettings ibus commit broke text input for Firefox & Chromium snaps