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

2024-04-16 Thread 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



Bug#1011713: FTBFS issue fixed in upstream release 1.3.0

2022-06-29 Thread 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#1000593: Failing testsuite with PHP 8.1

2022-01-07 Thread 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

2022-01-07 Thread 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#989191: Drop macros not supported in PHP 8

2021-05-27 Thread 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-

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

2019-05-06 Thread 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