Bug#1071480: libldap: sends some IPv6 addresses as server name

[Ryan Tandy]

Control: tag -1 upstream moreinfo

Hi Elliott, thank you for investigating this issue and contributing a 
patch.


However, I tested your patch, and I'm not sure it's correct.

If the IPv6 address contains a letter a-f before the first colon, I 
think the code you changed is never reached. On seeing the first 
non-digit, we break the loop with numeric=0, and never reach the colon.


Have I missed something?

I would appreciate if you would pursue this issue upstream. If the fix 
needs further review or discussion with the upstream developers, I'd 
really rather not be a middleman in that conversation.


Thank you,
Ryan

Bug#1070031: heimdal-kdc: fails to install if /usr/bin/kadmin is not Heimdal kadmin

[Ryan Tandy]

Package: heimdal-kdc
Version: 7.8.git20221117.28daf24+dfsg-5
Severity: normal

Dear Maintainer,

I noticed that if the package krb5-user is installed, then heimdal-kdc 
fails to install, because /usr/bin/kadmin is the wrong one:

# apt install krb5-user
[...]
# ls -l /etc/alternatives/kadmin
lrwxrwxrwx 1 root root 19 Mar 27 03:42 /etc/alternatives/kadmin -> 
/usr/bin/kadmin.mit
# apt install heimdal-kdc
[...]
Setting up heimdal-kdc (7.8.git20221117.28daf24+dfsg-5+b1) ...
kstash: writing key to `/var/lib/heimdal-kdc/m-key'
kadmin: invalid option -- 'l'
Usage: kadmin [-r realm] [-p principal] [-q query] [clnt|local args]
  [command args...]
clnt args: [-s admin_server[:port]] [[-c ccache]|[-k [-t keytab]]]|[-n] 
[-O | -N]
local args: [-x db_args]* [-d dbname] [-e "enc:salt ..."] [-m] [-w 
password] where,
[-x db_args]* - any number of database specific arguments.
Look at each database documentation for supported 
arguments
dpkg: error processing package heimdal-kdc (--configure):
 installed heimdal-kdc package post-installation script subprocess returned 
error exit status 1

The MIT alternative has a slightly higher priority (30 vs 
heimdal-clients 23), so update-alternatives prefers it.

# update-alternatives --display kadmin
kadmin - auto mode
  link best version is /usr/bin/kadmin.mit
  link currently points to /usr/bin/kadmin.mit
  link kadmin is /usr/bin/kadmin
  slave kadmin.1.gz is /usr/share/man/man1/kadmin.1.gz
/usr/bin/kadmin.heimdal - priority 23
  slave kadmin.1.gz: /usr/share/man/man1/kadmin.heimdal.1.gz
/usr/bin/kadmin.mit - priority 30
  slave kadmin.1.gz: /usr/share/man/man1/kadmin.mit.1.gz

I guess the Heimdal maintainer scripts should call kadmin.heimdal 
explicitly. I have not checked whether any other commands are affected.

thank you,
Ryan

Bug#1065633: openldap: FTBFS on hppa - implicit declaration of function 'kadm5_s_init_with_password_ctx'

[Ryan Tandy]

On Fri, Mar 08, 2024 at 07:33:59PM -0800, Steve Langasek wrote:

This bug is also reproducible on the armel and armhf release archs as a
result of the time_t transition, so bumping this to serious.


ACK.


This does fix the build failure.  I was about to push such a change to the
repo and do a maintainer upload, since I've never been removed from the
uploaders field after all these years ;)  Do you want me to do this, or
would you be able to do it tonight?  Getting openldap to build is a priority
wrt rebootstrapping 32-bit archs for time_t.


I wasn't sure where openldap was on the priority list for arm* since 
it's still BD-Uninstallable on the buildds.


Yes, I can upload it tonight, in a couple of hours from now. Is that OK?


BTW there's also a reproducible test failure that I'm seeing on armhf in
both Debian and Ubuntu which is new; I'm not sure if it's related to time_t,
or if it affects other archs?


Starting test046-dds for mdb...

running defines.sh
Running slapadd to build slapd database...
Running slapindex to index slapd database...

WARNING!
Running as root!
There's a fair chance slapd will fail to start.
Check file permissions!

Starting slapd on TCP/IP port 9011...
Testing slapd searching...
Creating a dynamic entry...
ldapadd failed (255)!
../../../tests/scripts/test046-dds: 93: kill: No such process


test046-dds failed for mdb after 2 seconds

(exit 255)
make[4]: *** [Makefile:303: mdb-mod] Error 255


I have not seen this failure. Ran it again just now and it passed. But I 
only run amd64... I wouldn't be able to dig into that tonight, even if I 
could reproduce it. Do you think I should disable the test proactively?


thanks,
Ryan

Bug#1065633: openldap: FTBFS on hppa - implicit declaration of function 'kadm5_s_init_with_password_ctx'

[Ryan Tandy]

Would you be willing to test build the attached patch on hppa? I've 
tested it on amd64 with -Werror=implicit-function-declaration appended.


thanks,
Ryan
>From fa0b704371762bdc479a5d8dc6a0a6df4ec3a52e Mon Sep 17 00:00:00 2001
From: Ryan Tandy 
Date: Fri, 8 Mar 2024 17:58:15 -0800
Subject: [PATCH] Fix implicit declaration of kadm5_s_init_with_password_ctx

---
 debian/patches/series|  1 +
 debian/patches/smbk5pwd-implicit-declaration | 12 
 2 files changed, 13 insertions(+)
 create mode 100644 debian/patches/smbk5pwd-implicit-declaration

diff --git a/debian/patches/series b/debian/patches/series
index a8d57cb99c..7381d0a06b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -13,3 +13,4 @@ add-tlscacert-option-to-ldap-conf
 fix-build-top-mk
 switch-to-lt_dlopenadvise-to-get-RTLD_GLOBAL-set.diff
 set-maintainer-name
+smbk5pwd-implicit-declaration
diff --git a/debian/patches/smbk5pwd-implicit-declaration b/debian/patches/smbk5pwd-implicit-declaration
new file mode 100644
index 00..a704086286
--- /dev/null
+++ b/debian/patches/smbk5pwd-implicit-declaration
@@ -0,0 +1,12 @@
+Description: Fix implicit declaration of kadm5_s_init_with_password_ctx
+Bug-Debian: https://bugs.debian.org/1065633
+--- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c
 b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c
+@@ -45,6 +45,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #ifndef HDB_INTERFACE_VERSION
+ #define	HDB_MASTER_KEY_SET	master_key_set
-- 
2.39.2

Bug#1065633: openldap: FTBFS on hppa - implicit declaration of function 'kadm5_s_init_with_password_ctx'

[Ryan Tandy]

On Thu, Mar 07, 2024 at 01:29:54PM -0800, Ryan Tandy wrote:
The binNMUs succeeded on several release arches already. I'm not sure 
why hppa would be different. I see 
-Werror=implicit-function-declaration in its compiler commands, but I 
don't know where it's coming from.


I remembered later maybe seeing something about this around time64 build 
flags, and sure enough, in dpkg 1.22.5:


https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=ef90821fe45b99fa8c8c4279b9a74c30f59f491d

So actually it looks like hppa was only the first to encounter it, and 
armel/armhf are likely to fail the same way (right now they are still 
BD-Uninstallable), in which case this bug will be RC.

Bug#1065633: openldap: FTBFS on hppa - implicit declaration of function 'kadm5_s_init_with_password_ctx'

[Ryan Tandy]

The implicit declaration occurs on all arches, but it's a warning, not 
an error. For example on amd64:


smbk5pwd.c:917:23: warning: implicit declaration of function 
‘kadm5_s_init_with_password_ctx’; did you mean ‘kadm5_init_with_password_ctx’? 
[-Wimplicit-function-declaration]
  917 | ret = kadm5_s_init_with_password_ctx( context,
  |   ^~
  |   kadm5_init_with_password_ctx


The binNMUs succeeded on several release arches already. I'm not sure 
why hppa would be different. I see -Werror=implicit-function-declaration 
in its compiler commands, but I don't know where it's coming from.


As for the implicit declaration, I don't remember why I didn't already 
submit a patch for it... At a quick glance it looks like the prototype 
is now in the private header . I don't know if 
there's a reason we can't/shouldn't include that one... The symbol may 
be private, but we're already using it regardless :)

Bug#1062872: mgba: NMU diff for 64-bit time_t transition

[Ryan Tandy]

On Sun, Feb 04, 2024 at 07:38:06AM +0200, Graham Inggs wrote:

Is a MR against https://salsa.debian.org/vorlon/armhf-time_t the right
place to proceed?


Yes.


https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/131

Bug#1062872: mgba: NMU diff for 64-bit time_t transition

[Ryan Tandy]

Hi Graham,

Would it be possible to configure the analysis tool to skip the 
headers under /usr/include/mgba-util/platform/*/?


The appropriate platform header is included automatically by 
, in our case that's 
 and the other ones require 
various foreign SDK headers.


I'm testing a fix for libmgba-dev to not install the foreign headers, 
but in the mean time, I'm wondering if the analyzer could just skip 
those ones, since we know including them will fail.


Is a MR against https://salsa.debian.org/vorlon/armhf-time_t the right 
place to proceed?


Thanks
Ryan

Bug#1062872: mgba: NMU diff for 64-bit time_t transition

[Ryan Tandy]

Hi Graham,

Checking the reports quickly, it looks like mgba came up because the 
tool failed to analyze its headers, i.e.


https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libmgba-dev/base/log.txt

In file included from /tmp/dZv19vBzjS/dump1.h:151:
/usr/include/mgba-util/platform/3ds/3ds-vfs.h:11:10: fatal error: 3ds.h: No 
such file or directory
   11 | #include <3ds.h>
  |  ^~~

This is most likely just a bug in the -dev package. It looks like I've 
accidentally included too many headers - some of them are probably only 
used to build mgba itself, and this one in particular is for another 
platform entirely.


I will try to deal with this so that libmgba-dev can be analyzed 
properly, as I suspect it won't actually need a transition. What is the 
deadline for figuring this out?


Thanks
Ryan

Bug#1040382: slapd: debian12 ships with slapd-2.5.13+dfsg-5 which crashes (segfault in dynlist.la).

[Ryan Tandy]

Hello splge,

Can you confirm whether the slapd setup where you encountered this crash 
might have included a global/frontend instance of the dynlist overlay? 
If you still have the logs, can you show a crash report from dmesg?


See additional context quoted below. I would like to know for sure 
whether you and wouldsmina are talking about the same crash.


Thank you,
Ryan

On Wed, Jan 24, 2024 at 08:02:49AM -0800, Quanah Gibson-Mount wrote:



--On Wednesday, January 24, 2024 3:07 PM +0100 wouldsmina 
 wrote:





Hello,


I am experiencing the same issue. Here are the logs I obtain in the
syslog: 
2024-01-24T09:38:16.810558+01:00 ldap kernel: [ 1553.168747]
slapd[13335]: segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error
4 in dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0,
socket 2)
2024-01-24T09:38:16.810568+01:00 ldap kernel: [ 1553.168761] Code: 48 29
d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 10 02
00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39
73 64 74 09 45 84 e4 0f 85 22 03 00 00 48
2024-01-24T09:38:16.840012+01:00 ldap slapd[13342]: Stopping OpenLDAP:
slapd.


To reproduce, simply activate the dynlist module and try to make an LDAP
query. In slapd.conf add:

moduleload   dynlist
overlay dynlist


Likely .

--Quanah

Bug#1052265: ldap.conf.5: some remarks and editorial changes for this man page

[Ryan Tandy]

Control: tag -1 moreinfo

Hello Bjarni, thank you for your contribution.

The man page is maintained upstream. May I ask you to submit your 
changes directly to the OpenLDAP project? (It's better if you can do so 
yourself, than if I do it on your behalf.)


There is a guide for contributors: 
. They will probably ask 
you to format your patch as unified diff (diff -u) or a git branch.


Thanks again,
Ryan

On Tue, Sep 19, 2023 at 06:13:42PM +, Bjarni Ingi Gislason wrote:

Package: libldap-common
Version: 2.5.13+dfsg-5
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and editorial fixes for the manual.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

 nroff -man -t  > 
 nroff -man -t  > 
 diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z -t - "

instead of "nroff -man"

 Read the output of "diff -u" with "less -R" or similar.

-.-.

 If "man" (man-db) is used to check the manual for warnings,
the following must be set:

 The option "-warnings=w"

 The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

 or

 (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint ldap.conf.5":

mandoc: ldap.conf.5:1:2: ERROR: skipping insecure request: lf
mandoc: ldap.conf.5:30:2: WARNING: skipping paragraph macro: PP empty
mandoc: ldap.conf.5:69:61: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:71:58: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:72:58: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:75:61: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:104:9: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:107:10: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:118:9: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:121:65: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:122:65: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:125:1: WARNING: tab in filled text
mandoc: ldap.conf.5:129:1: WARNING: tab in filled text
mandoc: ldap.conf.5:162:2: WARNING: line scope broken: TP breaks TP
mandoc: ldap.conf.5:166:9: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:214:75: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:255:46: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:283:20: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:291:20: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:299:24: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:305:87: STYLE: input text line longer than 80 bytes: Do not 
perform rever...
mandoc: ldap.conf.5:308:88: STYLE: input text line longer than 80 bytes: The 
channel-binding ...
mandoc: ldap.conf.5:310:94: STYLE: input text line longer than 80 bytes: If 
OpenLDAP is built...
mandoc: ldap.conf.5:363:57: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:382:67: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:384:28: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:411:83: STYLE: input text line longer than 80 bytes: This 
parameter is ig...
mandoc: ldap.conf.5:417:83: STYLE: input text line longer than 80 bytes: This 
parameter is ig...
mandoc: ldap.conf.5:475:71: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:479:104: STYLE: input text line longer than 80 bytes: 
parameter to be set
mandoc: ldap.conf.5:530:2: ERROR: skipping insecure request: lf
mandoc: ldap.conf.5:535:62: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:536:2: ERROR: skipping insecure request: lf

-.-.

Input file is ldap.conf.5.

Remove space characters at the end of lines.

69:conventionally written in uppercase, although not required),
71:The value starts with the first non-blank character after
72:the option's name, and terminates at the end of the line,
75:for that option, if any.  Quoting values that contain blanks
104:.I LDAP
107:.B ldaps
118:.B name
121:is required, nor allowed; note that directory separators must be
122:URL-encoded, like any other characters that are special to URLs;
166:.I LDAP
214:may still apply any server-side limit on the amount of entries that can be
255:Specifies Cyrus SASL security properties. The
283:.B minssf=
291:.B maxssf=
299:.B maxbufsize=
363: should be a cipher specification for
382:With GnuTLS the available specs can be found in the manual page of
384:(see the description of the
475:Specifies if the Certificate Revocation List (CRL) of the CA should be
535:is derived from the University of Michigan LDAP 3.3 Release.

-.-.

Use "\e" to print the escape character instead of "\\" (which gets
interpreted in copy mode).

89: BASEou=IT staff,o=Example\\2C Inc,c=US

-.-.

Wrong distance between sentences.

 Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) 

Bug#1042795: bookworm-pu: package mgba/0.10.1+dfsg-1+deb12u1

[Ryan Tandy]

On Tue, Aug 01, 2023 at 09:03:43PM +0100, Jonathan Wiltshire wrote:

Please go ahead (your changelog should target bookworm).


Thanks, the package has been uploaded.

Bug#1040382: slapd: debian12 ships with slapd-2.5.13+dfsg-5 which crashes (segfault in dynlist.la).

[Ryan Tandy]

Control: tag -1 moreinfo

Hello, I'm sorry for the long delay in following up on this.

I'm looking at this issue and I don't see where any dynlist crash was 
reported or fixed upstream for 2.5.14.


Can you please explain how to trigger the crash, or point to the 
upstream issue where it was fixed? In order to fix the issue in 
bookworm, I will have to be able to reproduce and verify it myself.


Thank you,
Ryan

Bug#1042795: bookworm-pu: package mgba/0.10.1+dfsg-1+deb12u1

[Ryan Tandy]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

I would like to update mgba in bookworm with the following changes. Both 
bugs were introduced in mgba 0.10.0 and are thus regressions in 
bookworm. The patches are cherry-picks from mgba 0.10.2.

  * Import upstream patch to fix broken audio in libretro core.
(Closes: #1036829)

The bug subject says "Audio stutters horribly and sounds distorted". On 
my system, I just get no audio at all, with either gnome-games-app or 
retroarch as frontend. In any case, the patch is the only change to 
libretro code in 0.10.2, and does make audio work properly for me.

The short explanation of the bug is that the libretro core is maintained 
downstream (in a fork owned by the libretro folks), changes are pulled 
back to mgba upstream from time to time, and they missed one hunk during 
a resync. The patch simply restores the missing hunk of code.

I asked the submitter to test the proposed package, but they didn't 
respond.

  * Import upstream patch to fix crash on hardware incapable of OpenGL 3.2.

I actually have hardware (Intel GM45) affected by this, so I was able to 
verify it. Depending on configuration, mgba crashes either on startup, 
or when starting emulation. The patch restores support for older OpenGL 
implementations.

  * debian/gbp.conf: Set debian-branch to bookworm.

Hopefully self-explanatory.

The package does not have automated tests. I verified each fix with the 
libretro core and mgba-qt, and did some additional smoke testing to 
check for obvious regressions.

Thank you,
Ryan
diff -Nru mgba-0.10.1+dfsg/debian/changelog mgba-0.10.1+dfsg/debian/changelog
--- mgba-0.10.1+dfsg/debian/changelog   2023-01-15 10:33:17.0 -0800
+++ mgba-0.10.1+dfsg/debian/changelog   2023-06-26 16:51:44.0 -0700
@@ -1,3 +1,12 @@
+mgba (0.10.1+dfsg-1+deb12u1) UNRELEASED; urgency=medium
+
+  * Import upstream patch to fix broken audio in libretro core.
+(Closes: #1036829)
+  * Import upstream patch to fix crash on hardware incapable of OpenGL 3.2.
+  * debian/gbp.conf: Set debian-branch to bookworm.
+
+ -- Ryan Tandy   Mon, 26 Jun 2023 16:51:44 -0700
+
 mgba (0.10.1+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru mgba-0.10.1+dfsg/debian/gbp.conf mgba-0.10.1+dfsg/debian/gbp.conf
--- mgba-0.10.1+dfsg/debian/gbp.conf2023-01-15 10:33:17.0 -0800
+++ mgba-0.10.1+dfsg/debian/gbp.conf2023-06-26 16:51:44.0 -0700
@@ -1,5 +1,6 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = bookworm
 
 [pq]
 patch-numbers = False
diff -Nru 
mgba-0.10.1+dfsg/debian/patches/Libretro-Add-back-missing-audio-overkill-fixes-2734.patch
 
mgba-0.10.1+dfsg/debian/patches/Libretro-Add-back-missing-audio-overkill-fixes-2734.patch
--- 
mgba-0.10.1+dfsg/debian/patches/Libretro-Add-back-missing-audio-overkill-fixes-2734.patch
   1969-12-31 16:00:00.0 -0800
+++ 
mgba-0.10.1+dfsg/debian/patches/Libretro-Add-back-missing-audio-overkill-fixes-2734.patch
   2023-06-26 16:51:44.0 -0700
@@ -0,0 +1,56 @@
+From 71d1f122f9ecc0e4d85bf64a9fead6cdfc11dbd8 Mon Sep 17 00:00:00 2001
+From: Vicki Pfau 
+Date: Tue, 29 Nov 2022 02:20:02 -0800
+Subject: [PATCH] Libretro: Add back missing audio overkill (fixes #2734)
+
+---
+ src/platform/libretro/libretro.c | 33 
+ 1 file changed, 33 insertions(+)
+
+diff --git a/src/platform/libretro/libretro.c 
b/src/platform/libretro/libretro.c
+index 9bbd55ae6..2c0184d99 100644
+--- a/src/platform/libretro/libretro.c
 b/src/platform/libretro/libretro.c
+@@ -617,6 +617,39 @@ void retro_run(void) {
+   core->desiredVideoDimensions(core, , );
+   videoCallback(outputBuffer, width, height, BYTES_PER_PIXEL * 256);
+ 
++#ifdef M_CORE_GBA
++  if (core->platform(core) == mPLATFORM_GBA) {
++  blip_t *audioChannelLeft  = core->getAudioChannel(core, 0);
++  blip_t *audioChannelRight = core->getAudioChannel(core, 1);
++  int samplesAvail  = 
blip_samples_avail(audioChannelLeft);
++  if (samplesAvail > 0) {
++  /* Update 'running average' of number of
++   * samples per frame.
++   * Note that this is not a true running
++   * average, but just a leaky-integrator/
++   * exponential moving average, used because
++   * it is simple and fast (i.e. requires no
++   * window of samples). */
++  audioSamplesPerFrameAvg = 
(SAMPLES_PER_FRAME_MOVING_AVG_ALPHA * (float)samplesAvail) +
++  ((1.0f - 
SAMPLES_PER_FRAME_MOVING_AVG_ALPHA) * audioSamplesPerFrameAvg);
++  size_t samplesToRead = 
(size_t)(audioSamplesPerFrameAvg);
++  /* Resize audio output buffer, if required */
++  

Bug#976991: I am stepping up to help with the GnuTLS → OpenSSL switch in OpenLDAP

[Ryan Tandy]

On Wed, Jul 26, 2023 at 09:54:16AM +, John Scott wrote:
I'll write some TLS autopkgtests, we'll rebuild reverse dependencies 
and see how they fare, it'll be great.


That's an excellent first step, thanks for looking into it!

Regarding staging in experimental, Sergio currently uses that for 
merging new upstream versions into Ubuntu. Not raising that as a blocker 
per se, just to be aware that coordination might be appreciated.


I don't really expect issues with reverse dependencies. It'll be good to 
confirm, but I'd be surprised if any users of the library have 
significant issues. The things that really concern me are:


- does changing the TLS backend affect the ABI of libldap, requiring a 
  library transition (it "shouldn't", but sometimes things leak 
  unintentionally)


- determining how upgrades work for people who currently use 
  TLSCipherSuite or the equivalent slapd settings, and supporting them 
  through the transition (before and after trixie's release)


Thanks for taking steps to move this forward!

Bug#1040382: slapd: debian12 ships with slapd-2.5.13+dfsg-5 which crashes (segfault in dynlist.la).

[Ryan Tandy]

Hello, thanks for reporting the issue.

On Wed, Jul 05, 2023 at 11:49:13AM +0200, splge wrote:

openldap-2.5.14 (slapd-2.5.14) does not have this problem (i have compiled from 
source, installed and tested).

please consider to replace slapd-2.5.13 by slpad-2.5.14 in debian12.


I probably can't import the entire 2.5.14 release to Debian 12, but if 
we can identify the change that fixes the crash you're experiencing, I 
can cherry-pick that fix.


Can you please explain the how to trigger the crash? An example 
configuration would be helpful.


Thanks
Ryan

Bug#1036829: libretro-mgba: Audio stutters horribly and sounds distorted

[Ryan Tandy]

Hello,

I'm preparing an update for mgba in bookworm to fix this issue. Can I 
ask you to test the proposed package and confirm that it works for you?


On my system, the current bookworm package has no audio at all in 
retroarch, which is different from what you reported, so I'd like to be 
sure I've got the right patch.


You can find debs built for bookworm here:

https://salsa.debian.org/rtandy/mgba/-/jobs/4381339/artifacts/browse/debian/output/

with these changes:

https://salsa.debian.org/rtandy/mgba/-/compare/debian%2F0.10.1+dfsg-1...bookworm+ci

thanks,
Ryan

Bug#877512: slapd: enabled systemd integration (untested patch)

[Ryan Tandy]

On Wed, Jun 28, 2023 at 01:03:33PM -0700, Ryan Tandy wrote:
SLAPD_CONF is also used (at least) by anyone who still uses a 
slapd.conf file instead of cn=config. Using -f or -F depending on what 
SLAPD_CONF points to was the main reason I assumed we'd need a wrapper 
script. But that could also be replaced by a drop-in.


I remembered later that the maintainer scripts also need to know the 
location of the config, for upgrades. Currently they get it by reading 
SLAPD_CONF from /etc/default/slapd. Not sure whether it would be 
feasible to parse that out from the slapd command line in a systemd 
unit. Probably not in the general case... (but of course a determined 
person can find ways to break the current setup as well.)

Bug#877512: slapd: enabled systemd integration (untested patch)

[Ryan Tandy]

On Wed, Jun 28, 2023 at 08:48:14PM +0200, Moritz Mühlenhoff wrote:

OTOH, moving to the systemd unit might also be a good opportunity to reduce
some complexity? Looking at slapd.default shipped with the current package
SLAPD_SENTINEL_FILE, SLAPD_PIDFILE and SLAPD_NO_START are all settings which
are no longer relevant with a systemd unit or can equally be achieved with
commands built-in to systemd (e.g. systemctl mask).


Yes, definitely meaning to review and drop at least those, as well as 
migrating /var/run/slapd to tmpfiles.d.



Then there's a handful of settings which IMHO probably very people actually 
modify
(SLAPD_USER, SLAPD_USER, SLAPD_CONF, SLAPD_SERVICES) and which folks wanting
to modify can always tweak with a local unit override/dropins.


Hmm. So on upgrade I suppose we would want to automatically migrate 
those settings to a drop-in? That actually sounds doable; such a drop-in 
would probably not have to be a conffile.


SLAPD_CONF is also used (at least) by anyone who still uses a slapd.conf 
file instead of cn=config. Using -f or -F depending on what SLAPD_CONF 
points to was the main reason I assumed we'd need a wrapper script. But 
that could also be replaced by a drop-in.



The most commonly used option is probably SLAPD_OPTIONS, which could also
be read via an EnvironmentFile from /etc/default.


Right. Although if that's the only thing still being consumed, I'd be 
tempted to just let it go too. :)


Another (lower priority) thing I meant to look into is the sd_notify(3) 
support. Enabling that means changing the service type and adding the -d 
flag to stop slapd from detaching.


Thanks for the input, it really does help. :)

Ryan

Bug#877512: slapd: enabled systemd integration (untested patch)

[Ryan Tandy]

On Wed, Jun 28, 2023 at 06:29:31PM +0200, Andreas Henriksson wrote:

I'm attaching a patch which has only been compile-tested as I don't
use slapd myself. It would be great if someone who uses slapd could
pick it up, test it and finish the remaining work.


Thanks for the patch and for doing the compile-testing. Unfortunately 
upstream's service file won't work for us as is. The remaining work 
includes (and this is the part I've been procrastinating) extracting 
from the init script the parts that determine the arguments to slapd 
(based on config from /etc/default/slapd, and I think in some cases 
possibly from the slapd config too), and turning that into a slapd 
launcher script that the service will have to invoke.



TODO: For unknown reason configure seems to want to use
/usr/lib/systemd/system (rather than /lib/systemd/system) despite the
precense of systemd.pc ... the configure script has hard-coded fallback
paths...


Thanks for noting this, definitely sounds like something we need to look 
into.


thanks,
Ryan

Bug#1036995: openldap: CVE-2023-2953

[Ryan Tandy]

Hi, thanks for the report. If I've understood the issue correctly 
(DoS/crash if malloc fails), it does not look too urgent.


Although the fixes look safe enough, I think we could wait until after 
bookworm is released, and fix this in unstable first and in a point 
release later. Does that sound OK to you?


thanks,
Ryan

Bug#1036829: libretro-mgba: Audio stutters horribly and sounds distorted

[Ryan Tandy]

Hi, thanks for the report. I don't think I'll be able to get this fix 
into the initial Bookworm release, but we can most likely get it 
addressed in the first point release.

Bug#1030814: openldap: autopkgtest regression

[Ryan Tandy]

Hi, thanks for reporting.

On Tue, Feb 07, 2023 at 07:25:31PM +0200, Adrian Bunk wrote:

/tmp/autopkgtest-lxc.jrj8ozx8/downtmp/build.7fx/src/debian/tests/sha2-contrib: 
line 6: slappasswd: command not found


The dependency is definitely installed so it must be a PATH issue. Maybe 
because this test doesn't require root... Worked for me locally (qemu 
backend) so I'm a little surprised debci is different.  Will fix ASAP.

Bug#1030716: openldap: password/sha2 produces incorrect SHA256

[Ryan Tandy]

Thanks for the patch and info.

One additional data point: openldap 2.5.13 in bullseye-backports (gcc 
10.2.1-6) seems to be OK.


I looked briefly at the assembly with/without -fno-strict-aliasing and 
noted a difference somewhere around sha2.c:609. It doesn't look 
obviously wrong to me -- buffer is an array of uint8_t, which AFAIK 
should be aliasing-safe...


The freeze is near and I don't have time for further investigation right 
now, so for now I'm just uploading your patch (with the autopkgtest 
marked superficial). Thanks a lot for providing the patch.


Thanks
Ryan

Bug#1030716: openldap: password/sha2 produces incorrect SHA256

[Ryan Tandy]

Hi Andreas. Thanks for forwarding the bug.

Were you able to determine whether this is a bug in the module or in the 
compiler? -fno-strict-aliasing sounds like more of a workaround, is that 
correct?


Thanks
Ryan

Bug#877512: systemd unit for slapd

[Ryan Tandy]

On Mon, Jan 30, 2023 at 03:14:09AM +0100, Chris Hofstaedtler wrote:

Hello Ryan,


Hi,


* Ryan Tandy  [19 Feb 2019 08:42:24]:

On Tue, Feb 19, 2019 at 09:27:29AM +0100, Karsten Heymann wrote:
> any news on this? Having a proper systemd unit for slapd would be quite nice.

Not for buster, I'm afraid.


Maybe for bookworm, then?


Sorry I didn't get to it for bookworm. :(

I'm trying to get out of being responsible for this package (RFH 
#512360) and not doing much with it beyond minimal updating/RC-fixing.


This would be a good ticket for a new maintainer to work on.

Bug#1010608: openldap: Flaky test test063-delta-multiprovider

[Ryan Tandy]

Control: severity -1 important

On Wed, Dec 28, 2022 at 10:32:30PM +0100, Paul Gevers wrote:
Then not running the script at all is an improvement over the current 
situation. Flaky tests are bad. Until a better solution is found, how 
about skipping the test?


I have uploaded -3 with the flaky test disabled. I'm downgrading the 
bug, but not closing it right now - I'm still optimistic about finding a 
proper solution (likely not for bookworm, though).

Bug#1010608: openldap: Flaky test test063-delta-multiprovider

[Ryan Tandy]

On Wed, Dec 28, 2022 at 10:32:30PM +0100, Paul Gevers wrote:
Then not running the script at all is an improvement over the current 
situation. Flaky tests are bad. Until a better solution is found, how 
about skipping the test?


Not ideal, but yeah, probably an improvement over shipping a flaky test 
in stable. Thanks for the reminder, I'll try to upload it soon.

Bug#1025815: maintainerscripts choke on debconf-set-selection set input

[Ryan Tandy]

Hi Marc, thanks for the report, and sorry for the slow response.

On Fri, Dec 09, 2022 at 08:15:29PM +0100, Marc Haber wrote:

Nevetheless, openldap should be able to reconfigure itself after the
Debconf database is preseeded with a string that came out of
debconf-get-selections.


The original file appears to have its columns separated by multiple 
space characters [1].


On my systems, the output from debconf-get-selections has columns 
separated by one tab character [2]. The debconf-set-selections man page 
also specifies that the columns should be "separated by one character of 
whitespace".


I'm wondering if your file had its tabs converted to spaces at some 
point.


You're right that the older slapd package does accept that input. I 
haven't figured out exactly what changed.


[1] curl 
https://salsa.debian.org/sudo-team/sudo/-/raw/e9b19ee70d8b0ac9604b2cb645d32acd5a1fa5e2/debian/tests/03/ldif/debconf
 | hexdump -C
[2] debconf-get-selections | grep slapd | hexdump -C

thanks,
Ryan

Bug#1023855: TOTP module not enabled in slapd-contrib

[Ryan Tandy]

Hi Kees,

On Tue, Nov 22, 2022 at 11:14:43AM +0100, Kees Meijs wrote:
Unfortunately I didn't have time earlier, but I just managed to 
install a new virtual machine using bookworm. After installing both 
the slapd and slapd-contrib packages, I do not see the TOTP module.


So no, it seems not to be included.


Sorry if I wasn't clear. I agree the contrib totp module is not built.

The slapd-otp(5) module, however, is:

# dpkg-query -W slapd
slapd   2.5.13+dfsg-2+b1
# dpkg-query -L slapd | grep otp
/usr/lib/ldap/otp-2.5.so.0.1.8
/usr/lib/ldap/otp.la
/usr/share/man/man5/slapo-otp.5.gz
/usr/lib/ldap/otp-2.5.so.0
/usr/lib/ldap/otp.so

My understanding is that slapd-otp(5) supersedes and obsoletes the 
contrib module, providing a superset of its features (the man page 
mentions both TOTP and HMAC). That's why I asked if it meets your needs, 
or if you specifically need the contrib totp module. I'm not keen on 
shipping both unless there's a convincing reason.


thanks, and sorry for the back-and-forth,
Ryan

Bug#1024057: slapd: service restart does not always restart slapd

[Ryan Tandy]

Hi Mike,

Sorry, I should have been more explicit. What I'm really looking for is 
journal output (journalctl -u slapd.service) or equivalent from the 
actual restart event. Specifically anything showing why slapd fails to 
restart, or any errors are emitted during the attempted restart.


thanks,
Ryan

Bug#1024057: slapd: service restart does not always restart slapd

[Ryan Tandy]

Control: tag -1 moreinfo

Hi Mike, thanks for reporting this.

Can you elaborate about the failures you're seeing, or share any logs?

On Mon, Nov 14, 2022 at 08:12:08AM +, Mike Gabriel wrote:
Unfortunately, I don't have any Debian testing systems in the field 
with a similar setup, but I assume that the fix is still present for 
slapd in bookworm, unless the issue has been explicitly addressed 
already.


^^^ I assume you mean "the *issue* is still present" and yes, I'd assume 
the same.


thanks,
Ryan

Bug#1023855: TOTP module not enabled in slapd-contrib

[Ryan Tandy]

Hi Kees,

I've been reminded that in 2.5 the slapo-otp(5) module (supports both 
TOTP and HMAC) was added, and we already ship that one in bookworm's 
slapd package.


https://manpages.debian.org/bookworm/slapd/slapo-otp.5.en.html

Could you please check whether slapo-otp(5) meets your needs?

thanks,
Ryan

Bug#1023855: TOTP module not enabled in slapd-contrib

[Ryan Tandy]

Control: severity -1 wishlist

On Fri, Nov 11, 2022 at 03:05:48PM +0100, Kees Meijs wrote:

Could you please enable the plugin to be built?


Will do. Thanks for putting in the request.

Bug#1020442: heimdal breaks openldap autopkgtest: test smbk5pwd

[Ryan Tandy]

Thanks for raising the bug. The slapd autopkgtest does a chgrp/chmod to 
grant slapd access to the heimdal master key, but the permissions on the 
containing directory (/var/lib/heimdal-kdc) became more restrictive (now 
700). I will update the autopkgtest ASAP.

Bug#1010971:

[Ryan Tandy]

Control: reassign -1 slapd 2.5.12+dfsg-1
Control: affects -1 src:sssd
Control: forcemerge -1 1010678

Thanks Andreas for providing the additional details here. I'm aware of 
the problem and will upload openldap with a workaround ASAP. I had not 
seen Dave's MR for debconf, though; thanks for that.


Merging with #1010678. I had also opened #1010677 against debhelper, 
which I guess I will close once debconf is fixed.

Bug#1010608: openldap: Flaky test test063-delta-multiprovider

[Ryan Tandy]

Control: tag -1 help

Hi Adrian,

On Thu, May 05, 2022 at 02:54:14PM +0300, Adrian Bunk wrote:

https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/openldap_2.5.11+dfsg-1.rbuild.log.gz


I'm afraid this link has been superseded by the new upload (which built 
successfully & reproducibly). Just to confirm, you're saying that it 
failed for the same reason as the amd64 build?



Using ldapadd to populate server 2...
Using ldapsearch to read all the entries from server 1...
Using ldapsearch to read all the entries from server 2...
Using ldapsearch to read all the entries from server 3...
Using ldapsearch to read all the entries from server 4...
Comparing retrieved entries from server 1 and server 2...
Comparing retrieved entries from server 1 and server 3...
test failed - server 1 and server 3 databases differ


I looked at this script, and I think I see how this part might be 
fragile: *if* I'm reading correctly, it waits for server 1 to receive 
the changes, but then I think it proceeds with the comparison 
immediately, and could fail if server 3 or 4 was slower.


https://git.openldap.org/openldap/openldap/-/blob/master/tests/scripts/test063-delta-multiprovider#L309-359

This is also different from the previous section (lines 264-294) which 
waits a flat $SLEEP1 seconds (default: 7) for changes to be synced.


However I'm not comfortable proposing changes to the script if I can't 
validate them. I could really use some help figuring out how to 
reproduce this failure. I would need to have just server 3 or 4 affected 
by some slowdown - and not sure what kind, whether CPU or network or 
disk. I guess I'll start by seeing if I can use tc to add latency to 
just the specific port...


thanks,
Ryan

Bug#1010679: golang-openldap: should this package be removed?

[Ryan Tandy]

Source: golang-openldap
Version: 0.2-2
Severity: serious
Tags: bookworm sid

Dear Go team,

I recently opened an RC bug against golang-openldap (#1007217). Rather 
than fixing the bug, I am wondering if golang-openldap should just be 
removed from Debian:


- It's an old library with no reverse-dependencies in the archive;
- Upstream has stopped development (last release in 2012, last commit in 
  2016);

- The package has been orphaned since 2016 (#836498);
- It looks like an actively maintained alternative exists: 
  golang-github-go-ldap-ldap.


thanks,
Ryan

Bug#1010678: slapd: dpkg-reconfigure doesn't restart slapd

[Ryan Tandy]

Package: slapd
Version: 2.5.12+dfsg-1
Severity: serious
Control: affects -1 src:sssd

The last upload of openldap is affected by #1010677 in debhelper: 
"dpkg-reconfigure slapd" doesn't restart slapd and the config reset 
isn't applied.


In addition to users' expectations, this breaks (at least) the 
autopkgtest of sssd, which uses dpkg-reconfigure to reset the 
configuration to a known starting point.

Bug#1010677: debhelper: dpkg-reconfigure doesn't restart --no-restart-after-upgrade services

[Ryan Tandy]

Package: debhelper
Version: 13.7.1
Control: affects -1 slapd

Hi Niels, hi Dave (in X-D-CC),

In #994204, Dave wrote:

I think it may be preferable to instead move the stop behaviour to the 
"preinst" script of the *new* version of the package so that both stop 
and start behaviours are encapsulated in a *single* version of the 
package (and hence can be freely moved between). This also means that 
"postinst" script's prior behaviour can be restored.


There's one issue with this: dpkg-reconfigure. It runs these scripts:

1. prerm upgrade
2. config reconfigure
3. postinst configure

The autoscripts now stop the service in "prerm remove" and "preinst 
upgrade". Unfortunately this means dpkg-reconfigure no longer 
restarts the service and the config changes are not applied.


I don't know what to suggest. I like Dave's solution for upgrades. Maybe 
dpkg-reconfigure should also run "preinst upgrade"? but I'm reluctant to 
suggest any change there, since its current behaviour has been stable 
for almost 20 years...


thanks,
Ryan

Bug#1008951: openldap FTBFS on musl-linux-any: conflicting declaration of calloc

[Ryan Tandy]

Control: tag -1 upstream moreinfo

Hi Helmut,

Thanks for the analysis and patch, and sorry for the slow response.

Has this been reported upstream yet? I searched and didn't find this 
specific issue, but it looks like upstream have fixed at least two other 
musl-specific issues recently [ITS#9648, ITS#9650].


Before applying a patch for this in Debian, I'd at least like to know 
whether and how upstream intend to address the issue. I'd rather not 
take a patch if it has no future upstream.


thanks,
Ryan

[ITS#9648]: https://bugs.openldap.org/show_bug.cgi?id=9648
[ITS#9650]: https://bugs.openldap.org/show_bug.cgi?id=9650

Bug#1008021: bind9: unused build-dependency on libldap2-dev

[Ryan Tandy]

Source: bind9
Version: 1:9.18.1-1
Severity: minor

Dear Maintainer,

I think bind9's build-dependency on libldap2-dev is unused.

As far as I can tell, it was added to support the dlz-ldap module:

https://salsa.debian.org/dns-team/bind9/-/commit/dcc91657062f34b22cceaceaac176e3d445770e9#58ef006ab62b83b4bec5d81fe5b32c3b4c2d1cc2

However, building the dlz modules seems to be disabled since 2011:

https://salsa.debian.org/dns-team/bind9/-/commit/6c6fcc660cb7be94857f42979bbae5558c7a4486

The current binary packages have no dependency on libldap, and I didn't 
find the word "ldap" in their contents, except for the apparmor profile 
and some documentation.

The package builds successfully with libldap2-dev dropped. The build is 
not reproducible (for other reasons) so I couldn't easily check whether 
the results were identical.

thanks,
Ryan

Bug#1007973: usbguard: Unused build-dependency on libldap2-dev

[Ryan Tandy]

Source: usbguard
Version: 1.0.0+ds-2
Severity: minor

Dear Maintainer,

usbguard's build-dependency on libldap2-dev appears to be unused.

It looks like the configure script disables LDAP unless explicitly 
enabled, and debian/rules does not enable it. I also see "libldap: None; 
building without LDAP support" in the build log.

I rebuilt the package with the libldap2-dev dependency removed, and the 
resulting binaries were bit-identical.

thanks,
Ryan

Bug#1007972: oddjob: Unused build-dependency: libldap2-dev

[Ryan Tandy]

Source: oddjob
Version: 0.34.6-1
Severity: minor

Dear Maintainer,

oddjob's build-dependency on libldap2-dev seems to be unused. The 
related part of configure.ac has been disabled since 2006:

https://pagure.io/oddjob/c/0113a5fce83a4155aa0c264751936a3c846b4273

I rebuilt the package with the libldap2-dev dependency removed, and the 
resulting binaries were bit-identical.

thanks,
Ryan

Bug#1007731: php-fpdf: Unused build dependencies on libldap2-dev and libgdbm-dev

[Ryan Tandy]

I confirm the libldap2-dev dependency is unused. I rebuilt php-fpdf with 
it removed and libldap2-dev purged, and the resulting .deb was 
bit-identical.


The dependencies on po-debconf and quilt also look suspect to me, as the 
package has no debconf templates and no patches.

Bug#1006456: transition: openldap

[Ryan Tandy]

Hi Sebastian,

On Mon, Mar 14, 2022 at 04:14:25PM -0700, Ryan Tandy wrote:

gnupg1 also has the dependency in Recommends and should be rebuilt.


^^^ Just wanted to re-highlight gnupg1 as it still links the old 
libldap.


I looked through unstable's Packages by hand to see if I missed anything 
else... I found a couple of sid-only packages that didn't show up on the 
tracker (lua-apr and googleearth-package both don't Build-Depend on 
libldap-dev) but nothing concerning.


Thank you,
Ryan

Bug#1006456: transition: openldap

[Ryan Tandy]

gnupg1 also has the dependency in Recommends and should be rebuilt.

Bug#1006456: transition: openldap

[Ryan Tandy]

On Mon, Mar 14, 2022 at 10:15:54PM +0100, Sebastian Ramacher wrote:

If it's really just compile-tome constants and not actual symbols, then
that it's fine.


There is one source file (SOGoLDAPUserDefaults.m) that calls ldap_ 
functions, but from the build log it looks like the feature isn't 
enabled ("ldap-based configuration: no") and that file doesn't seem to 
be compiled, so never mind.

Bug#1006456: transition: openldap

[Ryan Tandy]

On Mon, Mar 14, 2022 at 02:00:59PM -0700, Ryan Tandy wrote:
sogo is probably ok. It depends on libldap-dev because it uses a 
couple of constants from , but it doesn't seem to link -lldap 
itself, instead relying on libsope1 to link it transitively.


... although right after I sent this, it occurred to me: does the fact 
the symbols are versioned mess with this? Might have to take a closer 
look, but sogo does use libldap's symbols in its code...

Bug#1006456: transition: openldap

[Ryan Tandy]

collectd and monitoring-plugins should be rebuilt as well. They are 
showing as unknown in the tracker because they list their plugins' shlib 
dependencies in Suggests and Recommends respectively. Sorry it didn't 
occur to me to list those fields in the ben file.


sogo is probably ok. It depends on libldap-dev because it uses a couple 
of constants from , but it doesn't seem to link -lldap itself, 
instead relying on libsope1 to link it transitively.

Bug#1006456: transition: openldap

[Ryan Tandy]

On Sun, Mar 13, 2022 at 02:26:20PM +0100, Sebastian Ramacher wrote:

Please take a look at golang-openldap. It's an arch: all package and
hardcodes a dependency on libldap-2.4-2


Thanks. I hadn't noticed it was hard-coded. Filed #1006456.

Also examining some of the "unknown" rows in the tracker, looks like 
several might legitimately be unused/unneeded build-depends. Will 
probably file some sev:minor bugs for those later.


Otherwise looks like things are going smoothly so far?

Bug#1007217: golang-openldap: openldap 2.5 transition

[Ryan Tandy]

Source: golang-openldap
Version: 0.2-2
Severity: important
Control: block 1006456 by -1

Dear Maintainer,

golang-openldap-dev has a hard-coded dependency on libldap-2.4-2. For 
the openldap 2.5 transition which is currently underway, the dependency 
should be updated to libldap-2.5-0.

I'm sorry for the late notice. I didn't notice the hard-coded 
dependency; the release team brought it to my attention after the 
transition started.

I also noticed the package seems to embed old copies of some libldap 
headers; these are now out-of-date. I feel like there should be some 
better solution than embedding them? If golang-openldap-dev needs them 
in /usr/share/gocode for building, maybe they could be symlinks to 
/usr/include? Happy to create a separate bug for this, if you want.

The package builds fine for me with the new version of libldap-dev, but 
I don't know any Go and I don't know how to test it. It also doesn't 
seem to have any rdepends in the archive.

A couple of more minor things:

golang-openldap-dev depends on libldap2-dev which depends on the runtime 
library, so maybe the direct dependency on libldap isn't strictly 
necessary? Just thinking of future transitions.

I'm asking maintainers to depend on libldap-dev instead of libldap2-dev 
going forward. libldap2-dev is now a transitional package and I'd like 
to drop it at some point.

Thank you,
Ryan

Bug#1006456: transition: openldap

[Ryan Tandy]

On Fri, Mar 11, 2022 at 10:15:31PM +0100, Sebastian Ramacher wrote:

Please go ahead


Thank you. openldap/2.5.11+dfsg-1 has just been accepted into unstable.

Should I bump the remaining autopkgtest issues to RC severity at this 
time?


Could you please update the ben file for the transition? The 
auto-generated one is not ideal. I think it should look something like:


is_affected = .build-depends ~ /\b(libldap(2)?\-dev|libslapi\-dev)\b/;
is_bad = .depends ~ /\b(libldap\-2\.4\-2|libslapi\-2\.4\-2)\b/;
is_good = .depends ~ /\b(libldap\-2\.5\-0|libslapi\-2\.5\-0)\b/;

Thank you,
Ryan

Bug#1006016: marked as done (wine will probably FTBFS with OpenLDAP 2.5)

[Ryan Tandy]

Thank you, Mike!

Bug#1006456: transition: openldap

[Ryan Tandy]

Wine has been fixed. I confirmed a successful build with openldap 2.5.

Bug#1006456: transition: openldap

[Ryan Tandy]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-openldap-de...@lists.alioth.debian.org
Control: block -1 by 1006016
Control: block -1 by 1005996
Control: block -1 by 990335
Control: block -1 by 989409

Dear release team,

I would like to transition to OpenLDAP 2.5 for bookworm. This is my 
first transition, please be gentle. :) The new version is available in 
experimental and has built on all release architectures.

I propose the following ben file:

title = "openldap";
is_affected = .build-depends ~ /\b(libldap(2)?\-dev|libslapi\-dev)\b/;
is_bad = .depends ~ /\b(libldap\-2\.4\-2|libslapi\-2\.4\-2)\b/;
is_good = .depends ~ /\b(libldap\-2\.5\-0|libslapi\-2\.5\-0)\b/;

(libslapi apparently has no rdeps currently; included anyway for 
completeness.)

I'm currently aware of the following issues blocking the transition:

Related FTBFS:

wine: #1006016 (presumed; but unable to test due to #995580)
wine-development: #1005996

Unrelated FTBFS: (please tell me if these should also be linked as 
blocking this transition bug)

uwsgi: #1006119
wine: #995580
- also tried with older unicode-data, but configure failed

condor: #966726 (not in testing)
kopanocore: #990322 (not in testing)
libaws: #997457 (not in testing)
openscap: #1000279 (not in testing)
sarg: #966848 (not in testing)
xemacs21: #1005992 (not in testing)

Related autopkgtest failures:

django-ldapdb: uses volatildap (#990335)
nss-pam-ldapd: #989409
volatildap: #990335

Unrelated autopkgtest failures:

python-ldap:
- in unstable, has no tests
- in experimental, has failing tests, but not a regression
  (same failure with openldap from unstable)

The one that concerns me the most is wine. It has multiple RC bugs but 
appears to also be a key package.

Thank you,
Ryan

Bug#989409: nss-pam-ldapd's autopkgtest fails with OpenLDAP 2.5

[Ryan Tandy]

Hi Arthur,

sorry for the long delayed followup.

On Sun, Nov 14, 2021 at 04:20:03PM +0100, Arthur de Jong wrote:

However the test_pamcmds script fails with the new version. The login
with the correct password fails, the issue seems to be (from
nslcd.log):

nslcd: [a88611]  DEBUG: got 
LDAP_CONTROL_PASSWORDPOLICYRESPONSE (Password must be changed)
nslcd: [a88611]  DEBUG: myldap_search(base="cn=Veronica 
Sefcovic+uid=vsefcovic,ou=lotsofpeople,dc=test,dc=tld", filter="(objectClass=*)")
nslcd: [a88611]  ldap_result() failed: Insufficient access: 
Operations are restricted to bind/unbind/abandon/StartTLS/modify password

Still looking into it, not sure why the new ppolicy wants the
password changed after it was just reset earlier.


Do you know at which step this failed in the test_pamcmds test? In
general I found ppolicy controls during authentication to be somewhat
confusing, especially when a password was about to expire or needed to
be changed.


It failed on "testing correct password".

I think the behaviour change is due to ITS#7084:

https://bugs.openldap.org/show_bug.cgi?id=7084
https://git.openldap.org/openldap/openldap/-/commit/376d5d65cb4d622abdd4bba250c80250e56dc4d8

With OpenLDAP 2.5, when the user's password is changed in 
reset_password(), they get pwdReset: TRUE added, because the policy has 
pwdMustChange: TRUE and the change is done by the administrator. Exactly 
like you said, the bind succeeds but then the search is not permitted. I 
can't remember whether nss-pam-ldapd is supposed to show a "password 
must be changed now" prompt in this case?


With OpenLDAP 2.4, I think pwdMustChange is consulted only when binding.  
I think the user is forced to change their password only if 
pwdMustChange and pwdReset are both set.


I removed "pwdMustChange: TRUE" from the policy and then the tests 
passed. Not sure if this is the correct fix, but at least I don't 
currently see anything in test_pamcmds.expect that would be expecting a 
forced reset?


Ryan

Bug#1006016: wine will probably FTBFS with OpenLDAP 2.5

[Ryan Tandy]

Source: wine
Version: 5.0.3-3
Severity: important
Tags: sid bookworm

Dear Maintainer,

Wine will most likely FTBFS with OpenLDAP 2.5, which is now available in 
experimental. I wasn't able to test this directly, because of the other 
FTBFS issues, but I wanted to file this bug anyway, for tracking.

#1005996 is the same issue in wine-development, and shows the error I 
expect to see.

I believe wine 6.7 or later should build fine. Alternatively, there is a 
patch for earlier versions available, which was already applied to 
Ubuntu's wine package.

https://bugs.launchpad.net/ubuntu/+source/wine/+bug/1929859
http://launchpadlibrarian.net/540912385/wine_5.0.3-3_5.0.3-3ubuntu1.diff.gz
https://bugs.winehq.org/show_bug.cgi?id=51129
https://www.winehq.org/announce/6.7

If you are able to build wine successfully with openldap from 
experimental, please feel free to close this bug.

Thank you,
Ryan

Bug#1006014: FTBFS: void value not ignored as it ought to be

[Ryan Tandy]

Source: bind-dyndb-ldap
Version: 11.9-4
Severity: serious
Tags: ftbfs

Dear Maintainer,

bind-dyndb-ldap fails to build from source on amd64:

/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../src -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Werror 
-std=gnu99 -O2 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wno-uninitialized 
-fvisibility=hidden -fno-delete-null-pointer-checks -c -o ldap_la-acl.lo `test 
-f 'acl.c' || echo '../../src/'`acl.c
In file included from ../../src/fwd_register.h:11,
 from ../../src/ldap_entry.h:11,
 from ../../src/acl.h:10,
 from ../../src/acl.c:32:
../../src/acl.c: In function ‘acl_configure_zone_ssutable’:
../../src/util.h:29:24: error: void value not ignored as it ought to be
   29 | result = (op);  \
  |^
../../src/acl.c:286:9: note: in expansion of macro ‘CHECK’
  286 | CHECK(dns_ssutable_create(mctx, ));
  | ^
../../src/acl.c:328:24: error: void value not ignored as it ought to be
  328 | result = dns_ssutable_addrule(table, grant,
  |^
make[3]: *** [Makefile:542: ldap_la-acl.lo] Error 1

This looks like it could be caused by a recent change in bind9:

https://gitlab.isc.org/isc-projects/bind9/-/commit/8fb4c5bb7a703e7c174ccd13b2ede618696af69c

The complete build log is attached.

Thank you,
Ryan
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on w500.nardis.ca

+==+
| bind-dyndb-ldap (amd64)  Fri, 18 Feb 2022 22:36:49 + |
+==+

Package: bind-dyndb-ldap
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/sid-amd64-sbuild-cc45b3f8-e9fb-41dc-a68a-619475c5b7c7' 
with '<>'
I: NOTICE: Log filtering will replace 
'build/bind-dyndb-ldap-YBm24v/resolver-qcZoD4' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://ftp.ca.debian.org/debian sid InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'bind-dyndb-ldap' packaging is maintained in the 'Git' version control 
system at:
https://salsa.debian.org/freeipa-team/bind-dyndb-ldap.git
Please use:
git clone https://salsa.debian.org/freeipa-team/bind-dyndb-ldap.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 364 kB of source archives.
Get:1 http://ftp.ca.debian.org/debian sid/main bind-dyndb-ldap 11.9-4 (dsc) 
[2062 B]
Get:2 http://ftp.ca.debian.org/debian sid/main bind-dyndb-ldap 11.9-4 (tar) 
[353 kB]
Get:3 http://ftp.ca.debian.org/debian sid/main bind-dyndb-ldap 11.9-4 (diff) 
[9156 B]
Fetched 364 kB in 0s (3595 kB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 
'build/bind-dyndb-ldap-YBm24v/bind-dyndb-ldap-11.9' with '<>'
I: NOTICE: Log filtering will replace 'build/bind-dyndb-ldap-YBm24v' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 12), bind9-dev (>= 1:9.17.19-3), 
libkrb5-dev, libldap2-dev, libsasl2-dev, uuid-dev, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 12), bind9-dev (>= 1:9.17.19-3), 
libkrb5-dev, libldap2-dev, libsasl2-dev, uuid-dev, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [410 B]
Get:5 copy:/<>/apt_archive ./ Packages [493 B]
Fetched 1860 B in 0s (110 kB/s)
Reading package lists...
Reading package lists...

Install main build dependencies 

Bug#1005992: FTBFS: 'sys_siglist' undeclared

[Ryan Tandy]

Source: xemacs21
Version: 21.4.24-9
Severity: serious
Tags: ftbfs

Dear Maintainer,

xemacs21 fails to build from source on amd64:

process.c:1314:27: error: 'sys_siglist' undeclared (first use in this function)
 1314 | return (const char *) sys_siglist[signum];
  |   ^~~
process.c:1314:27: note: each undeclared identifier is reported only once for 
each function it appears in
make[3]: *** [GNUmakefile:58: process.o] Error 1

The glibc 2.32 release notes mention sys_siglist:

* The deprecated arrays sys_siglist, _sys_siglist, and sys_sigabbrev
  are no longer available to newly linked binaries, and their declarations
  have been removed from .  They are exported solely as
  compatibility symbols to support old binaries.  All programs should use
  strsignal instead.

https://lists.gnu.org/archive/html/info-gnu/2020-08/msg2.html

The complete build log is attached.

thank you,
Ryan
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on w500.nardis.ca

+==+
| xemacs21 (amd64) Thu, 17 Feb 2022 21:40:17 + |
+==+

Package: xemacs21
Distribution: sid
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/sid-amd64-sbuild-638405a7-026f-4a93-8dd2-fe6f3baafde8' 
with '<>'
I: NOTICE: Log filtering will replace 'build/xemacs21-bajcVO/resolver-2uPGW7' 
with '<>'

+--+
| Update chroot|
+--+

Get:1 http://ftp.ca.debian.org/debian sid InRelease [165 kB]
Get:2 http://ftp.ca.debian.org/debian sid/contrib Sources.diff/Index [63.3 kB]
Get:3 http://ftp.ca.debian.org/debian sid/main Sources.diff/Index [63.6 kB]
Get:4 http://ftp.ca.debian.org/debian sid/main amd64 Packages.diff/Index [63.6 
kB]
Get:5 http://ftp.ca.debian.org/debian sid/contrib Sources 
T-2022-02-17-2005.30-F-2022-02-17-2005.30.pdiff [663 B]
Get:6 http://ftp.ca.debian.org/debian sid/main Sources 
T-2022-02-17-2005.30-F-2022-02-17-2005.30.pdiff [24.4 kB]
Get:5 http://ftp.ca.debian.org/debian sid/contrib Sources 
T-2022-02-17-2005.30-F-2022-02-17-2005.30.pdiff [663 B]
Get:7 http://ftp.ca.debian.org/debian sid/main amd64 Packages 
T-2022-02-17-2005.30-F-2022-02-17-2005.30.pdiff [26.1 kB]
Get:6 http://ftp.ca.debian.org/debian sid/main Sources 
T-2022-02-17-2005.30-F-2022-02-17-2005.30.pdiff [24.4 kB]
Get:7 http://ftp.ca.debian.org/debian sid/main amd64 Packages 
T-2022-02-17-2005.30-F-2022-02-17-2005.30.pdiff [26.1 kB]
Fetched 407 kB in 6s (70.0 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
Need to get 7233 kB of source archives.
Get:1 http://ftp.ca.debian.org/debian sid/main xemacs21 21.4.24-9 (dsc) [2142 B]
Get:2 http://ftp.ca.debian.org/debian sid/main xemacs21 21.4.24-9 (tar) [7198 
kB]
Get:3 http://ftp.ca.debian.org/debian sid/main xemacs21 21.4.24-9 (diff) [33.4 
kB]
Fetched 7233 kB in 0s (30.4 MB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 'build/xemacs21-bajcVO/xemacs21-21.4.24' 
with '<>'
I: NOTICE: Log filtering will replace 'build/xemacs21-bajcVO' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: autotools-dev, texinfo, libcanna1g-dev, libwnn6-dev, 
libjpeg-dev, libncurses5-dev, libpng-dev, libtiff5-dev, zlib1g-dev, texi2html, 
debhelper (>> 5.0.0), libldap2-dev, libdb-dev, libpam0g-dev, libcompfaceg1-dev, 
libx11-dev, libxau-dev, libxext-dev, libxmu-dev, libxpm-dev, libxt-dev, 
xbitmaps, xcursor-themes, libxaw7-dev, autoconf2.13, libgpm-dev, 
build-essential, fakeroot
Filtered Build-Depends: autotools-dev, texinfo, libcanna1g-dev, libwnn6-dev, 
libjpeg-dev, libncurses5-dev, libpng-dev, libtiff5-dev, zlib1g-dev, texi2html, 
debhelper (>> 5.0.0), libldap2-dev, libdb-dev, libpam0g-dev, libcompfaceg1-dev, 
libx11-dev, libxau-dev, libxext-dev, libxmu-dev, libxpm-dev, libxt-dev, 
xbitmaps, xcursor-themes, 

Bug#976991: libldap-2.4-2:amd64: Please consider building with openssl instead of gnutls

[Ryan Tandy]

On Wed, Feb 02, 2022 at 12:53:59PM -0600, Matt Zagrabelny wrote:

Any traction on a gnutls -> openssl migration for openldap for bookworm?


I don't have any technical reasons to block it, but for personal reasons 
I'm not likely to pursue it myself.


As already written in the RFH bug (#512360), I'm already trying to get 
out of maintaining this package, and I'm really not keen on taking on 
additional support burden by breaking working TLS setups. If someone 
would join the team as co-maintainer and commit to helping with upgrades 
and user support for bookworm, that would help a lot. As it stands, I'm 
not enthusiastic about pursuing a breaking change like this by myself.

Bug#1004226: autopkgtest: qemu only boots qcow2 images

[Ryan Tandy]

Package: autopkgtest
Version: 5.16
Severity: normal
Tags: patch

Dear Maintainer,

I found that autopkgtest-virt-qemu in bullseye doesn't boot my disk 
images. The version in buster was working fine.

Using --show-boot I found that the VM doesn't boot at all:

Booting from Hard Disk...
Boot failed: could not read the boot disk

The reason is that my disk images are raw images, not qcow2. I found 
that autopkgtest runs qemu-img to create an overlay file in qcow2 
format, but it configures qemu with the base image format (format=raw) 
instead of the overlay format (format=qcow2). I converted an image to 
qcow2 format and then it worked fine.

I'm attaching a patch to use format=qcow2 for the overlay image. Please 
let me know if you'd prefer a Salsa merge request instead.

Thank you,
Ryan


-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autopkgtest depends on:
ii  apt-utils   2.2.4
ii  libdpkg-perl1.20.9
ii  procps  2:3.3.17-5
ii  python3 3.9.2-3
ii  python3-debian  0.1.39

Versions of packages autopkgtest recommends:
pn  autodep8  

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
pn  ovmf  
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:5.2+dfsg-11+deb11u1
ii  schroot   1.6.10-12
pn  vmdb2 

-- no debconf information
>From dc5722886920a030d850cd5e0a492c49ffa96988 Mon Sep 17 00:00:00 2001
From: Ryan Tandy 
Date: Sat, 22 Jan 2022 19:19:33 -0800
Subject: [PATCH] Fix qemu failing to boot raw base image

The overlay file is created with 'qemu-img -f qcow2', so pass
'format=qcow2' when using an overlay image. Otherwise, use the base
image format.
---
 lib/autopkgtest_qemu.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/autopkgtest_qemu.py b/lib/autopkgtest_qemu.py
index 6733ede..fc8225c 100644
--- a/lib/autopkgtest_qemu.py
+++ b/lib/autopkgtest_qemu.py
@@ -156,13 +156,14 @@ class QemuImage:
 
 if self.overlay is None:
 bits.append('file={}'.format(self.file))
+bits.append('format={}'.format(self.format))
 else:
 bits.append('file={}'.format(self.overlay))
+bits.append('format=qcow2')
 bits.append('cache=unsafe')
 
 bits.append('if=virtio')
 bits.append('discard=unmap')
-bits.append('format={}'.format(self.format))
 
 if self.readonly:
 bits.append('readonly')
-- 
2.30.2

Bug#1003291: ModuleNotFoundError: No module named 'pkg_resources'

[Ryan Tandy]

Package: goobook
Version: 3.5.1-1
Severity: serious
Justification: Policy 7.2

Dear Maintainer,

goobook seems to need a dependency on python3-pkg-resources:

(sid-amd64)# goobook
Traceback (most recent call last):
  File "/usr/bin/goobook", line 33, in 
sys.exit(load_entry_point('goobook==3.5.1', 'console_scripts', 'goobook')())
  File "/usr/bin/goobook", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/share/goobook/goobook/application.py", line 18, in 
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

After I installed python3-pkg-resources manually, it works fine.

This upstream MR might be relevant: 
https://gitlab.com/goobook/goobook/-/merge_requests/14

Thanks for maintaining goobook.

Ryan


-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages goobook depends on:
ii  python3   3.9.2-3
ii  python3-googleapi 1.7.11-4
ii  python3-oauth2client  4.1.2-7
ii  python3-simplejson3.17.2-1
ii  python3-xdg   0.27-2

goobook recommends no packages.

goobook suggests no packages.

-- no debconf information

Bug#989155: dh_installinit: when upgrading to a version that adds --no-restart-after-upgrade, the service is not restarted

[Ryan Tandy]

Hi Michael,

On Fri, Oct 29, 2021 at 09:51:46AM +0200, Michael Biebl wrote:

If you use "--no-restart-after-upgrade", why do you expect the service to be
restarted?


The man page describes --no-restart-after-upgrade:

 Undo a previous --restart-after-upgrade (or the default of compat 10).  
 If no other options are given, this will cause the service to be 
 stopped in the prerm script and started again in the postinst script.



Isn't the point of "--no-restart-after-upgrade" to *not* stop any
processes on upgrades.


I think the one you're talking about is -r, --no-stop-on-upgrade, 
--no-restart-on-upgrade.


thanks,
Ryan

Bug#992130: ldap-utils: [ldapsearch] wrong default location of -T in man page

[Ryan Tandy]

Control: tag -1 fixed-upstream

https://git.openldap.org/openldap/openldap/-/commit/f7d558a44912329019eaa5a2400fa0a460f48f10

Bug#991274: Package libldap-2.4-2 was built without LDAP_CONNECTIONLESS

[Ryan Tandy]

Control: retitle -1 sssd-ldap: ldap_init_fd failed: Bad parameter to an ldap 
routine
Control: reassign -1 sssd-ldap 2.4.0-1
Control: severity -1 important

Hi Timo,

Since this is kind of a regression in sssd 2.4.0, and a fix is now 
available for sssd [1], can I ask you to take care of it on sssd's side?  
maybe also in bullseye, since it seems we have a few stable users 
affected?


[1] https://github.com/SSSD/sssd/pull/5743

Thank you,

Ryan

Bug#982147: Test case for libmgba-dev

[Ryan Tandy]

Hello,

I'm working on the libmgba-dev package. Can either of you share a link 
to a project or test case that I can use to test it? or would either of 
you be willing to test the package if I push the changes (or a repo of 
built packages) somewhere?


thanks,
Ryan

Bug#993343: OpenLDAP 2.5 FTBFS on GNU/Hurd: MAXPATHLEN undeclared

[Ryan Tandy]

Hi Joshua,

On Sat, Sep 04, 2021 at 12:10:30PM -0400, Joshua Branson wrote:

This is supposed to be an "easy fix".  I'd be willing to try to work
with you to help you fix this.


Thanks a lot for offering to work on a fix. Actually it was easy enough 
that the upstream developers have already fixed it themselves, so that's 
no longer necessary and the next upload to experimental should build 
fine on Hurd. Appreciate your offer though.

Bug#993618: RFS: openldap/2.4.59+dfsg-1~bpo11+1

[Ryan Tandy]

Package: sponsorship-requests
Severity: normal

Dear mentors and backporters,

As with previous releases, I am looking for a sponsor to perform the 
initial upload of openldap to bullseye-backports since it will be NEW. I 
am DM for the package and can take care of future uploads myself.


Rationale for backporting: while the client library (libldap) is mature 
and stable, the OpenLDAP server (slapd) is more actively developed, so 
advanced slapd users often prefer to run the latest upstream version.


The backport is a simple rebuild, no changes needed.

The package can be found on mentors.debian.net:

https://mentors.debian.net/package/openldap/
https://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.59+dfsg-1~bpo11+1.dsc

The changes since stable are:

openldap (2.4.59+dfsg-1~bpo11+1) bullseye-backports; urgency=medium
.
  * Rebuild for bullseye-backports.
.
openldap (2.4.59+dfsg-1) unstable; urgency=medium
.
  * New upstream release.
  * Fix FTBFS with autoconf 2.71 (Closes: #993032):
- Backport upstream changes to support Autoconf 2.69 instead of simply
  disabling automake in debian/rules. Fixes FTBFS due to autoreconf
  thinking files required by Automake are missing, even though Automake is
  not actually used.
- Stop running autoreconf in contrib/ldapc++ since we don't build it.
- Drop custom config.{guess,sub} handling. dh_update_autotools_config does
  the right thing for us.
  * Update Standards-Version to 4.6.0; no changes required.
  * Add a superficial autopkgtest for smbk5pwd.
  * Stop disabling test060-mt-hot on ppc64el. The underlying kernel bug
(#866122) is fixed in all relevant suites by now.

Thank you,
Ryan

Bug#993343: OpenLDAP 2.5 FTBFS on GNU/Hurd: MAXPATHLEN undeclared

[Ryan Tandy]

Control: tag -1 fixed-upstream

https://bugs.openldap.org/show_bug.cgi?id=9659 has also been fixed. Now 
upstream git master builds fine on hurd-i386, as does a 2.5 package with 
the relevant fixes applied.


back-mdb even passes the first few tests, but still fails on 
test008-concurrency...

Bug#993343: OpenLDAP 2.5 FTBFS on GNU/Hurd: MAXPATHLEN undeclared

[Ryan Tandy]

The MAXPATHLEN failure has been fixed in the 2.5 branch. Still FTBFS 
though, the slapd code fails to compile on Hurd.


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

Bug#993343: OpenLDAP 2.5 FTBFS on GNU/Hurd: MAXPATHLEN undeclared

[Ryan Tandy]

Source: openldap
Version: 2.5.5+dfsg-1~exp1
Severity: important
Tags: upstream ftbfs help
Forwarded: https://bugs.openldap.org/show_bug.cgi?id=9658

https://buildd.debian.org/status/fetch.php?pkg=openldap=hurd-i386=2.5.5%2Bdfsg-1%7Eexp1=1623486618=0

libtool: compile:  cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c 
request.c  -fPIC -DPIC -o .libs/request.o
In file included from ldap-int.h:119,
from request.c:53:
request.c: In function 'ldap_dump_connection':
../../include/ldap_pvt.h:181:25: error: 'MAXPATHLEN' undeclared (first use in 
this function)
 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH="))
 | ^~
request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN'
 859 |charfrom[LDAP_IPADDRLEN];
 | ^~
../../include/ldap_pvt.h:181:25: note: each undeclared identifier is reported 
only once for each function it appears in
 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH="))
 | ^~
request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN'
 859 |charfrom[LDAP_IPADDRLEN];
 | ^~
Makefile:435: recipe for target 'request.lo' failed
make[2]: *** [request.lo] Error 1

I confirmed locally that current git master is still affected.

It's well-known that GNU/Hurd doesn't provide MAXPATHLEN.
https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL

I don't have the bandwidth to work on this myself. It would be great if 
someone from the Hurd community could look at it.


thanks
Ryan

Bug#991274: Package libldap-2.4-2 was built without LDAP_CONNECTIONLESS

[Ryan Tandy]

Hi Gerald,

The following patch is supposed to make CLDAP optional for sssd again:

https://github.com/SSSD/sssd/issues/5720
https://github.com/SSSD/sssd/pull/5743

Would it be possible for you to test that patch and report your findings 
in the issue or pull request?


CCing the sssd maintainers in case the fix might be suitable for 
backporting to bullseye.


thanks
Ryan

Bug#991274: Package libldap-2.4-2 was built without LDAP_CONNECTIONLESS

[Ryan Tandy]

Control: severity -1 wishlist

Hi,

I'm afraid this is too late for Debian 11 (bullseye). We could look at 
enabling it for Debian 12 (bookworm).


On Mon, Jul 19, 2021 at 03:35:38PM +0200, Gerald Vincent wrote:

Since 2.4.0, package sssd needs openldap library built with CONNECTIONLESS 
support to use cldap:// requests.
Without this feature enables, sssd is no longer working properly with Active 
Directory.


Why does the new version of sssd require this? Can it not remain 
optional on their side, if it was in the past?


See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539421 for the 
previous request about LDAP_CONNECTIONLESS. As far as I know the 
upstream status hasn't changed...


thanks
Ryan

Bug#989409: nss-pam-ldapd's autopkgtest fails with OpenLDAP 2.5

[Ryan Tandy]

Hi. The attached patch updates the test slapd config to support OpenLDAP 
2.5 in addition to 2.4.


However the test_pamcmds script fails with the new version. The login 
with the correct password fails, the issue seems to be (from nslcd.log):


2.4/good:

nslcd: [a88611]  DEBUG: got 
LDAP_CONTROL_PASSWORDPOLICYRESPONSE (No error)
nslcd: [a88611]  DEBUG: myldap_search(base="cn=Veronica 
Sefcovic+uid=vsefcovic,ou=lotsofpeople,dc=test,dc=tld", filter="(objectClass=*)")
nslcd: [a88611]  DEBUG: ldap_result(): cn=Veronica 
Sefcovic+uid=vsefcovic,ou=lotsofpeople,dc=test,dc=tld

2.5/bad:

nslcd: [a88611]  DEBUG: got 
LDAP_CONTROL_PASSWORDPOLICYRESPONSE (Password must be changed)
nslcd: [a88611]  DEBUG: myldap_search(base="cn=Veronica 
Sefcovic+uid=vsefcovic,ou=lotsofpeople,dc=test,dc=tld", filter="(objectClass=*)")
nslcd: [a88611]  ldap_result() failed: Insufficient access: 
Operations are restricted to bind/unbind/abandon/StartTLS/modify password

Still looking into it, not sure why the new ppolicy wants the password 
changed after it was just reset earlier.
>From 333260bde9b87cdc5362904f46507ea7ca06bc89 Mon Sep 17 00:00:00 2001
From: Ryan Tandy 
Date: Fri, 4 Jun 2021 10:36:23 -0700
Subject: [PATCH] Support running tests with OpenLDAP 2.5

- Change database backend to LMDB
- Load external ppolicy schema conditionally
---
 tests/config.ldif| 16 ++--
 tests/setup_slapd.sh |  4 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/tests/config.ldif b/tests/config.ldif
index 66ae428..3e1164e 100644
--- a/tests/config.ldif
+++ b/tests/config.ldif
@@ -10,7 +10,7 @@ olcTimeLimit: unlimited
 dn: cn=module{0},cn=config
 objectClass: olcModuleList
 cn: module{0}
-olcModuleLoad: back_bdb
+olcModuleLoad: back_mdb
 olcModuleLoad: ppolicy
 
 dn: cn=schema,cn=config
@@ -22,7 +22,7 @@ include: file:///etc/ldap/schema/cosine.ldif
 include: file:///etc/ldap/schema/nis.ldif
 include: file:///etc/ldap/schema/inetorgperson.ldif
 include: file:///etc/ldap/schema/misc.ldif
-include: file:///etc/ldap/schema/ppolicy.ldif
+#PPOLICY#include: file:///etc/ldap/schema/ppolicy.ldif
 
 dn: cn=samba,cn=schema,cn=config
 objectClass: olcSchemaConfig
@@ -83,10 +83,10 @@ olcAccess: to *
   by * break
 olcRootDN: cn=admin,cn=config
 
-dn: olcDatabase={1}bdb,cn=config
+dn: olcDatabase={1}mdb,cn=config
 objectClass: olcDatabaseConfig
-objectClass: olcBdbConfig
-olcDatabase: {1}bdb
+objectClass: olcmdbConfig
+olcDatabase: {1}mdb
 olcDbDirectory: @BASEDIR@/ldapdb
 olcSuffix: dc=test,dc=tld
 olcAccess: to attrs=userPassword
@@ -106,13 +106,9 @@ olcAccess: to *
 olcRootDN: cn=admin,dc=test,dc=tld
 olcRootPW: test
 olcDbCheckpoint: 512 30
-olcDbConfig: set_cachesize 0 2097152 0
-olcDbConfig: set_lk_max_objects 1500
-olcDbConfig: set_lk_max_locks 1500
-olcDbConfig: set_lk_max_lockers 1500
 olcDbIndex: objectClass eq
 
-dn: olcOverlay={0}ppolicy,olcDatabase={1}bdb,cn=config
+dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
 objectClass: olcOverlayConfig
 objectClass: olcPPolicyConfig
 olcOverlay: {0}ppolicy
diff --git a/tests/setup_slapd.sh b/tests/setup_slapd.sh
index 8f8874f..2534079 100755
--- a/tests/setup_slapd.sh
+++ b/tests/setup_slapd.sh
@@ -94,6 +94,10 @@ case "$2" in
 echo "Loading cn=config..."
 tmpldif=`mktemp -t slapadd.XX`
 sed "s|@BASEDIR@|$basedir|g" < "$srcdir/config.ldif" > "$tmpldif"
+if [ -f /etc/ldap/schema/ppolicy.ldif ]
+then
+  sed -i "s|#PPOLICY#||g" "$tmpldif"
+fi
 slapadd -v -F "$basedir/slapd.d" -b "cn=config" -l "$tmpldif" || (echo " FAILED"; exit 1)
 rm -f "$tmpldif"
 echo "Loading dc=test,dc=tld..."
-- 
2.20.1

Bug#989155: dh_installinit: when upgrading to a version that adds --no-restart-after-upgrade, the service is not restarted

[Ryan Tandy]

Package: debhelper
Version: 13.3.4
Severity: normal
Control: affects -1 slapd

Dear maintainer,

It looks like if I currently use dh_installinit --restart-after-upgrade 
(the default), and in a newer version I change it to use 
--no-restart-after-upgrade, then when I upgrade to that newer version, 
the service is not restarted and the old version is still running.


I think this happens because the stop call is added to prerm, but on 
upgrade it is the *old* prerm that runs, not the new one.


I did not test dh_installsystemd, but it looks like it would have the 
same issue.


The concrete case I have at hand is src:openldap. In bullseye it runs 
dh_installinit with no options, so slapd restarts after upgrade. For 
bookworm I will certainly need to stop slapd before upgrading it.


Thank you,
Ryan

Bug#989025: unblock: micro-evtd/3.4-7

[Ryan Tandy]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package micro-evtd

[ Reason ]

Fix micro-evtd creating its pid and status files in /var/run with 
world-writable permissions (#988119).


[ Impact ]

- The pid and status files in /var/run are mode 666, which could be a 
 potential security issue.
- micro-evtd does not stop when asked to with "/etc/init.d/micro-evtd 
 stop", because start-stop-daemon refuses to use the insecure pid file.
- Because of that, the daemon also does not restart on upgrade as it 
 should, instead the old version remains running.


[ Tests ]

There are no automated tests. I manually tested the install and upgrade 
cases (testing→unstable).


[ Risks ]

The change should be trivial, but it is possible (if unlikely) that I 
missed some case where the umask 000 was actually needed.


[ Checklist ]
 [✓] all changes are documented in the d/changelog
 [✓] I reviewed all changes and I approve them
 [✓] attach debdiff against the package in testing

[ Other info ]

The package builds a udeb. I tested an installation using a d-i daily 
build with the updated package included, and confirmed the corrected 
file permissions in the d-i environment.


The issue exists already in buster (not a regression).

unblock micro-evtd/3.4-7

Thank you,
Ryan
diff -Nru micro-evtd-3.4/debian/changelog micro-evtd-3.4/debian/changelog
--- micro-evtd-3.4/debian/changelog 2021-05-03 20:22:09.0 -0700
+++ micro-evtd-3.4/debian/changelog 2021-05-22 00:40:17.0 -0700
@@ -1,3 +1,12 @@
+micro-evtd (3.4-7) unstable; urgency=medium
+
+  [ Ryan Tandy ]
+  * Fix world-writable pid and status files in /var/run (Closes: #988119)
+- Patch micro-evtd.c to reset umask to 022 instead of 0.
+- Fix permissions on existing files on upgrade.
+
+ -- Roger Shimizu   Sat, 22 May 2021 16:40:17 +0900
+
 micro-evtd (3.4-6) unstable; urgency=medium
 
   [ Ryan Tandy ]
diff -Nru micro-evtd-3.4/debian/micro-evtd.postinst 
micro-evtd-3.4/debian/micro-evtd.postinst
--- micro-evtd-3.4/debian/micro-evtd.postinst   2021-05-03 20:22:09.0 
-0700
+++ micro-evtd-3.4/debian/micro-evtd.postinst   2021-05-22 00:40:17.0 
-0700
@@ -14,6 +14,18 @@
 rm /usr/sbin/micro-evtd.status
 fi
 fi
+
+if dpkg --compare-versions "$2" lt-nl "3.4-7~"; then
+# Fix permissions on the existing pid file
+# so that the daemon is actually restarted
+if [ -f /var/run/micro-evtd.pid ]; then
+chmod 644 /var/run/micro-evtd.pid
+fi
+
+if [ -f /var/run/micro-evtd.status ]; then
+chmod 644 /var/run/micro-evtd.status
+fi
+fi
 ;;
 
 *)
diff -Nru 
micro-evtd-3.4/debian/patches/0008-Don-t-create-world-writable-files.patch 
micro-evtd-3.4/debian/patches/0008-Don-t-create-world-writable-files.patch
--- micro-evtd-3.4/debian/patches/0008-Don-t-create-world-writable-files.patch  
1969-12-31 16:00:00.0 -0800
+++ micro-evtd-3.4/debian/patches/0008-Don-t-create-world-writable-files.patch  
2021-05-22 00:40:17.0 -0700
@@ -0,0 +1,26 @@
+From: Ryan Tandy 
+Date: Fri, 21 May 2021 13:06:41 -0700
+Subject: Don't create world-writable files
+
+Set umask to 022 on startup instead of 000.
+
+Fixes the pid and status files being created world-writable.
+
+Bug-Debian: https://bugs.debian.org/988119
+---
+ src/micro-evtd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/micro-evtd.c b/src/micro-evtd.c
+index da91549..cc05b6a 100644
+--- a/src/micro-evtd.c
 b/src/micro-evtd.c
+@@ -1777,7 +1777,7 @@ int main(int argc, char *argv[])
+   setsid();
+ 
+   /* clear file creation mask */
+-  umask(0);
++  umask(022);
+ 
+   // Lock out device resource
+   getResourceLock();
diff -Nru micro-evtd-3.4/debian/patches/series 
micro-evtd-3.4/debian/patches/series
--- micro-evtd-3.4/debian/patches/series2021-05-03 20:22:09.0 
-0700
+++ micro-evtd-3.4/debian/patches/series2021-05-22 00:40:17.0 
-0700
@@ -5,3 +5,4 @@
 0005-Check-for-mmap-returning-MAP_FAILED.patch
 0006-Match-default-temperature-configuration-to-the-confi.patch
 0007-Fix-FTBFS-with-glibc-2.30.patch
+0008-Don-t-create-world-writable-files.patch

Bug#988937: micro-evtd: beeps and runs the fan randomly

[Ryan Tandy]

Package: micro-evtd
Version: 3.4-4
Severity: normal

While testing the recent micro-evtd changes I noticed that this problem 
still happens in buster and bullseye. After some hours or days of 
uptime, the box sometimes beeps and runs the fan, for no apparent 
reason. Sometimes it beeps once, other times continuously.

I think these are the same root cause:

https://lists.debian.org/debian-arm/2017/02/msg00038.html
https://lists.debian.org/debian-arm/2019/04/msg5.html

The symptoms might vary by hardware.

I set DEBUG=2 in micro-evtd.conf and confirmed that micro-evtd is 
causing the beeping, e.g. /var/log/micro-evtd:

Wed May 19 19:21:46 PDT 2021 B 200 0 micon
Wed May 19 19:21:50 PDT 2021 B 201 0 micon
Wed May 19 19:21:52 PDT 2021 B 200 0 micon
Wed May 19 19:21:54 PDT 2021 B 201 0 micon

I am not running with iomem=relaxed, so micro-evtd uses the fallback 
button detection method instead of /dev/mem. I think there is something 
wrong with the button detection in this path.

I can't remember if we ever discussed whether there is some modern way 
of accessing the GPIO? would it require more kernel changes?

Bug#988607: unblock: openldap/2.4.57+dfsg-3

[Ryan Tandy]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package openldap

[ Reason ]

Fix bug #988565: slapd-smbk5pwd crashes when initializing Kerberos.

smbk5pwd is a contributed plugin for slapd. It extends LDAP password 
change operations to also update the attributes used by Samba and 
Heimdal when their databases are stored in the LDAP directory.


At some point slapd picked up a transitive dependency on libkrb5-3 (via 
libwrap0). This caused the crash because at runtime smbk5pwd would call 
the MIT implementation of krb5_init_context and then pass the same 
context to Heimdal functions.


The two libkrb5 implementations do use symbol versioning, however, 
smbk5pwd contained references to the bare/unversioned symbols because it 
was not linking -lkrb5.


The fix is just to add -lkrb5 to the link line for smbk5pwd, which lets 
it correctly use the versioned symbols such as  
"krb5_init_context@HEIMDAL_KRB5_2.0". The symbols can be manually 
inspected via "nm -D /usr/lib/ldap/smbk5pwd.so".


One of the changed lines also occurs as context in another patch, which 
had to be refreshed to avoid fuzz.


[ Impact ]

slapd crashes on startup, if the smbk5pwd plugin is loaded and its 
Heimdal integration is enabled. Regression since it works in buster.


[ Tests ]

Upstream has an extensive test suite which runs at build time, however 
it does not cover the contrib modules such as smbk5pwd.


There is a superficial autopkgtest, which only tests whether the core 
slapd runs and answers a trivial query.


I manually tested the smbk5pwd plugin with the Samba and Kerberos 
integrations enabled.


[ Risks ]

I think this is a low risk change. The contrib modules each have their 
own individual build systems, so the change only affects the smbk5pwd 
Makefile and not any other component. It should be impossible for this 
change to impact any core component such as libldap or slapd.


[ Checklist ]

 [✓] all changes are documented in the d/changelog
 [✓] I reviewed all changes and I approve them
 [✓] attach debdiff against the package in testing

unblock openldap/2.4.57+dfsg-3

Thank you,
Ryan
diff -Nru openldap-2.4.57+dfsg/debian/changelog 
openldap-2.4.57+dfsg/debian/changelog
--- openldap-2.4.57+dfsg/debian/changelog   2021-02-14 09:26:41.0 
-0800
+++ openldap-2.4.57+dfsg/debian/changelog   2021-05-15 16:03:34.0 
-0700
@@ -1,3 +1,9 @@
+openldap (2.4.57+dfsg-3) unstable; urgency=medium
+
+  * Link smbk5pwd with -lkrb5. (Closes: #988565)
+
+ -- Ryan Tandy   Sat, 15 May 2021 16:03:34 -0700
+
 openldap (2.4.57+dfsg-2) unstable; urgency=medium
 
   * Fix slapd assertion failure in Certificate List Exact Assertion validation
diff -Nru openldap-2.4.57+dfsg/debian/patches/contrib-makefiles 
openldap-2.4.57+dfsg/debian/patches/contrib-makefiles
--- openldap-2.4.57+dfsg/debian/patches/contrib-makefiles   2021-02-14 
09:26:41.0 -0800
+++ openldap-2.4.57+dfsg/debian/patches/contrib-makefiles   2021-05-15 
16:03:34.0 -0700
@@ -76,8 +76,8 @@
  
 -HEIMDAL_INC = -I/usr/heimdal/include
 -HEIMDAL_LIB = -L/usr/heimdal/lib -lkrb5 -lkadm5srv
-+HEIMDAL_INC = $(shell krb5-config.heimdal --cflags kadm-server)
-+HEIMDAL_LIB = $(shell krb5-config.heimdal --libs kadm-server)
++HEIMDAL_INC = $(shell krb5-config.heimdal --cflags krb5 kadm-server)
++HEIMDAL_LIB = $(shell krb5-config.heimdal --libs krb5 kadm-server)
  
  LIBTOOL = $(LDAP_BUILD)/libtool
  CC = gcc
diff -Nru openldap-2.4.57+dfsg/debian/patches/smbk5pwd-makefile-manpage 
openldap-2.4.57+dfsg/debian/patches/smbk5pwd-makefile-manpage
--- openldap-2.4.57+dfsg/debian/patches/smbk5pwd-makefile-manpage   
2021-02-14 09:26:41.0 -0800
+++ openldap-2.4.57+dfsg/debian/patches/smbk5pwd-makefile-manpage   
2021-05-15 16:03:34.0 -0700
@@ -18,7 +18,7 @@
 --- a/contrib/slapd-modules/smbk5pwd/Makefile
 +++ b/contrib/slapd-modules/smbk5pwd/Makefile
 @@ -25,6 +25,7 @@
- HEIMDAL_LIB = $(shell krb5-config.heimdal --libs kadm-server)
+ HEIMDAL_LIB = $(shell krb5-config.heimdal --libs krb5 kadm-server)
  
  LIBTOOL = $(LDAP_BUILD)/libtool
 +INSTALL = /usr/bin/install

Bug#988565: slapd-contrib: smbk5pwd crashes when enabling krb5 (again)

[Ryan Tandy]

Looks like this is a legitimate bug in how we build smbk5pwd. It's not 
linking -lkrb5, so it doesn't see its versioned symbols. This would have 
been introduced when we switched to heimdal-multidev and started using 
krb5-config, so quite a while ago.

Bug#988565: slapd-contrib: smbk5pwd crashes when enabling krb5 (again)

[Ryan Tandy]

Package: slapd-contrib
Version: 2.4.57+dfsg-2
Severity: serious

# ldapmodify -H ldapi:// -Y EXTERNAL << eof

dn: olcOverlay=smbk5pwd,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcSmbK5PwdConfig
olcSmbK5PwdEnable: krb5
eof

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcOverlay=smbk5pwd,olcDatabase={1}mdb,cn=config"
ldap_result: Can't contact LDAP server (-1)

Thread 3 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb5e98700 (LWP 2843)]
initialize_kadm5_error_table_r (list=0x7fffa8105048,
   list@entry=) at 
kadm5_err.c:101
101 kadm5_err.c: No such file or directory.


Same symptoms and root cause as #917129. Different package causing it.

This time the dependency chain is:
slapd -> libwrap.so.0 -> libnsl.so.2 -> libtirpc.so.3 -> libgssapi_krb5.so.2 -> libkrb5.so.3 

Bug#988119: micro-evtd: "/etc/init.d/micro-evtd stop" broken (world-writable pid file)

[Ryan Tandy]

The status file is also world writable.

$ ls -l /run/micro-evtd.*
-rw-rw-rw- 1 root root  4 May  5 22:32 /run/micro-evtd.pid
-rw-rw-rw- 1 root root 39 May  5 22:33 /run/micro-evtd.status

Bug#988083: unblock: micro-evtd/3.4-6

[Ryan Tandy]

I'm sorry, I belatedly noticed another issue with micro-evtd.

#988119: the daemon creates its pid and status files with mode 666, 
start-stop-daemon doesn't like that and refuses to stop the daemon.


I don't know what the appropriate severity is for that one. If it's RC I 
can make another upload to fix it.


Sorry for the noise.

Bug#988119: micro-evtd: "/etc/init.d/micro-evtd stop" broken (world-writable pid file)

[Ryan Tandy]

Package: micro-evtd
Version: 3.4-5
Severity: normal

I just noticed while testing 3.4-6, that stopping the daemon doesn't work:

May 05 19:32:22 LS-GL2B6 systemd[1]: Stopping LSB: Daemon for Linkstation/Kuro 
micro controller...
May 05 19:32:23 LS-GL2B6 micro-evtd[578]: Stopping Daemon for Linkstation/Kuro 
micro controller: micro-evtd
May 05 19:32:23 LS-GL2B6 micro-evtd[587]: start-stop-daemon: matching on 
world-writable pidfile /var/run/micro-evtd.pid is insecure
May 05 19:32:23 LS-GL2B6 systemd[1]: micro-evtd.service: Control process 
exited, code=exited, status=2/INVALIDARGUMENT
May 05 19:32:23 LS-GL2B6 systemd[1]: micro-evtd.service: Failed with result 
'exit-code'.
May 05 19:32:23 LS-GL2B6 systemd[1]: micro-evtd.service: Unit process 563 
(micro-evtd) remains running after unit stopped.
May 05 19:32:23 LS-GL2B6 systemd[1]: Stopped LSB: Daemon for Linkstation/Kuro 
micro controller.

According to the man page of start-stop-daemon, this would affect the version 
in buster as well.

Bug#988083: unblock: micro-evtd/3.4-6

[Ryan Tandy]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package micro-evtd

[ Reason ]

One-line patch to fix FTBFS (#987631). Also taking the opportunity to 
update the Maintainer field; I hope that's OK.


[ Impact ]

The package currently in bullseye (same as buster) works, however it 
FTBFS with bullseye's glibc.


[ Tests ]

There are no automated tests. I have been running the updated daemon for 
a few days, and I tested an installation with the updated udeb (using a 
d-i daily image).


[ Risks ]

I built the package on buster with and without the patch, to see what 
would change. The disassembly (objdump -d) was the same before and 
after, so I think I can be confident the header was not actually used 
and the patch should not change its behaviour.


However, the package had not been rebuilt since before buster was 
released, so there could be unknown risks arising from rebuilding with 
the newer toolchain.


[ Checklist ]

 [✔] all changes are documented in the d/changelog
 [✔] I reviewed all changes and I approve them
 [✔] attach debdiff against the package in testing

[ Other info ]

Very low popcon. The package provides hardware support for a specific 
subset of armel/orion5x NAS devices with few remaining users.


The package builds a udeb. I tested an installation using a daily d-i 
image that includes the update.


unblock micro-evtd/3.4-6

thanks,
Ryan
diff -Nru micro-evtd-3.4/debian/changelog micro-evtd-3.4/debian/changelog
--- micro-evtd-3.4/debian/changelog 2019-01-03 21:12:25.0 -0800
+++ micro-evtd-3.4/debian/changelog 2021-05-03 20:22:09.0 -0700
@@ -1,3 +1,18 @@
+micro-evtd (3.4-6) unstable; urgency=medium
+
+  [ Ryan Tandy ]
+  * Fix FTBFS with glibc 2.30 (Closes: #987631)
+  * Remove myself as Maintainer, and move Roger Shimizu from Uploaders to
+Maintainer, with his agreement.
+
+  [ Roger Shimizu ]
+  * debian/control:
+- Update to use my debian address.
+  * debian/patches:
+- Add ticket number to patch 0007.
+
+ -- Roger Shimizu   Tue, 04 May 2021 12:22:09 +0900
+
 micro-evtd (3.4-5) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru micro-evtd-3.4/debian/control micro-evtd-3.4/debian/control
--- micro-evtd-3.4/debian/control   2019-01-03 21:12:25.0 -0800
+++ micro-evtd-3.4/debian/control   2021-05-03 20:22:09.0 -0700
@@ -1,9 +1,8 @@
 Source: micro-evtd
 Section: utils
 Priority: optional
-Maintainer: Ryan Tandy 
+Maintainer: Roger Shimizu 
 Build-Depends: debhelper (>= 10)
-Uploaders: Roger Shimizu 
 Standards-Version: 3.9.8
 Homepage: http://www.sourceforge.net/projects/ppc-evtd
 Vcs-Browser: https://salsa.debian.org/debian/micro-evtd
diff -Nru micro-evtd-3.4/debian/patches/0007-Fix-FTBFS-with-glibc-2.30.patch 
micro-evtd-3.4/debian/patches/0007-Fix-FTBFS-with-glibc-2.30.patch
--- micro-evtd-3.4/debian/patches/0007-Fix-FTBFS-with-glibc-2.30.patch  
1969-12-31 16:00:00.0 -0800
+++ micro-evtd-3.4/debian/patches/0007-Fix-FTBFS-with-glibc-2.30.patch  
2021-05-03 20:22:09.0 -0700
@@ -0,0 +1,21 @@
+From: Ryan Tandy 
+Date: Sat, 1 May 2021 10:57:36 -0700
+Subject: Fix FTBFS with glibc 2.30
+
+Closes: #987631
+---
+ src/micro-evtd.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/src/micro-evtd.c b/src/micro-evtd.c
+index c8d6909..da91549 100644
+--- a/src/micro-evtd.c
 b/src/micro-evtd.c
+@@ -46,7 +46,6 @@
+ #include 
+ #include 
+ 
+-#include 
+ #include 
+ 
+ #include 
diff -Nru micro-evtd-3.4/debian/patches/series 
micro-evtd-3.4/debian/patches/series
--- micro-evtd-3.4/debian/patches/series2019-01-03 21:12:25.0 
-0800
+++ micro-evtd-3.4/debian/patches/series2021-05-03 20:22:09.0 
-0700
@@ -4,3 +4,4 @@
 0004-fix-typo-in-manpages.patch
 0005-Check-for-mmap-returning-MAP_FAILED.patch
 0006-Match-default-temperature-configuration-to-the-confi.patch
+0007-Fix-FTBFS-with-glibc-2.30.patch

Bug#987701: installation-reports: installation failed on Linkstation Pro: Out of memory during partitioning

[Ryan Tandy]

lowmem=2 worked nicely. I completed an installation successfully with 
that setting. Thanks!


Is there anything I can do to help improve the default experience on 
this target, besides documenting for others the process to set the extra 
bootarg in the u-boot environment?


thanks for your work on d-i,
Ryan

Bug#988033: slapd-contrib: It would be good to avoid generating sambaLMPassword hashes

[Ryan Tandy]

On Mon, May 03, 2021 at 06:08:40PM -0700, Diane Trout wrote:

If I understood how attributes could get added to the ldap schema it
might make sense to add something to the olcOverlay configuration to
allow disabling the LM password code path?

Maybe something like:

olcSmbK5PwdLMPasswordDisable: TRUE


I'm not likely to work on such a patch myself. I guess I could apply it 
if someone else wrote it, but reluctantly, because it would be another 
removed config element to deal with for upgrades to 2.5.


I think I'm coming to agree with you that the LM support should be 
deleted for bookworm (and bullseye-backports). The question remains 
whether it should be removed from bullseye as well. AFAIK the release is 
only a few weeks away, so I'm inclined to answer "it's too late", but I 
suppose I could be convinced otherwise.

Bug#988033: slapd-contrib: It would be good to avoid generating sambaLMPassword hashes

[Ryan Tandy]

Hi Diane,

Yes, the LM hash code has been removed upstream in the 2.5 series.

I don't know if I'd be comfortable removing the code from already 
released packages. One would hope no one actually uses it, but I have no 
way to know for sure.

Bug#987631: micro-evtd FTBFS with glibc 2.30

[Ryan Tandy]

Control: tag -1 pending

Thanks for the report.

I compiled the package with and without that include on buster, and the 
'objdump -d' output is the same, so I think it really was unused.

Bug#987701: installation-reports: installation failed on Linkstation Pro: Out of memory during partitioning

[Ryan Tandy]

Hi, thanks for the quick follow-up.

On Wed, Apr 28, 2021 at 07:35:00AM +0200, Cyril Brulebois wrote:

Or are you already aware of this, and don't know how to pass the extra
option via TFTP?


The latter: I don't have any access to the bootloader (serial or 
otherwise) so I don't think I have a way to append kernel args for TFTP 
boot.


I've just remembered, though, that the config-debian script that lives 
beside the images demonstrates how to change the bootloader config, so I 
can probably do it that way if I put the installer images on disk. I'll 
try that next (pending figuring out why fw_printenv/setenv seem to be 
unhappy with my fw_env.config).

Bug#987701: installation-reports: installation failed on Linkstation Pro: Out of memory during partitioning

[Ryan Tandy]

Package: installation-reports
Severity: important
Tags: d-i

Dear Maintainer,

Bullseye RC1 fails to install on my Linkstation Pro (LS-GL). It runs out 
of memory just after confirming the partitions, when it starts to format 
the disk, and the installation process gets killed. Ironically, I think 
this is happening only seconds before it would format and activate the 
swap partition.

The Linkstation Pro is an orion5x NAS with 128MB RAM. I checked the 
Installation Guide; it says that the installer's memory requirement is 
80 MB. https://www.debian.org/releases/testing/armel/ch02s05.en.html

The installation images were retrieved from: 
https://deb.debian.org/debian/dists/testing/main/installer-armel/current/images/orion5x/network-console/buffalo/lspro_ls-gl/

I have (re-)installed buster successfully. The installation process uses 
some swap (especially during 'apt-get update') but does eventually 
complete. I upgraded it to bullseye, no problem.

I am attaching the full syslog from a failed attempt at installing 
bullseye. Please let me know if I can provide any other information.

I am booting this network-console image over TFTP... I guess there's no 
easy way to provide the 'lowmem' boot parameter. I'd have to modify and 
rebuild the install image (probably the initrd)?

thanks,
Ryan
Jan  1 00:00:16 syslogd started: BusyBox v1.30.1
Jan  1 00:00:16 kernel: klogd started: BusyBox v1.30.1 (Debian 1:1.30.1-6+b1)
Jan  1 00:00:16 kernel: [0.00] Booting Linux on physical CPU 0x0
Jan  1 00:00:16 kernel: [0.00] Linux version 5.10.0-6-marvell 
(debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU 
ld (GNU Binutils for Debian) 2.35.2) #1 Debian 5.10.28-1 (2021-04-09)
Jan  1 00:00:16 kernel: [0.00] CPU: Feroceon [41069260] revision 0 
(ARMv5TEJ), cr=a005317f
Jan  1 00:00:16 kernel: [0.00] CPU: VIVT data cache, VIVT instruction 
cache
Jan  1 00:00:16 kernel: [0.00] OF: fdt: Machine model: Buffalo 
Linkstation Pro/Live
Jan  1 00:00:16 kernel: [0.00] Memory policy: Data cache writeback
Jan  1 00:00:16 kernel: [0.00] Zone ranges:
Jan  1 00:00:16 kernel: [0.00]   Normal   [mem 
0x-0x07ff]
Jan  1 00:00:16 kernel: [0.00]   HighMem  empty
Jan  1 00:00:16 kernel: [0.00] Movable zone start for each node
Jan  1 00:00:16 kernel: [0.00] Early memory node ranges
Jan  1 00:00:16 kernel: [0.00]   node   0: [mem 
0x-0x07ff]
Jan  1 00:00:16 kernel: [0.00] Initmem setup node 0 [mem 
0x-0x07ff]
Jan  1 00:00:16 kernel: [0.00] On node 0 totalpages: 32768
Jan  1 00:00:16 kernel: [0.00]   Normal zone: 256 pages used for memmap
Jan  1 00:00:16 kernel: [0.00]   Normal zone: 0 pages reserved
Jan  1 00:00:16 kernel: [0.00]   Normal zone: 32768 pages, LIFO batch:7
Jan  1 00:00:16 kernel: [0.00] pcpu-alloc: s0 r0 d32768 u32768 
alloc=1*32768
Jan  1 00:00:16 kernel: [0.00] pcpu-alloc: [0] 0 
Jan  1 00:00:16 kernel: [0.00] Built 1 zonelists, mobility grouping on. 
 Total pages: 32512
Jan  1 00:00:16 kernel: [0.00] Kernel command line: 
console=ttyS0,115200 root=/dev/sda2 rw initrd=0x00800040,15M panic=5 
BOOTVER=1.10 tftpboot=yes
Jan  1 00:00:16 kernel: [0.00] Dentry cache hash table entries: 16384 
(order: 4, 65536 bytes, linear)
Jan  1 00:00:16 kernel: [0.00] Inode-cache hash table entries: 8192 
(order: 3, 32768 bytes, linear)
Jan  1 00:00:16 kernel: [0.00] mem auto-init: stack:off, heap alloc:on, 
heap free:off
Jan  1 00:00:16 kernel: [0.00] Memory: 106908K/131072K available (4732K 
kernel code, 830K rwdata, 1312K rodata, 292K init, 224K bss, 24164K reserved, 
0K cma-reserved, 0K highmem)
Jan  1 00:00:16 kernel: [0.00] random: get_random_u32 called from 
cache_random_seq_create+0x60/0x110 with crng_init=0
Jan  1 00:00:16 kernel: [0.00] SLUB: HWalign=32, Order=0-3, 
MinObjects=0, CPUs=1, Nodes=1
Jan  1 00:00:16 kernel: [0.00] ftrace: allocating 8 entries in 44 
pages
Jan  1 00:00:16 kernel: [0.00] ftrace: allocated 44 pages with 3 groups
Jan  1 00:00:16 kernel: [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated 
irqs: 16
Jan  1 00:00:16 kernel: [0.00] clocksource: orion_clocksource: mask: 
0x max_cycles: 0x, max_idle_ns: 11467562657 ns
Jan  1 00:00:16 kernel: [0.28] sched_clock: 32 bits at 166MHz, 
resolution 6ns, wraps every 12884901885ns
Jan  1 00:00:16 kernel: [0.000116] Switching to timer-based delay loop, 
resolution 6ns
Jan  1 00:00:16 kernel: [0.000349] Calibrating delay loop (skipped), value 
calculated using timer frequency.. 333.33 BogoMIPS (lpj=66)
Jan  1 00:00:16 kernel: [0.000417] pid_max: default: 32768 minimum: 301
Jan  1 00:00:16 kernel: [0.001220] LSM: Security Framework initializing
Jan  1 00:00:16 kernel: [0.001775] Yama: 

Bug#987583: unblock: mgba/0.8.4+dfsg-2 (pre-approval)

[Ryan Tandy]

dfsg/debian/changelog
--- mgba-0.8.4+dfsg/debian/changelog2020-11-01 18:31:10.0 -0800
+++ mgba-0.8.4+dfsg/debian/changelog2021-04-20 18:31:14.0 -0700
@@ -1,3 +1,24 @@
+mgba (0.8.4+dfsg-2) UNRELEASED; urgency=medium
+
+  * Add upstream patches to remove unused OpenGL code from the libretro core
+and fix its undefined references. (Closes: #986986)
+- debian/patches/CMake-Move-gl.c-and-gles2.c-to-FEATURE_SRC.patch
+- debian/patches/CMake-Move-BUILD_GL-flags-to-FEATURE_DEFINES.patch
+  * Add upstream patch to fix PC alignment check when loading a save state.
+- debian/patches/GBA-Serialize-Fix-alignment-check-when-loading-state.patch
+  * Add upstream patch to fix crash when unloading a Game Boy ROM in a
+libretro frontend that doesn't implement the camera interface.
+- debian/patches/Libretro-Only-set-camera-peripheral-when-it-is-avail.patch
+  * Add upstream patches to fix crashes identified by fuzz testing.
+- debian/patches/Core-Fix-destroying-an-mVL-with-an-invalid-channel-c.patch
+- debian/patches/GB-MBC-Remove-unused-SRAM-size.patch
+- debian/patches/GB-MBC-Force-minimum-SRAM-size-on-rare-MBCs-that-alw.patch
+- debian/patches/GB-Video-Don-t-rendering-negative-batches.patch
+- debian/patches/GB-Video-Fix-deserializing-negative-LX-state.patch
+- debian/patches/GB-Video-Discard-SGB-packets-in-non-SGB-mVLs.patch
+
+ -- Ryan Tandy   Tue, 20 Apr 2021 18:31:14 -0700
+
 mgba (0.8.4+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
mgba-0.8.4+dfsg/debian/patches/CMake-Move-BUILD_GL-flags-to-FEATURE_DEFINES.patch
 
mgba-0.8.4+dfsg/debian/patches/CMake-Move-BUILD_GL-flags-to-FEATURE_DEFINES.patch
--- 
mgba-0.8.4+dfsg/debian/patches/CMake-Move-BUILD_GL-flags-to-FEATURE_DEFINES.patch
   1969-12-31 16:00:00.0 -0800
+++ 
mgba-0.8.4+dfsg/debian/patches/CMake-Move-BUILD_GL-flags-to-FEATURE_DEFINES.patch
   2021-04-20 18:31:14.0 -0700
@@ -0,0 +1,56 @@
+From 2e2ad705500f0f52769c14b6f9722def9057633c Mon Sep 17 00:00:00 2001
+From: Vicki Pfau 
+Date: Wed, 25 Nov 2020 21:16:30 -0800
+Subject: [PATCH] CMake: Move BUILD_GL flags to FEATURE_DEFINES
+
+---
+ CMakeLists.txt | 15 +++
+ 1 file changed, 3 insertions(+), 12 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 16c44c14c..49ca879d1 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -457,17 +457,20 @@ if(NOT BUILD_GLES2)
+ endif()
+ if(BUILD_GL)
+   list(APPEND FEATURE_SRC 
${CMAKE_CURRENT_SOURCE_DIR}/src/platform/opengl/gl.c)
++  list(APPEND FEATURE_DEFINES BUILD_GL)
+   list(APPEND DEPENDENCY_LIB ${OPENGL_LIBRARY})
+   include_directories(${OPENGL_INCLUDE_DIR})
+ endif()
+ if(BUILD_GLES2)
+   list(APPEND FEATURE_SRC 
${CMAKE_CURRENT_SOURCE_DIR}/src/platform/opengl/gles2.c)
++  list(APPEND FEATURE_DEFINES BUILD_GLES2)
+   list(APPEND DEPENDENCY_LIB ${OPENGLES2_LIBRARY})
+   include_directories(${OPENGLES2_INCLUDE_DIR})
+ endif()
+ if(BUILD_GLES3)
+   find_path(OPENGLES3_INCLUDE_DIR NAMES GLES3/gl3.h)
+   find_library(OPENGLES3_LIBRARY NAMES GLESv3 GLESv2)
++  list(APPEND FEATURE_DEFINES BUILD_GLES3)
+   if(NOT OPENGLES3_INCLUDE_DIR OR NOT OPENGLES3_LIBRARY)
+   set(BUILD_GLES3 OFF CACHE BOOL "OpenGL|ES 3 not found" FORCE)
+   endif()
+@@ -912,18 +915,6 @@ else()
+   endif()
+ endif()
+ 
+-if(BUILD_GL)
+-  add_definitions(-DBUILD_GL)
+-endif()
+-
+-if(BUILD_GLES2)
+-  add_definitions(-DBUILD_GLES2)
+-endif()
+-
+-if(BUILD_GLES3)
+-  add_definitions(-DBUILD_GLES3)
+-endif()
+-
+ if(DISABLE_FRONTENDS)
+   set(BUILD_SDL OFF)
+   set(BUILD_QT OFF)
+-- 
+2.20.1
+
diff -Nru 
mgba-0.8.4+dfsg/debian/patches/CMake-Move-gl.c-and-gles2.c-to-FEATURE_SRC.patch 
mgba-0.8.4+dfsg/debian/patches/CMake-Move-gl.c-and-gles2.c-to-FEATURE_SRC.patch
--- 
mgba-0.8.4+dfsg/debian/patches/CMake-Move-gl.c-and-gles2.c-to-FEATURE_SRC.patch 
1969-12-31 16:00:00.0 -0800
+++ 
mgba-0.8.4+dfsg/debian/patches/CMake-Move-gl.c-and-gles2.c-to-FEATURE_SRC.patch 
2021-04-20 18:31:14.0 -0700
@@ -0,0 +1,56 @@
+From a1c0318290b52302d919c33ce71763fc90353e4f Mon Sep 17 00:00:00 2001
+From: Vicki Pfau 
+Date: Tue, 24 Nov 2020 22:26:45 -0800
+Subject: [PATCH] CMake: Move gl.c and gles2.c to FEATURE_SRC
+
+---
+ CMakeLists.txt | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index a0912d7f8..16c44c14c 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -423,6 +423,7 @@ endif()
+ # Feature dependencies
+ set(FEATURE_DEFINES)
+ set(FEATURE_FLAGS)
++set(FEATURE_SRC)
+ set(FEATURES)
+ set(ENABLES)
+ if(CMAKE_SYSTEM_NAME MATCHES ".*BSD|DragonFly")
+@@ -455,12 +456,12 @@ if(NOT BUILD_GLES2)
+   set(OPENGLES2_LIBRARY "" CACHE PATH "" FORCE)
+ endif()
+ if(BUILD_GL)
+-  list(APPEND OS_SRC ${CMAKE_CURRENT_SOURCE_DIR}/src/platform/opengl/gl.c)
++  list(APPEND FEA

Bug#986986: libretro-mgba: doesn't work in retro-runner: undefined symbol: glUniform2i

[Ryan Tandy]

Package: libretro-mgba
Version: 0.8.4+dfsg-1
Severity: important
Control: affects -1 gnome-games-app

In bullseye, invoking libretro-gba from GNOME Games doesn't work. Other cores 
such as nestopia and bsnes are working fine.

I debugged into retro-runner and got this:

(gdb) n
100 in ../../../gmodule/gmodule-dl.c
(gdb) p handle
$2 = (gpointer) 0x0
(gdb) p dlerror()
$3 = 0x7fffe8015030 "/usr/lib/x86_64-linux-gnu/libretro/mgba_libretro.so: undefined 
symbol: glUniform2i"

I guess libretro-mgba needs to link -lGL.

It does work in retroarch, but I'm guessing that's probably by coincidence, as 
retroarch already links -lGL itself.

-- System Information:
Debian Release: bullseye/sid
 APT prefers testing
 APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libretro-mgba depends on:
ii  gnome-games-app [libretro-frontend]  3.38.0-1
ii  libc62.31-11
ii  libinih1 53-1+b2
ii  retroarch1.7.3+dfsg1-1.1+b2
ii  zlib1g   1:1.2.11.dfsg-2

libretro-mgba recommends no packages.

libretro-mgba suggests no packages.

-- no debconf information

Bug#983873: retroarch: Menu freezes shortly after start

[Ryan Tandy]

On Sat, Mar 13, 2021 at 09:58:59AM +0100, Pelle wrote:
I notice a similar bug in other packages in Debian Sid, such as 
ChessX. Would it make sense to report a bug with each of those 
packages, or would this be considered an issue with Sway / wlroots / 
xdg-shell?


Please report a separate bug against each package you have an issue 
with. The maintainers will merge or reassign them if appropriate.

Bug#983873: retroarch: Menu freezes shortly after start

[Ryan Tandy]

Thank you for providing the additional info.

Are you using sway as compositor? I reproduced the freezing behaviour 
when running under sway. In a GNOME session on Wayland, retroarch seems 
to work fine.


If that is correct, I think I will downgrade the severity of this bug, 
as retroarch is working on X11 and even on some Wayland setups - at 
least Mutter which (in bullseye) still supports wl-shell.


The key part of the log:

On Fri, Mar 12, 2021 at 02:51:24PM +0100, Pelle wrote:

  [INFO] [Wayland]: Seat name: seat0.
  [INFO] [Wayland]: Physical width: 380 mm x 210 mm.
  [INFO] [Wayland]: Video mode: 1600 x 900 @ 60.0830 Hz.
  [INFO] [Wayland]: Setting buffer scale factor to 1.
  [ERROR] [Wayland]: Failed to create shell.
  [INFO] [GLX]: GLX_OML_sync_control and GLX_MESA_swap_control supported, using 
better swap control method...
  [INFO] [GL]: Found GL context: x
  [INFO] [GL]: Detecting screen resolution 1600x900.
  [INFO] [GLX]: Window manager is wlroots wm.


Running under GNOME, I got this instead:

[INFO] [Wayland]: Physical width: 330 mm x 210 mm.
[INFO] [Wayland]: Video mode: 1680 x 1050 @ 60.1080 Hz.
[INFO] [Wayland]: Setting buffer scale factor to 1.
[INFO] [Wayland]: Seat name: seat0.
[INFO] [EGL] Found EGL client version >= 1.5, trying eglGetPlatformDisplay
[INFO] [EGL]: EGL version: 1.4
[INFO] [Wayland]: Loaded keymap.
[INFO] [GL]: Found GL context: wayland

The message "Failed to create shell" helped me find what I think is the 
corresponding upstream issue:


https://github.com/libretro/RetroArch/issues/7064

PR#7607 is linked as fixing it but it sounds like there might have been 
follow-up changes as well.


It's unfortunate that retroarch wasn't updated for bullseye, but I'm not 
sure trying to backport the xdg-shell feature to this version of 
retroarch is a good idea now that bullseye is in hard freeze.


thanks,
Ryan

Bug#983873: retroarch: Menu freezes shortly after start

[Ryan Tandy]

Control: tag -1 moreinfo

Hello Pelle and thank you for reporting this retroarch issue.

On Tue, 02 Mar 2021 16:10:32 +0100 Pelle  wrote:

When launching RetroArch, the menu freezes up instantly or after a couple of
seconds.


This isn't happening on my system. I can use the menu normally, launch 
content, etc.


Can you provide some more information about your environment? I'm using 
X11 (not Wayland) on an Intel GPU. I also don't have any controller 
connected, only mouse and keyboard.


Could you please run it as "retroarch --verbose" and post some or all of 
the output up to the point where it freezes? There are also some 
troubleshooting tips on the upstream site:

https://docs.libretro.com/guides/generating-retroarch-logs/

Would it be possible for you to install the debug symbols and capture a 
backtrace when it's frozen?

https://wiki.debian.org/HowToGetABacktrace


A work-around is to change the settings in .config/retroarch/retroarch.cfg
menu_driver = "rgui"
video_driver = "sdl2"


Just to confirm, I checked my config after starting it for the first 
time, and I got these defaults:


menu_driver = "xmb"
video_driver = "gl"

and did not experience any freezes.


The issue appears to be resolved in v1.9.0 which is the version currently
available as flatpak.


If the 1.9.0 you tested was the flatpak, I wonder whether it's possible 
for you to also to test a flatpak of 1.7.3, in case there is a relevant 
difference in the build environment or the libraries used?


Thank you!

Ryan

Bug#895091: openldap: Please replace 'c_rehash' with 'openssl rehash'

[Ryan Tandy]

Control: tag -1 fixed-upstream

https://git.openldap.org/openldap/openldap/-/commit/58caa2f8877d0c8562932fe063c401b0be9c19c6

Bug#932093: Bug#944114: Missing directory spec in Remap secdeb rule

[Ryan Tandy]

On Sat, Feb 20, 2021 at 07:48:41PM +0100, Eduard Bloch wrote:

Ok, so I think the default configuration has been PITA for some people
for the last couple of years and I am sorry. I intend to modify the
default mapping as shown below, or see:

https://salsa.debian.org/blade/apt-cacher-ng/-/commit/3090d97ed9794a64f509917c77f0bb7ebccf1fbf

Is this something we can agree on? I am not so sure about using
deb.debian.org as default backend.


Looks good to me. Including both security.d.o and deb.d.o as backends 
seems reasonable. I don't have any idea about which would be better as 
default. AFAIK security.d.o is also some kind of CDN, or at least 
mirrored/aliased.


Thanks again for maintaining acng.
Ryan

Bug#982147: mgba: Please provide a libmgba-dev package

[Ryan Tandy]

On Mon, Feb 08, 2021 at 01:59:46AM +0100, Celelibi wrote:

I opened a github issue asking for an official stance.
https://github.com/mgba-emu/mgba/issues/2042


Great - I'm happy to go ahead with this based on endrift's response 
there. Thank you for driving this!


I'm afraid it's too late to have this for Debian 11 (bullseye), but I 
can work on the changes in a git branch during the freeze.


Ryan

Bug#982147: mgba: Please provide a libmgba-dev package

[Ryan Tandy]

On Sun, Feb 07, 2021 at 10:05:38PM +0100, Celelibi wrote:

The program I'm writing would be an IRC bot a-la twitch-plays-pokemon. I
don't think it would be a good candidate for inclusion in Debian as I
intend it to be a quick-and-dirty program for my specific needs.


OK. Sounds fun. :)


I have no idea of an ABI compatibility policy. I'm not sure there's one
right now.


OK.


However, the CMakeLists.txt already contains everything needed to
install headers. So I guess there's an intent toward this usage even if
the support (especially regarding ABI stability) isn't well thought out.


Sure. I didn't mean to suggest that the library isn't meant to be used. 
In fact, It looks like upstream's own .deb packages also include 
mgba-dev as well as libmgba. However, for publishing it in Debian, it 
needs to meet the requirements set by Debian policy for shared 
libraries. (And I'm not even saying that it doesn't, only that I don't 
know whether it does or not.)



All I can say for sure right now is that the ABI will likely break with
version 0.9 because of a new field in the struct Table.


That's fine, as long as the SONAME also changes.


What exactly would be needed from the author of libmgba to make it
suitable as a public library? Would it be enough if they set a rule
saying that the minor version would be bumped at least on every ABI
break?


Specifically, we would want a commitment that there will not be any 
incompatible ABI change without a corresponding SONAME change. If the 
SONAME is tied to the minor version, then yes, what you said achieves 
that. The SONAME change is our trigger to recompile applications; if it 
doesn't change, we (want to) assume they don't need to be rebuilt.


This may well be how it works already. I just haven't found a written 
statement about it.


thanks,
Ryan