> This LGTM.

Thanks for the review, Athos.

> There is one space in line 2 of the changelog that would be nice to remove before uploading.

Ops, indeed.  Fixed.

> As for the changelog entries, I understand you put a lot of effort
> into filtering what should be added. Still, I believe we could come up
> with some algorithm for that. For instance, only including mentions to
> CVEs or bugs set to high in the upstream bug tracker. All the entries
> are in the upstream changelog anyway and it is being referenced in the
> package chagelog.

Yes, agreed.  I thought about only mentioning the CVE issue, but that's
moot since it's already been addressed by the Security team in a
previous upload.  I revisited the bugs fixed in this release and the
only one marked as high priority is this:

  https://bugs.openldap.org/show_bug.cgi?id=9584

I don't know if upstream worries too much about setting bug priorities
or not, so maybe we can't rely on this parameter.

I don't have a good answer for how to approach this problem right now.
For that reason, I'm going to postpone uploading this package until next
week.

> I also see you decided to pick debian's 2.5.12+dfsg-1 release instead of 2.5.12+dfsg-2 as a base for the merge.
> It was nice of you to reduce the amount of changes introduced in the
> MRE. You also explained offline that this specific change was only
> needed in debian since Ubuntu already has a fix in debconf. However,
> the next steps here would be to move this changes from Ubuntu to
> Debian to consolidate them there before the next MRE to avoid
> complications in a possible following merge.

Absolutely.

Dave Jones is already taking care of that here:

  https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/10
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006147

> Finally, since this was a merge from a specific Debian commit, I was
> wondering why you decided not to include a remaining changes
> section. It should be fine not to have one since this is not a
> traditional merge, but an MRE. Still, it would be nice to document
> "how developers should do things" in the MRE documentation page.

Thanks for bringing this up.  This prompted me into thinking more about
the changelog entry, and then I realized a misconception I was having
about the MRE.

Initially I thought that openldap was "special" because, aside from
doing the MRE the "standard way" (i.e., just grab the upstream tarball
and update the source package by hand with it), we could also merge the
package from Debian because they are also planning to stick with the
2.5.x series.

However, I noticed that openldap 2.5.x is actually just postgresql-14
right now: both packages get uploaded to Debian unstable as soon as
there's a new upstream microrelease.  For postgresql-14, we do our MREs
*without* merging the Debian package.  So I now believe that we should
do the same for openldap.

This would actually have a few benefits.  The first is that the MRE is
much easier: we really just need to grab the tarball and explode it on
top of the current version of the source package, then update the
patches and write a changelog entry for it.  The second benefit is that
we won't need to worry about changes that are made in the Debian package
and whether we want to have them MRE'd or not.  The third is that the
changelog entry becomes simpler: we just have to write about the
upstream changes, always.

We talked in private about this but I wanted to leave a record of my
thoughts.  I will likely abandon this MP and file a new one following
the regular MRE procedure.

Thanks again.