Bug#499858: x11proto-xext-dev: Missing libxi-dev dependency

[Bryce Harrington]

Subject: x11proto-xext-dev: Missing libxi-dev dependency
Package: x11proto-xext-dev
Version: 7.0.2-6build1
Severity: important
Tags: patch

(https://bugs.edge.launchpad.net/ubuntu/+source/x11proto-xext/+bug/273386)

/usr/include/X11/Extensions/XInput.h, which is included in
X11/Extensions/XTest.h, has moved from x11proto-input-dev to libx1-dev.
As a result, it seems that x11proto-xext-dev (or perhaps
x11proto-input-dev) needs to have a Depend added for libxi-dev.

This manifested as a FTBFS with synergy which has a BuildDep on
x11proto-xext-dev, but fails needing XInput.h.


diff -Nru x11proto-xext-7.0.2/debian/changelog 
x11proto-xext-7.0.2/debian/changelog
--- x11proto-xext-7.0.2/debian/changelog2008-09-22 17:28:16.0 
-0700
+++ x11proto-xext-7.0.2/debian/changelog2008-09-22 17:28:16.0 
-0700
@@ -1,3 +1,11 @@
+x11proto-xext (7.0.2-6build2) hardy; urgency=low
+
+  * control: Add dependency on libxi-dev.  XInput.h has moved from the
+x11proto-input-dev package to libxi-dev, so packages that include
+XTest.h would FTBS.  (LP: #273386)
+
+ -- Bryce Harrington [EMAIL PROTECTED]  Mon, 22 Sep 2008 17:22:20 -0700
+
 x11proto-xext (7.0.2-6build1) intrepid; urgency=low
 
   * Fakesync with Debian unstable (different .orig.tar.gz)
diff -Nru /tmp/RchLBO5iHg/x11proto-xext-7.0.2/debian/control 
/tmp/ZIi1gs3cTc/x11proto-xext-7.0.2/debian/control
--- x11proto-xext-7.0.2/debian/control  2008-09-22 17:28:16.0 -0700
+++ x11proto-xext-7.0.2/debian/control  2008-09-22 17:28:16.0 -0700
@@ -10,7 +10,7 @@
 
 Package: x11proto-xext-dev
 Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, x11proto-input-dev, libxau-dev
+Depends: ${shlibs:Depends}, ${misc:Depends}, x11proto-input-dev, libxau-dev, 
libx1-dev
 Conflicts: libxext-dev ( 6.8.2-25), libxtst-dev ( 6.8.2-25)
 Replaces: libxext-dev ( 6.8.2-25), libxtst-dev ( 6.8.2-25)
 Pre-Depends: x11-common (= 1:7.0.0)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#430545: Corrupt display when installing packages

[Bryce Harrington]

Hi David,

We ran into this bug on Ubuntu (e.g. LP# 127008).  The xprobe.sh script
fails on Intel laptop hardware during configure when using the -intel
driver.  This cropped up after -intel driver support was added.  I also
fixed a number of other issues in xresprobe you might be interested in,
although I know the goal is to get rid of xresprobe entirely.

The two patches that fixed this for us are:

http://people.ubuntu.com/~bryce/Testing/xresprobe/xresprobe_0.4.24ubuntu5.debdiff

http://people.ubuntu.com/~bryce/Testing/xresprobe/xresprobe_0.4.24ubuntu8.debdiff

Basically, we avoid using xprobe.sh for -intel.  doddc probe seems to
work adequately, and where it doesn't we just let the postinst ask the
user (this is better than corrupting out the display).

Bryce


diff -Nru /tmp/wEaX1jNQd9/xresprobe-0.4.24ubuntu4/xresprobe 
/tmp/n0birC4Yl7/xresprobe-0.4.24ubuntu5/xresprobe
--- /tmp/wEaX1jNQd9/xresprobe-0.4.24ubuntu4/xresprobe   2006-04-08 
06:52:21.0 -0700
+++ /tmp/n0birC4Yl7/xresprobe-0.4.24ubuntu5/xresprobe   2007-09-27 
14:37:25.0 -0700
@@ -137,7 +137,8 @@
 fi
 
 if [ x$LAPTOP = xyes ]; then
-  if [ $(uname -m) = ppc ] || [ $(uname -m) = ppc64 ]; then
+  # Allow use of ddc on intel; doprobe can result in screen corruption (LP: 
#127008)
+  if [ $(uname -m) = ppc ] || [ $(uname -m) = ppc64 ] || [ x$DRIVER 
= xintel ]; then
 doddc
   fi
   if [ -z $RES ]; then


diff -Nru /tmp/5BOwBjIGdL/xresprobe-0.4.24ubuntu7/xresprobe 
/tmp/XntHvitxcw/xresprobe-0.4.24ubuntu8/xresprobe
--- /tmp/5BOwBjIGdL/xresprobe-0.4.24ubuntu7/xresprobe   2007-10-15 
00:18:19.0 -0700
+++ /tmp/XntHvitxcw/xresprobe-0.4.24ubuntu8/xresprobe   2007-10-15 
01:53:08.0 -0700
@@ -141,7 +141,7 @@
   if [ $(uname -m) = ppc ] || [ $(uname -m) = ppc64 ] || [ x$DRIVER 
= xintel ]; then
 doddc
   fi
-  if [ -z $RES ]  [ ! $x$DRIVER = xintel ]; then
+  if [ -z $RES ]  [ ! x$DRIVER = xintel ]; then
 doprobe
   fi
   DISPTYPE=lcd/lvds



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#343840: inkscape: there should be per-user default templates

[Bryce Harrington]

This functionality is available in Inkscape since 0.44.  This patch can
be closed now.

Bryce


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#342388: please set up /usr/share/inkscape/default.svg automagicallly (not just A4)

[Bryce Harrington]

This feature is implemented since 0.44, so this patch can be closed.

Bryce


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#490258: info locals

[Bryce Harrington]

(gdb) info locals
info = value optimized out
rep = {type = 1 '\001', status = 160 'garbage', sequenceNumber = 12, length = 
8, timestamp = 2229926, crtc = 0, mmWidth = 0,  mmHeight = 0, connection = 0 
'\0', subpixelOrder = 5 '\005', nCrtcs = 1, nModes = 4, nPreferred = 0, nClones 
= 0,  nameLength = 7}
nbytes = 28
nbytesRead = 28
xoi = value optimized out



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#503251: xorg-server: Xorg should keep more rotated logs

[Bryce Harrington]

Severity: wishlist
Package: xorg-server
Version: All
Severity: wishlist
User: [EMAIL PROTECTED]
Usertags: origin-ubuntu intrepid


Forwarding this wishlist bug from a Ubuntu reporter:
https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/274870

Currently Xorg keeps only its current log and old older one. While this
is normally fine, there are situations where logs from a failed run can
disappear (e.g. the first run wedges your graphics hardware, so the
subsequent runs from GDM fail for different reasons and leave unhelpful
logs. GDM tries several times, so the original log will be lost).

While that is indeed a rare corner case, given how small they are, I
think it's probably worth keeping 5 or 6 old logs. There may be other
situations where being able to compare several runs, or pull an error
out of an older log, are useful.


So I'm gathering the idea would be to have something like Xorg.0.log,
Xorg.0.log.1.gz, Xorg.0.log.2.gz, etc.

-- System Information:
Debian Release: lenny/sid
  APT prefers intrepid-security
  APT policy: (500, 'intrepid-security'), (500, 'intrepid')
Architecture: i386 (i686)

Kernel: Linux 2.6.27-7-generic (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#504436: x11proto-gl-dev: Missing dependency for GL/gl.h include?

[Bryce Harrington]

Package: x11proto-gl-dev
Version: 1.4.9-1
Severity: important


Forwarding this bug from a Ubuntu reporter:
https://bugs.edge.launchpad.net/ubuntu/+source/x11proto-gl/+bug/292388

/usr/include/GL/glxint.h depends on /usr/include/GL/gl.h, provided by
the mesa-common-dev and nvidia-glx-*-dev packages.

The user is proposing the following dependency changes.  Would
appreciate your review/comments on this.

 Package: x11proto-gl-dev
 Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common (= 1:7.0.0)
+Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common (= 1:7.0.0),
 mesa-common-dev | nvidia-glx-173-dev | nvidia-glx-177-dev |
 nvidia-glx-71-dev | nvidia-glx-96-dev
 Replaces: xlibmesa-gl-dev
 Description: X11 OpenGL extension wire protocol
  This package provides development headers describing the wire protocol

-- System Information:
Debian Release: lenny/sid
  APT prefers intrepid-security
  APT policy: (500, 'intrepid-security'), (500, 'intrepid')
Architecture: i386 (i686)

Kernel: Linux 2.6.27-7-generic (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages x11proto-gl-dev depends on:
ii  x11-common1:7.4~5ubuntu2 X Window System (X.Org)
infrastruc

x11proto-gl-dev recommends no packages.

-- no debconf information




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#621409: vnc4: FTBFS on armel: macro 'in' not recognized -- ignoring

[Bryce Harrington]

hw/xfree86/common/compiler.h in the current Xserver has some
pre-processor conditional logic for __arm__, which needs ported
over to vnc4's older copy of this file.

More details:
 https://bugs.launchpad.net/ubuntu/+source/vnc4/+bug/945368/comments/2


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#928235: Reason for omission of client-pending patch?

[Bryce Harrington]

For CVE-2019-11494, three patches were provided by the vendor:

  https://seclists.org/oss-sec/2019/q2/82

In Ubuntu we included the three patches, but in updating our merge with
Debian I notice you included only the latter two.  Is this because the
first one suppresses a warning, and is considered non-critical?

Thank you,
Bryce

Bug#774970: Reviewed for ubuntu

[Bryce Harrington]

We're reviewing the change for inclusion in Ubuntu; we've found more
affected users.  First we wanted to check if Debian has had a chance to
look at merging this, or if there are any issues to consider?

Bug#941162: php-horde-mime: DEP-8 tests fail with error "Class 'Horde_Test_Case' not found".

[Bryce Harrington]

Package: php-horde-mime
Version: 2.11.0-2
Severity: normal

Dear Maintainer,

php-horde-mime fails its DEP-8 test with the error shown below, on
ci.debian.net, and similar failure was seen in Ubuntu.

PHP Fatal error:  Uncaught Error: Class 'Horde_Test_Case' not found in 
/tmp/autopkgtest.WKueSZ/build.G63/src/Horde_Mime-2.11.0/test/Horde/Mime/Filter/EncodingTest.php:26
Stack trace:
#0 /usr/share/php/PHPUnit/Util/FileLoader.php(57): include_once()
#1 /usr/share/php/PHPUnit/Util/FileLoader.php(45): 
PHPUnit\Util\FileLoader::load('/tmp/autopkgtes...')
#2 /usr/share/php/PHPUnit/Framework/TestSuite.php(540): 
PHPUnit\Util\FileLoader::checkAndLoad('/tmp/autopkgtes...')
#3 /usr/share/php/PHPUnit/Framework/TestSuite.php(618): 
PHPUnit\Framework\TestSuite->addTestFile('/tmp/autopkgtes...')
#4 /usr/share/php/PHPUnit/Runner/BaseTestRunner.php(70): 
PHPUnit\Framework\TestSuite->addTestFiles(Array)
#5 /usr/share/php/PHPUnit/TextUI/Command.php(183): 
PHPUnit\Runner\BaseTestRunner->getTest('.', '', Array)
#6 /usr/share/php/PHPUnit/TextUI/Command.php(162): 
PHPUnit\TextUI\Command->run(Array, true)
#7 /usr/bin/phpunit(42): PHPUnit\TextUI\Command::main()
#8 {main}
  thrown in 
/tmp/autopkgtest.WKueSZ/build.G63/src/Horde_Mime-2.11.0/test/Horde/Mime/Filter/EncodingTest.php
 on line 26

Debian log:

https://ci.debian.net/data/autopkgtest/unstable/amd64/p/php-horde-mime/3015914/log.gz
Ubuntu log:

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/p/php-horde-mime/20190913_195327_67b6b@/log.gz

I've added a patch in Ubuntu that works around the issue by adding an
include for AllTests.php.  (Is it possible AllTests.php is supposed to
be automatically included, yet isn't for some reason?)

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-62-generic (SMP w/6 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages php-horde-mime depends on:
ii  php-common   1:60ubuntu1
pn  php-horde-exception  
pn  php-horde-listheaders
pn  php-horde-mail   
pn  php-horde-stream 
pn  php-horde-stream-filter  
pn  php-horde-support
pn  php-horde-text-flowed
pn  php-horde-translation
pn  php-horde-util   

Versions of packages php-horde-mime recommends:
pn  php-horde-nls  
pn  php-horde-test 
pn  php-horde-text-filter  
pn  php-idn
pn  php-intl   
pn  php-net-dns2   

php-horde-mime suggests no packages.
Description: Fix test failure with "Class 'Horde_Test_Case' not found"
 Explicitly include AllTests.php to fix missing base class issue.  I get
 the impression this should really be automatically included but is not
 in our case.
Author: Bryce Harrington 
Origin: vendor
Last-Update: 2019-09-16

diff -Nurp php-horde-mime-2.11.0/Horde_Mime-2.11.0/test/Horde/Mime/Filter/EncodingTest.php php-horde-mime-2.11.0-fixed/Horde_Mime-2.11.0/test/Horde/Mime/Filter/EncodingTest.php
--- php-horde-mime-2.11.0/Horde_Mime-2.11.0/test/Horde/Mime/Filter/EncodingTest.php	2018-01-14 22:49:19.0 +
+++ php-horde-mime-2.11.0-fixed/Horde_Mime-2.11.0/test/Horde/Mime/Filter/EncodingTest.php	2019-09-13 21:40:17.263283745 +
@@ -1,4 +1,7 @@
 http://www.horde.org/)
  *

Bug#951220: openssh: Please include md5sum of shipped sshd_config in /usr/share/openssh/sshd_config.md5sum

[Bryce Harrington]

Source: openssh
Version: 1:8.1p1-5
Severity: important

Dear Maintainer,

Upgrading from stock 1:7.6p1-4 to 1:8.1p1-5, with no alterations to
sshd_config, results in a debconf prompt about changes to sshd_config.

>From my limited understanding, I suspect this is due to a missing md5sum
in openssh-server.ucf-md5sum.  At least, adding the md5sum
203e9b92fe3623aeba277ee44297f7dd seems to quell the prompt.

This issue is seen by Ubuntu users upgrading from 18.04 to 20.04:

   https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1861472

If this is, indeed, a proper fix, then it may be prudent to similarly
also add the md5sum of the sshd_config from 1:8.1p1-5,
18df1377273c4d51d4c03c9adc31021f.

Thank you,
Bryce

Bug#954955: phpunit-comparator: FTBFS from test failure due to warning about typo in test case

[Bryce Harrington]

Package: phpunit-comparator
Version: 3.0.2-1
Severity: normal

Dear Maintainer,

britney, debci, and ubuntu launchpad are seeing test failures while
building this package against PHP 7.4.

  "PHP Warning:  Creating default object from empty value in 
/usr/local/src/comparator/tests/MockObjectComparatorTest.php on line 95"

This is upstream bug #80:

  https://github.com/sebastianbergmann/comparator/issues/80

A trivial patch to fix the issue is attached to the bug report, and is
included in Ubuntu's phpunit-comparator version 3.0.2-1ubuntu1

  https://launchpad.net/ubuntu/+source/phpunit-comparator/3.0.2-1ubuntu1

This patch is applicable to Debian's package as well.

Bryce

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

Kernel: Linux 5.4.0-18-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#893481: libapache2-mod-php: Upgrade to php7.2 disables the php module

[Bryce Harrington]

It looks like the logic in the upgrader flags as an error if there are
previous enabled php mods enabled in apache.  It's a bit of a hack but
for ubuntu I changed the logic to make it disable those other mods; for
Ubuntu we always only support a single php version at a time, so this
should work for us.  I'm not sure this is suitable for Debian since
sometimes multiple php versions are supported.  However, at least this
could point to where a more generalized solution could be developed.

https://bugs.launchpad.net/ubuntu/+source/php7.4/+bug/1865218

On Mon, 19 Mar 2018 15:29:48 +0530 Sunil Mohan Adapa  wrote:
> Package: libapache2-mod-php
> Version: 1:7.2+60
> Severity: important
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Maintainer,
> 
> When an older version of libapache2-mod-php depending on libapache2-mod-php7.0
> is installed and upgraded to newer version, no php module is enabled.
> 
> One way to reproduce is as follows: first install an older version of
> libapache2-mode-php, such as in a fresh install of Debian stretch. This
> installs
> libapache2-mod-php7.0. Now upgrade to latest libapache2-mod-php, such as by
> upgrade to testing. This installs libapache2-mod-php7.2. However, php7.2 
> module
> is not enabled as php7.0 module is already enabled. After that, during
> autoremove, libapache2-mod-php7.0 is removed. Now, php7.0 is not
> enabled/installed and php7.2 is not enabled.
> 
> I expect that when libapache2-mod-php is installed, a php apache2 module is
> enabled and it stays that way even during upgrade from stable to testing.
> Currently, all FreedomBox users on testing are facing this issue due to
> dependency on libapache2-mod-php and the use of unattended-upgrades which auto
> removes packages.
> 
> For more details, see the following session (full logs are attached):
> 
> # apt install libapache2-mod-php
> 
> Edit /etc/apt/sources.list and s/stretch/testing/g
> 
> # apt update
> # apt dist-upgrade
> 
> [...]
> Setting up php-common (1:60) ...
> [...]
> Setting up php7.0-common (7.0.28-1) ...
> [...]
> Setting up libapache2-mod-php7.2 (7.2.3-1) ...
> Package apache2 is not configured yet. Will defer actions by package
> libapache2-mod-php7.2.
> 
> Creating config file /etc/php/7.2/apache2/php.ini with new version
> libapache2-mod-php7.2: php7.0 module already enabled, not enabling PHP 7.2
> [...]
> Setting up libapache2-mod-php7.0 (7.0.28-1) ...
> libapache2-mod-php7.0: not switching MPM - already enabled
> [...]
> 
> # a2query -m php7.0
> php7.0 (enabled by maintainer script)
> # a2query -m php7.2
> No module matches php7.2
> 
> # apt autoremove
> [...]
> The following packages will be REMOVED:


signature.asc
Description: PGP signature

Bug#961244: spamassassin: autopkgtest fails with python3

[Bryce Harrington]

Source: spamassassin
Version: 3.4.4-1
Severity: normal

Dear Maintainer,

I've posted a merge request for a fix to allow autopkgtest to run on
systems with either python2 or python3 as the default python version.

https://salsa.debian.org/debian/spamassassin/-/merge_requests/4

This issue was discovered in Ubuntu during a distro-wide check of
python2 dependence, and the above fix is being carried in Ubuntu's
spamassassin package.  While this does not currently affect Debian's CI,
it may become a problem if/when Debian deprecates python2.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-29-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#876365: Ubuntu patch

[Bryce Harrington]

This is a fix we have carried in the Ubuntu nginx package for this
issue.  If Debian can pick up this patch it'll help reduce the delta on
the Ubuntu side.

BryceDescription: Fix NGINX pidfile handling
Author: Tj 
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1581864
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876365
Last-Update: 2020-06-24
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
diff --git a/src/core/nginx.c b/src/core/nginx.c
index 9fcb0eb2..083eba1d 100644
--- a/src/core/nginx.c
+++ b/src/core/nginx.c
@@ -338,14 +338,21 @@ main(int argc, char *const *argv)
 ngx_process = NGX_PROCESS_MASTER;
 }
 
+/* tell-tale to detect if this is parent or child process */
+ngx_int_t child_pid = NGX_BUSY;
+
 #if !(NGX_WIN32)
 
 if (ngx_init_signals(cycle->log) != NGX_OK) {
 return 1;
 }
 
+/* tell-tale that this code has been executed */
+child_pid--;
+
 if (!ngx_inherited && ccf->daemon) {
-if (ngx_daemon(cycle->log) != NGX_OK) {
+child_pid = ngx_daemon(cycle->log);
+if (child_pid == NGX_ERROR) {
 return 1;
 }
 
@@ -358,8 +365,19 @@ main(int argc, char *const *argv)
 
 #endif
 
-if (ngx_create_pidfile(>pid, cycle->log) != NGX_OK) {
-return 1;
+/* If ngx_daemon() returned the child's PID in the parent process
+ * after the fork() set ngx_pid to the child_pid, which gets
+ * written to the PID file, then exit.
+ * For NGX_WIN32 always write the PID file
+ * For others, only write it from the parent process */
+if (child_pid < NGX_OK || child_pid > NGX_OK) {
+	ngx_pid = child_pid > NGX_OK ? child_pid : ngx_pid;
+if (ngx_create_pidfile(>pid, cycle->log) != NGX_OK) {
+return 1;
+	}
+}
+if (child_pid > NGX_OK) {
+exit(0);
 }
 
 if (ngx_log_redirect_stderr(cycle) != NGX_OK) {
diff --git a/src/os/unix/ngx_daemon.c b/src/os/unix/ngx_daemon.c
index 385c49b6..3719854c 100644
--- a/src/os/unix/ngx_daemon.c
+++ b/src/os/unix/ngx_daemon.c
@@ -7,14 +7,17 @@
 
 #include 
 #include 
+#include 
 
 
 ngx_int_t
 ngx_daemon(ngx_log_t *log)
 {
 int  fd;
+/* retain the return value for passing back to caller */
+pid_t pid_child = fork();
 
-switch (fork()) {
+switch (pid_child) {
 case -1:
 ngx_log_error(NGX_LOG_EMERG, log, ngx_errno, "fork() failed");
 return NGX_ERROR;
@@ -23,7 +26,8 @@ ngx_daemon(ngx_log_t *log)
 break;
 
 default:
-exit(0);
+/* let caller do the exit() */
+return pid_child;
 }
 
 ngx_parent = ngx_pid;

Bug#963668: debian/nginx-common.install

[Bryce Harrington]

The apport hook also needs this bit of delta added for installation:

--- a/debian/nginx-common.install
+++ b/debian/nginx-common.install
@@ -1,5 +1,6 @@
 contrib/vim/* usr/share/vim/addons
 debian/conf/* etc/nginx
+debian/apport/source_nginx.py usr/share/apport/package-hooks
 debian/ufw/nginx etc/ufw/applications.d
 debian/vim/nginx.yaml usr/share/vim/registry
 html/index.html usr/share/nginx/html/

Bug#963668: nginx: Please include ubuntu's apport hook for nginx

[Bryce Harrington]

Source: nginx
Severity: wishlist

Dear Maintainer,

Ubuntu's nginx package carries an apport hook for use in Ubuntu's CI to
validate the package.  It would help Ubuntu minimize delta with Debian
if you could include this apport hook in the Debian package.  Its
presence will have no effect on Debian's users.

I have attached debian/apport/source_nginx.py for your consideration.

Thank you,
Bryce


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-37-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
'''
apport package hook for nginx packages

Copyright (c) 2015, Thomas Ward 
'''

import apport.hookutils
import os
import subprocess

def add_info(report, ui):
if (report['Package'].split()[0] != 'nginx-common'
and report['ProblemType'] == 'Package'
and os.path.isdir('/run/systemd/system')):
report['Journalctl_Nginx.txt'] = apport.hookutils.command_output(
['journalctl', '-xe', '--unit=nginx.service'])
report['SystemctlStatusFull_Nginx.txt'] = subprocess.Popen(
['systemctl', '-l', 'status', 'nginx.service'],
stdout=subprocess.PIPE).communicate()[0]

Bug#927302: apache2ctl graceful can cause apache to run in a different cgroup

[Bryce Harrington]

Attached is our attempt for fixing this for ubuntu, I think this or
something like it should fix for Debian too.

Brycediff -Nru apache2-2.4.46/debian/apache2ctl apache2-2.4.46/debian/apache2ctl
--- apache2-2.4.46/debian/apache2ctl2020-08-05 11:40:13.0 -0700
+++ apache2-2.4.46/debian/apache2ctl2020-10-05 16:06:32.0 -0700
@@ -143,6 +143,18 @@
 fi
 }
 
+need_systemd () {
+# Detect if systemd is in use and should be used for managing
+# the Apache2 httpd service.  Returns 0 if so, 1 otherwise.
+if [ -z "${APACHE_STARTED_BY_SYSTEMD}" ]; then
+   case "$(readlink -f /proc/1/exe)" in
+   *systemd*)
+   return 0
+   ;;
+   esac
+fi
+return 1
+}
 
 [ ! -d ${APACHE_RUN_DIR:-/var/run/apache2} ] && mkdir -p 
${APACHE_RUN_DIR:-/var/run/apache2}
 [ ! -d ${APACHE_LOCK_DIR:-/var/lock/apache2} ] && mkdir_chown 
${APACHE_RUN_USER:-www-data} ${APACHE_LOCK_DIR:-/var/lock/apache2}
@@ -153,38 +165,38 @@
 # (this is bad if there are several apache2 instances running)
 rm -f ${APACHE_RUN_DIR:-/var/run/apache2}/*ssl_scache*
 
-need_systemd=false
-if [ -z "$APACHE_STARTED_BY_SYSTEMD" ] ; then
-case "$(readlink -f /proc/1/exe)" in
-*systemd*)
-need_systemd=true
-;;
-*)
-;;
-esac
-fi
-if $need_systemd ; then
+if need_systemd; then
 # If running on systemd we should not start httpd without systemd
 # or systemd will get confused about the status of httpd.
-echo "Invoking 'systemctl start $APACHE_SYSTEMD_SERVICE'."
-echo "Use 'systemctl status $APACHE_SYSTEMD_SERVICE' for more info."
-systemctl start "$APACHE_SYSTEMD_SERVICE"
+echo "Invoking 'systemctl start ${APACHE_SYSTEMD_SERVICE}'."
+echo "Use 'systemctl status ${APACHE_SYSTEMD_SERVICE}' for more info."
+systemctl start "${APACHE_SYSTEMD_SERVICE}"
 else
 unset APACHE_STARTED_BY_SYSTEMD
-$HTTPD ${APACHE_ARGUMENTS} -k "$ARGV"
+${HTTPD} ${APACHE_ARGUMENTS} -k "${ARGV}"
 fi
 
 ERROR=$?
 ;;
 stop|graceful-stop)
-$HTTPD ${APACHE_ARGUMENTS} -k "$ARGV"
+${HTTPD} ${APACHE_ARGUMENTS} -k "$ARGV"
 ERROR=$?
 ;;
 restart|graceful)
 if $HTTPD ${APACHE_ARGUMENTS} -t 2> /dev/null ; then
-$HTTPD ${APACHE_ARGUMENTS} -k "$ARGV"
+if need_systemd; then
+# If running on systemd we should not directly restart httpd since
+# systemd would be confused about httpd's status.
+# (See LP: #1832182)
+echo "Invoking 'systemctl restart ${APACHE_SYSTEMD_SERVICE}'."
+echo "Use 'systemctl status ${APACHE_SYSTEMD_SERVICE}' for more 
info."
+systemctl restart "${APACHE_SYSTEMD_SERVICE}"
+else
+unset APACHE_STARTED_BY_SYSTEMD
+${HTTPD} ${APACHE_ARGUMENTS} -k "${ARGV}"
+fi
 else
-$HTTPD ${APACHE_ARGUMENTS} -t
+${HTTPD} ${APACHE_ARGUMENTS} -t
 fi
 ERROR=$?
 ;;
diff -Nru apache2-2.4.46/debian/changelog apache2-2.4.46/debian/changelog
--- apache2-2.4.46/debian/changelog 2020-08-25 05:13:38.0 -0700
+++ apache2-2.4.46/debian/changelog 2020-10-05 16:06:32.0 -0700
@@ -1,3 +1,12 @@
+apache2 (2.4.46-1ubuntu2) groovy; urgency=medium
+
+  * d/apache2ctl: Also use systemd for graceful if it is in use.  This
+extends an earlier fix for the start command to behave similarly for
+restart / graceful.  Fixes service failures on unattended upgrade.
+(LP: #1832182)
+
+ -- Bryce Harrington   Mon, 05 Oct 2020 16:06:32 -0700
+
 apache2 (2.4.46-1ubuntu1) groovy; urgency=medium
 
   * Merge with Debian unstable. Remaining changes:

Bug#990322: Backport patch to allow kopanocore to build against PHP 8

[Bryce Harrington]

Source: kopanocore
Version: 8.7.0-7.1
Severity: normal
Tags: upstream patch

kopanocore 8.7.0-7.1 will FTBFS when built with PHP 8 or later.

This isn't an issue in debian currently since PHP 7.4 is still the
default.  For Ubuntu we've dropped 7.4 and moved to 8.0, and discovered
this failure.  Fortunately there is a patch available from upstream to
move to 8.0, however it does not apply cleanly on top of 8.7.0-7.1 due
to some intermediary refactoring in upstream's tree.  The original
upstream patch is:


https://github.com/Kopano-dev/kopano-core/commit/9b3bbd27ea63af180ce73a30a218d34b6e6535a4

At least one of the refactoring changes needed to make that apply is:


https://github.com/Kopano-dev/kopano-core/commit/b8d29e9f58440f1d75bddf77df3d25fd6367af20

However, there are some other differences such as changes for APIs not
included in 8.7.0-7.1, etc.  So I ended up doing a reimplementation of
the patch:

https://launchpad.net/ubuntu/+source/kopanocore/8.7.0-7.1ubuntu4

Please note one important addition I made to configure.ac to enable the
build:

+   AS_CASE([$PHP_VERSION],
+   [5.*], [with_php=5],
+-  [7.*], [with_php=7]
++  [7.*], [with_php=7],
++  [8.*], [with_php=7]

IOW this tricks the Makefile into treating PHP 8 as the same as PHP 7,
which for purposes of the build logic is fine.  However, this could
likely be done better (e.g. by merging the php-ext and php7-ext
directories together, as was done in commit b8d29e9f).

Thanks,
Bryce

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-70-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#988348: checksecurity: Please adjust Recommends/Suggests

[Bryce Harrington]

Source: checksecurity
Severity: normal

Dear Maintainer,

Could you consider moving a few of checksecurity's Recommends to
Suggests?  These packages aren't included in Ubuntu's main archive so
we've been moving them to Suggests, but if you would be willing to take
this change into Debian it would enable us to autosync your package
directly from now on.

Specifically, this would be the change:

-Recommends: tiger, logcheck, tripwire | integrit | aide | samhain | fcheck, 
debsecan
-Suggests: apt-watch | cron-apt, lockfile-progs
+Recommends: logcheck
+Suggests: apt-watch | cron-apt, lockfile-progs, tiger, tripwire | integrit | 
aide | samhain | fcheck, debsecan

We also have dropped fcron as a dependency since fcron is no longer in
the archive, but I see there is a separate bug report about this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798235

Bug#989191: [pkg-uWSGI-devel] Bug#989191: Drop macros not supported in PHP 8

[Bryce Harrington]

On Fri, May 28, 2021 at 12:36:03PM +0200, Jonas Smedegaard wrote:
> Control: severity -1 important
> 
> Quoting Bryce Harrington (2021-05-28 06:04:30)
> > Source: uwsgi
> > Severity: serious
> > Tags: patch upstream ftbfs
> > Justification: fails to build from source (but built successfully in the 
> > past)
> > 
> > TSRMLS_* was deprecated in PHP 7 and I believe the macro resolves to
> > null there.  The macro is removed for PHP 8, so uwsgi fails to build
> > from source when built with that PHP.
> > 
> > -- System Information:
> > Debian Release: bullseye/sid
> >   APT prefers focal-updates
> >   APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
> > 'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> 
> Thanks for reporting this issue.
> 
> Please in future be VERY CLEAR when filing issues tied to a derivative 
> of Debian rather than Debian itself: Debian does not fail to build on 
> any of its supported release, and has no release called "focal".
> 
> Lowering severity accordingly (and feeling kinda cheated into needlessly 
> polluting unstable here).
> 
> 
> Kind regards,
> 
>  - Jonas

Thank you for taking the patch.  
My apologies for the bug report.

Bug#989191: Drop macros not supported in PHP 8

[Bryce Harrington]

Source: uwsgi
Severity: serious
Tags: patch upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

TSRMLS_* was deprecated in PHP 7 and I believe the macro resolves to
null there.  The macro is removed for PHP 8, so uwsgi fails to build
from source when built with that PHP.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-70-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Description: Drop TSRMLS_* now obsolete in PHP 8 to fix FTBFS
 These C macros were nulled in PHP 7 and removed in PHP 8.
Author: Bryce Harrington 
Origin: vendor
Bug: 
Bug-: 
Forwarded: 
Last-Update: 2021-05-28
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/plugins/php/php_plugin.c
+++ b/plugins/php/php_plugin.c
@@ -82,9 +82,9 @@
 
 
 #ifdef UWSGI_PHP7
-static size_t sapi_uwsgi_ub_write(const char *str, size_t str_length TSRMLS_DC)
+static size_t sapi_uwsgi_ub_write(const char *str, size_t str_length)
 #else
-static int sapi_uwsgi_ub_write(const char *str, uint str_length TSRMLS_DC)
+static int sapi_uwsgi_ub_write(const char *str, uint str_length)
 #endif
 {
 	struct wsgi_request *wsgi_req = (struct wsgi_request *) SG(server_context);
@@ -97,7 +97,7 @@
 	return str_length;
 }
 
-static int sapi_uwsgi_send_headers(sapi_headers_struct *sapi_headers TSRMLS_DC)
+static int sapi_uwsgi_send_headers(sapi_headers_struct *sapi_headers)
 {
 	sapi_header_struct *h;
 	zend_llist_position pos;
@@ -132,9 +132,9 @@
 }
 
 #ifdef UWSGI_PHP7
-static size_t sapi_uwsgi_read_post(char *buffer, size_t count_bytes TSRMLS_DC)
+static size_t sapi_uwsgi_read_post(char *buffer, size_t count_bytes)
 #else
-static int sapi_uwsgi_read_post(char *buffer, uint count_bytes TSRMLS_DC)
+static int sapi_uwsgi_read_post(char *buffer, uint count_bytes)
 #endif
 {
 	uint read_bytes = 0;
@@ -159,7 +159,7 @@
 }
 
 
-static char *sapi_uwsgi_read_cookies(TSRMLS_D)
+static char *sapi_uwsgi_read_cookies()
 {
 	uint16_t len = 0;
 	struct wsgi_request *wsgi_req = (struct wsgi_request *) SG(server_context);
@@ -172,55 +172,55 @@
 	return NULL;
 }
 
-static void sapi_uwsgi_register_variables(zval *track_vars_array TSRMLS_DC)
+static void sapi_uwsgi_register_variables(zval *track_vars_array)
 {
 	int i;
 	struct wsgi_request *wsgi_req = (struct wsgi_request *) SG(server_context);
-	php_import_environment_variables(track_vars_array TSRMLS_CC);
+	php_import_environment_variables(track_vars_array);
 
 	if (uphp.server_software) {
 		if (!uphp.server_software_len) uphp.server_software_len = strlen(uphp.server_software);
-		php_register_variable_safe("SERVER_SOFTWARE", uphp.server_software, uphp.server_software_len, track_vars_array TSRMLS_CC);
+		php_register_variable_safe("SERVER_SOFTWARE", uphp.server_software, uphp.server_software_len, track_vars_array);
 	}
 	else {
-		php_register_variable_safe("SERVER_SOFTWARE", "uWSGI", 5, track_vars_array TSRMLS_CC);
+		php_register_variable_safe("SERVER_SOFTWARE", "uWSGI", 5, track_vars_array);
 	}
 
 	for (i = 0; i < wsgi_req->var_cnt; i += 2) {
 		php_register_variable_safe( estrndup(wsgi_req->hvec[i].iov_base, wsgi_req->hvec[i].iov_len),
 			wsgi_req->hvec[i + 1].iov_base, wsgi_req->hvec[i + 1].iov_len,
-			track_vars_array TSRMLS_CC);
+			track_vars_array);
 }
 
-	php_register_variable_safe("PATH_INFO", wsgi_req->path_info, wsgi_req->path_info_len, track_vars_array TSRMLS_CC);
+	php_register_variable_safe("PATH_INFO", wsgi_req->path_info, wsgi_req->path_info_len, track_vars_array);
 	if (wsgi_req->query_string_len > 0) {
-		php_register_variable_safe("QUERY_STRING", wsgi_req->query_string, wsgi_req->query_string_len, track_vars_array TSRMLS_CC);
+		php_register_variable_safe("QUERY_STRING", wsgi_req->query_string, wsgi_req->query_string_len, track_vars_array);
 	}
 
-	php_register_variable_safe("SCRIPT_NAME", wsgi_req->script_name, wsgi_req->script_name_len, track_vars_array TSRMLS_CC);
-	php_register_variable_safe("SCRIPT_FILENAME", wsgi_req->file, wsgi_req->file_len, track_vars_array TSRMLS_CC);
+	php_register_variable_safe("SCRIPT_NAME", wsgi_req->script_name, wsgi_req->script_name_len, track_vars_array);
+	php_register_variable_safe("SCRIPT_FILENAME", wsgi_req->file, wsgi_req->file_len, track_vars_array);
 
-	php_register_

Bug#985012: apache2: Race condition in DEP8 test case t/apache/expr_string.t

[Bryce Harrington]

Source: apache2
Version: 2.4.43-1
Severity: normal

Dear Maintainer,

One of the test cases has been seen to fail intermittently in Ubuntu,
so we added a small sleep to it which seems to have solved the problem.
I didn't notice that Debian hits this, but upstream did in the past, and
used the same solution to fix it.

https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1890302

Patch as applied to Ubuntu is attached.

Thanks,
Bryce

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-65-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apache2-bin depends on:
ii  libapr1  1.6.5-1ubuntu1
ii  libaprutil1  1.6.1-4ubuntu2
ii  libaprutil1-dbd-sqlite3  1.6.1-4ubuntu2
ii  libaprutil1-ldap 1.6.1-4ubuntu2
ii  libbrotli1   1.0.7-6ubuntu0.1
ii  libc62.31-0ubuntu9.2
ii  libcrypt11:4.4.10-10ubuntu4
ii  libcurl4 7.68.0-1ubuntu2.4
ii  libjansson4  2.12-1build1
ii  libldap-2.4-22.4.49+dfsg-2ubuntu1.7
ii  liblua5.2-0  5.2.4-1.1build3
ii  libnghttp2-141.40.0-1build1
ii  libpcre3 2:8.39-12build1
ii  libssl1.11.1.1f-1ubuntu2.2
ii  libxml2  2.9.10+dfsg-5
ii  perl 5.30.0-9ubuntu0.2
ii  zlib1g   1:1.2.11.dfsg-2ubuntu1.2

Versions of packages apache2-bin suggests:
pn  apache2-doc 
pn  apache2-suexec-pristine | apache2-suexec-c  
ii  chromium-browser [www-browser]  1:85.0.4183.83-0ubuntu0.20.04.2
ii  firefox [www-browser]   84.0.2+build1-0ubuntu0.20.04.1
ii  google-chrome-stable [www-browser]  88.0.4324.96-1
ii  links2 [www-browser]2.20.2-1
ii  lynx [www-browser]  2.9.0dev.5-1

Versions of packages apache2 is related to:
ii  apache2  2.4.41-4ubuntu3.1
ii  apache2-bin  2.4.41-4ubuntu3.1
>From 6ae8c18ed06dc19123c61616da55e6bb93b396bc Mon Sep 17 00:00:00 2001
From: Andreas Hasenack 
Date: Mon, 24 Aug 2020 18:18:55 -0300
Subject: [PATCH] - d/p/t/apache/expr_string.t: Avoid test suite failure
 due to timing   issue reading error log too quickly after request, by
 adding a sleep.   (LP #1890302)

---
 debian/perl-framework/t/apache/expr_string.t | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/perl-framework/t/apache/expr_string.t b/debian/perl-framework/t/apache/expr_string.t
index a9115eeec..66b09030d 100644
--- a/debian/perl-framework/t/apache/expr_string.t
+++ b/debian/perl-framework/t/apache/expr_string.t
@@ -7,6 +7,8 @@ use Apache::TestUtil qw(t_write_file t_start_error_log_watch t_finish_error_log_
 
 use File::Spec;
 
+use Time::HiRes qw(usleep);
+
 # test ap_expr
 
 Apache::TestRequest::user_agent(keep_alive => 1);
@@ -62,6 +64,8 @@ foreach my $t (@test_cases) {
'SomeHeader' => 'SomeValue',
'User-Agent' => 'SomeAgent',
'Referer'=> 'SomeReferer');
+### Sleep here, attempt to avoid intermittent failures. (LP: #1890302)
+usleep(25);
 my @loglines = t_finish_error_log_watch();
 
 my @evalerrors = grep {/(?:internal evaluation error|flex scanner jammed)/i
-- 
2.30.0

Bug#984960: fetchmail: DEP8 tests for fetchmail

[Bryce Harrington]

Source: fetchmail
Version: 6.4.16-1
Severity: wishlist

We've implemented a POP3 autopkgtest for fetchmail, that you might want
to consider including for Debian:


https://git.launchpad.net/~bryce/ubuntu/+source/fetchmail/commit/?id=d6e774e52d7b849a1043e54b46638023896e5d4b

It runs a mock POP3 mail server, then verifies fetchmail can get an
email from it.

I noticed as well that the upstream fetchmail code includes a few test
cases.  I added a DEP8 for them too (via make check):


https://git.launchpad.net/~bryce/ubuntu/+source/fetchmail/commit/?id=1deb68e705a23aa8c9bfa7d4942e1ff4191695e3

However, it might make more sense to run that as part of the build
process.  (Admittedly, the test cases look pretty trivial so maybe
they're not worth bothing with.  But maybe more will be added in the
future.)

We've added this to Ubuntu here:

https://launchpad.net/ubuntu/+source/fetchmail/6.4.16-1ubuntu1

If interested, some further discussion about both of these changes
happened on this MP review:


https://code.launchpad.net/~bryce/ubuntu/+source/fetchmail/+git/fetchmail/+merge/398937

Thank you,
Bryce

Bug#984473: postgresql-common: Only add postgres user to ssl-cert group if it's not already in the group

[Bryce Harrington]

Source: postgresql-common
Version: 225
Severity: normal

The postgres postinst script creates the postgres user with matching
group if, and only if, it doesn't already exist.  It also adds the user
to the ssl-cert but does this unconditionally, which is a bit
inconsistent.

This has cropped up in certain corner cases where the system config is
unwriteable for some odd reason (in one reported case, due to broken
oneconf; in a more immediate case we're hitting it building postgres
inside Docker, possibly due to a change in glibc/libseccomp behavior).

This change makes the postinst script more consistent in how it handles
setting up the postgres user's groups, and in so doing enables a
workaround for corner cases: the postgres user can be set up prior to
installing postgres; the postinst will then skip trying to make those
changes itself.


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-65-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#984473: Fix

[Bryce Harrington]

The ubuntu bug report this issue pertains to is:

https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1690432

The branch with the fix we're deploying for Ubuntu is:


https://code.launchpad.net/~bryce/ubuntu/+source/postgresql-common/+git/postgresql-common/+ref/fix-lp1690432-hirsute

A debdiff with these ubuntu changes is attached, for ease of
consideration.

Thank you,
Brycediff --git a/debian/changelog b/debian/changelog
index bce80a8..069345a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+postgresql-common (225ubuntu1) hirsute; urgency=medium
+
+  * d/postinst: Only add postgres to group ssl-cert if it isn't
+already a member of that group.
+(LP: #1690432)
+
+ -- Bryce Harrington   Thu, 25 Feb 2021 16:21:44 -0800
+
 postgresql-common (225) unstable; urgency=medium
 
   * pg_lsclusters, cluster_info: Show cluster managed by pacemaker or patroni.
diff --git a/debian/control b/debian/control
index 9c4e88a..c70ce42 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,8 @@
 Source: postgresql-common
 Section: database
 Priority: optional
-Maintainer: Debian PostgreSQL Maintainers 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian PostgreSQL Maintainers 

 Uploaders:
  Martin Pitt ,
  Christoph Berg ,
diff --git a/debian/postgresql-common.postinst 
b/debian/postgresql-common.postinst
index a435b72..fc897ac 100644
--- a/debian/postgresql-common.postinst
+++ b/debian/postgresql-common.postinst
@@ -90,9 +90,12 @@ EOF
 fi
 
 # Add postgres user to the ssl-cert group on fresh installs
+# if not already in the group
 if [ -z "$2" ]; then
if getent group ssl-cert >/dev/null; then
-   adduser $quiet postgres ssl-cert
+   if ! id -Gn postgres 2> /dev/null | grep -qw ssl-cert; then
+   adduser $quiet postgres ssl-cert
+   fi
fi
 fi
 

Bug#953530: Downstream bug LP: #1886114

[Bryce Harrington]

Fwiw, ubuntu reporters have hit this issue as well:

  https://bugs.launchpad.net/debian/+source/samba/+bug/1886114

We've not yet reproduced the error about /run/samba, but I found one way
to make it fail to get into an installation failure state:

$ sudo apt-get install samba
$ sudo apt-get remove --purge samba-common-bin
$ sudo rm -rf /run/samba
$ sudo rm -rf /etc/samba
$ sudo apt-get install samba-common-bin
Reading package lists... Done
...
Setting up samba-common-bin (2:4.13.3+dfsg-1ubuntu2) ...
Checking smb.conf with testparm
Load smb config files from /etc/samba/smb.conf
Error loading services.
dpkg: error processing package samba-common-bin (--configure):
 installed samba-common-bin package post-installation script subprocess 
returned error exit status 1

After this it will continue to exhibit error messages similar to what
other reporters have seen.

To restore the system back to working order, this seems to do it:

$ sudo apt-get remove --purge *samba*
$ sudo apt-get install samba

I tried tampering with and removing /run/samba at various points, and
tinkering with /usr/lib/tmpfiles.d/samba.conf in various ways, but
wasn't able to generate the "lock directory /run/samba does not exist"
issue.

I also tested the above with 2:4.11.6+dfsg-0ubuntu1.6, and found it
gives identical behavior as above.

Bug#998249: FTBFS with PHP 8.1

[Bryce Harrington]

Source: php-mongodb
Severity: normal

When building against PHP 8.1, php-mongodb 1.9.0+1.7.5-2 FTBFS due to
some deprecated functions.  I also checked the 1.10.0 version currently
staged in Debian's git repository but it has the same failures.  For
example, one of the errors is:

/<>/php-mongodb-1.9.0+1.7.5/build-8.1/src/MongoDB/BulkWrite.c:672:59: 
error: ‘spl_ce_Countable’ undeclared (first use in this function); did you mean 
‘zend_ce_countable’?
  672 | zend_class_implements(php_phongo_bulkwrite_ce, 1, 
spl_ce_Countable);
  |   
^~~~
  |   
zend_ce_countable

See 
https://launchpadlibrarian.net/566491878/buildlog_ubuntu-jammy-amd64.php-mongodb_1.9.0+1.7.5-2build3_BUILDING.txt.gz

There are fixes for these issues in upstream's tree, for instance the
above is fixed by:


https://github.com/mongodb/mongo-php-driver/commit/00e8f089e2cf688844ebc7ded5707c6c4554078b.patch
https://jira.mongodb.org/browse/PHPC-1793

However, it might be better to pull the 1.11.0 release, since there's
been several changes for PHP 8.1.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-89-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1008812: Consider reducing dependency level on chrom*?

[Bryce Harrington]

Source: node-puppeteer
Severity: wishlist

node-puppeteer has a build-dependency on chromium and chromium-sandbox,
which are not carried in Ubuntu, so a sync of this package into Ubuntu
failed and had to be removed (LP: #1967048).

Even though Ubuntu doesn't carry these, the package might still be of
utility for e.g. controlling remote chromium, or working with 3rd party
installations of it.

Other Debian packages that rely on chrom* list those depends as
Suggests/Enhances.  Would it be possible to consider doing similarly for
node-puppeteer?


Example:
Package: chrome-gnome-shell
...
Suggests: chromium | chromium-browser, firefox
Breaks: firefox (<< 56), firefox-esr (<< 56)
Enhances: chromium, chromium-browser, firefox

Thanks,
Bryce


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-99-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1005198: d/rules also needs updated for PHP 8.1

[Bryce Harrington]

Source: php-pecl-http
Version: 4.2.1+php8-2
Severity: normal

4.2.1+php8-2 updated d/control for PHP 8.1, but looks like perhaps
d/rules also needs adjusted to change the default?

  PHP_DEFAULT_VERSION_OVERRIDE := 7.4

s/b:

  PHP_DEFAULT_VERSION_OVERRIDE := 8.1

This may resolve the 'unsatisfiable dependency' migration errors for
php-pecl-http listed at:

  https://qa.debian.org/excuses.php?package=php-pecl-http


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-91-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Bryce Harrington]

On Thu, Jan 20, 2022 at 12:18:34PM +0100, Paul Gevers wrote:
> Hi Kunal,
> 
> Thanks for the analysis.
> 
> On 20-01-2022 10:56, Kunal Mehta wrote:
> > > I can't tell what it may be trying to encode, but presumably it's either
> > > Main_Page or something used by Main_Page, which I'm guessing should only
> > > take a fraction of a second to encode.  I suppose we could test
> > > increasing max_execution_time.  But my suspicion is that the encoder is
> > > getting stuck in a loop or a recursion.
> > 
> > 30 seconds seems a bit absurd, but given an empty opcache/jit, empty
> > caches, on 32-bit VMs, it's within the realm of possibility...I think
> > bumping max_execution_time is a good next step. Should the test add a
> > php.ini snippet or something?
> 
> I think that would be great. But please upload to Debian as well, let's not
> only have these tests in Ubuntu.
> 
> > I read through the 8.1 changelog
> > () and couldn't find
> > anything relevant that wasn't already in PHP 8.0.8 (specifically 
> > 
> > looked suspect, but that was included in 8.0.7).
> 
> In Debian we're going from 7.4 to 8.1, so all intermediate upstreams are
> relevant.
> 
> > Just to give some expectations, I won't have time to dig into this until
> > the weekend. I did drop a pointer to the bug in the MediaWiki developers
> > IRC channel in case anyone there had suggestions.
> 
> Can that php.ini addition to the test happen thought, or is even that to
> much of your time? (Not blaming, just asking).

I've not tried it myself but the web suggests this might also be
controllable on a per-test basis via patching the test with something
like:

ini_set('max_execution_time', '300');

Another option, which might be more suitable for a self-contained dep8
test than a patch, would be an .htaccess file, with a line like:

php_value max_execution_time 300

ref: 
https://stackoverflow.com/questions/8744107/increase-max-execution-time-in-php

Poking around a bit on SO, it does appear that hitting json_encode
timeouts is a thing:

https://stackoverflow.com/questions/36975512/maximum-execution-time-exceeded-on-json-decode
https://stackoverflow.com/questions/5164930/fatal-error-maximum-execution-time-of-30-seconds-exceeded
https://stackoverflow.com/questions/1263680/maximum-execution-time-in-phpmyadmin
https://stackoverflow.com/questions/7680572/fatal-error-maximum-execution-time-of-300-seconds-exceeded

Adjusting max_execution_time seems to be the commonly suggested solution
across the board.

Bryce

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Bryce Harrington]

On Thu, Jan 20, 2022 at 09:42:47AM -0800, Bryce Harrington wrote:
> On Thu, Jan 20, 2022 at 12:18:34PM +0100, Paul Gevers wrote:
> > Hi Kunal,
> > 
> > Thanks for the analysis.
> > 
> > On 20-01-2022 10:56, Kunal Mehta wrote:
> > > > I can't tell what it may be trying to encode, but presumably it's either
> > > > Main_Page or something used by Main_Page, which I'm guessing should only
> > > > take a fraction of a second to encode.  I suppose we could test
> > > > increasing max_execution_time.  But my suspicion is that the encoder is
> > > > getting stuck in a loop or a recursion.
> > > 
> > > 30 seconds seems a bit absurd, but given an empty opcache/jit, empty
> > > caches, on 32-bit VMs, it's within the realm of possibility...I think
> > > bumping max_execution_time is a good next step. Should the test add a
> > > php.ini snippet or something?
> > 
> > I think that would be great. But please upload to Debian as well, let's not
> > only have these tests in Ubuntu.
> > 
> > > I read through the 8.1 changelog
> > > (<https://www.php.net/ChangeLog-8.php#PHP_8_1>) and couldn't find
> > > anything relevant that wasn't already in PHP 8.0.8 (specifically 
> > > <https://github.com/php/php-src/commit/bf9dc534356ec3b372abe5f3030c3e362aa261ac>
> > > looked suspect, but that was included in 8.0.7).
> > 
> > In Debian we're going from 7.4 to 8.1, so all intermediate upstreams are
> > relevant.
> > 
> > > Just to give some expectations, I won't have time to dig into this until
> > > the weekend. I did drop a pointer to the bug in the MediaWiki developers
> > > IRC channel in case anyone there had suggestions.
> > 
> > Can that php.ini addition to the test happen thought, or is even that to
> > much of your time? (Not blaming, just asking).
> 
> I've not tried it myself but the web suggests this might also be
> controllable on a per-test basis via patching the test with something
> like:
> 
> ini_set('max_execution_time', '300');

I've kicked off a test with this, to see if adjusting the timeout would
be worth considering as a possible solution.

Probably unrelated but in prepping the changes I noticed this lintian
complaint:

Warning in processable ./mediawiki_1.35.5-1ubuntu3.dsc: Complex regular 
subexpression recursion limit (65534) exceeded at 
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 773.

Bryce

> Another option, which might be more suitable for a self-contained dep8
> test than a patch, would be an .htaccess file, with a line like:
> 
> php_value max_execution_time 300
> 
> ref: 
> https://stackoverflow.com/questions/8744107/increase-max-execution-time-in-php
> 
> Poking around a bit on SO, it does appear that hitting json_encode
> timeouts is a thing:
> 
> https://stackoverflow.com/questions/36975512/maximum-execution-time-exceeded-on-json-decode
> https://stackoverflow.com/questions/5164930/fatal-error-maximum-execution-time-of-30-seconds-exceeded
> https://stackoverflow.com/questions/1263680/maximum-execution-time-in-phpmyadmin
> https://stackoverflow.com/questions/7680572/fatal-error-maximum-execution-time-of-300-seconds-exceeded
> 
> Adjusting max_execution_time seems to be the commonly suggested solution
> across the board.
> 
> Bryce

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Bryce Harrington]

On Thu, Jan 20, 2022 at 03:38:43PM -0800, Bryce Harrington wrote:
> On Thu, Jan 20, 2022 at 09:42:47AM -0800, Bryce Harrington wrote:
> > On Thu, Jan 20, 2022 at 12:18:34PM +0100, Paul Gevers wrote:
> > > Hi Kunal,
> > > 
> > > Thanks for the analysis.
> > > 
> > > On 20-01-2022 10:56, Kunal Mehta wrote:
> > > > > I can't tell what it may be trying to encode, but presumably it's 
> > > > > either
> > > > > Main_Page or something used by Main_Page, which I'm guessing should 
> > > > > only
> > > > > take a fraction of a second to encode.  I suppose we could test
> > > > > increasing max_execution_time.  But my suspicion is that the encoder 
> > > > > is
> > > > > getting stuck in a loop or a recursion.
> > > > 
> > > > 30 seconds seems a bit absurd, but given an empty opcache/jit, empty
> > > > caches, on 32-bit VMs, it's within the realm of possibility...I think
> > > > bumping max_execution_time is a good next step. Should the test add a
> > > > php.ini snippet or something?
> > > 
> > > I think that would be great. But please upload to Debian as well, let's 
> > > not
> > > only have these tests in Ubuntu.
> 
> I've kicked off a test with this, to see if adjusting the timeout would
> be worth considering as a possible solution.

Looks like you were right Kunal, increasing the timeout did indeed let
the tests pass with php8.1 on armhf:

https://autopkgtest.ubuntu.com/packages/m/mediawiki/jammy/armhf

https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/armhf/m/mediawiki/20220121_020236_5c320@/log.gz
https://launchpad.net/ubuntu/+source/mediawiki/1:1.35.5-1ubuntu3

However like I mentioned, I think a more proper fix than what I did
above would be to make the dep8 test set up an .htaccess file with the
setting, rather than patching it in like this.  But it does appear that
adjusting the timeout should resolve the issue we're seeing on armhf,
and if the issue Debian has on i386 is also timeout-related may solve it
there too.

Bryce

Bug#1000593: Failing testsuite with PHP 8.1

[Bryce Harrington]

These tests fail due to changes in how objects are dumped, like the
ordering of members.  This seems to just be a formatting discrepancy.
Presumably the logical fix is to revise the expected output to match the
new output formatting style, or alternatively just disable the three
test cases until upstream has a chance to update to latest versions of
php, et al.

Bryce

Bug#1000650: Possible patch

[Bryce Harrington]

I reproduced these failures in Ubuntu, and found they're fixed by this
recently introduced upstream commit:


https://github.com/sebastianbergmann/phploc/commit/c21b0521f0d87ddc328b62dccafe2f90b62cfbe3.patch

HTH,
Bryce

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Bryce Harrington]

On Wed, Jan 19, 2022 at 09:58:52PM +0100, Paul Gevers wrote:
> Hi Bryce,
> 
> On 19-01-2022 10:28, Bryce Harrington wrote:
> 
> > With [4] applied, I'm seeing the following dumped on armhf:
> > 
> > ## https://autopkgtest.ubuntu.com/packages/m/mediawiki/jammy/armhf
> > cat: /var/log/mediawiki/error.log: No such file or directory
> > 2022-01-19 09:16:57 autopkgtest-lxd-eeoxik autopkgtestwiki: 
> > [e33d1ec89af515673078437e] /mediawiki/index.php/Main_Page   PHP Fatal Error 
> > from line 110 of /usr/share/mediawiki/includes/json/FormatJson.php: Maximum 
> > execution time of 30 seconds exceeded
> > #0 [internal function]: MWExceptionHandler::handleFatalError()
> > #1 {main}
> > 2022-01-19 09:17:27 autopkgtest-lxd-eeoxik autopkgtestwiki: 
> > [1284cbae5a84eb5387f33003] /mediawiki/index.php/Main_Page   PHP Fatal Error 
> > from line 152 of 
> > /usr/share/mediawiki/includes/HookContainer/HookContainer.php: Maximum 
> > execution time of 30 seconds exceeded
> > #0 [internal function]: MWExceptionHandler::handleFatalError()
> > #1 {main}
> > 2022-01-19 09:17:57 autopkgtest-lxd-eeoxik autopkgtestwiki: 
> > [31731278ed6070e946af4fbe] /mediawiki/index.php/Main_Page   PHP Fatal Error 
> > from line 110 of /usr/share/mediawiki/includes/json/FormatJson.php: Maximum 
> > execution time of 30 seconds exceeded
> > #0 [internal function]: MWExceptionHandler::handleFatalError()
> > #1 {main}
> > cat: /var/log/mediawiki/fatal.log: No such file or directory
> 
> As this issue seems intermittent (as mediawiki passed at one point) I guess
> you're trying to say that you think mediawiki got slower with php8.1? Or is
> this timeout new with php8.1?

The failing cases are mostly ones with triggers for
php-defaults/84~0ubuntu1 or newer, which marks where php8.1 is set as
default.  The ones that pass and don't specify that are thus running
php8.0.  So it looks like the pass-vs-fail correlates to php8.0-vs-8.1
and is something specific to armhf.

Unfortunately I don't have i386 builds to compare with (due to
dependency issues), so it's just a hunch that this is the same problem
Debian sees on i386.  It'd be illuminating to doublecheck on your i386
builds that it's also hitting this same timeout situation.

> Obviously the code that fails to finish is mediawiki's code, so it
> doesn't seem to be a generic issue with php8.1 except if the timeout
> happens because of something inside php8.1.

Line 110 that the error points to appears to be a json_encode() call.  

> Can anybody shed a light on if it's reasonable to time out on what
> mediawiki is trying to do here. And why doesn't it happen on other
> architectures (in Debian, as far as I checked)?

I can't tell what it may be trying to encode, but presumably it's either
Main_Page or something used by Main_Page, which I'm guessing should only
take a fraction of a second to encode.  I suppose we could test
increasing max_execution_time.  But my suspicion is that the encoder is
getting stuck in a loop or a recursion.

I've not been able to find any reports on the web similar enough to be
worth mentioning.

Bryce

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Bryce Harrington]

On Sun, Jan 16, 2022 at 09:49:37PM -0800, Kunal Mehta wrote:
> 
> Hi,
> 
> On 1/16/22 11:52, Paul Gevers wrote:
> > On 12-01-2022 21:16, Paul Gevers wrote:
> > > Priority may lay with the mediawiki* regression on i386: "Internal
> > > Server Error" doesn't sound great, and other non-horde package.
> > 
> > Did anybody already take a look at this [1, 2, 3]? It's the last thing
> > before I'll add a hint to ignore the autopkgtest regressions.
> > Intermittent "Internal Server Error" sounds more like something in
> > php8.1 than in mediawiki* hence my reluctance to let php-defaults
> > migrate. What do you think?
> 
> Sorry, didn't get a chance to look at this until now. All 3 failures are
> most likely the same underlying cause. As for whether this is a MediaWiki or
> PHP 8.1 issue, I'm not sure. Upstream in MW we don't run any 32-bit CI, so
> it's entirely possible some 8.0 or 8.1 change broke something we were doing.
> 
> I don't have any i386 hardware, I tried pulling down a i386 Debian unstable
> Docker container on my amd64 laptop and installing the mediawiki+php8.1
> packages on that but it didn't trigger the test failure. Do you have any
> other suggestions/tips on how I could debug this?
> 
> As an alternative I just committed [4] which would hopefully dump the
> underlying error message upon failure. Please let me know if it's OK for me
> to upload that without it being disruptive.
> 
> > [1] https://ci.debian.net/packages/m/mediawiki-skin-greystuff/testing/i386/
> > [2]
> > https://ci.debian.net/packages/m/mediawiki-extension-youtube/testing/i386/
> > [3] https://ci.debian.net/packages/m/mediawiki/testing/i386/
> 
> [4] 
> https://salsa.debian.org/mediawiki-team/mediawiki/-/commit/20a94e6971be6b06d5f41338ec2811cc8572e05f

With [4] applied, I'm seeing the following dumped on armhf:

## https://autopkgtest.ubuntu.com/packages/m/mediawiki/jammy/armhf
cat: /var/log/mediawiki/error.log: No such file or directory
2022-01-19 09:16:57 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[e33d1ec89af515673078437e] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 110 of /usr/share/mediawiki/includes/json/FormatJson.php: Maximum 
execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
2022-01-19 09:17:27 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[1284cbae5a84eb5387f33003] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 152 of /usr/share/mediawiki/includes/HookContainer/HookContainer.php: 
Maximum execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
2022-01-19 09:17:57 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[31731278ed6070e946af4fbe] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 110 of /usr/share/mediawiki/includes/json/FormatJson.php: Maximum 
execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
cat: /var/log/mediawiki/fatal.log: No such file or directory

HTH,
Bryce

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Bryce Harrington]

On Sun, Jan 16, 2022 at 08:52:28PM +0100, Paul Gevers wrote:
> Hi,
> 
> On 12-01-2022 21:16, Paul Gevers wrote:
> > Priority may lay with the mediawiki* regression on i386: "Internal
> > Server Error" doesn't sound great, and other non-horde package.
> 
> Did anybody already take a look at this [1, 2, 3]? It's the last thing
> before I'll add a hint to ignore the autopkgtest regressions. Intermittent
> "Internal Server Error" sounds more like something in php8.1 than in
> mediawiki* hence my reluctance to let php-defaults migrate. What do you
> think?

The apache2 error.log would likely shed light on what's going wrong...
Perhaps the dep8 tests could be modified to dump error.log on server
failure?

Fwiw, in Ubuntu on armhf we also have an Internal Server Error on armhf
so if it's the same as what you're seeing on i386 perhaps there's some
32-bit specific issue?

Bryce

Bug#1011713: FTBFS issue fixed in upstream release 1.3.0

[Bryce Harrington]

AttributeError: function/symbol 'EVP_PKEY_size' not found in library
'libcrypto.so.3': /lib/x86_64-linux-gnu/libcrypto.so.3: undefined
symbol: EVP_PKEY_size 

According to this upstream issue, this is an OpenSSL 3.0 incompatibility
that was fixed and appears to be available in the upstream 1.3.0
release.  I think the principle fix would be:

  
https://github.com/wbond/oscrypto/commit/e07413184f8038aa82c421350f4e49d1073f1491

However, https://github.com/wbond/oscrypto/commits/master shows
followup commits dcd19aa, f533aff, etc. to improve things, so e0741318
alone may not adequately fix things.

Bug#1008279: Alternative fix using getent

[Bryce Harrington]

Attached is a similar fix we're applying in Ubuntu, except it uses
getent rather than id, which seems to be a typical way for solving this
type of need.

>From 5b6f1ddbb759fad768d64a26e42427617910f9f8 Mon Sep 17 00:00:00 2001
From: Bryce Harrington 
Date: Wed, 18 May 2022 17:16:20 -0700
Subject: [PATCH]   * clamav-base.postinst.in: Quell warning from check for
 clamav user (LP: #1920217)

Signed-off-by: Bryce Harrington 
---
 debian/clamav-base.postinst.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/clamav-base.postinst.in b/debian/clamav-base.postinst.in
index 89c116f5..f3d1da9b 100644
--- a/debian/clamav-base.postinst.in
+++ b/debian/clamav-base.postinst.in
@@ -32,7 +32,7 @@ case "$1" in
 
   # Set up the clamav user on new install
   if [ -z "$2" ]; then
-if ! id clamav; then
+if ! getent passwd clamav >/dev/null; then
 adduser --system --no-create-home --quiet \
 --disabled-password --disabled-login \
 	--shell /bin/false --group --home /var/lib/clamav clamav
-- 
2.25.1

Bug#1021611: GuestStore and Guest Data Publisher plugins needed

[Bryce Harrington]

Source: open-vm-tools
Severity: wishlist

The GuestStore and Guest Data Publisher plugins (libguestStore.so and
libgdb.so respectively) are not being installed, but upstream intends
them to be included with the open-vm-tools package, as they're part of
the vmtoolsd service process.

This is also reported to Ubuntu:
  https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1992501

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-125-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1064559: Forwarded upstream (+ same ftbfs in Ubuntu)

[Bryce Harrington]

Ubuntu is seeing the same failures after its own rebuilds of the package
in Ubuntu noble, also on ppc64el only.  I investigated if it was a known
issue in pdbq or valgrind but did not find convincing matches.  I'm also
not certain if this is a single issue, or multiple.  There are also some
"Invalid opcode" errors from valgrind which I wonder might be a separate
problem.  In Ubuntu I'm going to test if disabling TEST5 is sufficient.

Ubuntu bug:  https://bugs.launchpad.net/ubuntu/+source/pmdk/+bug/2061913

Upstream bug:  https://github.com/pmem/pmdk/issues/5635