from:"Sergio"

BTW: pressing the "Revert" button tries to launch "dbus-launch", but in
my Noble system it wasn't installed. I had to manually install
"dbus-x11" to have it. Maybe it should be included in the
dependencies...

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

Title:
  software-properties-gtk does not start

Status in software-properties package in Ubuntu:
  Triaged

Bug description:
  On a new install with the new format sources.list software-properties-gtk 
does not start:
  corrado@corrado-n4-nn-0215:~$ software-properties-gtk
  Traceback (most recent call last):
File "/usr/bin/software-properties-gtk", line 100, in 
  app = SoftwarePropertiesGtk(datadir=options.data_dir, options=options, 
file=file)

^^^
File 
"/usr/lib/python3/dist-packages/softwareproperties/gtk/SoftwarePropertiesGtk.py",
 line 163, in __init__
  SoftwareProperties.__init__(self, options=options, datadir=datadir,
File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
109, in __init__
  self.backup_sourceslist()
File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
437, in backup_sourceslist
  source_bkp = SourceEntry(line=source.line,file=source.file)
   ^^
File "/usr/lib/python3/dist-packages/aptsources/sourceslist.py", line 509, 
in __init__
  raise ValueError("Classic SourceEntry cannot be written to .sources file")
  ValueError: Classic SourceEntry cannot be written to .sources file
  corrado@corrado-n4-nn-0215:~$

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: software-properties-gtk 0.99.42
  ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
  Uname: Linux 6.6.0-14-generic x86_64
  ApportVersion: 2.27.0-0ubuntu6
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Feb 15 10:07:43 2024
  InstallationDate: Installed on 2024-02-15 (0 days ago)
  InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240215)
  PackageArchitecture: all
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  SourcePackage: software-properties
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2053228/+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 2053228] Re: software-properties-gtk does not start

Anyway, the "Revert" button does nothing... so there is something else
that has to be done.

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

Title:
  software-properties-gtk does not start

Status in software-properties package in Ubuntu:
  Triaged

Bug description:
  On a new install with the new format sources.list software-properties-gtk 
does not start:
  corrado@corrado-n4-nn-0215:~$ software-properties-gtk
  Traceback (most recent call last):
File "/usr/bin/software-properties-gtk", line 100, in 
  app = SoftwarePropertiesGtk(datadir=options.data_dir, options=options, 
file=file)

^^^
File 
"/usr/lib/python3/dist-packages/softwareproperties/gtk/SoftwarePropertiesGtk.py",
 line 163, in __init__
  SoftwareProperties.__init__(self, options=options, datadir=datadir,
File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
109, in __init__
  self.backup_sourceslist()
File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
437, in backup_sourceslist
  source_bkp = SourceEntry(line=source.line,file=source.file)
   ^^
File "/usr/lib/python3/dist-packages/aptsources/sourceslist.py", line 509, 
in __init__
  raise ValueError("Classic SourceEntry cannot be written to .sources file")
  ValueError: Classic SourceEntry cannot be written to .sources file
  corrado@corrado-n4-nn-0215:~$

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: software-properties-gtk 0.99.42
  ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
  Uname: Linux 6.6.0-14-generic x86_64
  ApportVersion: 2.27.0-0ubuntu6
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Feb 15 10:07:43 2024
  InstallationDate: Installed on 2024-02-15 (0 days ago)
  InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240215)
  PackageArchitecture: all
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  SourcePackage: software-properties
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2053228/+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 2053228] Re: software-properties-gtk does not start

New patch that takes into account the _deb822 format.

** Patch added: "patch.diff"
   
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2053228/+attachment/5755308/+files/patch.diff

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

Title:
  software-properties-gtk does not start

Status in software-properties package in Ubuntu:
  Triaged

Bug description:
  On a new install with the new format sources.list software-properties-gtk 
does not start:
  corrado@corrado-n4-nn-0215:~$ software-properties-gtk
  Traceback (most recent call last):
File "/usr/bin/software-properties-gtk", line 100, in 
  app = SoftwarePropertiesGtk(datadir=options.data_dir, options=options, 
file=file)

^^^
File 
"/usr/lib/python3/dist-packages/softwareproperties/gtk/SoftwarePropertiesGtk.py",
 line 163, in __init__
  SoftwareProperties.__init__(self, options=options, datadir=datadir,
File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
109, in __init__
  self.backup_sourceslist()
File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
437, in backup_sourceslist
  source_bkp = SourceEntry(line=source.line,file=source.file)
   ^^
File "/usr/lib/python3/dist-packages/aptsources/sourceslist.py", line 509, 
in __init__
  raise ValueError("Classic SourceEntry cannot be written to .sources file")
  ValueError: Classic SourceEntry cannot be written to .sources file
  corrado@corrado-n4-nn-0215:~$

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: software-properties-gtk 0.99.42
  ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
  Uname: Linux 6.6.0-14-generic x86_64
  ApportVersion: 2.27.0-0ubuntu6
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Feb 15 10:07:43 2024
  InstallationDate: Installed on 2024-02-15 (0 days ago)
  InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240215)
  PackageArchitecture: all
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  SourcePackage: software-properties
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2053228/+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 2053228] Re: software-properties-gtk does not start

A quick patch.

** Patch added: "patch.diff"
   
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2053228/+attachment/5755261/+files/patch.diff

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

Title:
  software-properties-gtk does not start

Status in software-properties package in Ubuntu:
  Triaged

Bug description:
  On a new install with the new format sources.list software-properties-gtk 
does not start:
  corrado@corrado-n4-nn-0215:~$ software-properties-gtk
  Traceback (most recent call last):
File "/usr/bin/software-properties-gtk", line 100, in 
  app = SoftwarePropertiesGtk(datadir=options.data_dir, options=options, 
file=file)

^^^
File 
"/usr/lib/python3/dist-packages/softwareproperties/gtk/SoftwarePropertiesGtk.py",
 line 163, in __init__
  SoftwareProperties.__init__(self, options=options, datadir=datadir,
File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
109, in __init__
  self.backup_sourceslist()
File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
437, in backup_sourceslist
  source_bkp = SourceEntry(line=source.line,file=source.file)
   ^^
File "/usr/lib/python3/dist-packages/aptsources/sourceslist.py", line 509, 
in __init__
  raise ValueError("Classic SourceEntry cannot be written to .sources file")
  ValueError: Classic SourceEntry cannot be written to .sources file
  corrado@corrado-n4-nn-0215:~$

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: software-properties-gtk 0.99.42
  ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
  Uname: Linux 6.6.0-14-generic x86_64
  ApportVersion: 2.27.0-0ubuntu6
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Feb 15 10:07:43 2024
  InstallationDate: Installed on 2024-02-15 (0 days ago)
  InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240215)
  PackageArchitecture: all
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  SourcePackage: software-properties
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2053228/+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 2056152] Re: errors when starting thunderbird, directly after boot. error message: package dnsmasq 2.90-0ubuntu0.22.04.1 failed to install/upgrade: end of file on stdin at conffi

2024-03-06 Thread Sergio Durigan Junior

Thank you for taking the time to file a bug report.

>From DpkgTerminalLog.txt, we see the following message:

*** dnsmasq.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
dnsmasq (--configure):
 end of file on stdin at conffile prompt

This indicates that there was no reply to the question posed by dpkg
(debconf).  The upgrade process had to ask the question because there is
some local modification on your /etc/dnsmasq.conf, and it could not
figure out how to merge your modifications with the new configuration
file provided by the package.  As such, it expects you to answer how the
conflict should be resolved.  Since the answer provided was an EOF, it
errored out.  In other words, you have to be able to properly answer
dpkg's question in order to proceed with the upgrade.

Since it seems likely to me that this is a local configuration problem,
rather than a bug in Ubuntu, I am marking this bug as 'Incomplete'.

However, if you believe that this is really a bug in Ubuntu, then we would
be grateful if you would provide a more complete description of the problem
with steps to reproduce, explain why you believe this is a bug in Ubuntu
rather than a problem specific to your system, and then change the bug
status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

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

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

Title:
  errors when starting thunderbird, directly after boot. error message:
  package dnsmasq 2.90-0ubuntu0.22.04.1 failed to install/upgrade: end
  of file on stdin at conffile prompt

Status in dnsmasq package in Ubuntu:
  Incomplete

Bug description:
  see summary.
  after skipping the error message, thunderbird seems to work well

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: dnsmasq 2.90-0ubuntu0.22.04.1
  ProcVersionSignature: Ubuntu 6.5.0-21.21~22.04.1-generic 6.5.8
  Uname: Linux 6.5.0-21-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.11-0ubuntu82.5
  AptOrdering:
   dnsmasq:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Tue Mar  5 09:50:12 2024
  DpkgHistoryLog:
   Start-Date: 2024-03-05  09:50:11
   Commandline: /usr/bin/unattended-upgrade
   Upgrade: dnsmasq:amd64 (2.86-1.1ubuntu0.5, 2.90-0ubuntu0.22.04.1)
  ErrorMessage: end of file on stdin at conffile prompt
  InstallationDate: Installed on 2022-11-08 (482 days ago)
  InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 
3.10.6-1~22.04
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.21.1ubuntu2.2
   apt  2.4.11
  SourcePackage: dnsmasq
  Title: package dnsmasq 2.90-0ubuntu0.22.04.1 failed to install/upgrade: end 
of file on stdin at conffile prompt
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.dnsmasq: 2022-11-15T02:41:03.690882
  mtime.conffile..etc.dnsmasq.conf: 2022-11-15T02:41:10.043282

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2056152/+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 2040465] Re: New upstream microrelease 2.5.17

2024-02-16 Thread Sergio Durigan Junior

As is usual with these MREs, the verification phase is considered done
when all dep8 tests pass. This is now true for the Jammy upload.
Therefore, tagging the bug accordingly.

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

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

Title:
New upstream microrelease 2.5.17

Status in openldap package in Ubuntu:
Invalid
Status in openldap source package in Jammy:
Fix Committed

Bug description:
[ Impact ]

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

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

[ Test Plan ]

* Upstream gitlab pipeline results:

https://git.openldap.org/openldap/openldap/-/commit/99a124bb434052a71cf4ff115d0f949f6c6b7208/pipelines?ref=OPENLDAP_REL_ENG_2_5

* Upstream "call for testing":

https://lists.openldap.org/hyperkitty/list/openldap-
techni...@openldap.org/thread/4744NWC2HJP7L24WOUMZF4VCYGGUMRI7/

* As described in the MRE wiki page for OpenLDAP, the test plan is to
build the package in a PPA 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:
-
https://launchpadlibrarian.net/679769800/buildlog_ubuntu-jammy-amd64.openldap_2.5.16+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz

[ 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.16+dfsg-0ubuntu0.22.04.2 | jammy-security | source

Special cases:
- None.

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

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/2040465/+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 2040405] Re: Merge openldap from Debian unstable for noble

** Changed in: openldap (Ubuntu)
   Status: In Progress => Fix Committed

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

Title:
  Merge openldap from Debian unstable for noble

Status in openldap package in Ubuntu:
  Fix Committed

Bug description:
  Upstream: tbd
  Debian:   2.5.13+dfsg-52.6.6+dfsg-1~exp2
  Ubuntu:   2.6.6+dfsg-1~exp1ubuntu1


  Debian new has 2.6.6+dfsg-1~exp2, which may be available for merge
  soon.

  If it turns out this needs a sync rather than a merge, please change
  the tag 'needs-merge' to 'needs-sync', and (optionally) update the
  title as desired.

  
  ### New Debian Changes ###

  openldap (2.5.13+dfsg-5) unstable; urgency=medium

* Fix sha2-contrib autopkgtest failure. Call slappasswd using its full path.
  (Closes: #1030814)
* Disable flaky test test069-delta-multiprovider-starttls.

   -- Ryan Tandy   Tue, 07 Feb 2023 17:56:12 -0800

  openldap (2.5.13+dfsg-4) unstable; urgency=medium

[ Andreas Hasenack ]
* d/rules: Fix passwd/sha2 build (Closes: #1030716, LP: #2000817)
* d/t/sha2-contrib: add test for sha2 module

   -- Ryan Tandy   Mon, 06 Feb 2023 19:21:05 -0800

  openldap (2.5.13+dfsg-3) unstable; urgency=medium

[ Ryan Tandy ]
* Disable flaky test test063-delta-multiprovider. Mitigates #1010608.

[ Gioele Barabucci ]
* slapd.scripts-common: Avoid double-UTF8-encoding org name (Closes: 
#1016185)
* d/slapd.scripts-common: Remove outdated `migrate_to_slapd_d_style`
* d/slapd.postinst: Remove test for ancient version
* slapd.scripts-common: Remove unused `normalize_ldif`
* d/slapd.scripts-common: Use sed instead of perl in `release_diagnostics`

   -- Ryan Tandy   Fri, 13 Jan 2023 16:29:59 -0800

  openldap (2.5.13+dfsg-2) unstable; urgency=medium

* d/tests/smbk5pwd: Grant slapd access to /var/lib/heimdal-kdc. Fixes the
  autopkgtest failure due to heimdal setting mode 700 on this directory.
  (Closes: #1020442)
* d/source/lintian-overrides: Add wildcards to make overrides compatible
  with both older and newer versions of lintian.
* d/slapd-contrib.lintian-overrides: Remove unused
  custom-library-search-path override now that krb5-config no longer sets
  -rpath.

   -- Ryan Tandy   Sat, 24 Sep 2022 12:40:21 -0700

  openldap (2.5.13+dfsg-1) unstable; urgency=medium

* d/rules: Remove get-orig-source, now unnecessary.
* Check PGP signature when running uscan.
* d/watch: Modernize watch file; use repacksuffix.
* d/copyright: Update according to DEP-5.
* d/control: Add myself to Uploaders.
* New upstream release.

   -- Sergio Durigan Junior   Sun, 18 Sep 2022
  18:29:46 -0400

  openldap (2.5.12+dfsg-2) unstable; urgency=medium

* Stop slapd explicitly in prerm as a workaround for #1006147, which caused
  dpkg-reconfigure to not restart the service, so the new configuration was
  not applied. See also #994204. (Closes: #1010971)

   -- Ryan Tandy   Mon, 23 May 2022 10:14:53 -0700

  openldap (2.5.12+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Fixed SQL injection in back-sql (ITS#9815) (CVE-2022-29155)
* Update debconf translations:
  - German, thanks to Helge Kreutzmann. (Closes: #1007728)
  - Spanish, thanks to Camaleón. (Closes: #1008529)
  - Dutch, thanks to Frans Spiesschaert. (Closes: #1010034)

   -- Ryan Tandy   Wed, 04 May 2022 18:00:16 -0700

  openldap (2.5.11+dfsg-1) unstable; urgency=medium

* Upload to unstable.

   -- Ryan Tandy   Fri, 11 Mar 2022 19:38:02 -0800

  openldap (2.5.11+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Add openssl to Build-Depends to enable more checks in test067-tls.
* Update slapd-contrib's custom-library-search-path override to work with
  current Lintian.

   -- Ryan Tandy   Sun, 23 Jan 2022 17:16:05 -0800

  openldap (2.5.8+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Update slapd-contrib's custom-library-search-path override to work with
  Lintian 2.108.0.

   -- Ryan Tandy   Wed, 13 Oct 2021 18:42:55 -0700

  openldap (2.5.7+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Don't run autoreconf in contrib/ldapc++. We don't build it, and it is not


  ### Old Ubuntu Delta ###

  openldap (2.6.6+dfsg-1~exp1ubuntu1) mantic; urgency=medium

* Merge with Debian unstable (LP: #2028721). Remaining changes:
  - Enable AppArmor support:
+ d/apparmor-profile: add AppArmor profile
+ d/rules: use dh_apparmor
+ d/control: Build-Depends on dh-apparmor
+ d/slapd.README.Debian: add note about AppArmor
  - Enable ufw support:
+ d/control: suggest ufw.
+ d/rules: install ufw profile.
+ d/slapd.ufw.profile: add ufw profile.
  - d/{rules,slapd.py}: Add app

[Touch-packages] [Bug 2040465] Re: New upstream microrelease 2.5.17

dep8 results:

Results: (from 
http://autopkgtest.ubuntu.com/results/autopkgtest-jammy-sergiodj-openldap/?format=plain)
  openldap @ amd64:

http://autopkgtest.ubuntu.com/results/autopkgtest-jammy-sergiodj-openldap/jammy/amd64/o/openldap/20240209_225823_2ec27@/log.gz
09.02.24 22:58:23   ✅ Triggers: 
openldap/2.5.17+dfsg-0ubuntu0.22.04.1~ppa1
  openldap @ arm64:

http://autopkgtest.ubuntu.com/results/autopkgtest-jammy-sergiodj-openldap/jammy/arm64/o/openldap/20240209_230358_34851@/log.gz
09.02.24 23:03:58   ✅ Triggers: 
openldap/2.5.17+dfsg-0ubuntu0.22.04.1~ppa1
  openldap @ armhf:

http://autopkgtest.ubuntu.com/results/autopkgtest-jammy-sergiodj-openldap/jammy/armhf/o/openldap/20240209_230114_34851@/log.gz
09.02.24 23:01:14   ✅ Triggers: 
openldap/2.5.17+dfsg-0ubuntu0.22.04.1~ppa1
  openldap @ ppc64el:

http://autopkgtest.ubuntu.com/results/autopkgtest-jammy-sergiodj-openldap/jammy/ppc64el/o/openldap/20240209_231213_2ec27@/log.gz
09.02.24 23:12:13   ✅ Triggers: 
openldap/2.5.17+dfsg-0ubuntu0.22.04.1~ppa1
  openldap @ s390x:

http://autopkgtest.ubuntu.com/results/autopkgtest-jammy-sergiodj-openldap/jammy/s390x/o/openldap/20240209_225840_2ec27@/log.gz
09.02.24 22:58:40   ✅ Triggers: 
openldap/2.5.17+dfsg-0ubuntu0.22.04.1~ppa1

** Changed in: openldap (Ubuntu Jammy)
   Status: Triaged => In Progress

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

Title:
  New upstream microrelease 2.5.17

Status in openldap package in Ubuntu:
  Invalid
Status in openldap source package in Jammy:
  In Progress

Bug description:
  [ Impact ]

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

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

  [ Test Plan ]

   * Upstream gitlab pipeline results:

  
https://git.openldap.org/openldap/openldap/-/commit/99a124bb434052a71cf4ff115d0f949f6c6b7208/pipelines?ref=OPENLDAP_REL_ENG_2_5

   * Upstream "call for testing":

  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/thread/4744NWC2HJP7L24WOUMZF4VCYGGUMRI7/

   * As described in the MRE wiki page for OpenLDAP, the test plan is to
  build the package in a PPA 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:
- 
https://launchpadlibrarian.net/679769800/buildlog_ubuntu-jammy-amd64.openldap_2.5.16+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz

  [ 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.16+dfsg-0ubuntu0.22.04.2 | jammy-security  | source

  Special cases:
  - None.

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

  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/2040465/+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 2040465] Re: New upstream microrelease 2.5.17

As per Steve's reply here:

https://lists.ubuntu.com/archives/ubuntu-devel/2023-December/042854.html

I'm not going to run autopkgtest against all reverse dependencies of the
package.  Instead, I will rely on the results from the archive and act
accordingly.

Therefore, I've just uploaded the package to Jammy unapproved.

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

Title:
  New upstream microrelease 2.5.17

Status in openldap package in Ubuntu:
  Invalid
Status in openldap source package in Jammy:
  In Progress

Bug description:
  [ Impact ]

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

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

  [ Test Plan ]

   * Upstream gitlab pipeline results:

  
https://git.openldap.org/openldap/openldap/-/commit/99a124bb434052a71cf4ff115d0f949f6c6b7208/pipelines?ref=OPENLDAP_REL_ENG_2_5

   * Upstream "call for testing":

  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/thread/4744NWC2HJP7L24WOUMZF4VCYGGUMRI7/

   * As described in the MRE wiki page for OpenLDAP, the test plan is to
  build the package in a PPA 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:
- 
https://launchpadlibrarian.net/679769800/buildlog_ubuntu-jammy-amd64.openldap_2.5.16+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz

  [ 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.16+dfsg-0ubuntu0.22.04.2 | jammy-security  | source

  Special cases:
  - None.

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

  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/2040465/+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 2040465] Re: MRE updates of openldap for noble

** Description changed:

- Backport openldap as MRE to noble once the update for noble has been
- completed.
+ [ Impact ]
  
- 
+  * MRE for the latest stable OpenLDAP 2.5.x release, 2.5.17.
  
- [Impact]
- TBD
+ This update includes bugfixes only following the SRU policy exception
+ defined at https://wiki.ubuntu.com/OpenLDAPUpdates.
  
- [Major Changes]
- TBD
+ [ Major Changes ]
  
- [Test Plan]
- TBD
+  * See the list of bugs fixed in this release here:
  
- [Regression Potential]
- Upstream has an extensive build and integration test suite. So regressions 
would likely arise from a change in interaction with Ubuntu-specific 
integrations, such as in relation to the versions of dependencies available and 
other packaging-specific matters.
- 
+ https://lists.openldap.org/hyperkitty/list/openldap-
+ annou...@openldap.org/thread/XRQE4CVQDLTG4EYPKVEU2L76DYGIFR2Q/
+ 
+ [ Test Plan ]
+ 
+  * Upstream gitlab pipeline results:
+ 
+ 
https://git.openldap.org/openldap/openldap/-/commit/99a124bb434052a71cf4ff115d0f949f6c6b7208/pipelines?ref=OPENLDAP_REL_ENG_2_5
+ 
+  * Upstream "call for testing":
+ 
+ https://lists.openldap.org/hyperkitty/list/openldap-
+ techni...@openldap.org/thread/4744NWC2HJP7L24WOUMZF4VCYGGUMRI7/
+ 
+  * As described in the MRE wiki page for OpenLDAP, the test plan is to
+ build the package in a PPA 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:
+   - 
https://launchpadlibrarian.net/679769800/buildlog_ubuntu-jammy-amd64.openldap_2.5.16+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz
+ 
+ [ 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.16+dfsg-0ubuntu0.22.04.2 | jammy-security  | source
+ 
+ Special cases:
+ - None.
+ 
+ Previous MREs for OpenLDAP:
+ - https://pad.lv/1977627
+ - https://pad.lv/1983618
+ - https://pad.lv/2007625
+ - https://pad.lv/2027079
+ - https://pad.lv/2029170
+ 
+ As usual we test and prep from the PPA and then push through
+ SRU/Security as applicable.

** Also affects: openldap (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** No longer affects: openldap (Ubuntu Noble)

** Changed in: openldap (Ubuntu)
   Status: New => Invalid

** Changed in: openldap (Ubuntu Jammy)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

** Summary changed:

- MRE updates of openldap for noble
+ New upstream microrelease 2.5.17

** Changed in: openldap (Ubuntu Jammy)
   Status: New => Triaged

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

Title:
  New upstream microrelease 2.5.17

Status in openldap package in Ubuntu:
  Invalid
Status in openldap source package in Jammy:
  Triaged

Bug description:
  [ Impact ]

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

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

  [ Test Plan ]

   * Upstream gitlab pipeline results:

  
https://git.openldap.org/openldap/openldap/-/commit/99a124bb434052a71cf4ff115d0f949f6c6b7208/pipelines?ref=OPENLDAP_REL_ENG_2_5

   * Upstream "call for testing":

  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/thread/4744NWC2HJP7L24WOUMZF4VCYGGUMRI7/

   * As described in the MRE wiki page for OpenLDAP, the test plan is to
  build the package in a PPA 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:
- 
https://launchpadlibrarian.net/679769800/buildlog_ubuntu-jammy-amd64.openldap_2.5.16+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz

  [ 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 f

[Touch-packages] [Bug 2051895] Re: Lenovo XT99 BT headset can't work in HFP profile

2024-02-08 Thread Sergio Durigan Junior

Hello Hui,

The changes look good to me, but I have a few minor requests:

- Could you please expand the changelog entry and explain what the patch
fixes?  It doesn't need to be a long text or anything like that; just a
small sentence is enough.

- Could you add DEP-3 headers to the patch, please?  You can find more
information here:

https://dep-team.pages.debian.net/deps/dep3/

but basically, I'm looking for something like:

Origin: upstream, 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/commit/d7dc04e8f5c404b1fa16409f69dcde7c56312f02
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/2051895

I'm unsubscribing ubuntu-sponsors from the bug for now.  Please
resubscribe it once you've addressed the points above.

Thanks.

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

Title:
  Lenovo XT99 BT headset can't work in HFP profile

Status in HWE Next:
  New
Status in pulseaudio package in Ubuntu:
  In Progress
Status in pulseaudio source package in Jammy:
  In Progress
Status in pulseaudio source package in Mantic:
  In Progress
Status in pulseaudio source package in Noble:
  In Progress

Bug description:
  [Summary]
  When use the ThinkPluse xt99 bluetooth head set to run the test 
com.canonical.certification::bluetooth/audio_record_playback, it cannot record 
the sound and playback.
  It seems this device cannot switch to Hand free mode in this platform.

  [Steps to reproduce]
  Connect the ThinkPluse xt99, use the Handfree mode, then try to record some 
voice.

  [Expected result]
  The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound.

  [Actual result]
  The bluetooth headset xt99 cannot work in the Handfree mode.

  [Failure rate]
  100%

  
  [Impact]
  With the current Ubuntu 22.04 oem image, we try to connect the LENOVO
  XT99 bt headset and let it work in HFP mode, we select HFP profile
  from gnome sound-setting, but the microphone will not auto change to
  bt microphone and the bt output could not work too. So this BT headset
  could only work in A2DP mode with the current 22.04 OEM image.

  And we tried ubuntu 22.04 generic image, mantic image and noble image,
  none of them could make the headset work in HFP mode.
   
  [Fix]
  Cherry-pick a pulseaudio commit from upstream.

  [Test]
  Install the patched pulseaudio and reboot, connect to the LENOVO XT99
  bt headset, select it to work in HFP mode, tested playback and capture,
  all worked well.

  [Where problems could occur]
  This change will impact bt headset negotiation process in the pulseaudio,
  so the possiblity of regression is limited to bt headset, it could make
  the bt headset fail to connect, but this possibility is very low, we tested
  the patch with different bt headset and bt speaker, all worked well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2051895/+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 2052482] Re: Bad packet length 2424479189 Connection corrupted

2024-02-07 Thread Sergio Durigan Junior

Thank you for taking the time to report a bug and make Ubuntu better.

I tried reproducing the bug locally using an Oracle 8 container and an
Ubuntu container.  Here are the versions of the packages:

Oracle:
# rpm -qa | grep ssh
openssh-server-8.0p1-19.el8_8.x86_64
openssh-8.0p1-19.el8_8.x86_64
openssh-clients-8.0p1-19.el8_8.x86_64
libssh-config-0.9.6-13.el8_9.noarch
libssh-0.9.6-13.el8_9.x86_64

Ubuntu:
# dpkg -l | grep ssh
ii  openssh-client  1:8.9p1-3ubuntu0.6  amd64   
 secure shell (SSH) client, for secure access to remote machines

Everything worked as expected and I was able to ssh into the Oracle
container.

After some research, I found that this specific error you're getting
might be related to CVE-2023-48795 (Terrapin attack).  More
specifically, it has to do with the cipher suites being chosen by the
client/server at the time of the login:

https://superuser.com/questions/1828501/how-to-solve-ssh-connection-corrupted-error
https://unix.stackexchange.com/questions/765347/how-do-you-mitigate-the-terrapin-ssh-attack

Even when I explicitly disable the use of CHACHA20 on the server, I
still can login successfully and I see that another cipher has been
chosen during the key exchange:

...
debug1: kex: algorithm: curve25519-sha256   
 
debug1: kex: host key algorithm: ssh-ed25519
 
debug1: kex: server->client cipher: aes128-ctr MAC: umac-...@openssh.com 
compression: none   
debug1: kex: client->server cipher: aes128-ctr MAC: umac-...@openssh.com 
compression: none
...

This leads me to believe that there might be some local configuration on
your system that's affecting the choice of a suitable cipher.  Another
option would be some bogus configuration on the server side, I think.

Could you please tell us more details about your environment?  Did you
explicitly configure your ssh client to require CHACHA20 when connecting
to this specific server?

I'm going to mark this bug as Incomplete for to reflect the fact that
we're waiting on more details from you.  Please set it back to New when
you provide the requested information.  Thanks.

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-48795

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

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

Title:
  Bad packet length 2424479189 Connection corrupted

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ssh-clent:
  uname -a :5.15.0-48-generic #54-Ubuntu
  ```
  Ubuntu 22.04.3 LTS
  OpenSSH_8.9p1 Ubuntu-3ubuntu0.6, OpenSSL 3.0.2 15 Mar 2022
  ```

  ssh-server:
  ```
  OracleLinux 8.9
  OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
  ```

  ```
  userxxx@userxxx-H3C-X7-030s-0274:~$ ssh 192.168.xxx.xxx -vvv
  OpenSSH_8.9p1 Ubuntu-3ubuntu0.6, OpenSSL 3.0.2 15 Mar 2022
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf 
matched no files
  debug1: /etc/ssh/ssh_config line 21: Applying options for *
  debug2: resolve_canonicalize: hostname 192.168.xxx.xxx is address
  debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> 
'/home/userxxx/.ssh/known_hosts'
  debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> 
'/home/userxxx/.ssh/known_hosts2'
  debug3: ssh_connect_direct: entering
  debug1: Connecting to 192.168.xxx.xxx [192.168.xxx.xxx] port 22.
  debug3: set_sock_tos: set socket 3 IP_TOS 0x10
  debug1: Connection established.
  debug1: identity file /home/userxxx/.ssh/id_rsa type 0
  debug1: identity file /home/userxxx/.ssh/id_rsa-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ecdsa type 2
  debug1: identity file /home/userxxx/.ssh/id_ecdsa-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ecdsa_sk type -1
  debug1: identity file /home/userxxx/.ssh/id_ecdsa_sk-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519 type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519_sk type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519_sk-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_xmss type -1
  debug1: identity file /home/userxxx/.ssh/id_xmss-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_dsa type -1
  debug1: identity file /home/userxxx/.ssh/id_dsa-cert type -1
  debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
  debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
  debug1: compat_banner: match: OpenSSH_8.0 pat OpenSSH* compat 0x0400
  debug2: fd 3 setting O_NONBLOCK
  debug1: Authenticating to 192.168.xxx.xxx:22 as 'userxxx'
  debug3: record_hostkey: found key type ED25519 in file

[Touch-packages] [Bug 2040405] Re: Merge openldap from Debian unstable for noble

2024-02-06 Thread Sergio Durigan Junior

** Merge proposal linked:
   
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/460126

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

Title:
  Merge openldap from Debian unstable for noble

Status in openldap package in Ubuntu:
  In Progress

Bug description:
  Upstream: tbd
  Debian:   2.5.13+dfsg-52.6.6+dfsg-1~exp2
  Ubuntu:   2.6.6+dfsg-1~exp1ubuntu1


  Debian new has 2.6.6+dfsg-1~exp2, which may be available for merge
  soon.

  If it turns out this needs a sync rather than a merge, please change
  the tag 'needs-merge' to 'needs-sync', and (optionally) update the
  title as desired.

  
  ### New Debian Changes ###

  openldap (2.5.13+dfsg-5) unstable; urgency=medium

* Fix sha2-contrib autopkgtest failure. Call slappasswd using its full path.
  (Closes: #1030814)
* Disable flaky test test069-delta-multiprovider-starttls.

   -- Ryan Tandy   Tue, 07 Feb 2023 17:56:12 -0800

  openldap (2.5.13+dfsg-4) unstable; urgency=medium

[ Andreas Hasenack ]
* d/rules: Fix passwd/sha2 build (Closes: #1030716, LP: #2000817)
* d/t/sha2-contrib: add test for sha2 module

   -- Ryan Tandy   Mon, 06 Feb 2023 19:21:05 -0800

  openldap (2.5.13+dfsg-3) unstable; urgency=medium

[ Ryan Tandy ]
* Disable flaky test test063-delta-multiprovider. Mitigates #1010608.

[ Gioele Barabucci ]
* slapd.scripts-common: Avoid double-UTF8-encoding org name (Closes: 
#1016185)
* d/slapd.scripts-common: Remove outdated `migrate_to_slapd_d_style`
* d/slapd.postinst: Remove test for ancient version
* slapd.scripts-common: Remove unused `normalize_ldif`
* d/slapd.scripts-common: Use sed instead of perl in `release_diagnostics`

   -- Ryan Tandy   Fri, 13 Jan 2023 16:29:59 -0800

  openldap (2.5.13+dfsg-2) unstable; urgency=medium

* d/tests/smbk5pwd: Grant slapd access to /var/lib/heimdal-kdc. Fixes the
  autopkgtest failure due to heimdal setting mode 700 on this directory.
  (Closes: #1020442)
* d/source/lintian-overrides: Add wildcards to make overrides compatible
  with both older and newer versions of lintian.
* d/slapd-contrib.lintian-overrides: Remove unused
  custom-library-search-path override now that krb5-config no longer sets
  -rpath.

   -- Ryan Tandy   Sat, 24 Sep 2022 12:40:21 -0700

  openldap (2.5.13+dfsg-1) unstable; urgency=medium

* d/rules: Remove get-orig-source, now unnecessary.
* Check PGP signature when running uscan.
* d/watch: Modernize watch file; use repacksuffix.
* d/copyright: Update according to DEP-5.
* d/control: Add myself to Uploaders.
* New upstream release.

   -- Sergio Durigan Junior   Sun, 18 Sep 2022
  18:29:46 -0400

  openldap (2.5.12+dfsg-2) unstable; urgency=medium

* Stop slapd explicitly in prerm as a workaround for #1006147, which caused
  dpkg-reconfigure to not restart the service, so the new configuration was
  not applied. See also #994204. (Closes: #1010971)

   -- Ryan Tandy   Mon, 23 May 2022 10:14:53 -0700

  openldap (2.5.12+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Fixed SQL injection in back-sql (ITS#9815) (CVE-2022-29155)
* Update debconf translations:
  - German, thanks to Helge Kreutzmann. (Closes: #1007728)
  - Spanish, thanks to Camaleón. (Closes: #1008529)
  - Dutch, thanks to Frans Spiesschaert. (Closes: #1010034)

   -- Ryan Tandy   Wed, 04 May 2022 18:00:16 -0700

  openldap (2.5.11+dfsg-1) unstable; urgency=medium

* Upload to unstable.

   -- Ryan Tandy   Fri, 11 Mar 2022 19:38:02 -0800

  openldap (2.5.11+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Add openssl to Build-Depends to enable more checks in test067-tls.
* Update slapd-contrib's custom-library-search-path override to work with
  current Lintian.

   -- Ryan Tandy   Sun, 23 Jan 2022 17:16:05 -0800

  openldap (2.5.8+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Update slapd-contrib's custom-library-search-path override to work with
  Lintian 2.108.0.

   -- Ryan Tandy   Wed, 13 Oct 2021 18:42:55 -0700

  openldap (2.5.7+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Don't run autoreconf in contrib/ldapc++. We don't build it, and it is not


  ### Old Ubuntu Delta ###

  openldap (2.6.6+dfsg-1~exp1ubuntu1) mantic; urgency=medium

* Merge with Debian unstable (LP: #2028721). Remaining changes:
  - Enable AppArmor support:
+ d/apparmor-profile: add AppArmor profile
+ d/rules: use dh_apparmor
+ d/control: Build-Depends on dh-apparmor
+ d/slapd.README.Debian: add note about AppArmor
  - Enable ufw support:
+ d/control: suggest ufw.
+ d/rules: install ufw profile.
+ d/slapd.ufw.profile: add ufw profile

[Touch-packages] [Bug 2040405] Re: Merge openldap from Debian unstable for noble

2024-02-06 Thread Sergio Durigan Junior

** Changed in: openldap (Ubuntu)
   Status: New => In Progress

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

Title:
  Merge openldap from Debian unstable for noble

Status in openldap package in Ubuntu:
  In Progress

Bug description:
  Upstream: tbd
  Debian:   2.5.13+dfsg-52.6.6+dfsg-1~exp2
  Ubuntu:   2.6.6+dfsg-1~exp1ubuntu1


  Debian new has 2.6.6+dfsg-1~exp2, which may be available for merge
  soon.

  If it turns out this needs a sync rather than a merge, please change
  the tag 'needs-merge' to 'needs-sync', and (optionally) update the
  title as desired.

  
  ### New Debian Changes ###

  openldap (2.5.13+dfsg-5) unstable; urgency=medium

* Fix sha2-contrib autopkgtest failure. Call slappasswd using its full path.
  (Closes: #1030814)
* Disable flaky test test069-delta-multiprovider-starttls.

   -- Ryan Tandy   Tue, 07 Feb 2023 17:56:12 -0800

  openldap (2.5.13+dfsg-4) unstable; urgency=medium

[ Andreas Hasenack ]
* d/rules: Fix passwd/sha2 build (Closes: #1030716, LP: #2000817)
* d/t/sha2-contrib: add test for sha2 module

   -- Ryan Tandy   Mon, 06 Feb 2023 19:21:05 -0800

  openldap (2.5.13+dfsg-3) unstable; urgency=medium

[ Ryan Tandy ]
* Disable flaky test test063-delta-multiprovider. Mitigates #1010608.

[ Gioele Barabucci ]
* slapd.scripts-common: Avoid double-UTF8-encoding org name (Closes: 
#1016185)
* d/slapd.scripts-common: Remove outdated `migrate_to_slapd_d_style`
* d/slapd.postinst: Remove test for ancient version
* slapd.scripts-common: Remove unused `normalize_ldif`
* d/slapd.scripts-common: Use sed instead of perl in `release_diagnostics`

   -- Ryan Tandy   Fri, 13 Jan 2023 16:29:59 -0800

  openldap (2.5.13+dfsg-2) unstable; urgency=medium

* d/tests/smbk5pwd: Grant slapd access to /var/lib/heimdal-kdc. Fixes the
  autopkgtest failure due to heimdal setting mode 700 on this directory.
  (Closes: #1020442)
* d/source/lintian-overrides: Add wildcards to make overrides compatible
  with both older and newer versions of lintian.
* d/slapd-contrib.lintian-overrides: Remove unused
  custom-library-search-path override now that krb5-config no longer sets
  -rpath.

   -- Ryan Tandy   Sat, 24 Sep 2022 12:40:21 -0700

  openldap (2.5.13+dfsg-1) unstable; urgency=medium

* d/rules: Remove get-orig-source, now unnecessary.
* Check PGP signature when running uscan.
* d/watch: Modernize watch file; use repacksuffix.
* d/copyright: Update according to DEP-5.
* d/control: Add myself to Uploaders.
* New upstream release.

   -- Sergio Durigan Junior   Sun, 18 Sep 2022
  18:29:46 -0400

  openldap (2.5.12+dfsg-2) unstable; urgency=medium

* Stop slapd explicitly in prerm as a workaround for #1006147, which caused
  dpkg-reconfigure to not restart the service, so the new configuration was
  not applied. See also #994204. (Closes: #1010971)

   -- Ryan Tandy   Mon, 23 May 2022 10:14:53 -0700

  openldap (2.5.12+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Fixed SQL injection in back-sql (ITS#9815) (CVE-2022-29155)
* Update debconf translations:
  - German, thanks to Helge Kreutzmann. (Closes: #1007728)
  - Spanish, thanks to Camaleón. (Closes: #1008529)
  - Dutch, thanks to Frans Spiesschaert. (Closes: #1010034)

   -- Ryan Tandy   Wed, 04 May 2022 18:00:16 -0700

  openldap (2.5.11+dfsg-1) unstable; urgency=medium

* Upload to unstable.

   -- Ryan Tandy   Fri, 11 Mar 2022 19:38:02 -0800

  openldap (2.5.11+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Add openssl to Build-Depends to enable more checks in test067-tls.
* Update slapd-contrib's custom-library-search-path override to work with
  current Lintian.

   -- Ryan Tandy   Sun, 23 Jan 2022 17:16:05 -0800

  openldap (2.5.8+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Update slapd-contrib's custom-library-search-path override to work with
  Lintian 2.108.0.

   -- Ryan Tandy   Wed, 13 Oct 2021 18:42:55 -0700

  openldap (2.5.7+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Don't run autoreconf in contrib/ldapc++. We don't build it, and it is not


  ### Old Ubuntu Delta ###

  openldap (2.6.6+dfsg-1~exp1ubuntu1) mantic; urgency=medium

* Merge with Debian unstable (LP: #2028721). Remaining changes:
  - Enable AppArmor support:
+ d/apparmor-profile: add AppArmor profile
+ d/rules: use dh_apparmor
+ d/control: Build-Depends on dh-apparmor
+ d/slapd.README.Debian: add note about AppArmor
  - Enable ufw support:
+ d/control: suggest ufw.
+ d/rules: install ufw profile.
+ d/slapd.ufw.profile: add ufw profile.
  - d/{rules,slapd.py}: Add apport hook.

[Touch-packages] [Bug 2051454] Re: pipewire wireplumber can not detect the sound output device when using an unofficial linux kernel

2024-01-29 Thread Sergio Costas

Ok, people from the apparmor mailing list explained that ENOPROTOOPT
error is returned when the kernel doesn't have "fine grained unix
mediation", and that it still hasn't been merged upstream, so it's a
patch that has to be manually merged.

I prepared a patch.

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

Title:
  pipewire wireplumber can not detect the sound output device  when
  using an unofficial linux kernel

Status in apparmor package in Ubuntu:
  Confirmed
Status in pipewire package in Ubuntu:
  Confirmed
Status in wireplumber package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 24.04 noble

  I tested on Kernel-6.7.2, 6.7.1, 6.6.8, don't work.

  relating service status:
   
  gsd-media-keys[6441]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD 
(card)' failed

  pipewire-pulse[5768]: mod.protocol-pulse: client 0x5e701af4f9a0 [Mutter]: 
ERROR command:-1 (invalid) tag:418 error:25 (Input/output error)
  pipewire-pulse[5768]: mod.protocol-pulse: client 0x5e701af4f9a0 [Mutter]: 
ERROR command:-1 (invalid) tag:426 error:25 (Input/output error)
  pipewire-pulse[5298]: default: snap_get_audio_permissions: failed to get the 
AppArmor info.

  wireplumber[61568]:  si-standard-link: 
in/out items are not valid anymore
  wireplumber[61568]:  2 of 2 PipeWire links 
failed to activate

  It's worked on kernel linux-image-6.5.0-14-generic.

  I built the same version 1.0.1 from the
  https://gitlab.freedesktop.org/pipewire source code, The sound card
  can be detected normally and shown in the gnome setting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2051454/+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 2051454] Re: pipewire wireplumber can not detect the sound output device when using an unofficial linux kernel

2024-01-29 Thread Sergio Costas

I'm the author of the patch. The man page says nothing about
ENOPROTOOPT, that's why I didn't managed that error. Clearly it is
incomplete. Does anybody know where to send a patch for that?

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

Title:
  pipewire wireplumber can not detect the sound output device  when
  using an unofficial linux kernel

Status in apparmor package in Ubuntu:
  Confirmed
Status in pipewire package in Ubuntu:
  Confirmed
Status in wireplumber package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 24.04 noble

  I tested on Kernel-6.7.2, 6.7.1, 6.6.8, don't work.

  relating service status:
   
  gsd-media-keys[6441]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD 
(card)' failed

  pipewire-pulse[5768]: mod.protocol-pulse: client 0x5e701af4f9a0 [Mutter]: 
ERROR command:-1 (invalid) tag:418 error:25 (Input/output error)
  pipewire-pulse[5768]: mod.protocol-pulse: client 0x5e701af4f9a0 [Mutter]: 
ERROR command:-1 (invalid) tag:426 error:25 (Input/output error)
  pipewire-pulse[5298]: default: snap_get_audio_permissions: failed to get the 
AppArmor info.

  wireplumber[61568]:  si-standard-link: 
in/out items are not valid anymore
  wireplumber[61568]:  2 of 2 PipeWire links 
failed to activate

  It's worked on kernel linux-image-6.5.0-14-generic.

  I built the same version 1.0.1 from the
  https://gitlab.freedesktop.org/pipewire source code, The sound card
  can be detected normally and shown in the gnome setting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2051454/+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 2050874] Re: "Illegal characters in username" breaks sftp upload

2024-01-24 Thread Sergio Durigan Junior

Thank you for taking the time to report a bug.

As you mentioned yourself, this is indeed a security feature and not a
bug.  It would be wrong for Ubuntu (or any other GNU/Linux distro out
there, IMHO) to revert this change.

It also seems to me that your request less a "bug report" and more a
"request for help".  As such, I am taking the liberty of marking this
bug as Invalid.  My suggestion would be to look for help on the
appropriate technical forums (either Ubuntu's or upstream's).

Finally, you mentioned that using ~/.ssh/config is not ideal because
there's no obvious way to set the password.  I would strongly recommend
using key-based authentication instead.

Thank you.

** Changed in: openssh (Ubuntu)
   Status: New => Invalid

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

Title:
  "Illegal characters in username" breaks sftp upload

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  A new error message appeared in 1:8.2p1-4ubuntu0.11, "remote username
  contains invalid characters".

  The underlying commit seems to be this:
  https://github.com/openbsd/src/commit/ba05a7aae989020b8d05cc93cc6200109bba5a7b

  
  I need to work with an sftp connection where the username includes "|". The 
lftp client uses ssh to connect, triggering the error.

  It's possible to whitelist the username by adding it to a config file
  (e.g. ~/.ssh/config), but in that case, there's no obvious way to set
  the password.

  
  I suppose this is in fact a feature more than it is a bug, but it is really 
inconvenient. Any hints on how to handle it would be welcome.


  Regards,
  Jakob Lund


  Ubuntu 20.04.3 LTS

  openssh-client:
Installed: 1:8.2p1-4ubuntu0.11

  lftp:
Installed: 4.8.4-2build3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2050874/+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 2030684] Re: tzname[1] empty after tzset() with env TZ="UTC"

2024-01-22 Thread Sergio Durigan Junior

postgresql-15 has been Fix Released a while ago.  Marking the task
accordingly.

** Changed in: postgresql-15 (Ubuntu)
   Status: Fix Committed => Fix Released

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

Title:
  tzname[1] empty after tzset() with env TZ="UTC"

Status in django-mailman3 package in Ubuntu:
  Fix Released
Status in php8.2 package in Ubuntu:
  Triaged
Status in postgresql-15 package in Ubuntu:
  Fix Released
Status in python-django package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata package in Debian:
  Fix Released

Bug description:
  The following program prints different output when run with tzdata
  2023c-7ubuntu1 from mantic, versus tzdata 2023c-8ubuntu1 from mantic-
  proposed:

  root@mantic:~# cat bug.c 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
  int r;

  r = setenv("TZ", ":UTC", 1);
  if (r < 0) {
  printf("Failed to set TZ env var: %s\n", strerror(errno));
  return 1;
  }

  tzset();

  printf("timezone = %lu, daylight = %d\n", timezone, daylight);
  printf("tzname[0] = %s, tzname[1] = %s\n", tzname[0], tzname[1]);
  }

  root@mantic:~# gcc bug.c
  root@mantic:~# ./a.out 
  timezone = 0, daylight = 0
  tzname[0] = UTC, tzname[1] = UTC
  root@mantic:~# apt-cache policy tzdata
  tzdata:
Installed: 2023c-7ubuntu1
Candidate: 2023c-7ubuntu1
Version table:
   *** 2023c-7ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu mantic/main amd64 Packages
  100 /var/lib/dpkg/status

  If I install tzdata from mantic-proposed, I get different output:

  root@mantic:~# vi /etc/apt/sources.list
  root@mantic:~# apt update && apt install tzdata
  Hit:1 http://archive.ubuntu.com/ubuntu mantic InRelease
  Hit:2 http://security.ubuntu.com/ubuntu mantic-security InRelease
  Get:3 http://archive.ubuntu.com/ubuntu mantic-proposed InRelease [118 kB]
  Hit:4 http://archive.ubuntu.com/ubuntu mantic-updates InRelease
  Hit:5 http://archive.ubuntu.com/ubuntu mantic-backports InRelease
  Get:6 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 Packages 
[35.9 kB]
  Get:7 http://archive.ubuntu.com/ubuntu mantic-proposed/main Translation-en 
[14.8 kB]
  Get:8 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 DEP-11 
Metadata [2376 B]
  Get:9 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 c-n-f 
Metadata [1004 B]
  Get:10 http://archive.ubuntu.com/ubuntu mantic-proposed/restricted amd64 
Packages [15.9 kB]
  Get:11 http://archive.ubuntu.com/ubuntu mantic-proposed/restricted 
Translation-en [3564 B]
  Get:12 http://archive.ubuntu.com/ubuntu mantic-proposed/restricted amd64 
c-n-f Metadata [336 B]
  Fetched 192 kB in 1s (324 kB/s) 
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  72 packages can be upgraded. Run 'apt list --upgradable' to see them.
  root@mantic:~# apt install tzdata=2023c-8ubuntu1
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following packages were automatically installed and are no longer 
required:
libefiboot1 libefivar1
  Use 'apt autoremove' to remove them.
  The following packages will be upgraded:
tzdata
  1 upgraded, 0 newly installed, 0 to remove and 72 not upgraded.
  Need to get 269 kB of archives.
  After this operation, 142 kB disk space will be freed.
  Get:1 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 tzdata all 
2023c-8ubuntu1 [269 kB]
  Fetched 269 kB in 0s (867 kB/s)
  Preconfiguring packages ...
  (Reading database ... 39935 files and directories currently installed.)
  Preparing to unpack .../tzdata_2023c-8ubuntu1_all.deb ...
  Unpacking tzdata (2023c-8ubuntu1) over (2023c-7ubuntu1) ...
  Setting up tzdata (2023c-8ubuntu1) ...

  Current default time zone: 'Etc/UTC'
  Local time is now:  Mon Aug  7 21:18:35 UTC 2023.
  Universal Time is now:  Mon Aug  7 21:18:35 UTC 2023.
  Run 'dpkg-reconfigure tzdata' if you wish to change it.

  Scanning processes... 


 
  Scanning candidates...


 

  Restarting services...
  Service restarts being deferred:
   systemctl restart systemd-logind.service
   systemctl restart unattended-upgrades.service

  No containers need

[Touch-packages] [Bug 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2024-01-15 Thread Sergio Costas

Would this Qemu capture from a Core Desktop terminal be enough? There
you can see that the installed .deb for systemd is 249.11-0ubuntu3.12,
that /etc/default/keyboard and /etc/default/locale are soft links to the
same files at /etc/writable/default, that /etc/writable/default/keyboard
file doesn't exist and /etc/writable/default/locale contains C.UTF-8.
And after following the test protocol, locale now contains es_ES.UTF-8,
and keyboard file exists with es layout and pc105 model.

** Attachment added: "Window capture"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2035122/+attachment/5739596/+files/Captura%20desde%202024-01-15%2014-00-43.png

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

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Lunar:
  Won't Fix
Status in systemd source package in Mantic:
  Won't Fix

Bug description:
  [Impact]

  When working with ubuntu core or ubuntu core desktop, neither
  */etc/default/locale* nor */etc/default/keyboard* are modifiable, so
  it's not possible to set the global keyboard or the global language.
  This is required to allow to set the GDM language, and the default one
  during installation.

  The first half of the solution is to create the folder
  */etc/writable/default*, and make soft-links from
  */etc/default/locale* to */etc/writable/default/locale* and from
  */etc/default/keyboard* to */etc/writable/default/keyboard*, just like
  it is already being done with */etc/hostname*, */etc/issue*,
  */etc/localtime*, */etc/motd* and , */etc/timezone*.

  This solution, unfortunately, isn't complete. Although any application
  that just reads the files will work, not all of the applications that
  write to them will; specifically the systemd utilities that set the
  contents for those files, because they don't open the file directly;
  instead, they create first the new file in the same folder than the
  old one, fill its contents, and only then delete the old one and
  rename the new one. To solve this, systemd in Ubuntu already has
  several patches that detect if a file is a soft-link, in which case it
  replaces the old path with the destination one.

  Currently I have in place a patch for Ubuntu Core Desktop that
  implements both changes for both */etc/default/locale* and
  */etc/default/keyboard*.

  [Test plan]

  Using *sudo localectl set-locale xx_YY.UTF-8* in an Ubuntu Core or
  Ubuntu Core Desktop admin terminal must change the locale to the
  specified one, which can be checked by reading the
  */etc/default/locale* file. Also, *localectl* must return the new
  locale.

  Using *sudo dbus-send --system --print-reply
  --dest=org.freedesktop.locale1 /org/freedesktop/locale1
  org.freedesktop.locale1.SetX11Keyboard string:XX string:pc10Y string:
  string: boolean:true boolean:false" must change the
  */etc/default/keyboard* file to layout XX and model PC10Y (being Y
  either 1, 2, 4 or 5). Reading the file allows to check it. Also,
  *localectl status* must return the layout and model values in "X11
  Layout" and "X11 Model" entries.

  [Where problems could occur]

  In general, applications just read the content of the file and use the
  DBus interface to set the locale, so only those applications that
  modify by themselves the */etc/default/keyboard* and/or
  */etc/default/locale* would present a problem, in which case they
  would require specific patches. Anyway, those applications neither
  would work with the current state (with those files in a read-only
  filesystem).

  [Other info]

  For Noble, this will be addressed when we merge systemd v255 from
  Debian. This is only needed on core, so we don't need to fix for
  Mantic or Lunar.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2035122/+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 2003756] Re: Cannot configure krb5-kdc on Ubuntu Jammy 22.04.01, "Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142."

2024-01-10 Thread Sergio Durigan Junior

I'm changing my opinion here.

I feel like this is indeed a problem with how init-system-helpers (more
specifically, deb-systemd-invoke) warns users about errors.  Since it
uses "--quiet" when invoking systemctl, I believe it needs to be a bit
more verbose to explain what happened.

What's interesting that I can't reproduce the apt failure.  For example,
"apt install proftpd" will warn me about deb-systemd-invoke, but the
command will finish successfully.  ISTR having seen this behaviour
before, but I don't remember my conclusion at the time.

Anyway, this needs to be forwarded to Debian.  I don't believe Ubuntu
should diverge from Debian in this case.

** Changed in: init-system-helpers (Ubuntu)
   Status: Confirmed => Triaged

** Changed in: krb5 (Ubuntu)
   Status: Confirmed => Triaged

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

Title:
  Cannot configure krb5-kdc on Ubuntu Jammy 22.04.01, "Could not execute
  systemctl:  at /usr/bin/deb-systemd-invoke line 142."

Status in init-system-helpers package in Ubuntu:
  Triaged
Status in krb5 package in Ubuntu:
  Triaged

Bug description:
  I have a fresh install of Ubuntu Server 22.04.01 LTS.  After
  installing the server and running all updates, I run the following
  command:

  apt -y install slapd ldap-utils schema2ldif sasl2-bin
  libsasl2-modules-gssapi-mit krb5-kdc-ldap krb5-admin-server krb5-kdc

  This will be installing krb5-kdc 1.19.2-2.

  This is in preparation for setting up an OpenLDAP server, a Kerberos
  server with an LDAP backend, and saslauthd for pass-through
  authentication.  krb5-kdc was auto-selected when running the steps in
  the guide here in my development environment:
  https://ubuntu.com/server/docs/service-kerberos-with-openldap-backend
  When installing that, I get the following in the output:

  Setting up krb5-kdc (1.19.2-2) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/krb5-kdc.service 
→ /lib/systemd/system/krb5-kdc.service.
  Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 142.

  I do get the prompts for the realm, kdc, and admin server hostnames,
  and they are reflected in /etc/krb5.conf.  If I then run the
  following:

  dpkg-reconfigure krb5-kdc

  I am prompted for whether I want the package to create the Kerberos
  KDC configuration automatically, and when I say yes, it then repeats
  the following error:

  Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 142.

  I cannot find any further debug in the syslog or anything to indicate
  what the root cause is; the list of packages here are all installed
  together on a separate development server where I experimented with
  the configuration I will be deploying here in production so I don't
  think it's incompatible packages in the install list, but I am open to
  feedback on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/2003756/+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 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2024-01-10 Thread Sergio Costas

Sorry for the delay, I had some trouble these days to build a Core
Desktop image mixing our PPA and the "proposed" repository. Finally I've
been able to do so and test this, and it seems to work as expected.
Thanks!

** Description changed:

  [Impact]
  
  When working with ubuntu core or ubuntu core desktop, neither
  */etc/default/locale* nor */etc/default/keyboard* are modifiable, so
  it's not possible to set the global keyboard or the global language.
  This is required to allow to set the GDM language, and the default one
  during installation.
  
  The first half of the solution is to create the folder
  */etc/writable/default*, and make soft-links from */etc/default/locale*
  to */etc/writable/default/locale* and from */etc/default/keyboard* to
  */etc/writable/default/keyboard*, just like it is already being done
  with */etc/hostname*, */etc/issue*, */etc/localtime*, */etc/motd* and ,
  */etc/timezone*.
  
  This solution, unfortunately, isn't complete. Although any application
  that just reads the files will work, not all of the applications that
  write to them will; specifically the systemd utilities that set the
  contents for those files, because they don't open the file directly;
  instead, they create first the new file in the same folder than the old
  one, fill its contents, and only then delete the old one and rename the
  new one. To solve this, systemd in Ubuntu already has several patches
  that detect if a file is a soft-link, in which case it replaces the old
  path with the destination one.
  
  Currently I have in place a patch for Ubuntu Core Desktop that
  implements both changes for both */etc/default/locale* and
  */etc/default/keyboard*.
  
  [Test plan]
  
- Using *sudo localectl set-lang LANG="xx_YY.UTF-8"* in an Ubuntu Core or
+ Using *sudo localectl set-locale xx_YY.UTF-8* in an Ubuntu Core or
  Ubuntu Core Desktop admin terminal must change the locale to the
  specified one, which can be checked by reading the */etc/default/locale*
  file. Also, *localectl* must return the new locale.
  
  Using *sudo dbus-send --system --print-reply
  --dest=org.freedesktop.locale1 /org/freedesktop/locale1
  org.freedesktop.locale1.SetX11Keyboard string:XX string:pc10Y string:
  string: boolean:true boolean:false" must change the
  */etc/default/keyboard* file to layout XX and model PC10Y (being Y
  either 1, 2, 4 or 5). Reading the file allows to check it. Also,
  *localectl status* must return the layout and model values in "X11
  Layout" and "X11 Model" entries.
  
  [Where problems could occur]
  
  In general, applications just read the content of the file and use the
  DBus interface to set the locale, so only those applications that modify
  by themselves the */etc/default/keyboard* and/or */etc/default/locale*
  would present a problem, in which case they would require specific
  patches. Anyway, those applications neither would work with the current
  state (with those files in a read-only filesystem).
  
  [Other info]
  
  For Noble, this will be addressed when we merge systemd v255 from
  Debian. This is only needed on core, so we don't need to fix for Mantic
  or Lunar.

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

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Lunar:
  Won't Fix
Status in systemd source package in Mantic:
  Won't Fix

Bug description:
  [Impact]

  When working with ubuntu core or ubuntu core desktop, neither
  */etc/default/locale* nor */etc/default/keyboard* are modifiable, so
  it's not possible to set the global keyboard or the global language.
  This is required to allow to set the GDM language, and the default one
  during installation.

  The first half of the solution is to create the folder
  */etc/writable/default*, and make soft-links from
  */etc/default/locale* to */etc/writable/default/locale* and from
  */etc/default/keyboard* to */etc/writable/default/keyboard*, just like
  it is already being done with */etc/hostname*, */etc/issue*,
  */etc/localtime*, */etc/motd* and , */etc/timezone*.

  This solution, unfortunately, isn't complete. Although any application
  that just reads the files will work, not all of the applications that
  write to them will; specifically the systemd utilities that set the
  contents for those files, because they don't open the file directly;
  instead, they create first the new file in the same folder than the
  old one, fill its contents, and only then delete the old one and
  rename the new one. To solve this, systemd in Ubuntu already has
  several patches that detect if a file is a soft-link, in which case it
  replaces the old path with the destination one.

  Currently I have in place a patch for Ubuntu

[Touch-packages] [Bug 2020913] Re: /etc/profile.d/debuginfd.{sh, csh} are created with 600 permissions

2024-01-09 Thread Sergio Durigan Junior

** Tags removed: server-todo

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

Title:
  /etc/profile.d/debuginfd.{sh,csh} are created with 600 permissions

Status in elfutils package in Ubuntu:
  Fix Released
Status in elfutils source package in Jammy:
  Incomplete

Bug description:
  [ Impact ]

  Users installing libdebuginfod-common (the package that ships the
  shell snippets responsible for configuring the DEBUGINFOD_URLS
  environment variable, which will ultimately be used by GDB to contact
  the Ubuntu debuginfod service) experience a problem caused by
  permissions being set too tightly for
  /etc/profile.d/debuginfod.{sh,csh}.  This results in DEBUGINFOD_URLS
  not being set for non-root users.

  [ Test Plan ]

  Inside a Jammy container:

  # apt install -y libdebuginfod-common
  # ls -lah /etc/profile.d/debuginfod*

  Verify that the permission of both files allow them to be world-
  readable.

  [ Where problems could occur ]

  Care has been taken to not modify existing file permissions
  unnecessarily by using "g+r,o+r" when invoking chmod, but it is still
  possible to conceive a scenario where upgrading the package would make
  the files world-readable when the user is actually expecting
  otherwise.  However, such "regression" would arguably not be something
  supported because if the intention is to prevent non-root users from
  making use of debuginfod, there are better ways to achieve it.

  [ Original Description ]

  In a fresh container, installing libdebuginfod-common gives a
  /etc/profile.d that looks like this:

  ```
  root@32f34f7e271e:/etc/profile.d# ls -lah
  total 24K
  drwxr-xr-x 1 root root 4.0K May 26 17:23 .
  drwxr-xr-x 1 root root 4.0K May 26 17:23 ..
  -rw-r--r-- 1 root root   96 Oct 15  2021 01-locale-fix.sh
  -rw--- 1 root root  677 May 26 17:23 debuginfod.csh
  -rw--- 1 root root  692 May 26 17:23 debuginfod.sh

  ```

  when I login as a nonprivledged user, DEBUGINFOD_URLS is not set
  because the permissions are incorrect on the profile files.

  ```
  # dpkg -l  | grep libdebug
  ii  libdebuginfod-common0.186-1build1   all   
   configuration to enable the Debian debug info server
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2020913/+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 2037604] Re: Backport packages for 22.04.4 HWE stack

2024-01-09 Thread Sergio Costas

Can somebody modify the description to specify exactly how to do those
tests, please? (which commands/parameters, and expected results).

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

Title:
  Backport packages for 22.04.4 HWE stack

Status in directx-headers package in Ubuntu:
  Invalid
Status in mesa package in Ubuntu:
  Invalid
Status in rust-bindgen package in Ubuntu:
  Invalid
Status in rust-clang-sys package in Ubuntu:
  Invalid
Status in directx-headers source package in Jammy:
  Fix Committed
Status in mesa source package in Jammy:
  Fix Committed
Status in rust-bindgen source package in Jammy:
  Invalid
Status in rust-clang-sys source package in Jammy:
  Invalid

Bug description:
  [Impact]
  The graphics HWE stack from mantic needs to be backported for 22.04.4

  directx-headers
  - build-dep of the new Mesa

  mesa
  - new major release (23.2.x)
  - new HW support, Meteor Lake..

  [Test case]
  We want to cover at least 2-3 different, widely used and already previously 
supported GPU generations from both AMD and Intel which are supported by this 
release, as those are the ones that cover most bases; nouveau users tend to 
switch to the NVIDIA blob after installation. No need to test ancient GPU's 
supported by mesa-amber. And best to focus on the newer generations (~5y and 
newer) as the older ones are less likely to break at this point.
  - AMD: Vega, Navi1x (RX5000*), Navi2x (RX6000*), Navi3x (RX7000*)
  - Intel: gen9 (SKL/APL/KBL/CFL/WHL/CML), gen11 (ICL), gen12 (TGL/RKL/RPL/DG2)

  Install the new packages and run some tests:
  - check that the desktop is still using hw acceleration and hasn't fallen 
back to swrast/llvmpipe
  - run freely available benchmarks that torture the GPU (Unigine 
Heaven/Valley/Superposition)
  - run some games from Steam if possible

  and in each case check that there is no gfx corruption happening or
  worse.

  Note that upstream releases have already been tested for OpenGL and
  Vulkan conformance by their CI.

  [Where things could go wrong]
  This is a major update of Mesa, there could be regressions but we'll try to 
catch any with testing. And since it shares bugs with mantic, we'd already know 
if there are serious issues. We will backport the final 23.2.x at a later 
stage, the first backport is needed for enabling Intel Meteor Lake.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/directx-headers/+bug/2037604/+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 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2024-01-08 Thread Sergio Costas

Brian,

Done the changes requested in the Test Plan.

** Description changed:

  [Impact]
  
  When working with ubuntu core or ubuntu core desktop, neither
  */etc/default/locale* nor */etc/default/keyboard* are modifiable, so
  it's not possible to set the global keyboard or the global language.
  This is required to allow to set the GDM language, and the default one
  during installation.
  
  The first half of the solution is to create the folder
  */etc/writable/default*, and make soft-links from */etc/default/locale*
  to */etc/writable/default/locale* and from */etc/default/keyboard* to
  */etc/writable/default/keyboard*, just like it is already being done
  with */etc/hostname*, */etc/issue*, */etc/localtime*, */etc/motd* and ,
  */etc/timezone*.
  
  This solution, unfortunately, isn't complete. Although any application
  that just reads the files will work, not all of the applications that
  write to them will; specifically the systemd utilities that set the
  contents for those files, because they don't open the file directly;
  instead, they create first the new file in the same folder than the old
  one, fill its contents, and only then delete the old one and rename the
  new one. To solve this, systemd in Ubuntu already has several patches
  that detect if a file is a soft-link, in which case it replaces the old
  path with the destination one.
  
  Currently I have in place a patch for Ubuntu Core Desktop that
  implements both changes for both */etc/default/locale* and
  */etc/default/keyboard*.
  
  [Test plan]
  
  Using *sudo localectl set-lang LANG="xx_YY.UTF-8"* in an Ubuntu Core or
  Ubuntu Core Desktop admin terminal must change the locale to the
  specified one, which can be checked by reading the */etc/default/locale*
  file. Also, *localectl* must return the new locale.
  
+ Using *sudo dbus-send --system --print-reply
+ --dest=org.freedesktop.locale1 /org/freedesktop/locale1
+ org.freedesktop.locale1.SetX11Keyboard string:XX string:pc10Y string:
+ string: boolean:true boolean:false" must change the
+ */etc/default/keyboard* file to layout XX and model PC10Y (being Y
+ either 1, 2, 4 or 5). Reading the file allows to check it. Also,
+ *localectl status* must return the layout and model values in "X11
+ Layout" and "X11 Model" entries.
+ 
  [Where problems could occur]
  
  In general, applications just read the content of the file and use the
  DBus interface to set the locale, so only those applications that modify
  by themselves the */etc/default/keyboard* and/or */etc/default/locale*
  would present a problem, in which case they would require specific
  patches. Anyway, those applications neither would work with the current
  state (with those files in a read-only filesystem).
  
  [Other info]
  
  For Noble, this will be addressed when we merge systemd v255 from
  Debian. This is only needed on core, so we don't need to fix for Mantic
  or Lunar.

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

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Lunar:
  Won't Fix
Status in systemd source package in Mantic:
  Won't Fix

Bug description:
  [Impact]

  When working with ubuntu core or ubuntu core desktop, neither
  */etc/default/locale* nor */etc/default/keyboard* are modifiable, so
  it's not possible to set the global keyboard or the global language.
  This is required to allow to set the GDM language, and the default one
  during installation.

  The first half of the solution is to create the folder
  */etc/writable/default*, and make soft-links from
  */etc/default/locale* to */etc/writable/default/locale* and from
  */etc/default/keyboard* to */etc/writable/default/keyboard*, just like
  it is already being done with */etc/hostname*, */etc/issue*,
  */etc/localtime*, */etc/motd* and , */etc/timezone*.

  This solution, unfortunately, isn't complete. Although any application
  that just reads the files will work, not all of the applications that
  write to them will; specifically the systemd utilities that set the
  contents for those files, because they don't open the file directly;
  instead, they create first the new file in the same folder than the
  old one, fill its contents, and only then delete the old one and
  rename the new one. To solve this, systemd in Ubuntu already has
  several patches that detect if a file is a soft-link, in which case it
  replaces the old path with the destination one.

  Currently I have in place a patch for Ubuntu Core Desktop that
  implements both changes for both */etc/default/locale* and
  */etc/default/keyboard*.

  [Test plan]

  Using *sudo localectl set-lang LANG="xx_YY.UTF-8"* in an Ubuntu Core
  or Ubuntu Core Desktop admin

[Touch-packages] [Bug 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2023-12-13 Thread Sergio Costas

Fixed.

** Description changed:

  [Impact]
  
  When working with ubuntu core or ubuntu core desktop, neither
  */etc/default/locale* nor */etc/default/keyboard* are modifiable, so
  it's not possible to set the global keyboard or the global language.
  This is required to allow to set the GDM language, and the default one
  during installation.
  
  The first half of the solution is to create the folder
  */etc/writable/default*, and make soft-links from */etc/default/locale*
  to */etc/writable/default/locale* and from */etc/default/keyboard* to
  */etc/writable/default/keyboard*, just like it is already being done
  with */etc/hostname*, */etc/issue*, */etc/localtime*, */etc/motd* and ,
  */etc/timezone*.
  
  This solution, unfortunately, isn't complete. Although any application
  that just reads the files will work, not all of the applications that
  write to them will; specifically the systemd utilities that set the
  contents for those files, because they don't open the file directly;
  instead, they create first the new file in the same folder than the old
  one, fill its contents, and only then delete the old one and rename the
  new one. To solve this, systemd in Ubuntu already has several patches
  that detect if a file is a soft-link, in which case it replaces the old
  path with the destination one.
  
  Currently I have in place a patch for Ubuntu Core Desktop that
  implements both changes for both */etc/default/locale* and
  */etc/default/keyboard*.
  
  [Test plan]
  
- Using *localectl set-lang LANG="xx_YY.UTF-8"* should change the locale
- to the specified one. Also, *localectl* should return the current
- locale.
+ Using *sudo localectl set-lang LANG="xx_YY.UTF-8"* in an Ubuntu Core or
+ Ubuntu Core Desktop admin terminal must change the locale to the
+ specified one, which can be checked by reading the */etc/default/locale*
+ file. Also, *localectl* must return the new locale.
  
  [Where problems could occur]
  
  In general, applications just read the content of the file and use the
  DBus interface to set the locale, so only those applications that modify
  by themselves the */etc/default/keyboard* and/or */etc/default/locale*
  would present a problem, in which case they would require specific
  patches. Anyway, those applications neither would work with the current
  state (with those files in a read-only filesystem).
  
  [Other info]
  
  For Noble, this will be addressed when we merge systemd v255 from
  Debian. This is only needed on core, so we don't need to fix for Mantic
  or Lunar.

** Changed in: systemd (Ubuntu Jammy)
   Status: Incomplete => 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/2035122

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  New
Status in systemd source package in Lunar:
  Won't Fix
Status in systemd source package in Mantic:
  Won't Fix

Bug description:
  [Impact]

  When working with ubuntu core or ubuntu core desktop, neither
  */etc/default/locale* nor */etc/default/keyboard* are modifiable, so
  it's not possible to set the global keyboard or the global language.
  This is required to allow to set the GDM language, and the default one
  during installation.

  The first half of the solution is to create the folder
  */etc/writable/default*, and make soft-links from
  */etc/default/locale* to */etc/writable/default/locale* and from
  */etc/default/keyboard* to */etc/writable/default/keyboard*, just like
  it is already being done with */etc/hostname*, */etc/issue*,
  */etc/localtime*, */etc/motd* and , */etc/timezone*.

  This solution, unfortunately, isn't complete. Although any application
  that just reads the files will work, not all of the applications that
  write to them will; specifically the systemd utilities that set the
  contents for those files, because they don't open the file directly;
  instead, they create first the new file in the same folder than the
  old one, fill its contents, and only then delete the old one and
  rename the new one. To solve this, systemd in Ubuntu already has
  several patches that detect if a file is a soft-link, in which case it
  replaces the old path with the destination one.

  Currently I have in place a patch for Ubuntu Core Desktop that
  implements both changes for both */etc/default/locale* and
  */etc/default/keyboard*.

  [Test plan]

  Using *sudo localectl set-lang LANG="xx_YY.UTF-8"* in an Ubuntu Core
  or Ubuntu Core Desktop admin terminal must change the locale to the
  specified one, which can be checked by reading the
  */etc/default/locale* file. Also, *localectl* must return the new
  locale.

  [Where problems could occur]

  In general, applications just read the content of the file and use the
  DBus interface to set the locale, so

Re: [Touch-packages] [Bug 2015562] Re: [SRU] Segfault in dnsmasq when using certain static domain entries + DoH (bugfix possibly exists upstream)

2023-12-08 Thread Sergio Durigan Junior

On Friday, December 08 2023, Timo Aaltonen wrote:

> man/dnsmasq.8.orig | 2582
> +
>
> this must be a leftover from applying the commit?

Hm, I don't see this difference.  In fact, if I look at the dnsmasq
package that's currently shipped in Jammy, man/dnsmasq.8.orig already
exists there.

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

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

Title:
  [SRU] Segfault in dnsmasq when using certain static domain entries +
  DoH (bugfix possibly exists upstream)

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Jammy:
  In Progress

Bug description:
  [ Impact ]

  Some users may face an unpleasant segmentation fault if they combine 
configurations options like
  server=/domain/# with server|address=/domain/ since the domain matching 
functionality was rewritten in
  version 2.86.

  The  special server address ’#’ means "use the standard servers". The SEGV 
occurs due to the struct server
  datastructure associated with it is passed to forward_query() call without 
been properly reserved and filled
  due to resolvconf servers didn't belong to the priority list.

  Without resolving this, dnsmasq stops running due to the SEGV and
  (non-experienced) users might not notice it.

  [ Test Plan ]

  #0.Prepare a VM or Container. i.e:
  # lxc launch ubuntu-daily:jammy Jdnsmasq

  #1. Install dnsmasq
  # apt update && apt upgrade -y
  # apt install -y dnsmasq

  #2. Disable systemd-resolved service and enabling resolution through
  dnsmasq, configuring DNS servers through it.

  # systemctl disable --now systemd-resolved.service
  # rm -f /etc/resolv.conf
  # cat > /etc/resolv.conf << __EOF__
  nameserver 127.0.0.1
  __EOF__
  # echo "server=8.8.8.8" >> /etc/dnsmasq.conf (or edit the file to add it if 
you prefer)
  # (Optional) echo "log-queries" >> /etc/dnsmasq.conf
  # (optional) echo "log-debug" >> /etc/dnsmasq.conf
  # systemctl start dnsmasq.service

  3. Copy netflix-nov6.conf into /etc/dnsmasq.d/
  # cat > /etc/dnsmasq.d/netflix-nov6.conf << __EOF__
  # Null  response on these domains
  server=/netflix.com/#
  address=/netflix.com/::
  server=/netflix.net/#
  address=/netflix.net/::
  server=/nflxext.com/#
  address=/nflxext.com/::
  server=/example.com/#
  address=/example.com/::
  __EOF__

  #4. Restart/reload dnsmasq
  # systemctl restart dnsmasq

  #5. Verify that dnsmasq resolves domains correctly:

  root@Jdnsmasq:~# dig +short -tA ubuntu.com @127.0.0.1
  185.125.190.21
  185.125.190.20
  185.125.190.29
  root@Jdnsmasq:~# dig +short -t ubuntu.com @127.0.0.1
  2620:2d:4000:1::28
  2620:2d:4000:1::26
  2620:2d:4000:1::27

  #6. Perform a type65 / HTTPS recordtype query for netflix.com towards
  the dnsmasq server twice:

  root@Jdnsmasq:~# dig A netflix.com @127.0.0.1

  ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> A netflix.com @127.0.0.1
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 48730
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 1232
  ; EDE: 23 (Network Error)
  ;; QUESTION SECTION:
  ;netflix.com. IN  A

  ;; Query time: 23 msec
  ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
  ;; WHEN: Wed Nov 15 16:46:19 UTC 2023
  ;; MSG SIZE  rcvd: 46

  root@Jdnsmasq-checking:~# dig A netflix.com @127.0.0.1
  ;; communications error to 127.0.0.1#53: timed out
  ;; communications error to 127.0.0.1#53: connection refused
  ;; communications error to 127.0.0.1#53: connection refused

  #7. Check logs to verify segfault:
  # journalctl -u dnsmasq

  Apr 27 11:22:52 Jdnsmasq systemd[1]: Started dnsmasq - A lightweight DHCP and 
caching DNS server.
  Apr 27 11:22:53 Jdnsmasq dnsmasq[111585]: query[type=65] netflix.com from 
127.0.0.1
  Apr 27 11:22:53 Jdnsmasq dnsmasq[111585]: config error is REFUSED (EDE: 
network error)
  Apr 27 11:22:54 Jdnsmasq dnsmasq[111585]: query[type=65] netflix.com from 
127.0.0.1
  Apr 27 11:22:54 Jdnsmasq systemd[1]: dnsmasq.service: Main process exited, 
code=dumped, status=11/SEGV
  Apr 27 11:22:54 Jdnsmasq systemd[1]: dnsmasq.service: Failed with result 
'core-dump'.

  [ Where problems could occur ]

   This cherry picked commit from upstream incorporates a rewrite of the server 
priority list in the dnsmasq header file.
   Fortunately, that headers are not exported outside dnsmasq, so it cannot 
impact other third-party pieces of software.
   However, it can lend to think about the matching domain functionality that 
is being patched: could it be affect in
   some way to other types of server displ

[Touch-packages] [Bug 2040405] Re: Merge openldap from Debian unstable for noble

2023-11-30 Thread Sergio Durigan Junior

Nothing to merge yet.

** Changed in: openldap (Ubuntu)
Milestone: ubuntu-23.12 => ubuntu-24.01

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

Title:
  Merge openldap from Debian unstable for noble

Status in openldap package in Ubuntu:
  New

Bug description:
  Upstream: tbd
  Debian:   2.5.13+dfsg-52.6.6+dfsg-1~exp2
  Ubuntu:   2.6.6+dfsg-1~exp1ubuntu1


  Debian new has 2.6.6+dfsg-1~exp2, which may be available for merge
  soon.

  If it turns out this needs a sync rather than a merge, please change
  the tag 'needs-merge' to 'needs-sync', and (optionally) update the
  title as desired.

  
  ### New Debian Changes ###

  openldap (2.5.13+dfsg-5) unstable; urgency=medium

* Fix sha2-contrib autopkgtest failure. Call slappasswd using its full path.
  (Closes: #1030814)
* Disable flaky test test069-delta-multiprovider-starttls.

   -- Ryan Tandy   Tue, 07 Feb 2023 17:56:12 -0800

  openldap (2.5.13+dfsg-4) unstable; urgency=medium

[ Andreas Hasenack ]
* d/rules: Fix passwd/sha2 build (Closes: #1030716, LP: #2000817)
* d/t/sha2-contrib: add test for sha2 module

   -- Ryan Tandy   Mon, 06 Feb 2023 19:21:05 -0800

  openldap (2.5.13+dfsg-3) unstable; urgency=medium

[ Ryan Tandy ]
* Disable flaky test test063-delta-multiprovider. Mitigates #1010608.

[ Gioele Barabucci ]
* slapd.scripts-common: Avoid double-UTF8-encoding org name (Closes: 
#1016185)
* d/slapd.scripts-common: Remove outdated `migrate_to_slapd_d_style`
* d/slapd.postinst: Remove test for ancient version
* slapd.scripts-common: Remove unused `normalize_ldif`
* d/slapd.scripts-common: Use sed instead of perl in `release_diagnostics`

   -- Ryan Tandy   Fri, 13 Jan 2023 16:29:59 -0800

  openldap (2.5.13+dfsg-2) unstable; urgency=medium

* d/tests/smbk5pwd: Grant slapd access to /var/lib/heimdal-kdc. Fixes the
  autopkgtest failure due to heimdal setting mode 700 on this directory.
  (Closes: #1020442)
* d/source/lintian-overrides: Add wildcards to make overrides compatible
  with both older and newer versions of lintian.
* d/slapd-contrib.lintian-overrides: Remove unused
  custom-library-search-path override now that krb5-config no longer sets
  -rpath.

   -- Ryan Tandy   Sat, 24 Sep 2022 12:40:21 -0700

  openldap (2.5.13+dfsg-1) unstable; urgency=medium

* d/rules: Remove get-orig-source, now unnecessary.
* Check PGP signature when running uscan.
* d/watch: Modernize watch file; use repacksuffix.
* d/copyright: Update according to DEP-5.
* d/control: Add myself to Uploaders.
* New upstream release.

   -- Sergio Durigan Junior   Sun, 18 Sep 2022
  18:29:46 -0400

  openldap (2.5.12+dfsg-2) unstable; urgency=medium

* Stop slapd explicitly in prerm as a workaround for #1006147, which caused
  dpkg-reconfigure to not restart the service, so the new configuration was
  not applied. See also #994204. (Closes: #1010971)

   -- Ryan Tandy   Mon, 23 May 2022 10:14:53 -0700

  openldap (2.5.12+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Fixed SQL injection in back-sql (ITS#9815) (CVE-2022-29155)
* Update debconf translations:
  - German, thanks to Helge Kreutzmann. (Closes: #1007728)
  - Spanish, thanks to Camaleón. (Closes: #1008529)
  - Dutch, thanks to Frans Spiesschaert. (Closes: #1010034)

   -- Ryan Tandy   Wed, 04 May 2022 18:00:16 -0700

  openldap (2.5.11+dfsg-1) unstable; urgency=medium

* Upload to unstable.

   -- Ryan Tandy   Fri, 11 Mar 2022 19:38:02 -0800

  openldap (2.5.11+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Add openssl to Build-Depends to enable more checks in test067-tls.
* Update slapd-contrib's custom-library-search-path override to work with
  current Lintian.

   -- Ryan Tandy   Sun, 23 Jan 2022 17:16:05 -0800

  openldap (2.5.8+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Update slapd-contrib's custom-library-search-path override to work with
  Lintian 2.108.0.

   -- Ryan Tandy   Wed, 13 Oct 2021 18:42:55 -0700

  openldap (2.5.7+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Don't run autoreconf in contrib/ldapc++. We don't build it, and it is not


  ### Old Ubuntu Delta ###

  openldap (2.6.6+dfsg-1~exp1ubuntu1) mantic; urgency=medium

* Merge with Debian unstable (LP: #2028721). Remaining changes:
  - Enable AppArmor support:
+ d/apparmor-profile: add AppArmor profile
+ d/rules: use dh_apparmor
+ d/control: Build-Depends on dh-apparmor
+ d/slapd.README.Debian: add note about AppArmor
  - Enable ufw support:
+ d/control: suggest ufw.
+ d/rules: install ufw profile.
+ d/slapd.ufw.profile: add ufw profile.
  - d/{rules,slapd

[Touch-packages] [Bug 2044654] Re: No debugging symbols found in libgdk-3.so.0

2023-11-28 Thread Sergio Durigan Junior

I've added ubuntu-debuginfod as an affected project and marked the bug
as Invalid for gtk-3.

BTW, this is a known issue that's being worked on.  Hopefully it should
be resolved in the next days.

Thanks for reporting the bug!

** Also affects: ubuntu-debuginfod
   Importance: Undecided
   Status: New

** Changed in: gtk+3.0 (Ubuntu)
   Status: New => Invalid

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

Title:
  No debugging symbols found in libgdk-3.so.0

Status in ubuntu-debuginfod:
  New
Status in gtk+3.0 package in Ubuntu:
  Invalid

Bug description:
  Attach gdb to a running yelp process!

  (gdb) share libgdk
  Reading symbols from /lib/x86_64-linux-gnu/libgdk-3.so.0...
  (No debugging symbols found in /lib/x86_64-linux-gnu/libgdk-3.so.0)

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: libgtk-3-0 3.24.33-1ubuntu2
  ProcVersionSignature: Ubuntu 6.2.0-1016.16~22.04.1-azure 6.2.16
  Uname: Linux 6.2.0-1016-azure x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Nov 26 13:11:15 2023
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=pl_PL.UTF-8
   SHELL=/bin/bash
  SourcePackage: gtk+3.0
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-debuginfod/+bug/2044654/+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 2030684] Re: tzname[1] empty after tzset() with env TZ="UTC"

2023-11-21 Thread Sergio Durigan Junior

According to comment #10 from Athos, the php8.2 task has been added to
this bug only to serve as a reminder for a future investigation when
time permits.  Since everything else affected by the bug has been marked
as Fix Released, I removed the update-excuses tag.

** Tags removed: update-excuse

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

Title:
  tzname[1] empty after tzset() with env TZ="UTC"

Status in django-mailman3 package in Ubuntu:
  Fix Released
Status in php8.2 package in Ubuntu:
  Triaged
Status in postgresql-15 package in Ubuntu:
  Fix Committed
Status in python-django package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata package in Debian:
  Fix Released

Bug description:
  The following program prints different output when run with tzdata
  2023c-7ubuntu1 from mantic, versus tzdata 2023c-8ubuntu1 from mantic-
  proposed:

  root@mantic:~# cat bug.c 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
  int r;

  r = setenv("TZ", ":UTC", 1);
  if (r < 0) {
  printf("Failed to set TZ env var: %s\n", strerror(errno));
  return 1;
  }

  tzset();

  printf("timezone = %lu, daylight = %d\n", timezone, daylight);
  printf("tzname[0] = %s, tzname[1] = %s\n", tzname[0], tzname[1]);
  }

  root@mantic:~# gcc bug.c
  root@mantic:~# ./a.out 
  timezone = 0, daylight = 0
  tzname[0] = UTC, tzname[1] = UTC
  root@mantic:~# apt-cache policy tzdata
  tzdata:
Installed: 2023c-7ubuntu1
Candidate: 2023c-7ubuntu1
Version table:
   *** 2023c-7ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu mantic/main amd64 Packages
  100 /var/lib/dpkg/status

  If I install tzdata from mantic-proposed, I get different output:

  root@mantic:~# vi /etc/apt/sources.list
  root@mantic:~# apt update && apt install tzdata
  Hit:1 http://archive.ubuntu.com/ubuntu mantic InRelease
  Hit:2 http://security.ubuntu.com/ubuntu mantic-security InRelease
  Get:3 http://archive.ubuntu.com/ubuntu mantic-proposed InRelease [118 kB]
  Hit:4 http://archive.ubuntu.com/ubuntu mantic-updates InRelease
  Hit:5 http://archive.ubuntu.com/ubuntu mantic-backports InRelease
  Get:6 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 Packages 
[35.9 kB]
  Get:7 http://archive.ubuntu.com/ubuntu mantic-proposed/main Translation-en 
[14.8 kB]
  Get:8 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 DEP-11 
Metadata [2376 B]
  Get:9 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 c-n-f 
Metadata [1004 B]
  Get:10 http://archive.ubuntu.com/ubuntu mantic-proposed/restricted amd64 
Packages [15.9 kB]
  Get:11 http://archive.ubuntu.com/ubuntu mantic-proposed/restricted 
Translation-en [3564 B]
  Get:12 http://archive.ubuntu.com/ubuntu mantic-proposed/restricted amd64 
c-n-f Metadata [336 B]
  Fetched 192 kB in 1s (324 kB/s) 
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  72 packages can be upgraded. Run 'apt list --upgradable' to see them.
  root@mantic:~# apt install tzdata=2023c-8ubuntu1
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following packages were automatically installed and are no longer 
required:
libefiboot1 libefivar1
  Use 'apt autoremove' to remove them.
  The following packages will be upgraded:
tzdata
  1 upgraded, 0 newly installed, 0 to remove and 72 not upgraded.
  Need to get 269 kB of archives.
  After this operation, 142 kB disk space will be freed.
  Get:1 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 tzdata all 
2023c-8ubuntu1 [269 kB]
  Fetched 269 kB in 0s (867 kB/s)
  Preconfiguring packages ...
  (Reading database ... 39935 files and directories currently installed.)
  Preparing to unpack .../tzdata_2023c-8ubuntu1_all.deb ...
  Unpacking tzdata (2023c-8ubuntu1) over (2023c-7ubuntu1) ...
  Setting up tzdata (2023c-8ubuntu1) ...

  Current default time zone: 'Etc/UTC'
  Local time is now:  Mon Aug  7 21:18:35 UTC 2023.
  Universal Time is now:  Mon Aug  7 21:18:35 UTC 2023.
  Run 'dpkg-reconfigure tzdata' if you wish to change it.

  Scanning processes... 


 
  Scanning candidates...


 

  Restarting services...
  Service

[Touch-packages] [Bug 2038834] Re: GPU acceleration via VirGL is broken in qemu

2023-11-16 Thread Sergio Durigan Junior

Hello Mate,

I see that the debdiff you provided applies to Noble, but this bug is
also marked as affecting Mantic.  Could you provide an updated debdiff
for the Mantic version?  Thanks!

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

Title:
  GPU acceleration via VirGL is broken in qemu

Status in Release Notes for Ubuntu:
  New
Status in mesa package in Ubuntu:
  Fix Released
Status in mesa source package in Mantic:
  New
Status in mesa source package in Noble:
  Fix Released

Bug description:
  
  [ Impact ] 
   * Enabling GPU acceleration can cause host-side crashes on mantic/noble VMs 

   * This was reported by someone else upstream and is already fixed by 
 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25580.

  [ Test Plan ]

   * I've tested the patch on an affected macOS host running Ubuntu in UTM with 
 OpenGL enabled on both Mantic and Noble VMs.

   * Anyone else can do the same on an affected host by simply installing the 
 patched package and booting to the desktop.

  [ Where problems could occur ]

   * This patch fixes an upstream mesa regression which caused libvirglrendrer 
to 
 crash on the host side.

   * This makes a non-working use case work, VirGL on affected hosts cannot 
 regress as it simply didn't work before.

   * Risk of breakage is mainly from other packages possible affected by a mesa 
 rebuild.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/2038834/+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 2043114] Re: sshd segmentation fault on 20.04.6 (focal)

2023-11-15 Thread Sergio Durigan Junior

Thank you for providing more information.

Unfortunately I am still unable to reproduce the problem.  I tried using
a container and a VM, to no avail.

But I did open the coredump:

(gdb) bt
#0  _int_free (av=av@entry=0x7fcbaccd8b80 , 
p=p@entry=0x558afb81e0c0, have_lock=, have_lock@entry=1) at 
malloc.c:4341
#1  0x7fcbacb84f22 in _int_realloc (av=av@entry=0x7fcbaccd8b80 
, oldp=oldp@entry=0x558afb81e070, oldsize=oldsize@entry=8208, 
nb=80) at malloc.c:4644
#2  0x7fcbacb86fb6 in __GI___libc_realloc (oldmem=0x558afb81e080, bytes=64) 
at malloc.c:3226
#3  0x7fcbacb77748 in _IO_mem_finish (fp=0x558afb805e80, dummy=) at memstream.c:131
#4  0x7fcbacb6de41 in _IO_new_fclose (fp=fp@entry=0x558afb805e80) at 
libioP.h:948
#5  0x7fcbacc03ddb in __vsyslog_internal (pri=, 
fmt=0x558afa13ac80 "%.500s", ap=0x7ffd8170e5c0, mode_flags=2) at 
../misc/syslog.c:237
#6  0x7fcbacc04363 in __syslog_chk (pri=pri@entry=7, flag=flag@entry=1, 
fmt=fmt@entry=0x558afa13ac80 "%.500s") at ../misc/syslog.c:136
#7  0x558afa0f8b78 in syslog (__fmt=0x558afa13ac80 "%.500s", __pri=7) at 
/usr/include/x86_64-linux-gnu/bits/syslog.h:31
#8  do_log (level=level@entry=SYSLOG_LEVEL_DEBUG1, fmt=, 
args=args@entry=0x7ffd8170ef00) at ../../log.c:476
#9  0x558afa0f8ff8 in debug (fmt=) at ../../log.c:229
#10 0x558afa0ae3fe in server_accept_loop (config_s=0x7ffd8170f050, 
newsock=, sock_out=, sock_in=) at ../../sshd.c:1338
#11 main (ac=, av=) at ../../sshd.c:2040

This stack trace is a bit intriguing.  It's realloc that is crashing,
way too deep into glibc.  It seems to point at some weird interaction
between your setup and the memory management involved in syslog.

I spent time trying to find upstream bugs to see if there was anything
remotely similar, but couldn't find anything either.  Can you provide
more details on the setup you're using to reproduce the problem?  For
example, are you using a VM, a container, bare metal?  How many (v)CPUs?
What about memory?  If it's a container/VM, what's the underlying host?

Also, since you can reproduce the issue pretty reliably, could you
perhaps check if the same crash happens on Jammy?

Thank you.

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

Title:
  sshd segmentation fault on 20.04.6 (focal)

Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  We have a physical server running Ubuntu 20.04.6 LTS (amd64) and 
openssh-server 1:8.2p1-4ubuntu0.9. Sometimes sshd crashes with a segmentation 
fault on remote login with key authentication:
  [193107.651745] sshd[1229630]: segfault at 5557eba6a008 ip 7f2326a2ca53 
sp 7ffcba40c510 error 4 in libc-2.31.so[7f23269b8000+178000]

  We’ve changed only the following values in the stock sshd_config file:

  LogLevel DEBUG
  PasswordAuthentication no
  MaxStartups 100:30:100

  The server is used for automated software testing, and sometimes our test 
suite might make a large amount of SSH connections in a short period of time, 
which seems to be correlated with the crashes. But at the same time, I have to 
note that the connection count was not near the MaxStartups limit, and we’ve 
had crashes before adding that setting.
  Since the backtrace shows the debug logging function in the stack, we’re 
currently experimenting with using `LogLevel INFO` to try and isolate the issue.

  I am attaching the backtrace. I could provide the full dump file,
  although I am hesitant due to the possibility of private keys or other
  sensitive information leaking.

  # apt-cache policy openssh-server
  openssh-server:
Installed: 1:8.2p1-4ubuntu0.9
Candidate: 1:8.2p1-4ubuntu0.9
Version table:
   *** 1:8.2p1-4ubuntu0.9 500
  500 http://mirrors.storpool.com/ubuntu/archive focal-updates/main 
amd64 Packages
  500 http://security.ubuntu.com/ubuntu focal-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:8.2p1-4 500
  500 http://mirrors.storpool.com/ubuntu/archive focal/main amd64 
Packages
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu27.27
  Architecture: amd64
  CasperMD5CheckResult: skip
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.2p1-4ubuntu0.9
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 5.4.0-128.144-generic 5.4.210
  Tags:  focal
  Uname: Linux 5.4.0-128-generic x86_64
  UpgradeStatus: Upgraded to focal on 2021-01-13 (1030 days ago)
  UserGroups: N/A
  _MarkForUpload: True

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

2023-11-12 Thread Sergio Callegari

Noticed that in the forthcoming LibO 24.2, the "remote" is being given
prominence, by moving its settings from the Tools ▸ Options ▸
LibreOffice Impress configuration dialog to the Slide Show ▸ Slide Show
Settings menu.

IMHO this makes it quite important to have this feature working as
intended on all the supported platforms.

The remote is meant to work either with a WIFI connection or a Bluetooth
one.

The current bug is about the Bluetooth connection.

Bluetooth Connection


As of today, because of the issue at hand, the Bluetooth connection is
completely unusable on standard Linux distributions that use Pulseaudio
(a detailed discussion why is in the previous comments).

Notwithstanding the fact that this but is about the Bluetooth
connection, I am providing also a few notes about the Wifi connection to
highlight why the Bluetooth connection is so important and should be
fixed.

WIFI Connection
---

Unfortunately, the WIFI option is practically unusable in almost every
professional working environment, including universities and
conferencing sites. This is because in all these environments the
network is completely out of the user control, restricted in any
possible way, heavily firewalled, with the wifi framework consisting of
multiple access points under the same SSID. In a similar arrangement the
possibility of the remote to reach LibO at a non-standard TCP port is
erratic if not negligible.

The impossibility to use the WIFI connection precisely in those real
world environments where the usage of the remote would be most important
is the reason why a working Bluetooth connection is needed.

Note that in practice the WIFI connection situation could be improved by
suggesting the possibility to let the presenter laptop connect to the
internet via the mobile phone hotspot. This would need the remote app to
try to connect to LibO not just via the phone default interface, but
also on the network used for the hotspot.

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

Title:
  [upstream] Regression: cannot use impress remote over bluetooth with
  ubuntu bionic

Status in LibreOffice:
  Confirmed
Status in bluez package in Ubuntu:
  Confirmed
Status in libreoffice package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in libreoffice package in Fedora:
  Unknown

Bug description:
  Trying to use the impress remote
  (https://wiki.documentfoundation.org/Impress_Remote) over bluetooth
  with libreoffice over ubuntu bionic fails.

  The handset errors out that it cannot connect with Libreoffice on the
  computer even if the bluetooth adapter on the handset and on the
  computer are correctly paired.

  This does not seem to be an issue in the Libreoffice or in the impress
  remote code:

  - I have tested also past LibO versions
  - The Impress remote codebase has not changed recently

  This used to work on the same hardware (headset and laptop) with
  ubuntu 16.04.

  Hence the issue seems to be in a regression in the ubuntu bluetooth
  stack.

  To replicate:

  1) Install Libreoffice on Ubuntu bionic (either from the ubuntu repo
  or with the deb packages from the document fundation)

  2) Assure that your computer has bluetooth

  3) Install impress remote on an android handset (either from the play
  store of via fdroid)

  4) Assure that "remote control" is enabled in impress
  Tools>Options>Impress>General

  5) Pair the bluetooth adapters in the laptop and in the computer

  6) Open a presentation on the laptop

  7) Open the remote on the handset, got to the bluetooth pane see the
  computer there, touch it

  8) See the impress remote erroring out

  Most likely you will also get a bluetooth error on dmesg

  RFCOMM server failed for LibreOffice Impress Remote: rfcomm_bind:
  Address already in use (98)

  Same issue was reported for fedora

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: bluez 5.48-0ubuntu3.1
  ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
  Uname: Linux 4.15.0-36-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Wed Oct 17 16:57:29 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2013-12-12 (1769 days ago)
  InstallationMedia: Kubuntu 13.10 "Saucy Salamander" - Release amd64 
(20131016.1)
  InterestingModules: rfcomm bnep btusb bluetooth
  MachineType: Notebook W740SU
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-36-generic 
root=/dev/mapper/zagar_ssd--vg-root ro quiet splash 
resume=/dev/zagar_ssd-vg/swap_1 acpi_backlight=vendor vt.handoff=1
  SourcePackage: bluez
  UpgradeStatus: Upgraded to bionic on 2018-06-08 (131 days ago)
  dmi.bios.date: 10/02/2013
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.5
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: W740SU
  dmi.board.vendor:

[Touch-packages] [Bug 2041396] Re: gdb 12.1 generates SIGILL on armhf

2023-10-27 Thread Sergio Durigan Junior

After several hours trying to obtain access to an ARM64 machine where I
could test the fix, vorlon kindly provided me with credentials to a
machine that's capable of launching an armhf container.

I could reproduce the bug:

# gdb -q ./a.out -ex 'b 3' -ex r -ex c
Reading symbols from ./a.out...
Breakpoint 1, thumb_func () at 1.c:3
3 return 42;
Continuing.

Program received signal SIGILL, Illegal instruction.
0x00401004 in ?? ()
...

And also verify that Liu's package fixes the problem:

# gdb -q ./a.out -ex 'b 3' -ex r -ex c
Reading symbols from ./a.out...
Breakpoint 1 at 0x4d8: file 1.c, line 3.
Starting program: /root/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Breakpoint 1, thumb_func () at 1.c:3
3 return 42;
Continuing.
[Inferior 1 (process 2666) exited with code 052]

Therefore, I sponsored the upload for him.

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

Title:
  gdb 12.1 generates SIGILL on armhf

Status in gdb:
  Fix Released
Status in gdb package in Ubuntu:
  New
Status in gdb source package in Jammy:
  New

Bug description:
  [ Impact ]

   * GDB 12.1 introduced a regression where it will break program execution 
when the program contains mixed ARM code and THUMB code.
   * Upstream stated they tested the changes on Ubuntu 20.04 and it went okay.

  [ Test Plan ]

  Considering the following C program:

  ```
  __attribute__((target("arm"), noinline))
  int thumb_func() {
    return 42;
  }

  __attribute__((target("thumb")))
  int main() { return thumb_func(); }
  ```

  If you build it using `gcc repro.c -ggdb3 -Og -o repro` and run the
  GDB using the following commands ...

  ```
  b 3
  r
  c
  ```

  (you can save the contents above to a file and run GDB using `gdb -x
  script ./repro`)

  ... you will notice GDB broke the program and threw SIGILL.
  If you run the program without GDB, the program exits normally.

  [ Where problems could occur ]

   * GDB is a complex software. As the patch suggests, it may break other use 
cases (like single-stepping) entirely.
   * Since this is an ARM-only patch, it's unlikely to affect other CPU 
architectures. However, it is possible that this fix may break ARM64 execution.

  [ Other Info ]
   
   * This bug has been fixed in GDB 13, but the fix was never backported to GDB 
12. You can find the upstream bug in the remote bug watch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gdb/+bug/2041396/+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 2041396] Re: gdb 12.1 generates SIGILL on armhf

2023-10-27 Thread Sergio Durigan Junior

** Merge proposal linked:
   
https://code.launchpad.net/~liushuyu-011/ubuntu/+source/gdb/+git/gdb/+merge/454654

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

Title:
  gdb 12.1 generates SIGILL on armhf

Status in gdb:
  Fix Released
Status in gdb package in Ubuntu:
  New
Status in gdb source package in Jammy:
  New

Bug description:
  [ Impact ]

   * GDB 12.1 introduced a regression where it will break program execution 
when the program contains mixed ARM code and THUMB code.
   * Upstream stated they tested the changes on Ubuntu 20.04 and it went okay.

  [ Test Plan ]

  Considering the following C program:

  ```
  __attribute__((target("arm"), noinline))
  int thumb_func() {
    return 42;
  }

  __attribute__((target("thumb")))
  int main() { return thumb_func(); }
  ```

  If you build it using `gcc repro.c -ggdb3 -Og -o repro` and run the
  GDB using the following commands ...

  ```
  b 3
  r
  c
  ```

  (you can save the contents above to a file and run GDB using `gdb -x
  script ./repro`)

  ... you will notice GDB broke the program and threw SIGILL.
  If you run the program without GDB, the program exits normally.

  [ Where problems could occur ]

   * GDB is a complex software. As the patch suggests, it may break other use 
cases (like single-stepping) entirely.
   * Since this is an ARM-only patch, it's unlikely to affect other CPU 
architectures. However, it is possible that this fix may break ARM64 execution.

  [ Other Info ]
   
   * This bug has been fixed in GDB 13, but the fix was never backported to GDB 
12. You can find the upstream bug in the remote bug watch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gdb/+bug/2041396/+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 2040405] Re: Merge openldap from Debian unstable for noble

2023-10-25 Thread Sergio Durigan Junior

** Changed in: openldap (Ubuntu)
 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 openldap in Ubuntu.
https://bugs.launchpad.net/bugs/2040405

Title:
  Merge openldap from Debian unstable for noble

Status in openldap package in Ubuntu:
  New

Bug description:
  Upstream: tbd
  Debian:   2.5.13+dfsg-52.6.6+dfsg-1~exp2
  Ubuntu:   2.6.6+dfsg-1~exp1ubuntu1


  Debian new has 2.6.6+dfsg-1~exp2, which may be available for merge
  soon.

  If it turns out this needs a sync rather than a merge, please change
  the tag 'needs-merge' to 'needs-sync', and (optionally) update the
  title as desired.

  
  ### New Debian Changes ###

  openldap (2.5.13+dfsg-5) unstable; urgency=medium

* Fix sha2-contrib autopkgtest failure. Call slappasswd using its full path.
  (Closes: #1030814)
* Disable flaky test test069-delta-multiprovider-starttls.

   -- Ryan Tandy   Tue, 07 Feb 2023 17:56:12 -0800

  openldap (2.5.13+dfsg-4) unstable; urgency=medium

[ Andreas Hasenack ]
* d/rules: Fix passwd/sha2 build (Closes: #1030716, LP: #2000817)
* d/t/sha2-contrib: add test for sha2 module

   -- Ryan Tandy   Mon, 06 Feb 2023 19:21:05 -0800

  openldap (2.5.13+dfsg-3) unstable; urgency=medium

[ Ryan Tandy ]
* Disable flaky test test063-delta-multiprovider. Mitigates #1010608.

[ Gioele Barabucci ]
* slapd.scripts-common: Avoid double-UTF8-encoding org name (Closes: 
#1016185)
* d/slapd.scripts-common: Remove outdated `migrate_to_slapd_d_style`
* d/slapd.postinst: Remove test for ancient version
* slapd.scripts-common: Remove unused `normalize_ldif`
* d/slapd.scripts-common: Use sed instead of perl in `release_diagnostics`

   -- Ryan Tandy   Fri, 13 Jan 2023 16:29:59 -0800

  openldap (2.5.13+dfsg-2) unstable; urgency=medium

* d/tests/smbk5pwd: Grant slapd access to /var/lib/heimdal-kdc. Fixes the
  autopkgtest failure due to heimdal setting mode 700 on this directory.
  (Closes: #1020442)
* d/source/lintian-overrides: Add wildcards to make overrides compatible
  with both older and newer versions of lintian.
* d/slapd-contrib.lintian-overrides: Remove unused
  custom-library-search-path override now that krb5-config no longer sets
  -rpath.

   -- Ryan Tandy   Sat, 24 Sep 2022 12:40:21 -0700

  openldap (2.5.13+dfsg-1) unstable; urgency=medium

* d/rules: Remove get-orig-source, now unnecessary.
* Check PGP signature when running uscan.
* d/watch: Modernize watch file; use repacksuffix.
* d/copyright: Update according to DEP-5.
* d/control: Add myself to Uploaders.
* New upstream release.

   -- Sergio Durigan Junior   Sun, 18 Sep 2022
  18:29:46 -0400

  openldap (2.5.12+dfsg-2) unstable; urgency=medium

* Stop slapd explicitly in prerm as a workaround for #1006147, which caused
  dpkg-reconfigure to not restart the service, so the new configuration was
  not applied. See also #994204. (Closes: #1010971)

   -- Ryan Tandy   Mon, 23 May 2022 10:14:53 -0700

  openldap (2.5.12+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Fixed SQL injection in back-sql (ITS#9815) (CVE-2022-29155)
* Update debconf translations:
  - German, thanks to Helge Kreutzmann. (Closes: #1007728)
  - Spanish, thanks to Camaleón. (Closes: #1008529)
  - Dutch, thanks to Frans Spiesschaert. (Closes: #1010034)

   -- Ryan Tandy   Wed, 04 May 2022 18:00:16 -0700

  openldap (2.5.11+dfsg-1) unstable; urgency=medium

* Upload to unstable.

   -- Ryan Tandy   Fri, 11 Mar 2022 19:38:02 -0800

  openldap (2.5.11+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Add openssl to Build-Depends to enable more checks in test067-tls.
* Update slapd-contrib's custom-library-search-path override to work with
  current Lintian.

   -- Ryan Tandy   Sun, 23 Jan 2022 17:16:05 -0800

  openldap (2.5.8+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Update slapd-contrib's custom-library-search-path override to work with
  Lintian 2.108.0.

   -- Ryan Tandy   Wed, 13 Oct 2021 18:42:55 -0700

  openldap (2.5.7+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Don't run autoreconf in contrib/ldapc++. We don't build it, and it is not


  ### Old Ubuntu Delta ###

  openldap (2.6.6+dfsg-1~exp1ubuntu1) mantic; urgency=medium

* Merge with Debian unstable (LP: #2028721). Remaining changes:
  - Enable AppArmor support:
+ d/apparmor-profile: add AppArmor profile
+ d/rules: use dh_apparmor
+ d/control: Build-Depends on dh-apparmor
+ d/slapd.README.Debian: add note about AppArmor
  - Enable ufw support:
+ d/control: suggest ufw.
+ d/rules: install ufw profile.
+ d/slapd.ufw.profile: add ufw profile.
  - d/{rules,slapd.py}:

[Touch-packages] [Bug 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2023-10-25 Thread Sergio Costas

This is the patch used in systemd .deb for Ubuntu Core Desktop.

** Patch added: "UBUNTU-CORE-support-etc-default-in-writable.patch"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2035122/+attachment/5713202/+files/UBUNTU-CORE-support-etc-default-in-writable.patch

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

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  [Impact]

  When working with ubuntu core or ubuntu core desktop, neither
  */etc/default/locale* nor */etc/default/keyboard* are modifiable, so
  it's not possible to set the global keyboard or the global language.
  This is required to allow to set the GDM language, and the default one
  during installation.

  The first half of the solution is to create the folder
  */etc/writable/default*, and make soft-links from
  */etc/default/locale* to */etc/writable/default/locale* and from
  */etc/default/keyboard* to */etc/writable/default/keyboard*, just like
  it is already being done with */etc/hostname*, */etc/issue*,
  */etc/localtime*, */etc/motd* and , */etc/timezone*.

  This solution, unfortunately, isn't complete. Although any application
  that just reads the files will work, not all of the applications that
  write to them will; specifically the systemd utilities that set the
  contents for those files, because they don't open the file directly;
  instead, they create first the new file in the same folder than the
  old one, fill its contents, and only then delete the old one and
  rename the new one. To solve this, systemd in Ubuntu already has
  several patches that detect if a file is a soft-link, in which case it
  replaces the old path with the destination one.

  Currently I have in place a patch for Ubuntu Core Desktop that
  implements both changes for both */etc/default/locale* and
  */etc/default/keyboard*.

  [Test plan]

  Using *localectl set-lang LANG="xx_YY.UTF-8"* should change the locale
  to the specified one. Also, *localectl* should return the current
  locale.

  [Where problems could occur]

  In general, applications just read the content of the file and use the
  DBus interface to set the locale, so only those applications that
  modify by themselves the */etc/default/keyboard* and/or
  */etc/default/locale* would present a problem, in which case they
  would require specific patches. Anyway, those applications neither
  would work with the current state (with those files in a read-only
  filesystem).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2035122/+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 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2023-10-25 Thread Sergio Costas

** Description changed:

+ [Impact]
+ 
  When working with ubuntu core or ubuntu core desktop, neither
- /etc/default/locale nor /etc/default/keyboard are modificable, so it's
- not possible to set the global keyboard or the global language.
+ */etc/default/locale* nor */etc/default/keyboard* are modifiable, so
+ it's not possible to set the global keyboard or the global language.
+ This is required to allow to set the GDM language, and the default one
+ during installation.
+ 
+ The first half of the solution is to create the folder
+ */etc/writable/default*, and make soft-links from */etc/default/locale*
+ to */etc/writable/default/locale* and from */etc/default/keyboard* to
+ */etc/writable/default/keyboard*, just like it is already being done
+ with */etc/hostname*, */etc/issue*, */etc/localtime*, */etc/motd* and ,
+ */etc/timezone*.
+ 
+ This solution, unfortunately, isn't complete. Although any application
+ that just reads the files will work, not all of the applications that
+ write to them will; specifically the systemd utilities that set the
+ contents for those files, because they don't open the file directly;
+ instead, they create first the new file in the same folder than the old
+ one, fill its contents, and only then delete the old one and rename the
+ new one. To solve this, systemd in Ubuntu already has several patches
+ that detect if a file is a soft-link, in which case it replaces the old
+ path with the destination one.
+ 
+ Currently I have in place a patch for Ubuntu Core Desktop that
+ implements both changes for both */etc/default/locale* and
+ */etc/default/keyboard*.
+ 
+ [Test plan]
+ 
+ Using *localectl set-lang LANG="xx_YY.UTF-8"* should change the locale
+ to the specified one. Also, *localectl* should return the current
+ locale.
+ 
+ [Where problems could occur]
+ 
+ In general, applications just read the content of the file and use the
+ DBus interface to set the locale, so only those applications that modify
+ by themselves the */etc/default/keyboard* and/or */etc/default/locale*
+ would present a problem, in which case they would require specific
+ patches. Anyway, those applications neither would work with the current
+ state (with those files in a read-only filesystem).

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

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  [Impact]

  When working with ubuntu core or ubuntu core desktop, neither
  */etc/default/locale* nor */etc/default/keyboard* are modifiable, so
  it's not possible to set the global keyboard or the global language.
  This is required to allow to set the GDM language, and the default one
  during installation.

  The first half of the solution is to create the folder
  */etc/writable/default*, and make soft-links from
  */etc/default/locale* to */etc/writable/default/locale* and from
  */etc/default/keyboard* to */etc/writable/default/keyboard*, just like
  it is already being done with */etc/hostname*, */etc/issue*,
  */etc/localtime*, */etc/motd* and , */etc/timezone*.

  This solution, unfortunately, isn't complete. Although any application
  that just reads the files will work, not all of the applications that
  write to them will; specifically the systemd utilities that set the
  contents for those files, because they don't open the file directly;
  instead, they create first the new file in the same folder than the
  old one, fill its contents, and only then delete the old one and
  rename the new one. To solve this, systemd in Ubuntu already has
  several patches that detect if a file is a soft-link, in which case it
  replaces the old path with the destination one.

  Currently I have in place a patch for Ubuntu Core Desktop that
  implements both changes for both */etc/default/locale* and
  */etc/default/keyboard*.

  [Test plan]

  Using *localectl set-lang LANG="xx_YY.UTF-8"* should change the locale
  to the specified one. Also, *localectl* should return the current
  locale.

  [Where problems could occur]

  In general, applications just read the content of the file and use the
  DBus interface to set the locale, so only those applications that
  modify by themselves the */etc/default/keyboard* and/or
  */etc/default/locale* would present a problem, in which case they
  would require specific patches. Anyway, those applications neither
  would work with the current state (with those files in a read-only
  filesystem).

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


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

[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result

Ah, I noticed that this is part of a big SRU that's being completed on
bug #2033422.  Just leaving a comment here for the record.

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

Title:
  CMS_final: do not ignore CMS_dataFinal result

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Kinetic:
  Won't Fix
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.

  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.

  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/pull/18876

  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  https://github.com/openssl/openssl/pull/18876

  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.

  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"

  Thanks

  Upstream commit:

  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300

  Handle SMIME_crlf_copy return code

  Currently the SMIME_crlf_copy result is ignored in all usages. It does
  return failure when memory allocation fails.

  This patch handles the SMIME_crlf_copy return code in all
  occurrences.

  Signed-off-by: Alon Bar-Lev 

  Reviewed-by: Tomas Mraz 
  Reviewed-by: Paul Dale 
  Reviewed-by: Hugo Landau 
  (Merged from https://github.com/openssl/openssl/pull/18876)
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy

Ah, I noticed that this is part of a big SRU that's being completed on
bug #2033422.  Just leaving a comment here for the record.

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

Title:
  backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
  1.1 with blowfish in OFB or CFB modes" to Jammy

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  Decryption for Blowfish with OFB and CFB modes fails due to using a key 
shorter than expected by default.
  Encryption will also use a key shorter than expected.
  Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead 
to decryption issues.

  [Test plan]
  On Focal, run the following and copy the output to your clipboard

  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do  echo "Test with ${cipher}" 
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
  tar c pouet.bf-* | xz | base64 -w 60

  You can also run this on Lunar or Mantic if you add "-provider legacy
  -provider default" to the "openssl enc" invocation.

  On Jammy, run the following and paste your clipboard

  base64 -d | xz -d | tar x
  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider 
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}"; 
done

  Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
  decrypted: the other two will result in garbage on screen.

  Here is the result of the enc + tar + xz + base64 on Focal (works with
  Lunar/Mantic too but you need to added ):

  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
  hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
  m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
  D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
  ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
  GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
  AoBQAACjzq5WscRn+wIABFla

  Here is the same but from Jammy if you want to test encryption on
  Jammy and decryption on Lunar/Mantic:

  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
  HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
  jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
  2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
  k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
  /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
  1AABrQKAUAAABh3ynbHEZ/sCAARZWg==

  The contents are expected to be different due to the use of
  randomness. Don't try to compare the base64 outputs: I'm only using
  them to ease testing across containers.

  [Where problems could occur]
  This patch makes openssl match the documented default (see "man openssl-enc" 
and search for "Blowfish" for instance) and fixes decryption from an up-to-date 
Jammy to pretty much everything else, but it also create an issue for data 
encrypted on Jammy without this patch and Jammy with this patch.

  There are two possible cases: encrypted data being streamed across
  this boundary or data at rest being transferred or read later.

  Streaming is probably not an issue in practice because it's rather the
  current situation that has been an issue and it's easy to remedy by
  updating everything (which is relatively few machines since that's
  only Jammy and not any other OS or distribution).

  Data at rest is more annoying since updating Jammy will make it
  impossible to read the data again without updates to other pieces of
  software. That sounds like a really bad thing and it kind of is but at
  the same, the benefits are much larger than the issues. Indeed, there
  is already an incompatibility at the moment between Jammy and
  everything else and the more time passes by, the more such problematic
  files can be created. Luckily very few people are using blowfish
  nowadays and it's not even enabled by default anymore in openssl.
  Moreover the software update to work around the issue should be a
  single API call which is documented in the upstream bug report (
  https://github.com/openssl/openssl/issues/18359 ). Finally, I have
  warned the two projects that I am aware are impacted; this is made
  easier by the fact that they encountered the initial incompatibility.

  [Patches]
  The patches come directly from upstream and apply

[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

Thanks for the contribution, Adrien.

I find the naming scheme you chose for the patches a bit confusing. For
example, you're using the prefix "jammy-sru-0001-" on several patches
that are actually not strictly related. You also don't mention any
patch explicitly in the d/changelog entry, which forces the reader to
open d/p/series and look at the comments there. Moreover, the patches
are missing DEP-3 headers (which, in this case, would be very useful
when trying to understand the context when looking at a single patch).

Could you please address the concerns above before we proceed with the
upload?

Thanks.

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

Title:
openssl: backport to jammy "clear method store / query cache
confusion"

Status in openssl package in Ubuntu:
New
Status in openssl source package in Jammy:
In Progress
Status in openssl source package in Lunar:
Fix Released

Bug description:
=== SRU information ===
[Meta]
This bug is part of a series of four bugs for a single SRU.
This ( #2033422 ) is the "central" bug with the global information and
debdiff.

This SRU addresses four issues with Jammy's openssl version:
- http://pad.lv/1990216: Blowfish OFB/CFB decryption
- http://pad.lv/1994165: ignored SMIME signature errors
- http://pad.lv/2023545: imbca engine dumps core
- http://pad.lv/2033422: very high CPU usage for concurrent TLS connections

The SRU information has been added to the four bug reports and I am
attaching the debdiff here only for all four.

All the patches have been included in subsequent openssl 3.0.x
releases which in turn have been included in subsequent Ubuntu
releases. There has been no report of issues when updating to these
Ubuntu releases.

I have rebuilt the openssl versions and used abi-compliance-checker to
compare the ABIs of the libraries in jammy and the one for the SRU.
Both matched completely (FYI, mantic's matched completely too).

The patch related to blowfish presents an annoying situation: jammy's openssl
creates incompatible files and cannot read other files but fixing it will lead
to files created on jammy so far to become unreadable. Fortunately, blowfish is
long-deprecated and applications can be improved to handle this situation if
the need arises in practice.
This is stated in the SRU information in the bug and in d/changelog.
The current situation in Jammy could be a security issue but due to the
aforementioned deprecation, the low usage of blowfish and the fact that
upstream didn't consider this worthy of a security notice, we (this includes
the security team) chose not to pursue that path either.

I have also pushed the code to git (without any attempt to make it
git-ubuntu friendly).

https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
sru

I asked Brian Murray about phasing speed and he concurs a slow roll-out is
probably better for openssl. There is a small uncertainty because a security
update could come before the phasing is over, effectively fast-forwarding the
SRU. Still, unless there is already a current pre-advisory, this is probably
better than a 10% phasing which is over after only a couple days anyway.
NB: at the moment openssl doesn't phase slowly so this needs to be
implemented.

[Impact]
Severely degraded performance for concurrent operations compared to openssl
1.1. The performance is so degraded that some workloads fail due to timeouts or
insufficient resources (noone magically has 5 times more machines). As a
consequence, a number of people use openssl 1.1 instead and do not get security
updates.

[Test plan]
Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
.
Using this, I get the following numbers on my laptop:

3.0.2:
real 2m5.567s
user 4m3.948s
sys 2m0.233s

this SRU:
real 0m23.966s
user 2m35.687s
sys 0m1.920s

As can be easily seen, the speed-up is massive: system time is divided
by 60 and overall wall clock time is roughly five times lower.

In http://pad.lv/2009544 , Rafael also shared his performance numbers
and they are relatable to these. He used slightly different versions
(upstreams rather than patched with cherry-picks) but at least one of
the version used does not include other performance change. He also
used different hardware and this performance issue seems to depend on
the number of CPUs available but also obtained a performance several
times better. Results on a given machine vary also very little across
runs (less than 2% variation on runs of size 10). They are also very
similar on a Raspberry Pi 4 (8GB).

The benchmark uses https://www.google.com/humans.txt

[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result

Hello,

ubuntu-sponsors is subscribed to this bug but I couldn't find anything
actionable. I'm unsubscribing ubuntu-sponsors; feel free to subscribe it
again if there's anything that needs sponsoring. Thanks.

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

Title:
  CMS_final: do not ignore CMS_dataFinal result

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Kinetic:
  Won't Fix
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.

  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.

  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/pull/18876

  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  https://github.com/openssl/openssl/pull/18876

  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.

  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"

  Thanks

  Upstream commit:

  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300

  Handle SMIME_crlf_copy return code

  Currently the SMIME_crlf_copy result is ignored in all usages. It does
  return failure when memory allocation fails.

  This patch handles the SMIME_crlf_copy return code in all
  occurrences.

  Signed-off-by: Alon Bar-Lev 

  Reviewed-by: Tomas Mraz 
  Reviewed-by: Paul Dale 
  Reviewed-by: Hugo Landau 
  (Merged from https://github.com/openssl/openssl/pull/18876)
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy

Hello,

ubuntu-sponsors is subscribed to this bug but I couldn't find anything
actionable.  I'm unsubscribing ubuntu-sponsors; feel free to subscribe
it again if there's anything that needs sponsoring.  Thanks.

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

Title:
  backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
  1.1 with blowfish in OFB or CFB modes" to Jammy

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  Decryption for Blowfish with OFB and CFB modes fails due to using a key 
shorter than expected by default.
  Encryption will also use a key shorter than expected.
  Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead 
to decryption issues.

  [Test plan]
  On Focal, run the following and copy the output to your clipboard

  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do  echo "Test with ${cipher}" 
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
  tar c pouet.bf-* | xz | base64 -w 60

  You can also run this on Lunar or Mantic if you add "-provider legacy
  -provider default" to the "openssl enc" invocation.

  On Jammy, run the following and paste your clipboard

  base64 -d | xz -d | tar x
  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider 
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}"; 
done

  Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
  decrypted: the other two will result in garbage on screen.

  Here is the result of the enc + tar + xz + base64 on Focal (works with
  Lunar/Mantic too but you need to added ):

  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
  hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
  m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
  D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
  ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
  GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
  AoBQAACjzq5WscRn+wIABFla

  Here is the same but from Jammy if you want to test encryption on
  Jammy and decryption on Lunar/Mantic:

  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
  HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
  jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
  2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
  k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
  /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
  1AABrQKAUAAABh3ynbHEZ/sCAARZWg==

  The contents are expected to be different due to the use of
  randomness. Don't try to compare the base64 outputs: I'm only using
  them to ease testing across containers.

  [Where problems could occur]
  This patch makes openssl match the documented default (see "man openssl-enc" 
and search for "Blowfish" for instance) and fixes decryption from an up-to-date 
Jammy to pretty much everything else, but it also create an issue for data 
encrypted on Jammy without this patch and Jammy with this patch.

  There are two possible cases: encrypted data being streamed across
  this boundary or data at rest being transferred or read later.

  Streaming is probably not an issue in practice because it's rather the
  current situation that has been an issue and it's easy to remedy by
  updating everything (which is relatively few machines since that's
  only Jammy and not any other OS or distribution).

  Data at rest is more annoying since updating Jammy will make it
  impossible to read the data again without updates to other pieces of
  software. That sounds like a really bad thing and it kind of is but at
  the same, the benefits are much larger than the issues. Indeed, there
  is already an incompatibility at the moment between Jammy and
  everything else and the more time passes by, the more such problematic
  files can be created. Luckily very few people are using blowfish
  nowadays and it's not even enabled by default anymore in openssl.
  Moreover the software update to work around the issue should be a
  single API call which is documented in the upstream bug report (
  https://github.com/openssl/openssl/issues/18359 ). Finally, I have
  warned the two projects that I am aware are impacted; this is made
  easier by the fact that they encountered the initial

[Touch-packages] [Bug 2026757] Re: dnsmasq on Ubuntu Jammy/Lunar crashes on neutron-dhcp-agent updates

2023-10-03 Thread Sergio Durigan Junior

Hi,

I'm marking the status of this bug to Incomplete to reflect the fact
that we're waiting for information from the reporter.

@yatin, please let me know when you are able to give my PPA a try.

Thanks.

** Changed in: dnsmasq (Ubuntu Jammy)
   Status: Confirmed => Incomplete

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

Title:
  dnsmasq on Ubuntu Jammy/Lunar crashes on neutron-dhcp-agent updates

Status in Ironic:
  New
Status in neutron:
  New
Status in dnsmasq package in Ubuntu:
  Invalid
Status in dnsmasq source package in Jammy:
  Incomplete
Status in dnsmasq source package in Kinetic:
  Won't Fix
Status in dnsmasq source package in Lunar:
  Invalid
Status in dnsmasq source package in Mantic:
  Invalid

Bug description:
  The Ironic project's CI has been having major blocking issues moving
  to utilizing Ubuntu Jammy and with some investigation we were able to
  isolate the issues down to the dhcp updates causing dnsmasq to crash
  on Ubuntu Jammy, which ships with dnsmasq 2.86. This issue sounds
  similar to an issue known about to the dnsmasq maintainers, where
  dnsmasq would crash with updates occurring due to configuration
  refresh[0].

  This resulted in us upgrading dnsmasq to the version which ships with
  Ubuntu Lunar.

  Which was no better. Dnsmasq still crashed upon record updates for
  addresses and ports getting configuration added/changed/removed.

  We later downgraded to the version of dnsmasq shipped in Ubuntu Focal,
  and dnsmasq stopped crashing and appeared stable enough to utilize for
  CI purposes.

  ** Kernel log from Ubuntu Jammy Package **

  [229798.876726] dnsmasq[81586]: segfault at 7c28 ip 7f6e8313147e sp 
7fffb3d6f830 error 4 in libc.so.6[7f6e830b4000+195000]
  [229798.876745] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [229805.444912] dnsmasq[401428]: segfault at dce8 ip 7fe63bf6a47e sp 
7ffdb105b440 error 4 in libc.so.6[7fe63beed000+195000]
  [229805.444933] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [230414.213448] dnsmasq[401538]: segfault at 78b8 ip 7f12160e447e sp 
7ffed6ef2190 error 4 in libc.so.6[7f1216067000+195000]
  [230414.213467] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [230465.098989] dnsmasq[402665]: segfault at c378 ip 7f81458f047e sp 
7fff0db334a0 error 4 in libc.so.6[7f8145873000+195000]
  [230465.099005] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [231787.247374] dnsmasq[402863]: segfault at 7318 ip 7f3940b9147e sp 
7ffc8df4f010 error 4 in libc.so.6[7f3940b14000+195000]
  [231787.247392] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [231844.886399] dnsmasq[405182]: segfault at dc58 ip 7f32a29e147e sp 
7ffddedd7480 error 4 in libc.so.6[7f32a2964000+195000]
  [231844.886420] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [234692.482154] dnsmasq[405289]: segfault at 67d8 ip 7fab0c5c447e sp 
7fffd6fd8fa0 error 4 in libc.so.6[7fab0c547000+195000]
  [234692.482173] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a

  ** Kernel log entries from Ubuntu Lunar package **

  [234724.842339] dnsmasq[409843]: segfault at fffd ip 
7f35a147647e sp 7ffd536038c0 error 5 in libc.so.6[7f35a13f9000+195000]
  [234724.842368] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [234784.918116] dnsmasq[410019]: segfault at fffd ip 
7f634233947e sp 7fff33877f20 error 5 in libc.so.6[7f63422bc000+195000]
  [234784.918133] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17

[Touch-packages] [Bug 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2023-09-15 Thread Sergio Costas

So it requires a fix both in Ubuntu Core and systemd.

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

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  When working with ubuntu core or ubuntu core desktop, neither
  /etc/default/locale nor /etc/default/keyboard are modificable, so it's
  not possible to set the global keyboard or the global language.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2035122/+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 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2023-09-15 Thread Sergio Costas

The point is that the way of fixing them is to make links to
/etc/writable. But the systemd tools modify them by creating a new,
temporary file first in the place, and then overwriting the old one with
the new. So the patch does the same that was already done for other
files: detect if the file is a soft link, and in that case, follow it up
to the destination.

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

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  When working with ubuntu core or ubuntu core desktop, neither
  /etc/default/locale nor /etc/default/keyboard are modificable, so it's
  not possible to set the global keyboard or the global language.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2035122/+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 2033325] Re: systemd fails to set unit as inactive when using socket activation and the main process has exited

2023-09-12 Thread Sergio Durigan Junior

** No longer affects: libvirt (Ubuntu)

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

Title:
  systemd fails to set unit as inactive when using socket activation and
  the main process has exited

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  systemd 253.5 on Mantic is affected by a bug which makes it fail to
  mark a unit as inactive even when its main process exited (when using
  socket activation).  This is affecting libvirt and possibly other
  services.

  Upstream has a bug: https://github.com/systemd/systemd/issues/27953

  which has been fixed by: https://github.com/systemd/systemd/pull/28000

  To reproduce the problem:

  $ lxc launch ubuntu-daily:mantic libvirt-hang --vm
  $ lxc shell libvirt-hang
  # apt update && apt upgrade -y
  # apt install -y libvirt-daemon-system
  # systemctl status libvirtd.service

  You'll notice that there is a libvirt process running:

  ...
   CGroup: /system.slice/libvirtd.service
   ├─ 870 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
   ├─ 871 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
   └─1020 /usr/sbin/libvirtd --timeout 120
  ...

  Wait for two minutes (or edit /etc/default/libvirtd and reduce the
  timeout), then check the status again.  You'll notice that the
  libvirtd process has exited, but the unit is still marked as active:

  root@libvirt-hang:~# systemctl status libvirtd.service 
  ● libvirtd.service - Virtualization daemon
   Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; preset: 
enabled)
   Active: active (running) since Mon 2023-08-28 23:06:23 UTC; 57s ago
  TriggeredBy: ● libvirtd-admin.socket
   ● libvirtd.socket
   ● libvirtd-ro.socket
 Docs: man:libvirtd(8)
   https://libvirt.org
  Process: 1020 ExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGS (code=exited, 
status=0/SUCCESS)
 Main PID: 1020 (code=exited, status=0/SUCCESS)
Tasks: 2 (limit: 32768)
   Memory: 22.4M
  CPU: 161ms
   CGroup: /system.slice/libvirtd.service
   ├─870 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
   └─871 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
  ...

  
  libvirtd.service is socket-activated, but the fact that it is still 
considered to be active after the main process exited means that the socket 
won't be actively listening, and you end up seeing libvirt-related commands 
hang indefinitely, effectively rendering libvirt useless until you manually 
restart the service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/2033325/+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 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2023-09-11 Thread Sergio Costas

In ubuntu core desktop, we need to be able to change these two files to
allow to set the GDM keyboard and language.

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

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Jammy:
  New

Bug description:
  When working with ubuntu core or ubuntu core desktop, neither
  /etc/default/locale nor /etc/default/keyboard are modificable, so it's
  not possible to set the global keyboard or the global language.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2035122/+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 2035122] Re: Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2023-09-11 Thread Sergio Costas

I have a patch that fixes this. We are already using it in ubuntu core
desktop. I'm preparing to upload it to the GIT repo.

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

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New

Bug description:
  When working with ubuntu core or ubuntu core desktop, neither
  /etc/default/locale nor /etc/default/keyboard are modificable, so it's
  not possible to set the global keyboard or the global language.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2035122/+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 2035122] [NEW] Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

2023-09-11 Thread Sergio Costas

Public bug reported:

When working with ubuntu core or ubuntu core desktop, neither
/etc/default/locale nor /etc/default/keyboard are modificable, so it's
not possible to set the global keyboard or the global language.

** 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/2035122

Title:
  Under ubuntu core/core-desktop, /etc/default/locale is not modifiable

Status in systemd package in Ubuntu:
  New

Bug description:
  When working with ubuntu core or ubuntu core desktop, neither
  /etc/default/locale nor /etc/default/keyboard are modificable, so it's
  not possible to set the global keyboard or the global language.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2035122/+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 2033325] [NEW] systemd fails to set unit as inactive when using socket activation and the main process has exited

2023-08-28 Thread Sergio Durigan Junior

Public bug reported:

systemd 253.5 on Mantic is affected by a bug which makes it fail to mark
a unit as inactive even when its main process exited (when using socket
activation).  This is affecting libvirt and possibly other services.

Upstream has a bug: https://github.com/systemd/systemd/issues/27953

which has been fixed by: https://github.com/systemd/systemd/pull/28000

To reproduce the problem:

$ lxc launch ubuntu-daily:mantic libvirt-hang --vm
$ lxc shell libvirt-hang
# apt update && apt upgrade -y
# apt install -y libvirt-daemon-system
# systemctl status libvirtd.service

You'll notice that there is a libvirt process running:

...
 CGroup: /system.slice/libvirtd.service
 ├─ 870 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
 ├─ 871 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
 └─1020 /usr/sbin/libvirtd --timeout 120
...

Wait for two minutes (or edit /etc/default/libvirtd and reduce the
timeout), then check the status again.  You'll notice that the libvirtd
process has exited, but the unit is still marked as active:

root@libvirt-hang:~# systemctl status libvirtd.service 
● libvirtd.service - Virtualization daemon
 Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; preset: 
enabled)
 Active: active (running) since Mon 2023-08-28 23:06:23 UTC; 57s ago
TriggeredBy: ● libvirtd-admin.socket
 ● libvirtd.socket
 ● libvirtd-ro.socket
   Docs: man:libvirtd(8)
 https://libvirt.org
Process: 1020 ExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGS (code=exited, 
status=0/SUCCESS)
   Main PID: 1020 (code=exited, status=0/SUCCESS)
  Tasks: 2 (limit: 32768)
 Memory: 22.4M
CPU: 161ms
 CGroup: /system.slice/libvirtd.service
 ├─870 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
 └─871 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
...


libvirtd.service is socket-activated, but the fact that it is still considered 
to be active after the main process exited means that the socket won't be 
actively listening, and you end up seeing libvirt-related commands hang 
indefinitely, effectively rendering libvirt useless until you manually restart 
the service.

** Affects: systemd
 Importance: Unknown
 Status: Fix Released

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

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

** Bug watch added: github.com/systemd/systemd/issues #27953
   https://github.com/systemd/systemd/issues/27953

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/27953
   Importance: Unknown
   Status: Unknown

** Also affects: libvirt (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/2033325

Title:
  systemd fails to set unit as inactive when using socket activation and
  the main process has exited

Status in systemd:
  Fix Released
Status in libvirt package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  systemd 253.5 on Mantic is affected by a bug which makes it fail to
  mark a unit as inactive even when its main process exited (when using
  socket activation).  This is affecting libvirt and possibly other
  services.

  Upstream has a bug: https://github.com/systemd/systemd/issues/27953

  which has been fixed by: https://github.com/systemd/systemd/pull/28000

  To reproduce the problem:

  $ lxc launch ubuntu-daily:mantic libvirt-hang --vm
  $ lxc shell libvirt-hang
  # apt update && apt upgrade -y
  # apt install -y libvirt-daemon-system
  # systemctl status libvirtd.service

  You'll notice that there is a libvirt process running:

  ...
   CGroup: /system.slice/libvirtd.service
   ├─ 870 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
   ├─ 871 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
   └─1020 /usr/sbin/libvirtd --timeout 120
  ...

  Wait for two minutes (or edit /etc/default/libvirtd and reduce the
  timeout), then check the status again.  You'll notice that the
  libvirtd process has exited, but the unit is still marked as active:

  root@libvirt-hang:~# systemctl status libvirtd.service 
  ● libvirtd.service - Virtualization daemon
   Loaded: loaded

[Touch-packages] [Bug 2016252] Re: qemu-system-x86_64 crashes inside systemd autopkgtest (nested VM)

2023-07-27 Thread Sergio Durigan Junior

Spoke too soon: that commit is already present in qemu 8.0, of course.

The rest of what I wrote still applies, though: I need to see if I can
reproduce the failure here.

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

Title:
  qemu-system-x86_64 crashes inside systemd autopkgtest (nested VM)

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

Bug description:
  Systemd package has autopkgtests
  the upstream-2 test cases use upstream systemd testsuite, i.e. make -C 
str/test/TEST-70-TPM2 setup run
  it launches a nested VM to do quick tests inside it.

  It appears that qemu-system-x86_64 crashes in such cases:

  TEST-70-TPM2 RUN: cryptenroll/cryptsetup with TPM2 devices
  + timeout --foreground 1800 /bin/qemu-system-x86_64 -smp 4 -net none -m 1024M 
-nographic -vga none -kernel /boot/vmlinuz-6.2.0-1003-lowlatency -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.G2RH6i/tpm2.img -device 
virtio-rng-pci,max-bytes=1024,period=1000 -chardev 
socket,id=chrtpm,path=/tmp/tmp.cRBa43SrLC/sock -tpmdev 
emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 -initrd 
/boot/initrd.img-6.2.0-1003-lowlatency -append 'root=LABEL=systemd_boot rw 
raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-70.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-70.service oops=panic 
panic=1 softlockup_panic=1 systemd.wants=end.service'
  qemu-system-x86_64: ../../util/cacheflush.c:208: init_cache_info: Assertion 
`(isize & (isize - 1)) == 0' failed.
  timeout: the monitored command dumped core
  ..//test-functions: line 377: 152120 Aborted ( set -x; 
"${qemu_cmd[@]}" "${qemu_options[@]}" -append "${kernel_params[*]}" )
  E: qemu failed with exit code 134

  The important bit seems to be:

  qemu-system-x86_64: ../../util/cacheflush.c:208: init_cache_info:
  Assertion `(isize & (isize - 1)) == 0' failed.

  Which is an assert inside qemu source code.

  Is the systemd test suite VM setup doing something wrong, or is there
  something wrong in qemu?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2016252/+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 2016252] Re: qemu-system-x86_64 crashes inside systemd autopkgtest (nested VM)

2023-07-27 Thread Sergio Durigan Junior

The following upstream commit looks interesting:

https://github.com/qemu/qemu/commit/00b5032eaddb7193f03f0a28b10286244d2e2a7b

I'll see if I can reproduce the issue here, and then check if
backporting the commit above makes any difference.

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

Title:
  qemu-system-x86_64 crashes inside systemd autopkgtest (nested VM)

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

Bug description:
  Systemd package has autopkgtests
  the upstream-2 test cases use upstream systemd testsuite, i.e. make -C 
str/test/TEST-70-TPM2 setup run
  it launches a nested VM to do quick tests inside it.

  It appears that qemu-system-x86_64 crashes in such cases:

  TEST-70-TPM2 RUN: cryptenroll/cryptsetup with TPM2 devices
  + timeout --foreground 1800 /bin/qemu-system-x86_64 -smp 4 -net none -m 1024M 
-nographic -vga none -kernel /boot/vmlinuz-6.2.0-1003-lowlatency -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.G2RH6i/tpm2.img -device 
virtio-rng-pci,max-bytes=1024,period=1000 -chardev 
socket,id=chrtpm,path=/tmp/tmp.cRBa43SrLC/sock -tpmdev 
emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 -initrd 
/boot/initrd.img-6.2.0-1003-lowlatency -append 'root=LABEL=systemd_boot rw 
raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-70.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-70.service oops=panic 
panic=1 softlockup_panic=1 systemd.wants=end.service'
  qemu-system-x86_64: ../../util/cacheflush.c:208: init_cache_info: Assertion 
`(isize & (isize - 1)) == 0' failed.
  timeout: the monitored command dumped core
  ..//test-functions: line 377: 152120 Aborted ( set -x; 
"${qemu_cmd[@]}" "${qemu_options[@]}" -append "${kernel_params[*]}" )
  E: qemu failed with exit code 134

  The important bit seems to be:

  qemu-system-x86_64: ../../util/cacheflush.c:208: init_cache_info:
  Assertion `(isize & (isize - 1)) == 0' failed.

  Which is an assert inside qemu source code.

  Is the systemd test suite VM setup doing something wrong, or is there
  something wrong in qemu?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2016252/+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 2028721] Re: Merge openldap from Debian experimental for mantic

2023-07-26 Thread Sergio Durigan Junior

** Merge proposal linked:
   
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/447816

** Changed in: openldap (Ubuntu)
   Status: New => In Progress

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

Title:
  Merge openldap from Debian experimental for mantic

Status in openldap package in Ubuntu:
  In Progress

Bug description:
  I uploaded version 2.6.5 to Debian experimental yesterday.  This bug
  is a reminder to merge it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2028721/+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 2026757] Re: dnsmasq on Ubuntu Jammy/Lunar crashes on neutron-dhcp-agent updates

2023-07-26 Thread Sergio Durigan Junior

Hello and thanks for taking the time to report this bug.

I read the discussion above and would like to clarify a few things:

1) Does the segfault happen with the dnsmasq package from Lunar/Mantic?
I see tasks for both systems added to this bug (and the Mantic one is
set as Confirmed), but it's not clear from the messages above whether
the failure really happens there.

2) Assuming that the segfault does *not* happen in Lunar/Mantic, I can
prepare a PPA with the backported patch from upstream and ask you to
test it.

3) If the failure *does* happen in Lunar/Mantic, we will need to
investigate it further.


FWIW, Kinetic has reached its end of standard support so I will set its task as 
Won't Fix.

Thank you.

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

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

Title:
  dnsmasq on Ubuntu Jammy/Lunar crashes on neutron-dhcp-agent updates

Status in Ironic:
  New
Status in neutron:
  New
Status in dnsmasq package in Ubuntu:
  Confirmed
Status in dnsmasq source package in Jammy:
  New
Status in dnsmasq source package in Kinetic:
  Won't Fix
Status in dnsmasq source package in Lunar:
  New
Status in dnsmasq source package in Mantic:
  Confirmed

Bug description:
  The Ironic project's CI has been having major blocking issues moving
  to utilizing Ubuntu Jammy and with some investigation we were able to
  isolate the issues down to the dhcp updates causing dnsmasq to crash
  on Ubuntu Jammy, which ships with dnsmasq 2.86. This issue sounds
  similar to an issue known about to the dnsmasq maintainers, where
  dnsmasq would crash with updates occurring due to configuration
  refresh[0].

  This resulted in us upgrading dnsmasq to the version which ships with
  Ubuntu Lunar.

  Which was no better. Dnsmasq still crashed upon record updates for
  addresses and ports getting configuration added/changed/removed.

  We later downgraded to the version of dnsmasq shipped in Ubuntu Focal,
  and dnsmasq stopped crashing and appeared stable enough to utilize for
  CI purposes.

  ** Kernel log from Ubuntu Jammy Package **

  [229798.876726] dnsmasq[81586]: segfault at 7c28 ip 7f6e8313147e sp 
7fffb3d6f830 error 4 in libc.so.6[7f6e830b4000+195000]
  [229798.876745] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [229805.444912] dnsmasq[401428]: segfault at dce8 ip 7fe63bf6a47e sp 
7ffdb105b440 error 4 in libc.so.6[7fe63beed000+195000]
  [229805.444933] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [230414.213448] dnsmasq[401538]: segfault at 78b8 ip 7f12160e447e sp 
7ffed6ef2190 error 4 in libc.so.6[7f1216067000+195000]
  [230414.213467] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [230465.098989] dnsmasq[402665]: segfault at c378 ip 7f81458f047e sp 
7fff0db334a0 error 4 in libc.so.6[7f8145873000+195000]
  [230465.099005] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [231787.247374] dnsmasq[402863]: segfault at 7318 ip 7f3940b9147e sp 
7ffc8df4f010 error 4 in libc.so.6[7f3940b14000+195000]
  [231787.247392] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [231844.886399] dnsmasq[405182]: segfault at dc58 ip 7f32a29e147e sp 
7ffddedd7480 error 4 in libc.so.6[7f32a2964000+195000]
  [231844.886420] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a
  [234692.482154] dnsmasq[405289]: segfault at 67d8 ip 7fab0c5c447e sp 
7fffd6fd8fa0 error 4 in libc.so.6[7fab0c547000+195000]
  [234692.482173] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e fa 48 85 
ff 0f 84 bb 00 00 00 55 48 8d 77 f0 53 48 83 ec 18 48 8b 1d 92 39 17 00 <48> 8b 
47 f8 64 8b 2b a8 02 75 57 48 8b 15 18 39 17 00 64 48 83 3a

  ** Kernel log entries from Ubuntu Lunar package **

  [234724.842339] dnsmasq[409843]: segfault at fffd ip 
7f35a147647e sp 7ffd536038c0 error 5 in libc.so.6[7f35a13f9000+195000]
  [234724.842368] Code: 98 13 00 e8 04 b9 ff ff 0f 1f 40 00 f3 0f 1e

[Touch-packages] [Bug 2028721] [NEW] Merge openldap from Debian experimental for mantic

2023-07-25 Thread Sergio Durigan Junior

Public bug reported:

I uploaded version 2.6.5 to Debian experimental yesterday.  This bug is
a reminder to merge it.

** Affects: openldap (Ubuntu)
 Importance: Undecided
 Assignee: Sergio Durigan Junior (sergiodj)
 Status: New


** Tags: needs-merge upgrade-software-version

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

Title:
  Merge openldap from Debian experimental for mantic

Status in openldap package in Ubuntu:
  New

Bug description:
  I uploaded version 2.6.5 to Debian experimental yesterday.  This bug
  is a reminder to merge it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2028721/+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 2027079] Re: New upstream microrelease 2.5.15

2023-07-18 Thread Sergio Durigan Junior

As is usual with these MREs, the verification phase is considered done
when all dep8 tests pass. This is now true for the Jammy upload.
Therefore, tagging the bug accordingly.

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

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

Title:
New upstream microrelease 2.5.15

Status in openldap package in Ubuntu:
Invalid
Status in openldap source package in Jammy:
Fix Committed

Bug description:
[ Impact ]

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

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

[ Test Plan ]

* Upstream gitlab pipeline results:

https://git.openldap.org/openldap/openldap/-/commit/d0fbbc3599148e1033218ec097bf5ab5f6236c76/pipelines?ref=OPENLDAP_REL_ENG_2_5_15

* Upstream "call for testing":

https://lists.openldap.org/hyperkitty/list/openldap-
techni...@openldap.org/message/HUNFQO6GJR7CCJAYKMTRXE44ZPHBKKMD/

* Build log (amd64) confirming that the build-time testsuite has been
performed and completed successfully:
-
https://launchpadlibrarian.net/676793029/buildlog_ubuntu-jammy-amd64.openldap_2.5.15+dfsg-0ubuntu0.22.04.1_BUILDING.txt.gz

[ Where problems could occur ]

[ 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.14+dfsg-0ubuntu0.22.04.2 | jammy-updates | source

Special cases:
- None.

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

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/2027079/+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 2019010] Re: environment variable SSH_ORIGINAL_COMMAND on server side set with wrong value

2023-07-12 Thread Sergio Durigan Junior

Hello Andrey,

This seems to be more of a support question than a bug per se, so I am
keeping this bug marked as Expired.  There are many places where you can
obtain help for the questions you are having; you can take a look at
https://www.ubuntu.com/support/community and choose one of the available
fora.

Thank you.

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

Title:
  environment variable SSH_ORIGINAL_COMMAND  on server side set with
  wrong value

Status in openssh package in Ubuntu:
  Expired

Bug description:
  After updating to Ubuntu 23.04 when running  scp command environment variable 
SSH_ORIGINAL_COMMAND on server side is set with 
SSH_ORIGINAL_COMMAND=/usr/libexec/openssh/sftp-server.
  With  previous version this environment variable  was set to "scp -t " or "scp -f  " depends on if it was push or get command to 
copy file from or to remote system
  SSH_ORIGINAL_COMMAND environment variable is used to validate scp command on 
server side.

  System information:
  lsb_release -rd
  No LSB modules are available.
  Description:  Ubuntu 23.04
  Release:  23.04

  
  apt-cache policy openssh-client
  openssh-client:
Installed: 1:9.0p1-1ubuntu8
Candidate: 1:9.0p1-1ubuntu8
Version table:
   *** 1:9.0p1-1ubuntu8 500
  500 http://us.archive.ubuntu.com/ubuntu lunar/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2019010/+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 1983618] Re: New upstream microrelease 2.5.13

** Tags removed: needs-mre-backport

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

Title:
  New upstream microrelease 2.5.13

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Jammy:
  Fix Released

Bug description:
  [ Impact ]

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

  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/3PLJDVP7QWTRFHC2GPQTGBLEQFCBUZZ2/

  [ Test Plan ]

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

   * Upstream "call for testing":
  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/thread/RXOSXVLKTIDM4XJUA5EZZ42677JXRHYN/

   * 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: https://launchpad.net/~ci-train-
  ppa-service/+archive/ubuntu/4887/+build/24250107

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

  [ 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.12+dfsg-0ubuntu0.22.04.1 | jammy-updates   | source

  Special cases:
  - None.

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

  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/1983618/+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 2027079] Re: New upstream microrelease 2.5.15

** Changed in: openldap (Ubuntu)
   Status: New => Invalid

** Merge proposal linked:
   
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/446555

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

Title:
   New upstream microrelease 2.5.15

Status in openldap package in Ubuntu:
  Invalid
Status in openldap source package in Jammy:
  In Progress

Bug description:
  [ Impact ]

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

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

  [ Test Plan ]

   * Upstream gitlab pipeline results:
  
https://git.openldap.org/openldap/openldap/-/commit/d0fbbc3599148e1033218ec097bf5ab5f6236c76/pipelines?ref=OPENLDAP_REL_ENG_2_5_15

   * Upstream "call for testing":

  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/message/HUNFQO6GJR7CCJAYKMTRXE44ZPHBKKMD/

   * As described in the MRE wiki page for OpenLDAP, the test plan is to
  build the package in a PPA 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:
    - 
https://launchpadlibrarian.net/676793029/buildlog_ubuntu-jammy-amd64.openldap_2.5.15+dfsg-0ubuntu0.22.04.1_BUILDING.txt.gz

  [ 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.14+dfsg-0ubuntu0.22.04.2 | jammy-updates   | source

  Special cases:
  - None.

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

  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/2027079/+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 2027079] Re: New upstream microrelease 2.5.15

** Description changed:

[ Impact ]

- * MRE for the latest stable OpenLDAP 2.5.x release, 2.5.15.
+ * MRE for the latest stable OpenLDAP 2.5.x release, 2.5.15.

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:
+ * See the list of bugs fixed in this release here:

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

[ Test Plan ]

- * Upstream gitlab pipeline results:
+ * Upstream gitlab pipeline results:

https://git.openldap.org/openldap/openldap/-/commit/d0fbbc3599148e1033218ec097bf5ab5f6236c76/pipelines?ref=OPENLDAP_REL_ENG_2_5_15

- * Upstream "call for testing":
+ * Upstream "call for testing":

https://lists.openldap.org/hyperkitty/list/openldap-
techni...@openldap.org/message/HUNFQO6GJR7CCJAYKMTRXE44ZPHBKKMD/

- * As described in the MRE wiki page for OpenLDAP, the test plan is to
+ * As described in the MRE wiki page for OpenLDAP, the test plan is to
build the package in a PPA 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
+ * Build log (amd64) confirming that the build-time testsuite has been
performed and completed successfully:
+ -
https://launchpadlibrarian.net/676793029/buildlog_ubuntu-jammy-amd64.openldap_2.5.15+dfsg-0ubuntu0.22.04.1_BUILDING.txt.gz

[ Where problems could occur ]

- * Upstream tests are always executed during build-time. There are many
+ * 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
+ * This is a reoccurring MRE. See below for links to previous OpenLDAP
MREs.

- * CVEs fixed by this release:
-- None.
+ * CVEs fixed by this release:
+ - None.

Special cases:
- None.

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

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

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

Title:
New upstream microrelease 2.5.15

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

Bug description:
[ Impact ]

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

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

[ Test Plan ]

* Upstream gitlab pipeline results:

https://git.openldap.org/openldap/openldap/-/commit/d0fbbc3599148e1033218ec097bf5ab5f6236c76/pipelines?ref=OPENLDAP_REL_ENG_2_5_15

* Upstream "call for testing":

https://lists.openldap.org/hyperkitty/list/openldap-
techni...@openldap.org/message/HUNFQO6GJR7CCJAYKMTRXE44ZPHBKKMD/

[ Where problems could occur ]

[ Other Info ]

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

* CVEs fixed by this release:
- None.

[Touch-packages] [Bug 2027079] [NEW] New upstream microrelease 2.5.15

Public bug reported:

[ Impact ]

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

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

[ Test Plan ]

* Upstream gitlab pipeline results:
https://git.openldap.org/openldap/openldap/-/commit/d0fbbc3599148e1033218ec097bf5ab5f6236c76/pipelines?ref=OPENLDAP_REL_ENG_2_5_15

* Upstream "call for testing":

https://lists.openldap.org/hyperkitty/list/openldap-
techni...@openldap.org/message/HUNFQO6GJR7CCJAYKMTRXE44ZPHBKKMD/

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

[ 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.14+dfsg-0ubuntu0.22.04.2 | jammy-updates | source

Special cases:
- None.

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

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

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

** Affects: openldap (Ubuntu Jammy)
Importance: Undecided
Assignee: Sergio Durigan Junior (sergiodj)
Status: In Progress

** Tags: server-todo

** Also affects: openldap (Ubuntu Jammy)
Importance: Undecided
Status: New

** Changed in: openldap (Ubuntu Jammy)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

** Tags added: server-todo

** Changed in: openldap (Ubuntu Jammy)
Status: New => In Progress

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

Title:
New upstream microrelease 2.5.15

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

Bug description:
[ Impact ]

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

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

[ Test Plan ]

* Upstream gitlab pipeline results:

https://git.openldap.org/openldap/openldap/-/commit/d0fbbc3599148e1033218ec097bf5ab5f6236c76/pipelines?ref=OPENLDAP_REL_ENG_2_5_15

* Upstream "call for testing":

https://lists.openldap.org/hyperkitty/list/openldap-
techni...@openldap.org/message/HUNFQO6GJR7CCJAYKMTRXE44ZPHBKKMD/

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

[ Where problems could occur ]

[ 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.14+dfsg-0ubuntu0.22.04.2 | jammy-updates | source

Special cases:
- None.

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

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/+so

[Touch-packages] [Bug 2020913] Re: /etc/profile.d/debuginfd.{sh, csh} are created with 600 permissions

2023-07-07 Thread Sergio Durigan Junior

You're correct, but your message made me look a bit deeper into the
issue and made me remember that, for Jammy, installing libdebuginfod-
common alone won't configure the system to use our debuginfod service.

I would like to turn this bug into a broader "make sure we enable
support for debuginfod.ubuntu.com when installing libdebuginfod-common"
thing.  WDYT (as an SRU team member)?

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

Title:
  /etc/profile.d/debuginfd.{sh,csh} are created with 600 permissions

Status in elfutils package in Ubuntu:
  Fix Released
Status in elfutils source package in Jammy:
  In Progress

Bug description:
  [ Impact ]

  Users installing libdebuginfod-common (the package that ships the
  shell snippets responsible for configuring the DEBUGINFOD_URLS
  environment variable, which will ultimately be used by GDB to contact
  the Ubuntu debuginfod service) experience a problem caused by
  permissions being set too tightly for
  /etc/profile.d/debuginfod.{sh,csh}.  This results in DEBUGINFOD_URLS
  not being set for non-root users.

  [ Test Plan ]

  Inside a Jammy container:

  # apt install -y libdebuginfod-common
  # ls -lah /etc/profile.d/debuginfod*

  Verify that the permission of both files allow them to be world-
  readable.

  [ Where problems could occur ]

  Care has been taken to not modify existing file permissions
  unnecessarily by using "g+r,o+r" when invoking chmod, but it is still
  possible to conceive a scenario where upgrading the package would make
  the files world-readable when the user is actually expecting
  otherwise.  However, such "regression" would arguably not be something
  supported because if the intention is to prevent non-root users from
  making use of debuginfod, there are better ways to achieve it.

  [ Original Description ]

  In a fresh container, installing libdebuginfod-common gives a
  /etc/profile.d that looks like this:

  ```
  root@32f34f7e271e:/etc/profile.d# ls -lah
  total 24K
  drwxr-xr-x 1 root root 4.0K May 26 17:23 .
  drwxr-xr-x 1 root root 4.0K May 26 17:23 ..
  -rw-r--r-- 1 root root   96 Oct 15  2021 01-locale-fix.sh
  -rw--- 1 root root  677 May 26 17:23 debuginfod.csh
  -rw--- 1 root root  692 May 26 17:23 debuginfod.sh

  ```

  when I login as a nonprivledged user, DEBUGINFOD_URLS is not set
  because the permissions are incorrect on the profile files.

  ```
  # dpkg -l  | grep libdebug
  ii  libdebuginfod-common0.186-1build1   all   
   configuration to enable the Debian debug info server
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2020913/+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 2020913] Re: /etc/profile.d/debuginfd.{sh, csh} are created with 600 permissions

2023-07-07 Thread Sergio Durigan Junior

** Description changed:

+ [ Impact ]
+ 
+ Users installing libdebuginfod-common (the package that ships the shell
+ snippets responsible for configuring the DEBUGINFOD_URLS environment
+ variable, which will ultimately be used by GDB to contact the Ubuntu
+ debuginfod service) experience a problem caused by permissions being set
+ too tightly for /etc/profile.d/debuginfod.{sh,csh}.  This results in
+ DEBUGINFOD_URLS not being set for non-root users.
+ 
+ [ Test Plan ]
+ 
+ Inside a Jammy container:
+ 
+ # apt install -y libdebuginfod-common
+ # ls -lah /etc/profile.d/debuginfod*
+ 
+ Verify that the permission of both files allow them to be world-
+ readable.
+ 
+ [ Where problems could occur ]
+ 
+ Care has been taken to not modify existing file permissions
+ unnecessarily by using "g+r,o+r" when invoking chmod, but it is still
+ possible to conceive a scenario where upgrading the package would make
+ the files world-readable when the user is actually expecting otherwise.
+ However, such "regression" would arguably not be something supported
+ because if the intention is to prevent non-root users from making use of
+ debuginfod, there are better ways to achieve it.
+ 
+ [ Original Description ]
+ 
  In a fresh container, installing libdebuginfod-common gives a
  /etc/profile.d that looks like this:
  
  ```
  root@32f34f7e271e:/etc/profile.d# ls -lah
  total 24K
  drwxr-xr-x 1 root root 4.0K May 26 17:23 .
  drwxr-xr-x 1 root root 4.0K May 26 17:23 ..
  -rw-r--r-- 1 root root   96 Oct 15  2021 01-locale-fix.sh
  -rw--- 1 root root  677 May 26 17:23 debuginfod.csh
  -rw--- 1 root root  692 May 26 17:23 debuginfod.sh
  
  ```
  
  when I login as a nonprivledged user, DEBUGINFOD_URLS is not set because
  the permissions are incorrect on the profile files.
  
  ```
  # dpkg -l  | grep libdebug
  ii  libdebuginfod-common0.186-1build1   all   
   configuration to enable the Debian debug info server
  ```

** Changed in: elfutils (Ubuntu Jammy)
   Status: Triaged => In Progress

** Tags added: server-todo

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

Title:
  /etc/profile.d/debuginfd.{sh,csh} are created with 600 permissions

Status in elfutils package in Ubuntu:
  Fix Released
Status in elfutils source package in Jammy:
  In Progress

Bug description:
  [ Impact ]

  Users installing libdebuginfod-common (the package that ships the
  shell snippets responsible for configuring the DEBUGINFOD_URLS
  environment variable, which will ultimately be used by GDB to contact
  the Ubuntu debuginfod service) experience a problem caused by
  permissions being set too tightly for
  /etc/profile.d/debuginfod.{sh,csh}.  This results in DEBUGINFOD_URLS
  not being set for non-root users.

  [ Test Plan ]

  Inside a Jammy container:

  # apt install -y libdebuginfod-common
  # ls -lah /etc/profile.d/debuginfod*

  Verify that the permission of both files allow them to be world-
  readable.

  [ Where problems could occur ]

  Care has been taken to not modify existing file permissions
  unnecessarily by using "g+r,o+r" when invoking chmod, but it is still
  possible to conceive a scenario where upgrading the package would make
  the files world-readable when the user is actually expecting
  otherwise.  However, such "regression" would arguably not be something
  supported because if the intention is to prevent non-root users from
  making use of debuginfod, there are better ways to achieve it.

  [ Original Description ]

  In a fresh container, installing libdebuginfod-common gives a
  /etc/profile.d that looks like this:

  ```
  root@32f34f7e271e:/etc/profile.d# ls -lah
  total 24K
  drwxr-xr-x 1 root root 4.0K May 26 17:23 .
  drwxr-xr-x 1 root root 4.0K May 26 17:23 ..
  -rw-r--r-- 1 root root   96 Oct 15  2021 01-locale-fix.sh
  -rw--- 1 root root  677 May 26 17:23 debuginfod.csh
  -rw--- 1 root root  692 May 26 17:23 debuginfod.sh

  ```

  when I login as a nonprivledged user, DEBUGINFOD_URLS is not set
  because the permissions are incorrect on the profile files.

  ```
  # dpkg -l  | grep libdebug
  ii  libdebuginfod-common0.186-1build1   all   
   configuration to enable the Debian debug info server
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2020913/+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 2020913] Re: /etc/profile.d/debuginfd.{sh, csh} are created with 600 permissions

2023-07-07 Thread Sergio Durigan Junior

** Also affects: elfutils (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: elfutils (Ubuntu Jammy)
   Status: New => Triaged

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

** Changed in: elfutils (Ubuntu Jammy)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

** Changed in: elfutils (Ubuntu Jammy)
   Importance: Undecided => High

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

Title:
  /etc/profile.d/debuginfd.{sh,csh} are created with 600 permissions

Status in elfutils package in Ubuntu:
  Fix Released
Status in elfutils source package in Jammy:
  Triaged

Bug description:
  In a fresh container, installing libdebuginfod-common gives a
  /etc/profile.d that looks like this:

  ```
  root@32f34f7e271e:/etc/profile.d# ls -lah
  total 24K
  drwxr-xr-x 1 root root 4.0K May 26 17:23 .
  drwxr-xr-x 1 root root 4.0K May 26 17:23 ..
  -rw-r--r-- 1 root root   96 Oct 15  2021 01-locale-fix.sh
  -rw--- 1 root root  677 May 26 17:23 debuginfod.csh
  -rw--- 1 root root  692 May 26 17:23 debuginfod.sh

  ```

  when I login as a nonprivledged user, DEBUGINFOD_URLS is not set
  because the permissions are incorrect on the profile files.

  ```
  # dpkg -l  | grep libdebug
  ii  libdebuginfod-common0.186-1build1   all   
   configuration to enable the Debian debug info server
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/2020913/+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 2007529] Re: package slapd 2.4.49+dfsg-2ubuntu1.9 failed to install/upgrade: installed slapd package post-installation script subprocess returned error exit status 1

Thank you very much for the quick reply, Oleksii.

>From what you describe, it really seems like this was a local
configuration issue, possibly with some other component from your
system.  I will close this bug as Invalid based on that observation, but
feel free to reopen it if you encounter the problem again.

Thanks!

** Changed in: openldap (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  package slapd 2.4.49+dfsg-2ubuntu1.9 failed to install/upgrade:
  installed slapd package post-installation script subprocess returned
  error exit status 1

Status in openldap package in Ubuntu:
  Invalid

Bug description:
  The system asked me to send a report about a failure. Here it is.

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: slapd 2.4.49+dfsg-2ubuntu1.9
  ProcVersionSignature: Ubuntu 5.15.0-60.66~20.04.1-generic 5.15.78
  Uname: Linux 5.15.0-60-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.25
  AptOrdering:
   gir1.2-webkit2-4.0:amd64: Install
   gir1.2-javascriptcoregtk-4.0:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  CNConfig: Error: command ['/usr/bin/ldapsearch', '-Q', '-LLL', '-Y EXTERNAL', 
'-H ldapi:///', '-b cn=config'] failed with exit code 255: 
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
  CasperMD5CheckResult: skip
  Date: Wed Feb 15 06:54:50 2023
  ErrorMessage: installed slapd package post-installation script subprocess 
returned error exit status 1
  InstallationDate: Installed on 2022-02-20 (360 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-5.15.0-60-generic 
root=UUID=02b06a5b-7026-48f6-9745-993e04e5aba6 ro quiet splash
  Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3.2
   apt  2.0.9
  SourcePackage: openldap
  Title: package slapd 2.4.49+dfsg-2ubuntu1.9 failed to install/upgrade: 
installed slapd package post-installation script subprocess returned error exit 
status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.slapd: 2022-10-24T00:13:25.321836

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2007529/+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 2007529] Re: package slapd 2.4.49+dfsg-2ubuntu1.9 failed to install/upgrade: installed slapd package post-installation script subprocess returned error exit status 1

Thank you for taking the time to submit a bug report.

I'm afraid we're going to need more information before we can act on it,
though.  It's not entirely clear to me what happened here.  Do you still
have access to the logs from when you've experienced the issue?
Something that caught my attention is the fact that several dpkg
operations seem to be failing on your system (based on
DpkgHistoryLog.txt).  It seems that slapd did not successfully restart
after the upgrade, but it's not possible to determine what caused this
problem.  Can you reproduce the bug?  If yes, could you please provide
steps explaining how to do it?

Thanks in advance.

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

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

Title:
  package slapd 2.4.49+dfsg-2ubuntu1.9 failed to install/upgrade:
  installed slapd package post-installation script subprocess returned
  error exit status 1

Status in openldap package in Ubuntu:
  Incomplete

Bug description:
  The system asked me to send a report about a failure. Here it is.

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: slapd 2.4.49+dfsg-2ubuntu1.9
  ProcVersionSignature: Ubuntu 5.15.0-60.66~20.04.1-generic 5.15.78
  Uname: Linux 5.15.0-60-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.25
  AptOrdering:
   gir1.2-webkit2-4.0:amd64: Install
   gir1.2-javascriptcoregtk-4.0:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  CNConfig: Error: command ['/usr/bin/ldapsearch', '-Q', '-LLL', '-Y EXTERNAL', 
'-H ldapi:///', '-b cn=config'] failed with exit code 255: 
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
  CasperMD5CheckResult: skip
  Date: Wed Feb 15 06:54:50 2023
  ErrorMessage: installed slapd package post-installation script subprocess 
returned error exit status 1
  InstallationDate: Installed on 2022-02-20 (360 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-5.15.0-60-generic 
root=UUID=02b06a5b-7026-48f6-9745-993e04e5aba6 ro quiet splash
  Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3.2
   apt  2.0.9
  SourcePackage: openldap
  Title: package slapd 2.4.49+dfsg-2ubuntu1.9 failed to install/upgrade: 
installed slapd package post-installation script subprocess returned error exit 
status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.slapd: 2022-10-24T00:13:25.321836

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2007529/+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 2015380] Re: slapd crash when using pwdMinDelay of ppolicy

Fixed in 2.6.5 (upcoming release) by:
https://git.openldap.org/openldap/openldap/-/commit/f12d6c047c31c7b0009f10e3be05ae066bac61ac

Fixed in 2.5.15 (upcoming release) by:
https://git.openldap.org/openldap/openldap/-/commit/e765972f

** Also affects: openldap (Ubuntu Mantic)
   Importance: Medium
 Assignee: Sergio Durigan Junior (sergiodj)
   Status: New

** Also affects: openldap (Ubuntu Lunar)
   Importance: Undecided
   Status: New

** Also affects: openldap (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: openldap (Ubuntu Kinetic)
   Importance: Undecided
   Status: New

** Changed in: openldap (Ubuntu Jammy)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

** Changed in: openldap (Ubuntu Kinetic)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

** Changed in: openldap (Ubuntu Lunar)
 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 openldap in Ubuntu.
https://bugs.launchpad.net/bugs/2015380

Title:
  slapd crash when using pwdMinDelay of ppolicy

Status in openldap package in Ubuntu:
  New
Status in openldap source package in Jammy:
  New
Status in openldap source package in Kinetic:
  New
Status in openldap source package in Lunar:
  New
Status in openldap source package in Mantic:
  New

Bug description:
  Bug reported upstream[1], and confirmed in the mailing list[2].

  PR at [3].

  From the mailing list post[2], we can see that slapd crashes:
  """
  But if I test with a wrong password ( yyy) I got:
  root@zeus:/usr/lib/python3/dist-packages# ldapsearch -xLLLZZD
  uid=pauloric,ou=users,dc=contatogs,dc=com,dc=br -w yyy |wc -l
  ldap_result: Can't contact LDAP server (-1)
  0

  my openldap stop working.Active: inactive (dead)

  root@zeus:/usr/lib/python3/dist-packages# systemctl status -l slapd
  ○ slapd.service - LSB: OpenLDAP standalone server (Lightweight Director>
   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /usr/lib/systemd/system/slapd.service.d
   └─slapd-remain-after-exit.conf
   Active: inactive (dead) since Tue 2023-04-04 14:44:49 -03; 20s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 986673 ExecStart=/etc/init.d/slapd start (code=exited, sta>
  Process: 986688 ExecStop=/etc/init.d/slapd stop (code=exited, statu>
  CPU: 47ms
  """


  1. https://bugs.openldap.org/show_bug.cgi?id=10028
  2. 
https://lists.openldap.org/hyperkitty/list/openldap-techni...@openldap.org/thread/3LYIPMT6TYJM4C7NUFXVYJS7YMODB5ZH/
  3. https://git.openldap.org/openldap/openldap/-/merge_requests/609

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2015380/+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 2018093] Re: Merge openldap from Debian unstable for mantic

** Changed in: openldap (Ubuntu)
   Status: New => In Progress

** Merge proposal linked:
   
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/445156

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

Title:
  Merge openldap from Debian unstable for mantic

Status in openldap package in Ubuntu:
  In Progress

Bug description:
  Upstream: tbd
  Debian:   2.5.13+dfsg-52.6.4+dfsg-1~exp1
  Ubuntu:   2.6.3+dfsg-1~exp1ubuntu2


  Debian new has 2.6.4+dfsg-1~exp1, which may be available for merge
  soon.

  If it turns out this needs a sync rather than a merge, please change
  the tag 'needs-merge' to 'needs-sync', and (optionally) update the
  title as desired.

  
  ### New Debian Changes ###

  openldap (2.5.13+dfsg-5) unstable; urgency=medium

* Fix sha2-contrib autopkgtest failure. Call slappasswd using its full path.
  (Closes: #1030814)
* Disable flaky test test069-delta-multiprovider-starttls.

   -- Ryan Tandy   Tue, 07 Feb 2023 17:56:12 -0800

  openldap (2.5.13+dfsg-4) unstable; urgency=medium

[ Andreas Hasenack ]
* d/rules: Fix passwd/sha2 build (Closes: #1030716, LP: #2000817)
* d/t/sha2-contrib: add test for sha2 module

   -- Ryan Tandy   Mon, 06 Feb 2023 19:21:05 -0800

  openldap (2.5.13+dfsg-3) unstable; urgency=medium

[ Ryan Tandy ]
* Disable flaky test test063-delta-multiprovider. Mitigates #1010608.

[ Gioele Barabucci ]
* slapd.scripts-common: Avoid double-UTF8-encoding org name (Closes: 
#1016185)
* d/slapd.scripts-common: Remove outdated `migrate_to_slapd_d_style`
* d/slapd.postinst: Remove test for ancient version
* slapd.scripts-common: Remove unused `normalize_ldif`
* d/slapd.scripts-common: Use sed instead of perl in `release_diagnostics`

   -- Ryan Tandy   Fri, 13 Jan 2023 16:29:59 -0800

  openldap (2.5.13+dfsg-2) unstable; urgency=medium

* d/tests/smbk5pwd: Grant slapd access to /var/lib/heimdal-kdc. Fixes the
  autopkgtest failure due to heimdal setting mode 700 on this directory.
  (Closes: #1020442)
* d/source/lintian-overrides: Add wildcards to make overrides compatible
  with both older and newer versions of lintian.
* d/slapd-contrib.lintian-overrides: Remove unused
  custom-library-search-path override now that krb5-config no longer sets
  -rpath.

   -- Ryan Tandy   Sat, 24 Sep 2022 12:40:21 -0700

  openldap (2.5.13+dfsg-1) unstable; urgency=medium

* d/rules: Remove get-orig-source, now unnecessary.
* Check PGP signature when running uscan.
* d/watch: Modernize watch file; use repacksuffix.
* d/copyright: Update according to DEP-5.
* d/control: Add myself to Uploaders.
* New upstream release.

   -- Sergio Durigan Junior   Sun, 18 Sep 2022
  18:29:46 -0400

  openldap (2.5.12+dfsg-2) unstable; urgency=medium

* Stop slapd explicitly in prerm as a workaround for #1006147, which caused
  dpkg-reconfigure to not restart the service, so the new configuration was
  not applied. See also #994204. (Closes: #1010971)

   -- Ryan Tandy   Mon, 23 May 2022 10:14:53 -0700

  openldap (2.5.12+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Fixed SQL injection in back-sql (ITS#9815) (CVE-2022-29155)
* Update debconf translations:
  - German, thanks to Helge Kreutzmann. (Closes: #1007728)
  - Spanish, thanks to Camaleón. (Closes: #1008529)
  - Dutch, thanks to Frans Spiesschaert. (Closes: #1010034)

   -- Ryan Tandy   Wed, 04 May 2022 18:00:16 -0700

  openldap (2.5.11+dfsg-1) unstable; urgency=medium

* Upload to unstable.

   -- Ryan Tandy   Fri, 11 Mar 2022 19:38:02 -0800

  openldap (2.5.11+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Add openssl to Build-Depends to enable more checks in test067-tls.
* Update slapd-contrib's custom-library-search-path override to work with
  current Lintian.

   -- Ryan Tandy   Sun, 23 Jan 2022 17:16:05 -0800

  openldap (2.5.8+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Update slapd-contrib's custom-library-search-path override to work with
  Lintian 2.108.0.

   -- Ryan Tandy   Wed, 13 Oct 2021 18:42:55 -0700

  openldap (2.5.7+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Don't run autoreconf in contrib/ldapc++. We don't build it, and it is not


  ### Old Ubuntu Delta ###

  openldap (2.6.3+dfsg-1~exp1ubuntu2) lunar; urgency=medium

* Build the passwd/sha2 contrib module with -fno-strict-aliasing to
  avoid computing an incorrect SHA256 hash with some versions of the
  compiler (LP: #2000817):
  - d/t/{control,sha2-contrib}: test to verify the SHA256 hash
produced by passwd/sha2
  - d/rules: set -fno-strict-aliasing only when building the
passwd/sha2 contrib mod

[Touch-packages] [Bug 2016439] Re: Regression finding system certificates

2023-05-25 Thread Sergio Durigan Junior

All dep8 failures have been resolved.

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

Title:
  Regression finding system certificates

Status in curl package in Ubuntu:
  Fix Released
Status in curl source package in Lunar:
  Fix Committed
Status in curl source package in Mantic:
  Fix Released
Status in curl package in Debian:
  Fix Released

Bug description:
  [ Impact ]

  Users of applications that link against libcurl's NSS flavour might
  experience issues when trying to contact HTTPS servers.  This can lead
  to scenarios where the application is unable to connect.

  [ Test Plan ]

  First, let's verify that the GNUTLS flavour of libcurl does the right
  thing:

  $ lxc launch ubuntu-daily:lunar curl-bug2016439
  $ lxc shell curl-bug2016439
  # apt update && apt install -y libcurl4-gnutls-dev gcc
  # cat > curl-test.c << __EOF__
  #include 
  #include 
   
  int main(void)
  {
CURL *curl;
CURLcode res;
   
curl = curl_easy_init();
if(curl) {
  curl_easy_setopt(curl, CURLOPT_URL, "https://example.com;);
  /* example.com is redirected, so we tell libcurl to follow redirection */
  curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
   
  /* Perform the request, res will get the return code */
  res = curl_easy_perform(curl);
  /* Check for errors */
  if(res != CURLE_OK)
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
   
  /* always cleanup */
  curl_easy_cleanup(curl);
}
return 0;
  }
  __EOF__
  # gcc curl-test.c -o curl-test -lcurl
  # ./curl-test
 
 
  
   
  Example Domain
  ...
  #

  You should see the HTML dump of example.com.  Now, let's install the
  NSS flavour of libcurl and recompile the test program against it:

  # apt install -y libcurl4-nss-dev
  # gcc curl-test.c -o curl-test -lcurl
  # ./curl-test
  curl_easy_perform() failed: SSL peer certificate or SSH remote key was not OK

  As we can see, there was an error when validating the TLS certificate.

  [ Where problems could occur ]

  The adjustment needed to the downstream patch is pretty simple and has
  been tested extensively.  The original reporter mentioned that the
  issue did not happen before this patch was applied, so in the unlikely
  event of a regression the best route would be to revert the patch
  entirely.

  [ More Info ]

  This happens because of an error in one of our patches (authored by
  me) to teach libcurl where to properly find libnsspem.so and
  libnssckbi.so.  The problem is that libnsspem.so is installed under
  /usr/lib/$(DEB_HOST_ARCH)/nss/, while libnssckbi.so is installed under
  /usr/lib/$(DEB_HOST_ARCH)/, but I mistakenly pointed libcurl to look
  under the "/nss/" directory for both libraries.  As it turns out,
  libnssckbi.so is necessary in order to use the Mozilla's root
  certificate.

  [ Original Description ]

  [ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]

  Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
  nss looks for loadable libraries:

  curl (7.88.1-4) unstable; urgency=medium

    * d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
  Prepend "/nss/" before the library name.

  Before the change to the load path, curl could find
  /lib/x86_64-linux-gnu/libnssckbi.so but not
  /lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
  reverse.

  libnssckbi.so is enough to get a trust root (the mozilla certificate
  store is compiled inside that library), whereas libnsspem.so
  (1.0.8+1-1) isn't.
  This makes it impossible to connect to https servers by default for
  programs that use curl with NSS.

  Here is a way to test the regression:
  debbisect -v --cache=./cache \
     
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
  \
    20230306T145638Z 20230306T203828Z \
  'chroot "$1" bash -exuc "
  git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
  cd curl-rust
  time cargo fetch
  time cargo build --offline --example https
  strace -efile target/debug/examples/https >/dev/null
  "'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+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 2016439] Re: Regression finding system certificates

2023-05-12 Thread Sergio Durigan Junior

Verifying the bug for Lunar.

First, make sure we can reproduce the problem.  After following the
steps outlined in the Test Plan, we see:

# ./curl-test
curl_easy_perform() failed: SSL peer certificate or SSH remote key was not OK
# apt policy libcurl4-nss-dev
libcurl4-nss-dev:
  Installed: 7.88.1-8ubuntu1
  Candidate: 7.88.1-8ubuntu1
  Version table:
 *** 7.88.1-8ubuntu1 500
500 http://archive.ubuntu.com/ubuntu lunar/universe amd64 Packages
100 /var/lib/dpkg/status

Now, install libcurl4-nss-dev from -proposed and verify that the new
package fixes the issue:

# apt policy libcurl4-nss-dev
libcurl4-nss-dev:
  Installed: 7.88.1-8ubuntu2
  Candidate: 7.88.1-8ubuntu2
  Version table:
 *** 7.88.1-8ubuntu2 400
400 http://archive.ubuntu.com/ubuntu lunar-proposed/universe amd64 
Packages
100 /var/lib/dpkg/status
 7.88.1-8ubuntu1 500
500 http://archive.ubuntu.com/ubuntu lunar/universe amd64 Packages
# gcc curl-test.c -o curl-test -lcurl
# ./curl-test   
 
  
   
  
  
Example Domain

[Touch-packages] [Bug 2016439] Re: Regression finding system certificates

2023-05-12 Thread Sergio Durigan Junior

Thanks for the review and for accepting the SRU, Andreas.

The bug can be considered fixed in Mantic, although the change present
there is not exactly the same as the one I uploaded to Lunar (it still
uses $(DEB_HOST_ARCH) instead of $(DEB_TARGET_ARCH), and it
unnecessarily patches the load path for libnssckbi.so).

I'm a bit weary of introducing another delta to the package only to
address these minor details, so I will instead upload a small change to
the patch in Debian and later merge it into Mantic.

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

Title:
  Regression finding system certificates

Status in curl package in Ubuntu:
  Fix Released
Status in curl source package in Lunar:
  Fix Committed
Status in curl source package in Mantic:
  Fix Released
Status in curl package in Debian:
  Fix Released

Bug description:
  [ Impact ]

  Users of applications that link against libcurl's NSS flavour might
  experience issues when trying to contact HTTPS servers.  This can lead
  to scenarios where the application is unable to connect.

  [ Test Plan ]

  First, let's verify that the GNUTLS flavour of libcurl does the right
  thing:

  $ lxc launch ubuntu-daily:lunar curl-bug2016439
  $ lxc shell curl-bug2016439
  # apt update && apt install -y libcurl4-gnutls-dev gcc
  # cat > curl-test.c << __EOF__
  #include 
  #include 
   
  int main(void)
  {
CURL *curl;
CURLcode res;
   
curl = curl_easy_init();
if(curl) {
  curl_easy_setopt(curl, CURLOPT_URL, "https://example.com;);
  /* example.com is redirected, so we tell libcurl to follow redirection */
  curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
   
  /* Perform the request, res will get the return code */
  res = curl_easy_perform(curl);
  /* Check for errors */
  if(res != CURLE_OK)
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
   
  /* always cleanup */
  curl_easy_cleanup(curl);
}
return 0;
  }
  __EOF__
  # gcc curl-test.c -o curl-test -lcurl
  # ./curl-test
 
 
  
   
  Example Domain
  ...
  #

  You should see the HTML dump of example.com.  Now, let's install the
  NSS flavour of libcurl and recompile the test program against it:

  # apt install -y libcurl4-nss-dev
  # gcc curl-test.c -o curl-test -lcurl
  # ./curl-test
  curl_easy_perform() failed: SSL peer certificate or SSH remote key was not OK

  As we can see, there was an error when validating the TLS certificate.

  [ Where problems could occur ]

  The adjustment needed to the downstream patch is pretty simple and has
  been tested extensively.  The original reporter mentioned that the
  issue did not happen before this patch was applied, so in the unlikely
  event of a regression the best route would be to revert the patch
  entirely.

  [ More Info ]

  This happens because of an error in one of our patches (authored by
  me) to teach libcurl where to properly find libnsspem.so and
  libnssckbi.so.  The problem is that libnsspem.so is installed under
  /usr/lib/$(DEB_HOST_ARCH)/nss/, while libnssckbi.so is installed under
  /usr/lib/$(DEB_HOST_ARCH)/, but I mistakenly pointed libcurl to look
  under the "/nss/" directory for both libraries.  As it turns out,
  libnssckbi.so is necessary in order to use the Mozilla's root
  certificate.

  [ Original Description ]

  [ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]

  Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
  nss looks for loadable libraries:

  curl (7.88.1-4) unstable; urgency=medium

    * d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
  Prepend "/nss/" before the library name.

  Before the change to the load path, curl could find
  /lib/x86_64-linux-gnu/libnssckbi.so but not
  /lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
  reverse.

  libnssckbi.so is enough to get a trust root (the mozilla certificate
  store is compiled inside that library), whereas libnsspem.so
  (1.0.8+1-1) isn't.
  This makes it impossible to connect to https servers by default for
  programs that use curl with NSS.

  Here is a way to test the regression:
  debbisect -v --cache=./cache \
     
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
  \
    20230306T145638Z 20230306T203828Z \
  'chroot "$1" bash -exuc "
  git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
  cd curl-rust
  time cargo fetch
  time cargo build --offline --example https
  strace -efile target/debug/examples/https >/dev/null
  "'

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


-- 
Mailing list:

[Touch-packages] [Bug 2017434] Re: README.Debian.gz instructions for disabling socket activation inaccurate

2023-05-09 Thread Sergio Durigan Junior

** Changed in: openssh (Ubuntu)
   Status: Confirmed => Triaged

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

Title:
  README.Debian.gz instructions for disabling socket activation
  inaccurate

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  The documentation about how to roll back socket activation of sshd
  became inaccurate after version 1:9.0p1-1ubuntu4 when we started using
  a drop-in file to finalize activation rather than this being
  configured statically in ssh.service.  The drop-in file
  /etc/systemd/system/ssh.service.d/00-socket.conf must also be removed
  first.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2017434/+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 2018093] Re: Merge openldap from Debian unstable for mantic

2023-04-28 Thread Sergio Durigan Junior

** Changed in: openldap (Ubuntu)
 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 openldap in Ubuntu.
https://bugs.launchpad.net/bugs/2018093

Title:
  Merge openldap from Debian unstable for mantic

Status in openldap package in Ubuntu:
  New

Bug description:
  Upstream: tbd
  Debian:   2.5.13+dfsg-52.6.4+dfsg-1~exp1
  Ubuntu:   2.6.3+dfsg-1~exp1ubuntu2


  Debian new has 2.6.4+dfsg-1~exp1, which may be available for merge
  soon.

  If it turns out this needs a sync rather than a merge, please change
  the tag 'needs-merge' to 'needs-sync', and (optionally) update the
  title as desired.

  
  ### New Debian Changes ###

  openldap (2.5.13+dfsg-5) unstable; urgency=medium

* Fix sha2-contrib autopkgtest failure. Call slappasswd using its full path.
  (Closes: #1030814)
* Disable flaky test test069-delta-multiprovider-starttls.

   -- Ryan Tandy   Tue, 07 Feb 2023 17:56:12 -0800

  openldap (2.5.13+dfsg-4) unstable; urgency=medium

[ Andreas Hasenack ]
* d/rules: Fix passwd/sha2 build (Closes: #1030716, LP: #2000817)
* d/t/sha2-contrib: add test for sha2 module

   -- Ryan Tandy   Mon, 06 Feb 2023 19:21:05 -0800

  openldap (2.5.13+dfsg-3) unstable; urgency=medium

[ Ryan Tandy ]
* Disable flaky test test063-delta-multiprovider. Mitigates #1010608.

[ Gioele Barabucci ]
* slapd.scripts-common: Avoid double-UTF8-encoding org name (Closes: 
#1016185)
* d/slapd.scripts-common: Remove outdated `migrate_to_slapd_d_style`
* d/slapd.postinst: Remove test for ancient version
* slapd.scripts-common: Remove unused `normalize_ldif`
* d/slapd.scripts-common: Use sed instead of perl in `release_diagnostics`

   -- Ryan Tandy   Fri, 13 Jan 2023 16:29:59 -0800

  openldap (2.5.13+dfsg-2) unstable; urgency=medium

* d/tests/smbk5pwd: Grant slapd access to /var/lib/heimdal-kdc. Fixes the
  autopkgtest failure due to heimdal setting mode 700 on this directory.
  (Closes: #1020442)
* d/source/lintian-overrides: Add wildcards to make overrides compatible
  with both older and newer versions of lintian.
* d/slapd-contrib.lintian-overrides: Remove unused
  custom-library-search-path override now that krb5-config no longer sets
  -rpath.

   -- Ryan Tandy   Sat, 24 Sep 2022 12:40:21 -0700

  openldap (2.5.13+dfsg-1) unstable; urgency=medium

* d/rules: Remove get-orig-source, now unnecessary.
* Check PGP signature when running uscan.
* d/watch: Modernize watch file; use repacksuffix.
* d/copyright: Update according to DEP-5.
* d/control: Add myself to Uploaders.
* New upstream release.

   -- Sergio Durigan Junior   Sun, 18 Sep 2022
  18:29:46 -0400

  openldap (2.5.12+dfsg-2) unstable; urgency=medium

* Stop slapd explicitly in prerm as a workaround for #1006147, which caused
  dpkg-reconfigure to not restart the service, so the new configuration was
  not applied. See also #994204. (Closes: #1010971)

   -- Ryan Tandy   Mon, 23 May 2022 10:14:53 -0700

  openldap (2.5.12+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Fixed SQL injection in back-sql (ITS#9815) (CVE-2022-29155)
* Update debconf translations:
  - German, thanks to Helge Kreutzmann. (Closes: #1007728)
  - Spanish, thanks to Camaleón. (Closes: #1008529)
  - Dutch, thanks to Frans Spiesschaert. (Closes: #1010034)

   -- Ryan Tandy   Wed, 04 May 2022 18:00:16 -0700

  openldap (2.5.11+dfsg-1) unstable; urgency=medium

* Upload to unstable.

   -- Ryan Tandy   Fri, 11 Mar 2022 19:38:02 -0800

  openldap (2.5.11+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Add openssl to Build-Depends to enable more checks in test067-tls.
* Update slapd-contrib's custom-library-search-path override to work with
  current Lintian.

   -- Ryan Tandy   Sun, 23 Jan 2022 17:16:05 -0800

  openldap (2.5.8+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Update slapd-contrib's custom-library-search-path override to work with
  Lintian 2.108.0.

   -- Ryan Tandy   Wed, 13 Oct 2021 18:42:55 -0700

  openldap (2.5.7+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Don't run autoreconf in contrib/ldapc++. We don't build it, and it is not


  ### Old Ubuntu Delta ###

  openldap (2.6.3+dfsg-1~exp1ubuntu2) lunar; urgency=medium

* Build the passwd/sha2 contrib module with -fno-strict-aliasing to
  avoid computing an incorrect SHA256 hash with some versions of the
  compiler (LP: #2000817):
  - d/t/{control,sha2-contrib}: test to verify the SHA256 hash
produced by passwd/sha2
  - d/rules: set -fno-strict-aliasing only when building the
passwd/sha2 contrib module
* d/t/smbk5pwd: Allow the openldap user to read the Heimdal master key in 
the
  smbk5

[Touch-packages] [Bug 2016439] Re: Regression finding system certificates

** Description changed:

  [ Impact ]
  
  Users of applications that link against libcurl's NSS flavour might
  experience issues when trying to contact HTTPS servers.  This can lead
  to scenarios where the application is unable to connect.
  
  [ Test Plan ]
  
- TBD.
+ First, let's verify that the GNUTLS flavour of libcurl does the right
+ thing:
+ 
+ $ lxc launch ubuntu-daily:lunar curl-bug2016439
+ $ lxc shell curl-bug2016439
+ # apt update && apt install -y libcurl4-gnutls-dev gcc
+ # cat > curl-test.c << __EOF__
+ #include 
+ #include 
+  
+ int main(void)
+ {
+   CURL *curl;
+   CURLcode res;
+  
+   curl = curl_easy_init();
+   if(curl) {
+ curl_easy_setopt(curl, CURLOPT_URL, "https://example.com;);
+ /* example.com is redirected, so we tell libcurl to follow redirection */
+ curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
+  
+ /* Perform the request, res will get the return code */
+ res = curl_easy_perform(curl);
+ /* Check for errors */
+ if(res != CURLE_OK)
+   fprintf(stderr, "curl_easy_perform() failed: %s\n",
+   curl_easy_strerror(res));
+  
+ /* always cleanup */
+ curl_easy_cleanup(curl);
+   }
+   return 0;
+ }
+ __EOF__
+ # gcc curl-test.c -o curl-test -lcurl
+ # ./curl-test
+
 
+ 
+  
+ Example Domain
+ ...
+ #
+ 
+ You should see the HTML dump of example.com.  Now, let's install the NSS
+ flavour of libcurl and recompile the test program against it:
+ 
+ # apt install -y libcurl4-nss-dev
+ # gcc curl-test.c -o curl-test -lcurl
+ # ./curl-test
+ curl_easy_perform() failed: SSL peer certificate or SSH remote key was not OK
+ 
+ As we can see, there was an error when validating the TLS certificate.
  
  [ Where problems could occur ]
  
  The adjustment needed to the downstream patch is pretty simple and has
  been tested extensively.  The original reporter mentioned that the issue
  did not happen before this patch was applied, so in the unlikely event
  of a regression the best route would be to revert the patch entirely.
  
  [ More Info ]
  
  This happens because of an error in one of our patches (authored by me)
  to teach libcurl where to properly find libnsspem.so and libnssckbi.so.
  The problem is that libnsspem.so is installed under
  /usr/lib/$(DEB_HOST_ARCH)/nss/, while libnssckbi.so is installed under
  /usr/lib/$(DEB_HOST_ARCH)/, but I mistakenly pointed libcurl to look
  under the "/nss/" directory for both libraries.  As it turns out,
  libnssckbi.so is necessary in order to use the Mozilla's root
  certificate.
  
  [ Original Description ]
  
  [ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]
  
  Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
  nss looks for loadable libraries:
  
  curl (7.88.1-4) unstable; urgency=medium
  
    * d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
  Prepend "/nss/" before the library name.
  
  Before the change to the load path, curl could find
  /lib/x86_64-linux-gnu/libnssckbi.so but not
  /lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
  reverse.
  
  libnssckbi.so is enough to get a trust root (the mozilla certificate
  store is compiled inside that library), whereas libnsspem.so
  (1.0.8+1-1) isn't.
  This makes it impossible to connect to https servers by default for
  programs that use curl with NSS.
  
  Here is a way to test the regression:
  debbisect -v --cache=./cache \
     
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
  \
    20230306T145638Z 20230306T203828Z \
  'chroot "$1" bash -exuc "
  git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
  cd curl-rust
  time cargo fetch
  time cargo build --offline --example https
  strace -efile target/debug/examples/https >/dev/null
  "'

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

Title:
  Regression finding system certificates

Status in curl package in Ubuntu:
  In Progress
Status in curl package in Debian:
  Fix Released

Bug description:
  [ Impact ]

  Users of applications that link against libcurl's NSS flavour might
  experience issues when trying to contact HTTPS servers.  This can lead
  to scenarios where the application is unable to connect.

  [ Test Plan ]

  First, let's verify that the GNUTLS flavour of libcurl does the right
  thing:

  $ lxc launch ubuntu-daily:lunar curl-bug2016439
  $ lxc shell curl-bug2016439
  # apt update && apt install -y libcurl4-gnutls-dev gcc
  # cat > curl-test.c << __EOF__
  #include 
  #include 
   
  int main(void)
  {
CURL *curl;
CURLcode res;
   
curl = curl_easy_init();
if(curl) {
  curl_easy_setopt(curl, CURLOPT_URL, "https://example.com;);
  /* example.com is redirected,

[Touch-packages] [Bug 2016439] Re: Regression finding system certificates

** Description changed:

+ [ Impact ]
+
+ Users of applications that link against libcurl's NSS flavour might
+ experience issues when trying to contact HTTPS servers. This can lead
+ to scenarios where the application is unable to connect.
+
+ [ Test Plan ]
+
+ TBD.
+
+ [ Where problems could occur ]
+
+ The adjustment needed to the downstream patch is pretty simple and has
+ been tested extensively. The original reporter mentioned that the issue
+ did not happen before this patch was applied, so in the unlikely event
+ of a regression the best route would be to revert the patch entirely.
+
+ [ More Info ]
+
+ This happens because of an error in one of our patches (authored by me)
+ to teach libcurl where to properly find libnsspem.so and libnssckbi.so.
+ The problem is that libnsspem.so is installed under
+ /usr/lib/$(DEB_HOST_ARCH)/nss/, while libnssckbi.so is installed under
+ /usr/lib/$(DEB_HOST_ARCH)/, but I mistakenly pointed libcurl to look
+ under the "/nss/" directory for both libraries. As it turns out,
+ libnssckbi.so is necessary in order to use the Mozilla's root
+ certificate.
+
+ [ Original Description ]
+
[ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]

Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
nss looks for loadable libraries:

curl (7.88.1-4) unstable; urgency=medium

- * d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
- Prepend "/nss/" before the library name.
+ * d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
+ Prepend "/nss/" before the library name.

Before the change to the load path, curl could find
/lib/x86_64-linux-gnu/libnssckbi.so but not
/lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
reverse.

libnssckbi.so is enough to get a trust root (the mozilla certificate
store is compiled inside that library), whereas libnsspem.so
(1.0.8+1-1) isn't.
This makes it impossible to connect to https servers by default for
programs that use curl with NSS.

Here is a way to test the regression:
debbisect -v --cache=./cache \
-
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
+
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
\
- 20230306T145638Z 20230306T203828Z \
- 'chroot "$1" bash -exuc "
+ 20230306T145638Z 20230306T203828Z \
+ 'chroot "$1" bash -exuc "
git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
cd curl-rust
time cargo fetch
time cargo build --offline --example https
strace -efile target/debug/examples/https >/dev/null
"'

** Changed in: curl (Ubuntu)
Status: Triaged => In Progress

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

Title:
Regression finding system certificates

Status in curl package in Ubuntu:
In Progress
Status in curl package in Debian:
Fix Released

Bug description:
[ Impact ]

Users of applications that link against libcurl's NSS flavour might
experience issues when trying to contact HTTPS servers. This can lead
to scenarios where the application is unable to connect.

[ Test Plan ]

TBD.

[ Where problems could occur ]

The adjustment needed to the downstream patch is pretty simple and has
been tested extensively. The original reporter mentioned that the
issue did not happen before this patch was applied, so in the unlikely
event of a regression the best route would be to revert the patch
entirely.

[ More Info ]

This happens because of an error in one of our patches (authored by
me) to teach libcurl where to properly find libnsspem.so and
libnssckbi.so. The problem is that libnsspem.so is installed under
/usr/lib/$(DEB_HOST_ARCH)/nss/, while libnssckbi.so is installed under
/usr/lib/$(DEB_HOST_ARCH)/, but I mistakenly pointed libcurl to look
under the "/nss/" directory for both libraries. As it turns out,
libnssckbi.so is necessary in order to use the Mozilla's root
certificate.

[ Original Description ]

[ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]

Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
nss looks for loadable libraries:

curl (7.88.1-4) unstable; urgency=medium

* d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
Prepend "/nss/" before the library name.

Before the change to the load path, curl could find
/lib/x86_64-linux-gnu/libnssckbi.so but not
/lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
reverse.

[Touch-packages] [Bug 2015562] Re: Segfault in dnsmasq when using certain static domain entries + DoH (bugfix possibly exists upstream)

Kinetic doesn't seem to be affected.

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

Title:
  Segfault in dnsmasq when using certain static domain entries + DoH
  (bugfix possibly exists upstream)

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Jammy:
  Triaged

Bug description:
  Hi folks,

  I've been using dnsmasq for my home DNS needs, which includes
  returning null entries for certain domain queries. The specific case
  in which I found this segfault was returning null  records for
  Netflix (to ensure Netflix does not try to use my IPv6 tunnel to
  egress traffic through).

  I've been using very simple configuration snippet to achieve this,
  this is attached as netflix-nov6.conf (the full file contains more
  entries).

  Ever since I've upgraded from Ubuntu 20.04 to 22.04, dnsmasq kept
  segfaulting at random occasions. I also attempted do an apt
  update&, but there are no newer versions of this package
  available.

  Further research into this issue showed that a surefire way to trigger
  this segfault was to go to a website blocked via this method (for
  testing purposes, a dig query works quite well). The segfault can be
  reproduced reliably, and always occurs after one or a few queries
  towards the "blocked" domain entries.

  I found a commit in the upstream dnsmasq git repo which seems to fix this 
issue, the fix made it into 2.87:
  
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=de372d6914ae20a1f9997815f258efbf3b14c39b

  Would it be possible to backport this into the version used in the
  current LTS Ubuntu release? Thanks!

  --

  $ lsb_release -d
  Description:  Ubuntu 22.04.2 LTS
  $ apt-cache policy dnsmasq
  dnsmasq:
    Installed: 2.86-1.1ubuntu0.2
    Candidate: 2.86-1.1ubuntu0.2
    Version table:
   *** 2.86-1.1ubuntu0.2 500
  500 http://de.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 
Packages
  100 /var/lib/dpkg/status
   2.86-1.1ubuntu0.1 500
  500 http://de.archive.ubuntu.com/ubuntu jammy-security/universe amd64 
Packages
   2.86-1.1 500
  500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

  --

  Excerpt from the dnsmasq logs, with debugging enabled, after I loaded 
fast.com:
  Apr 07 13:47:41 budgie systemd[1]: Started dnsmasq - A lightweight DHCP and 
caching DNS server.
  Apr 07 13:47:42 budgie dnsmasq[109976]: query[type=65] 
fast.dradis.netflix.com from 192.168.10.82
  Apr 07 13:47:42 budgie dnsmasq[109976]: config error is REFUSED (EDE: network 
error)
  Apr 07 13:47:43 budgie dnsmasq[109976]: query[type=65] 
ichnaea-web.netflix.com from 192.168.10.82
  Apr 07 13:47:43 budgie systemd[1]: dnsmasq.service: Main process exited, 
code=dumped, status=11/SEGV
  Apr 07 13:47:43 budgie systemd[1]: dnsmasq.service: Failed with result 
'core-dump'.

  Core dump is also attached.

  Reproduction steps:
  - 1. Install dnsmasq on Ubuntu 22.04 (or any Ubuntu release using dnsmasq 
2.86)
  - 1.5. Configure one or multiple DNS servers for dnsmasq
  - 2. Copy netflix-nov6.conf into /etc/dnsmasq.d/
  - 3. Restart/reload dnsmasq
  - 3.5 Verify that dnsmasq resolves domains correctly:

  root@budgie:~# dig +short -tA ubuntu.com @127.0.0.1
  185.125.190.21
  185.125.190.20
  185.125.190.29
  root@budgie:~# dig +short -t ubuntu.com @127.0.0.1
  2620:2d:4000:1::28
  2620:2d:4000:1::26
  2620:2d:4000:1::27

  - 4. Perform a type65 / HTTPS recordtype query for netflix.com towards
  the dnsmasq server once or twice:

  root@budgie:~# dig +short -tTYPE65 netflix.com @127.0.0.1
  root@budgie:~# dig +short -tTYPE65 netflix.com @127.0.0.1
  ;; communications error to 127.0.0.1#53: timed out
  ;; communications error to 127.0.0.1#53: connection refused
  ;; communications error to 127.0.0.1#53: connection refused
  ;; no servers could be reached

  - 5. Check logs to verify segfault:

  Apr 07 14:03:28 budgie systemd[1]: Started dnsmasq - A lightweight DHCP and 
caching DNS server.
  Apr 07 14:03:32 budgie dnsmasq[111585]: query[type=65] netflix.com from 
127.0.0.1
  Apr 07 14:03:32 budgie dnsmasq[111585]: config error is REFUSED (EDE: network 
error)
  Apr 07 14:03:33 budgie dnsmasq[111585]: query[type=65] netflix.com from 
127.0.0.1
  Apr 07 14:03:33 budgie systemd[1]: dnsmasq.service: Main process exited, 
code=dumped, status=11/SEGV
  Apr 07 14:03:33 budgie systemd[1]: dnsmasq.service: Failed with result 
'core-dump'.

  --
  netflix-nov6.conf:
  # Null  response on these domains
  server=/netflix.com/#
  address=/netflix.com/::
  server=/netflix.net/#
  address=/netflix.net/::
  server=/nflxext.com/#
  address=/nflxext.com/::

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to

[Touch-packages] [Bug 2015562] Re: Segfault in dnsmasq when using certain static domain entries + DoH (bugfix possibly exists upstream)

I see that Miriam will work on this one (thanks!).

I was able to reproduce the issue (thank you Gordon for the great bug
description), and confirmed that it manifests on Jammy but is fixed in
Lunar.  I'm trying to reproduce it on Kinetic; will update the bug with
results once I have them.

** Also affects: dnsmasq (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: dnsmasq (Ubuntu Jammy)
   Status: New => Triaged

** Changed in: dnsmasq (Ubuntu Jammy)
 Assignee: (unassigned) => Miriam España Acebal (mirespace)

** Changed in: dnsmasq (Ubuntu)
   Status: New => Fix Released

** Changed in: dnsmasq (Ubuntu)
 Assignee: Miriam España Acebal (mirespace) => (unassigned)

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

Title:
  Segfault in dnsmasq when using certain static domain entries + DoH
  (bugfix possibly exists upstream)

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Jammy:
  Triaged

Bug description:
  Hi folks,

  I've been using dnsmasq for my home DNS needs, which includes
  returning null entries for certain domain queries. The specific case
  in which I found this segfault was returning null  records for
  Netflix (to ensure Netflix does not try to use my IPv6 tunnel to
  egress traffic through).

  I've been using very simple configuration snippet to achieve this,
  this is attached as netflix-nov6.conf (the full file contains more
  entries).

  Ever since I've upgraded from Ubuntu 20.04 to 22.04, dnsmasq kept
  segfaulting at random occasions. I also attempted do an apt
  update&, but there are no newer versions of this package
  available.

  Further research into this issue showed that a surefire way to trigger
  this segfault was to go to a website blocked via this method (for
  testing purposes, a dig query works quite well). The segfault can be
  reproduced reliably, and always occurs after one or a few queries
  towards the "blocked" domain entries.

  I found a commit in the upstream dnsmasq git repo which seems to fix this 
issue, the fix made it into 2.87:
  
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=de372d6914ae20a1f9997815f258efbf3b14c39b

  Would it be possible to backport this into the version used in the
  current LTS Ubuntu release? Thanks!

  --

  $ lsb_release -d
  Description:  Ubuntu 22.04.2 LTS
  $ apt-cache policy dnsmasq
  dnsmasq:
    Installed: 2.86-1.1ubuntu0.2
    Candidate: 2.86-1.1ubuntu0.2
    Version table:
   *** 2.86-1.1ubuntu0.2 500
  500 http://de.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 
Packages
  100 /var/lib/dpkg/status
   2.86-1.1ubuntu0.1 500
  500 http://de.archive.ubuntu.com/ubuntu jammy-security/universe amd64 
Packages
   2.86-1.1 500
  500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

  --

  Excerpt from the dnsmasq logs, with debugging enabled, after I loaded 
fast.com:
  Apr 07 13:47:41 budgie systemd[1]: Started dnsmasq - A lightweight DHCP and 
caching DNS server.
  Apr 07 13:47:42 budgie dnsmasq[109976]: query[type=65] 
fast.dradis.netflix.com from 192.168.10.82
  Apr 07 13:47:42 budgie dnsmasq[109976]: config error is REFUSED (EDE: network 
error)
  Apr 07 13:47:43 budgie dnsmasq[109976]: query[type=65] 
ichnaea-web.netflix.com from 192.168.10.82
  Apr 07 13:47:43 budgie systemd[1]: dnsmasq.service: Main process exited, 
code=dumped, status=11/SEGV
  Apr 07 13:47:43 budgie systemd[1]: dnsmasq.service: Failed with result 
'core-dump'.

  Core dump is also attached.

  Reproduction steps:
  - 1. Install dnsmasq on Ubuntu 22.04 (or any Ubuntu release using dnsmasq 
2.86)
  - 1.5. Configure one or multiple DNS servers for dnsmasq
  - 2. Copy netflix-nov6.conf into /etc/dnsmasq.d/
  - 3. Restart/reload dnsmasq
  - 3.5 Verify that dnsmasq resolves domains correctly:

  root@budgie:~# dig +short -tA ubuntu.com @127.0.0.1
  185.125.190.21
  185.125.190.20
  185.125.190.29
  root@budgie:~# dig +short -t ubuntu.com @127.0.0.1
  2620:2d:4000:1::28
  2620:2d:4000:1::26
  2620:2d:4000:1::27

  - 4. Perform a type65 / HTTPS recordtype query for netflix.com towards
  the dnsmasq server once or twice:

  root@budgie:~# dig +short -tTYPE65 netflix.com @127.0.0.1
  root@budgie:~# dig +short -tTYPE65 netflix.com @127.0.0.1
  ;; communications error to 127.0.0.1#53: timed out
  ;; communications error to 127.0.0.1#53: connection refused
  ;; communications error to 127.0.0.1#53: connection refused
  ;; no servers could be reached

  - 5. Check logs to verify segfault:

  Apr 07 14:03:28 budgie systemd[1]: Started dnsmasq - A lightweight DHCP and 
caching DNS server.
  Apr 07 14:03:32 budgie dnsmasq[111585]: query[type=65] netflix.com from 
127.0.0.1
  Apr 07 14:03:32 budgie dnsmasq[111585]: config error is REFUSED (EDE: network 
error)
  Apr 07

[Touch-packages] [Bug 2016439] Re: Regression finding system certificates

** Tags added: server-todo

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

Title:
  Regression finding system certificates

Status in curl package in Ubuntu:
  Triaged
Status in curl package in Debian:
  Fix Released

Bug description:
  [ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]

  Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
  nss looks for loadable libraries:

  curl (7.88.1-4) unstable; urgency=medium

* d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
  Prepend "/nss/" before the library name.

  Before the change to the load path, curl could find
  /lib/x86_64-linux-gnu/libnssckbi.so but not
  /lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
  reverse.

  libnssckbi.so is enough to get a trust root (the mozilla certificate
  store is compiled inside that library), whereas libnsspem.so
  (1.0.8+1-1) isn't.
  This makes it impossible to connect to https servers by default for
  programs that use curl with NSS.

  Here is a way to test the regression:
  debbisect -v --cache=./cache \
 
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
  \
20230306T145638Z 20230306T203828Z \
  'chroot "$1" bash -exuc "
  git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
  cd curl-rust
  time cargo fetch
  time cargo build --offline --example https
  strace -efile target/debug/examples/https >/dev/null
  "'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+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 2016439] Re: Regression finding system certificates

2023-04-17 Thread Sergio Durigan Junior

** Bug watch added: Debian Bug tracker #1034359
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359

** Also affects: curl (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359
   Importance: Unknown
   Status: Unknown

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

Title:
  Regression finding system certificates

Status in curl package in Ubuntu:
  Triaged
Status in curl package in Debian:
  Fix Released

Bug description:
  [ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]

  Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
  nss looks for loadable libraries:

  curl (7.88.1-4) unstable; urgency=medium

* d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
  Prepend "/nss/" before the library name.

  Before the change to the load path, curl could find
  /lib/x86_64-linux-gnu/libnssckbi.so but not
  /lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
  reverse.

  libnssckbi.so is enough to get a trust root (the mozilla certificate
  store is compiled inside that library), whereas libnsspem.so
  (1.0.8+1-1) isn't.
  This makes it impossible to connect to https servers by default for
  programs that use curl with NSS.

  Here is a way to test the regression:
  debbisect -v --cache=./cache \
 
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
  \
20230306T145638Z 20230306T203828Z \
  'chroot "$1" bash -exuc "
  git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
  cd curl-rust
  time cargo fetch
  time cargo build --offline --example https
  strace -efile target/debug/examples/https >/dev/null
  "'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+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 2016439] [NEW] Regression finding system certificates

2023-04-16 Thread Sergio Durigan Junior

Public bug reported:

[ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]

Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
nss looks for loadable libraries:

curl (7.88.1-4) unstable; urgency=medium

  * d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
Prepend "/nss/" before the library name.

Before the change to the load path, curl could find
/lib/x86_64-linux-gnu/libnssckbi.so but not
/lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
reverse.

libnssckbi.so is enough to get a trust root (the mozilla certificate
store is compiled inside that library), whereas libnsspem.so
(1.0.8+1-1) isn't.
This makes it impossible to connect to https servers by default for
programs that use curl with NSS.

Here is a way to test the regression:
debbisect -v --cache=./cache \
   
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
\
  20230306T145638Z 20230306T203828Z \
'chroot "$1" bash -exuc "
git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
cd curl-rust
time cargo fetch
time cargo build --offline --example https
strace -efile target/debug/examples/https >/dev/null
"'

** Affects: curl (Ubuntu)
 Importance: High
 Assignee: Sergio Durigan Junior (sergiodj)
 Status: Triaged

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

Title:
  Regression finding system certificates

Status in curl package in Ubuntu:
  Triaged

Bug description:
  [ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]

  Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
  nss looks for loadable libraries:

  curl (7.88.1-4) unstable; urgency=medium

* d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
  Prepend "/nss/" before the library name.

  Before the change to the load path, curl could find
  /lib/x86_64-linux-gnu/libnssckbi.so but not
  /lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
  reverse.

  libnssckbi.so is enough to get a trust root (the mozilla certificate
  store is compiled inside that library), whereas libnsspem.so
  (1.0.8+1-1) isn't.
  This makes it impossible to connect to https servers by default for
  programs that use curl with NSS.

  Here is a way to test the regression:
  debbisect -v --cache=./cache \
 
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
  \
20230306T145638Z 20230306T203828Z \
  'chroot "$1" bash -exuc "
  git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
  cd curl-rust
  time cargo fetch
  time cargo build --offline --example https
  strace -efile target/debug/examples/https >/dev/null
  "'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+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 2015380] Re: slapd crash when using pwdMinDelay of ppolicy

2023-04-05 Thread Sergio Durigan Junior

I'll see if I can work on this one tomorrow.

** Changed in: openldap (Ubuntu)
 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 openldap in Ubuntu.
https://bugs.launchpad.net/bugs/2015380

Title:
  slapd crash when using pwdMinDelay of ppolicy

Status in openldap package in Ubuntu:
  New

Bug description:
  Bug reported upstream[1], and confirmed in the mailing list[2].

  PR at [3].

  From the mailing list post[2], we can see that slapd crashes:
  """
  But if I test with a wrong password ( yyy) I got:
  root@zeus:/usr/lib/python3/dist-packages# ldapsearch -xLLLZZD
  uid=pauloric,ou=users,dc=contatogs,dc=com,dc=br -w yyy |wc -l
  ldap_result: Can't contact LDAP server (-1)
  0

  my openldap stop working.Active: inactive (dead)

  root@zeus:/usr/lib/python3/dist-packages# systemctl status -l slapd
  ○ slapd.service - LSB: OpenLDAP standalone server (Lightweight Director>
   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /usr/lib/systemd/system/slapd.service.d
   └─slapd-remain-after-exit.conf
   Active: inactive (dead) since Tue 2023-04-04 14:44:49 -03; 20s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 986673 ExecStart=/etc/init.d/slapd start (code=exited, sta>
  Process: 986688 ExecStop=/etc/init.d/slapd stop (code=exited, statu>
  CPU: 47ms
  """


  1. https://bugs.openldap.org/show_bug.cgi?id=10028
  2. 
https://lists.openldap.org/hyperkitty/list/openldap-techni...@openldap.org/thread/3LYIPMT6TYJM4C7NUFXVYJS7YMODB5ZH/
  3. https://git.openldap.org/openldap/openldap/-/merge_requests/609

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2015380/+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 2012140] Re: The documented DEFCCNAME is not the actual credential cache name

2023-03-22 Thread Sergio Durigan Junior

Thanks for taking the time to report the bug.

I am going to reassign the bug to sssd, and set its priority to low.
Feel free to file a bug against Debian's sssd package (which is where
this problem should be addressed, IMHO).  Thanks.

** Package changed: krb5 (Ubuntu) => sssd (Ubuntu)

** Changed in: sssd (Ubuntu)
   Status: New => Triaged

** Changed in: sssd (Ubuntu)
   Importance: Undecided => Low

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

Title:
  The documented DEFCCNAME is not the actual credential cache name

Status in sssd package in Ubuntu:
  Triaged
Status in krb5 package in Debian:
  Unknown

Bug description:
  The krb5 documentation says that DEFCCNAME is /tmp/krb5cc_%{uid}.  But
  actual credential cache file names look like:
  /tmp/krb5cc_127408622_wH2NwY

  Setting [libdefaults] default_ccache_name to krb5cc_%{uid} in
  /etc/krb5.conf produces the expected credential cache file.

  Unless you know this, using "mutiuser" in fstab with cifs/samba/smb
  mounts is nigh impossible.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: krb5-user 1.19.2-2ubuntu0.1
  ProcVersionSignature: Ubuntu 5.15.0-67.74-generic 5.15.85
  Uname: Linux 5.15.0-67-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Sat Mar 18 17:33:32 2023
  InstallationDate: Installed on 2023-03-09 (9 days ago)
  InstallationMedia: Ubuntu-Server 22.04.2 LTS "Jammy Jellyfish" - Release 
amd64 (20230217.1)
  ProcEnviron:
   SHELL=/bin/bash
   LANG=en_US.UTF-8
   TERM=xterm-256color
   PATH=(custom, no user)
  SourcePackage: krb5
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2012140/+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 2012140] Re: The documented DEFCCNAME is not the actual credential cache name

2023-03-20 Thread Sergio Durigan Junior

** Also affects: krb5 (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033164
   Importance: Unknown
   Status: Unknown

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

Title:
  The documented DEFCCNAME is not the actual credential cache name

Status in krb5 package in Ubuntu:
  New
Status in krb5 package in Debian:
  Unknown

Bug description:
  The krb5 documentation says that DEFCCNAME is /tmp/krb5cc_%{uid}.  But
  actual credential cache file names look like:
  /tmp/krb5cc_127408622_wH2NwY

  Setting [libdefaults] default_ccache_name to krb5cc_%{uid} in
  /etc/krb5.conf produces the expected credential cache file.

  Unless you know this, using "mutiuser" in fstab with cifs/samba/smb
  mounts is nigh impossible.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: krb5-user 1.19.2-2ubuntu0.1
  ProcVersionSignature: Ubuntu 5.15.0-67.74-generic 5.15.85
  Uname: Linux 5.15.0-67-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Sat Mar 18 17:33:32 2023
  InstallationDate: Installed on 2023-03-09 (9 days ago)
  InstallationMedia: Ubuntu-Server 22.04.2 LTS "Jammy Jellyfish" - Release 
amd64 (20230217.1)
  ProcEnviron:
   SHELL=/bin/bash
   LANG=en_US.UTF-8
   TERM=xterm-256color
   PATH=(custom, no user)
  SourcePackage: krb5
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/2012140/+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 2012119] Re: imageinfo fails in Ubuntu 23.04 with a "no such file or directory" error

2023-03-20 Thread Sergio Durigan Junior

Thank you for taking the time to file a bug report.

I did some investigation and noticed that the problem is actually with
imageinfo.

From imageinfo.c:

  filename = poptGetArg(poptctxt);
  if (poptGetArg(poptctxt) != NULL) {
fprintf(stderr, "imageinfo: must specify a single filename\n");
poptFreeContext(poptctxt);
exit(2);
  }
  poptFreeContext(poptctxt);
  if (!filename) {
fprintf(stderr, "imageinfo: must specify a filename\n");
exit(3);
  }

This excerpt is saving a pointer to the the "filename" string that's
found inside "poptctxt", but then it calls "poptFreeContext", which will
invoke "free" on that same string.

** Package changed: popt (Ubuntu) => imageinfo (Ubuntu)

** Changed in: imageinfo (Ubuntu)
   Status: New => Triaged

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

Title:
  imageinfo fails in Ubuntu 23.04 with a "no such file or directory"
  error

Status in imageinfo package in Ubuntu:
  Triaged

Bug description:
  imageinfo fails in Ubuntu 23.04 with a "no such file or directory"
  error, eg:

  $ imageinfo --size /usr/share/backgrounds/Lunar-lobster-side_by_Gixo-dark.png 
  imageinfo: unable to open image `��s��U': No such file or directory @ 
error/blob.c/OpenBlob/2924.

  $ imageinfo --size 
/usr/share/backgrounds/Copper_Mountain_by_Eduardo_Battaglia.jpg 
  imageinfo: unable to open image `�=�V': No such file or directory @ 
error/blob.c/OpenBlob/2924.

  The filename it complains is not found seems to be random and changes
  each time. Under WSL, it fails but just says "unable to open image `':
  No such file", ie it doesn't show the random text.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.04
  Package: imageinfo 0.04-0ubuntu12
  ProcVersionSignature: Ubuntu 6.1.0-16.16-generic 6.1.6
  Uname: Linux 6.1.0-16-generic x86_64
  ApportVersion: 2.26.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Mar 18 16:31:02 2023
  InstallationDate: Installed on 2021-09-28 (536 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Beta amd64 (20210924)
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  SourcePackage: imageinfo
  UpgradeStatus: Upgraded to lunar on 2023-03-16 (1 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/imageinfo/+bug/2012119/+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 2007272] Re: I have ubuntu 22.04 on my system and have the following vulnerability : CVE-2022-42898. On which release/path of Ubuntu can I expect them to be fixed ?

2023-03-20 Thread Sergio Durigan Junior

Thank you for taking the time to report a bug.

The CVE mentioned affects only 32-bit systems.  Are you running a samba
32-bit binary?  Are you on amd64?  If yes to both question, then this is
an unsupported scenario.

Thanks.

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

Title:
  I have ubuntu 22.04 on my system and have the following vulnerability
  : CVE-2022-42898.  On which release/path of Ubuntu can I expect them
  to be fixed ?

Status in heimdal package in Ubuntu:
  Confirmed

Bug description:
  I have ubuntu 22.04 on my system and it has the following
  vulnerability : CVE-2022-42898. Here is the link to the Ubuntu CVE
  link : https://ubuntu.com/security/CVE-2022-42898. On which
  version/patch of Ubuntu can I expect this to get fixed ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/2007272/+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 2011458] [NEW] ssh fails to rebind when it is killed with -HUP

2023-03-13 Thread Sergio Cazzolato

Public bug reported:

In kinetic and lunar gce images we are facing an issue when ssh is being killed 
with -HUP
SSH is failing to rebind port 22. It is not failing in other previous systems. 

It can be reproduced by running


# pkill -o -HUP sshd || true
# journalctl -n 20
Mar 13 14:58:52 mar131454-025105 sshd[1371]: Received SIGHUP; restarting.
Mar 13 14:58:52 mar131454-025105 sshd[1371]: error: Bind to port 22 on 0.0.0.0 
failed: Address already in use.
Mar 13 14:58:52 mar131454-025105 sshd[1371]: error: Bind to port 22 on :: 
failed: Address already in use.
Mar 13 14:58:52 mar131454-025105 sshd[1371]: fatal: Cannot bind any address.
Mar 13 14:58:52 mar131454-025105 systemd[1]: ssh.service: Main process exited, 
code=exited, status=255/EXCEPTION
Mar 13 14:58:52 mar131454-025105 systemd[1]: ssh.service: Failed with result 
'exit-code'.

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

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

Title:
  ssh fails to rebind when it is killed with -HUP

Status in openssh package in Ubuntu:
  New

Bug description:
  In kinetic and lunar gce images we are facing an issue when ssh is being 
killed with -HUP
  SSH is failing to rebind port 22. It is not failing in other previous 
systems. 

  It can be reproduced by running

  
  # pkill -o -HUP sshd || true
  # journalctl -n 20
  Mar 13 14:58:52 mar131454-025105 sshd[1371]: Received SIGHUP; restarting.
  Mar 13 14:58:52 mar131454-025105 sshd[1371]: error: Bind to port 22 on 
0.0.0.0 failed: Address already in use.
  Mar 13 14:58:52 mar131454-025105 sshd[1371]: error: Bind to port 22 on :: 
failed: Address already in use.
  Mar 13 14:58:52 mar131454-025105 sshd[1371]: fatal: Cannot bind any address.
  Mar 13 14:58:52 mar131454-025105 systemd[1]: ssh.service: Main process 
exited, code=exited, status=255/EXCEPTION
  Mar 13 14:58:52 mar131454-025105 systemd[1]: ssh.service: Failed with result 
'exit-code'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2011458/+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 2007625] Re: New upstream microrelease 2.5.14

2023-03-06 Thread Sergio Durigan Junior

As is usual with these MREs, the verification phase is considered done
when all dep8 tests pass.  This is now true for both Kinetic and Jammy
uploads.  Therefore, tagging the bug accordingly.

** Tags removed: verification-needed verification-needed-jammy 
verification-needed-kinetic
** Tags added: verification-done verification-done-jammy 
verification-done-kinetic

-- 
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:
  Invalid
Status in openldap source package in Jammy:
  Fix Committed
Status in openldap source package in Kinetic:
  Fix Committed

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:
    - kinetic: 
https://launchpad.net/~sergiodj/+archive/ubuntu/openldap/+build/25633699/+files/buildlog_ubuntu-kinetic-amd64.openldap_2.5.14+dfsg-0ubuntu0.22.10.1~ppa1_BUILDING.txt.gz
    - jammy: 
https://launchpad.net/~sergiodj/+archive/ubuntu/openldap/+build/25601017/+files/buildlog_ubuntu-jammy-amd64.openldap_2.5.14+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz

   * Bileto ticket: N/A (bileto is not working at the moment)

  [ 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 1988819] Re: When apt keeps back packages due to phased updates, it should list them separately

2023-03-03 Thread Sergio Callegari

After further investigation, I would say that "Discover" wants to
upgrade a package (libmm-glib0) notwithstanding the fact that it is
phased and that apt does not want to upgrade it.

Funny enough, Discover does not indicate the other phased packages (it
is up to 24!) as upgradable.

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

Title:
  When apt keeps back packages due to phased updates, it should list
  them separately

Status in apt package in Ubuntu:
  Triaged

Bug description:
  After phased updates have been introduced, it may happen that apt
  upgrade shows packages as upgradable but ends up not upgrading them.
  In this case the packages are indicated as being "kept back".

  Unfortunately, the feedback provided about this to the user is not
  very informative. The user sees the packages being kept back and
  thinks something is going wrong on the system.

  When packages are kept back because of phased updates, apt should say
  so e.g., it should say that the upgrade is delayed.

  Incidentally note that aptitude does not respect phased updates.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: apt 2.4.7
  ProcVersionSignature: Ubuntu 5.15.0-47.51-generic 5.15.46
  Uname: Linux 5.15.0-47-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: KDE
  Date: Tue Sep  6 10:05:14 2022
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2020-02-16 (933 days ago)
  InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: apt
  UpgradeStatus: Upgraded to jammy on 2022-06-03 (94 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1988819/+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 1988819] Re: When apt keeps back packages due to phased updates, it should list them separately

2023-03-03 Thread Sergio Callegari

There is a further problem, I do not know if it should be a separate
issue.

The updates icon in the system tray now appears also when there are in
fact no updates that can be applied. Don't know if this actually depends
on the presence of updates that are phased out or on the presence of
Ubuntu Pro (esm-apps) that are not enabled.

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

Title:
  When apt keeps back packages due to phased updates, it should list
  them separately

Status in apt package in Ubuntu:
  Triaged

Bug description:
  After phased updates have been introduced, it may happen that apt
  upgrade shows packages as upgradable but ends up not upgrading them.
  In this case the packages are indicated as being "kept back".

  Unfortunately, the feedback provided about this to the user is not
  very informative. The user sees the packages being kept back and
  thinks something is going wrong on the system.

  When packages are kept back because of phased updates, apt should say
  so e.g., it should say that the upgrade is delayed.

  Incidentally note that aptitude does not respect phased updates.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: apt 2.4.7
  ProcVersionSignature: Ubuntu 5.15.0-47.51-generic 5.15.46
  Uname: Linux 5.15.0-47-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: KDE
  Date: Tue Sep  6 10:05:14 2022
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2020-02-16 (933 days ago)
  InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: apt
  UpgradeStatus: Upgraded to jammy on 2022-06-03 (94 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1988819/+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 2007625] Re: New upstream microrelease 2.5.14

** Changed in: openldap (Ubuntu Kinetic)
   Status: New => In Progress

-- 
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:
  In Progress

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:
    - kinetic: 
https://launchpad.net/~sergiodj/+archive/ubuntu/openldap/+build/25633699/+files/buildlog_ubuntu-kinetic-amd64.openldap_2.5.14+dfsg-0ubuntu0.22.10.1~ppa1_BUILDING.txt.gz
    - jammy: 
https://launchpad.net/~sergiodj/+archive/ubuntu/openldap/+build/25601017/+files/buildlog_ubuntu-jammy-amd64.openldap_2.5.14+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz

   * Bileto ticket: N/A (bileto is not working at the moment)

  [ 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 2007625] Re: New upstream microrelease 2.5.14

I believe this addresses everything that was needed to move forward with
the MRE.  Let me know otherwise, and apologies for the half-baked MRE.

-- 
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:
    - kinetic: 
https://launchpad.net/~sergiodj/+archive/ubuntu/openldap/+build/25633699/+files/buildlog_ubuntu-kinetic-amd64.openldap_2.5.14+dfsg-0ubuntu0.22.10.1~ppa1_BUILDING.txt.gz
    - jammy: 
https://launchpad.net/~sergiodj/+archive/ubuntu/openldap/+build/25601017/+files/buildlog_ubuntu-jammy-amd64.openldap_2.5.14+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz

   * Bileto ticket: N/A (bileto is not working at the moment)

  [ 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 2007625] Re: New upstream microrelease 2.5.14

Update on Kinetic dep8 retriggers:

- balsa @ amd64: Passed.
- balsa @ arm64: Passed.

- dogtag-pki @ amd64: Passed.

- exim4 @ ppc64el: Passed.

-- 
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:
    - kinetic: 
https://launchpad.net/~sergiodj/+archive/ubuntu/openldap/+build/25633699/+files/buildlog_ubuntu-kinetic-amd64.openldap_2.5.14+dfsg-0ubuntu0.22.10.1~ppa1_BUILDING.txt.gz
    - jammy: 
https://launchpad.net/~sergiodj/+archive/ubuntu/openldap/+build/25601017/+files/buildlog_ubuntu-jammy-amd64.openldap_2.5.14+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz

   * Bileto ticket: N/A (bileto is not working at the moment)

  [ 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 2007625] Re: New upstream microrelease 2.5.14

Analysis of the dep8 failures in Jammy:

- cyrus-imapd @ amd64: Neutral in Jammy.

- libaws @ amd64: Failure is unrelated to openldap; triggered a 
migration-reference/0.
- libaws @ arm64: Failure is unrelated to openldap; triggered a 
migration-reference/0.
- libaws @ armhf: Failure is unrelated to openldap; triggered a 
migration-reference/0.
- libaws @ ppc64el: Failure is unrelated to openldap; triggered a 
migration-reference/0.
- libaws @ s390x: Failure is unrelated to openldap; triggered a 
migration-reference/0.

- nss-pam-ldapd @ arm64: Already failing in Jammy.

- pdns @ arm64: Already failing in Jammy.
- pdns @ armhf: Already failing in Jammy.
- pdns @ s390x: Already failing in Jammy.

- courier @ armhf: Neutral in Jammy.

- nss-pam-ldapd @ armhf: Already failing in Jammy.

- squid @ armhf: Already failing in Jammy.

- sudo @ armhf: Already failing in Jammy.

- kopanocore @ s390x: Already failing in Jammy.

-- 
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:
    - kinetic: 
https://launchpad.net/~sergiodj/+archive/ubuntu/openldap/+build/25633699/+files/buildlog_ubuntu-kinetic-amd64.openldap_2.5.14+dfsg-0ubuntu0.22.10.1~ppa1_BUILDING.txt.gz
    - jammy: 
https://launchpad.net/~sergiodj/+archive/ubuntu/openldap/+build/25601017/+files/buildlog_ubuntu-jammy-amd64.openldap_2.5.14+dfsg-0ubuntu0.22.04.1~ppa1_BUILDING.txt.gz

   * Bileto ticket: N/A (bileto is not working at the moment)

  [ 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 2007625] Re: New upstream microrelease 2.5.14