Script 'mail_helper' called by obssrc
Hello community,

here is the log from the commit of package postgresql13.17141 for 
openSUSE:Leap:15.2:Update checked in at 2021-11-06 20:06:09
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Leap:15.2:Update/postgresql13.17141 (Old)
 and      /work/SRC/openSUSE:Leap:15.2:Update/.postgresql13.17141.new.1890 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "postgresql13.17141"

Sat Nov  6 20:06:09 2021 rev:1 rq:929073 version:13.4

Changes:
--------
New Changes file:

--- /dev/null   2021-10-14 08:13:55.193858881 +0200
+++ 
/work/SRC/openSUSE:Leap:15.2:Update/.postgresql13.17141.new.1890/postgresql13.changes
       2021-11-06 20:06:15.395828541 +0100
@@ -0,0 +1,134 @@
+-------------------------------------------------------------------
+Mon Sep 27 13:58:17 UTC 2021 - Reinhard Max <m...@suse.com>
+
+- Stop building the mini and lib packages as they are now coming
+  from postgresql14.
+- Let genlists skip non-existing binaries to avoid lots of version
+  conditionals in the file lists.
+- Remove postgresql-testsuite-int8.sql.patch, because its purpose
+  is unclear. This affects only the test subpackage.
+
+-------------------------------------------------------------------
+Tue Aug 31 11:14:53 UTC 2021 - Reinhard Max <m...@suse.com>
+
+- bsc#1185952: fix build with llvm12 on s390x.
+  0001-jit-Workaround-potential-datalayout-mismatch-on-s390.patch 
+- bsc#1179945: Re-enable icu for PostgreSQL 10.
+
+-------------------------------------------------------------------
+Tue Aug 24 12:45:53 UTC 2021 - Marcus Rueckert <mrueck...@suse.de>
+
+- Upgrade to version 13.4:
+  https://www.postgresql.org/docs/13/release-13-4.html
+  * CVE-2021-3677 (boo#1189748)
+    The planner could create an incorrect plan in cases where two
+    ProjectionPaths were stacked on top of each other. The only
+    known way to trigger that situation involves parallel sort
+    operations, but there may be other instances. The result would
+    be crashes or incorrect query results. Disclosure of server
+    memory contents is also possible.
+
+-------------------------------------------------------------------
+Mon Jun 28 10:00:46 UTC 2021 - Reinhard Max <m...@suse.com>
+
+- bsc#1187751: Make the dependency of postgresqlXX-server-devel on
+  llvm and clang optional (postgresql-llvm-optional.patch).
+
+-------------------------------------------------------------------
+Wed May 19 15:24:24 UTC 2021 - Reinhard Max <m...@suse.com>
+
+- bsc#1185952: llvm12 breaks PostgreSQL 11 and 12 on s390x.
+  Use llvm11 as a workaround.
+
+-------------------------------------------------------------------
+Tue May 11 13:50:14 UTC 2021 - Reinhard Max <m...@suse.com>
+
+- Upgrade to version 13.3:
+  * https://www.postgresql.org/docs/13/release-13-3.html
+  * CVE-2021-32027, bsc#1185924:
+    Prevent integer overflows in array subscripting calculations.
+  * CVE-2021-32028, bsc#1185925: Fix mishandling of ???junk???
+    columns in INSERT ... ON CONFLICT ... UPDATE target lists.
+  * CVE-2021-32029, bsc#1185926: Fix possibly-incorrect
+    computation of UPDATE ... RETURNING
+    "pg_psql_temporary_savepoint" does not exist???.
+
+- Don't use %_stop_on_removal, because it was meant to be private
+  and got removed from openSUSE. %_restart_on_update is also
+  private, but still supported and needed for now (bsc#1183168).
+
+-------------------------------------------------------------------
+Mon Mar 15 19:29:39 UTC 2021 - Reinhard Max <m...@suse.com>
+
+- Re-enable build of the llvmjit subpackage on SLE, but it will
+  only be delivered on PackageHub for now (boo#1183118).
+
+-------------------------------------------------------------------
+Tue Mar  9 13:52:19 UTC 2021 - Reinhard Max <m...@suse.com>
+
+- Remove leftover PreReq on chkconfig, we stopped using it long
+  time ago.
+
+-------------------------------------------------------------------
+Fri Feb 19 15:30:08 UTC 2021 - Reinhard Max <m...@suse.com>
+
+- boo#1179945: Disable icu for PostgreSQL 10 (and older) on TW.
+
+-------------------------------------------------------------------
+Wed Feb 10 13:16:32 UTC 2021 - Reinhard Max <m...@suse.com>
+
+- Upgrade to version 13.2:
+  * https://www.postgresql.org/docs/13/release-13-2.html
+  * Updating stored views and reindexing might be needed after
+    applying this update.
+  * CVE-2021-3393, bsc#1182040: Fix information leakage in
+    constraint-violation error messages.
+  * CVE-2021-20229, bsc#1182039: Fix failure to check per-column
+    SELECT privileges in some join queries.
+  * Obsoletes postgresql-icu68.patch.
+
+-------------------------------------------------------------------
+Mon Dec 14 16:19:05 UTC 2020 - Callum Farmer <gm...@opensuse.org>
+
+- Add postgresql-icu68.patch: fix build with ICU 68
+
+-------------------------------------------------------------------
+Fri Nov 20 11:51:37 UTC 2020 - Reinhard Max <m...@suse.com>
+
+- bsc#1178961: %ghost the symlinks to pg_config and ecpg.
+- boo#1179765: BuildRequire libpq5 and libecpg6 when not building
+  them to avoid dangling symlinks in the devel package.
+
+-------------------------------------------------------------------
+Wed Nov 11 11:36:01 UTC 2020 - Reinhard Max <m...@suse.com>
+
+- Upgrade to version 13.1:
+  * CVE-2020-25695, bsc#1178666: Block DECLARE CURSOR ... WITH HOLD
+    and firing of deferred triggers within index expressions and
+    materialized view queries.
+  * CVE-2020-25694, bsc#1178667:
+    a) Fix usage of complex connection-string parameters in pg_dump,
+    pg_restore, clusterdb, reindexdb, and vacuumdb.
+    b) When psql's \connect command re-uses connection parameters,
+    ensure that all non-overridden parameters from a previous
+    connection string are re-used.
+  * CVE-2020-25696, bsc#1178668: Prevent psql's \gset command from
+    modifying specially-treated variables.
+  * Fix recently-added timetz test case so it works when the USA
+    is not observing daylight savings time.
+    (obsoletes postgresql-timetz.patch)
+  * https://www.postgresql.org/about/news/2111/
+  * https://www.postgresql.org/docs/13/release-13-1.html
+
+-------------------------------------------------------------------
+Tue Nov  3 13:54:38 UTC 2020 - Reinhard Max <m...@suse.com>
+
+- Fix a DST problem in the test suite: postgresql-timetz.patch
+  https://postgr.es/m/16689-57701daa23b37...@postgresql.org
+
+-------------------------------------------------------------------
+Fri Sep 25 06:57:55 UTC 2020 - Reinhard Max <m...@suse.com>
+
+- Initial packaging of PostgreSQL 13:
+  * https://www.postgresql.org/about/news/2077/
+  * https://www.postgresql.org/docs/13/release-13.html

New:
----
  0001-jit-Workaround-potential-datalayout-mismatch-on-s390.patch
  baselibs.conf
  postgresql-13.4.tar.bz2
  postgresql-13.4.tar.bz2.sha256
  postgresql-README.SUSE
  postgresql-conf.patch
  postgresql-llvm-optional.patch
  postgresql-plperl-keep-rpath.patch
  postgresql-rpmlintrc
  postgresql-testsuite-keep-results-file.patch
  postgresql-var-run-socket.patch
  postgresql13.changes
  postgresql13.spec

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ postgresql13.spec ++++++
++++ 942 lines (skipped)

++++++ 0001-jit-Workaround-potential-datalayout-mismatch-on-s390.patch ++++++
>From 0edaa982336823d4d7af8f10b91579fe0099ef3d Mon Sep 17 00:00:00 2001
From: Tom Stellard <tstel...@redhat.com>
Date: Tue, 20 Apr 2021 20:14:21 -0700
Subject: [PATCH] jit: Workaround potential datalayout mismatch on s390x

LLVM's s390x target uses a different datalayout for z13 and newer processors.
If llvmjit_types.bc is compiled to target a processor older than z13, and
then the JIT runs on a z13 or newer processor, then there will be a mismatch
in datalayouts between llvmjit_types.bc and the JIT engine.  This mismatch
causes the JIT to fail at runtime.
---
 src/backend/jit/llvm/llvmjit.c | 46 ++++++++++++++++++++++++++++++++--
 1 file changed, 44 insertions(+), 2 deletions(-)

--- src/backend/jit/llvm/llvmjit.c.orig
+++ src/backend/jit/llvm/llvmjit.c
@@ -736,6 +736,35 @@ llvm_compile_module(LLVMJitContext *cont
 }
 
 /*
+ * For the systemz target, LLVM uses a different datalayout for z13 and newer
+ * CPUs than it does for older CPUs.  This can cause a mismatch in datalayouts
+ * in the case where the llvm_types_module is compiled with a pre-z13 CPU
+ * and the JIT is running on z13 or newer.
+ * See computeDataLayout() function in
+ * llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp for information on the
+ * datalayout differences.
+ */
+static bool
+needs_systemz_workaround(void)
+{
+       bool ret = false;
+       LLVMContextRef llvm_context;
+       LLVMTypeRef vec_type;
+       LLVMTargetDataRef llvm_layoutref;
+       if (strncmp(LLVMGetTargetName(llvm_targetref), "systemz", 
strlen("systemz")))
+       {
+               return false;
+       }
+
+       llvm_context = LLVMGetModuleContext(llvm_types_module);
+       vec_type = LLVMVectorType(LLVMIntTypeInContext(llvm_context, 32), 4);
+       llvm_layoutref = LLVMCreateTargetData(llvm_layout);
+       ret = (LLVMABIAlignmentOfType(llvm_layoutref, vec_type) == 16);
+       LLVMDisposeTargetData(llvm_layoutref);
+       return ret;
+}
+
+/*
  * Per session initialization.
  */
 static void
@@ -744,6 +773,7 @@ llvm_session_initialize(void)
        MemoryContext oldcontext;
        char       *error = NULL;
        char       *cpu = NULL;
+       char       *host_features = NULL;
        char       *features = NULL;
        LLVMTargetMachineRef opt0_tm;
        LLVMTargetMachineRef opt3_tm;
@@ -775,10 +805,17 @@ llvm_session_initialize(void)
         * features not all CPUs have (weird, huh).
         */
        cpu = LLVMGetHostCPUName();
-       features = LLVMGetHostCPUFeatures();
+       features = host_features = LLVMGetHostCPUFeatures();
        elog(DEBUG2, "LLVMJIT detected CPU \"%s\", with features \"%s\"",
                 cpu, features);
 
+       if (needs_systemz_workaround())
+       {
+               const char *no_vector =",-vector";
+               features = malloc(sizeof(char) * (strlen(host_features) + 
strlen(no_vector) + 1));
+               sprintf(features, "%s%s", host_features, no_vector);
+       }
+
        opt0_tm =
                LLVMCreateTargetMachine(llvm_targetref, llvm_triple, cpu, 
features,
                                                                
LLVMCodeGenLevelNone,
@@ -792,8 +829,13 @@ llvm_session_initialize(void)
 
        LLVMDisposeMessage(cpu);
        cpu = NULL;
-       LLVMDisposeMessage(features);
+       if (features != host_features)
+       {
+               free(features);
+       }
        features = NULL;
+       LLVMDisposeMessage(host_features);
+       host_features = NULL;
 
        /* force symbols in main binary to be loaded */
        LLVMLoadLibraryPermanently(NULL);
++++++ baselibs.conf ++++++
libpq5
        provides  "postgresql-libs-<targettype> = <version>"
        obsoletes "postgresql-libs-<targettype> < <version>"
        conflicts "postgresql-libs-<targettype> < 9.1.6"
libecpg6
++++++ postgresql-13.4.tar.bz2.sha256 ++++++
ea93e10390245f1ce461a54eb5f99a48d8cabd3a08ce4d652ec2169a357bc0cd  
postgresql-13.4.tar.bz2
++++++ postgresql-README.SUSE ++++++
Unix-Domain Socket Directory
============================



Upgrading PostgreSQL on openSUSE and SUSE Linux Enterprise Server
=================================================================

Current versions of PostgreSQL come with the pg_upgrade tool that
simplifies and speeds up the migration of a PostgreSQL installation to
a new version. Before version 9.1 dump and restore was needed which
was much slower.

pg_upgrade needs to have the server binaries of both versions
available. To allow this, we had to change the way PostgreSQL is
packaged as well as the naming of the packages, so that two or more
versions of PostgreSQL can be installed in parallel.  The package
names for PostgreSQL contain numbers indicating the major version.

In PostgreSQL terms for versions up to 9.6 the major version consisted
of the first two components of the three-component version number,
i.e. 8.3, 8.4, 9.0, or 9.1. So, the packages for Postgresql 9.1 are
named postgresql91, postgresql91-server, etc. Inside the packages the
files were moved from their standard locations to a versioned location
such as /usr/lib/postgresql83/bin or /usr/lib/postgresql91/bin to
avoid file conflicts if packages are installed in parallel.

Starting with version 10 the PostgreSQL project changed their
versioning scheme from from three components to two, which means one
component for the major version and one for the minor.  So, the
sequence of major version across the versioning scheme change will be:
9.4, 9.5, 9.6, 10, 11, 12. For versions that use the new versioning
scheme SUSE only puts the single component major version into the
package name, so the postgresql96 package (containg version 9.6
according to the old versioning scheme) will be followed by
postgresql10, then postgresql11, and so on.

The update-alternatives mechanism creates and maintains symbolic links
that cause one version (by default the highest installed version) to
re-appear in the standard locations. By default, database data are
stored under /var/lib/pgsql/data on SUSE Linux.

The following preconditions have to be fulfilled before data migration
can be started:

 1. If not already done, the packages of the old PostgreSQL version
 must be upgraded to the new packaging scheme through a maintenance
 update.

 2. The packages of the new PostgreSQL major version need to be
 installed. As pg_upgrade is contained in postgresql91-contrib, that
 one has to be installed as well, at least until the migration is
 done.

 3. Unless pg_upgrade is used in link mode, the server must have
 enough free disk space to temporarily hold a copy of the database
 files. If the database instance was installed in the default
 location, the needed space in megabytes can be determined by running
 the follwing command as root: "du -hs /var/lib/pgsql/data". If space
 is tight, it might help to run the "VACUUM FULL" SQL command on each
 database in the instance to be migrated, but be aware that it might
 take very long.

The latest upstream documentation for pg_upgrade including step by
step instructions for performing a database migration can be found
online under https://www.postgresql.org/docs/current/pgupgrade.html ,
or locally under
file:///usr/share/doc/packages/postgresqlXX/html/pgupgrade.html , if
the postgresqlXX-docs package is installed. XX is a place holder for
the respective major version here.

NOTE: The online documentation starts with explaining how you can
install PostgreSQL from the upstream sources (which is not necessary
when you install the SUSE RPMs) and also uses other directory names
(/usr/local instead of the update-alternatives based path as described
above).

For background information about the inner workings of pg_upgrade and
a performance comparison with the old dump and restore method, see
http://momjian.us/main/writings/pgsql/pg_upgrade.pdf .
++++++ postgresql-conf.patch ++++++
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
--- src/backend/utils/misc/postgresql.conf.sample.orig
+++ src/backend/utils/misc/postgresql.conf.sample
@@ -416,13 +416,13 @@
 
 # - Where to Log -
 
-#log_destination = 'stderr'            # Valid values are combinations of
+log_destination = 'stderr'             # Valid values are combinations of
                                        # stderr, csvlog, syslog, and eventlog,
                                        # depending on platform.  csvlog
                                        # requires logging_collector to be on.
 
 # This is used when logging to stderr:
-#logging_collector = off               # Enable capturing of stderr and csvlog
+logging_collector = on                 # Enable capturing of stderr and csvlog
                                        # into log files. Required to be on for
                                        # csvlogs.
                                        # (change requires restart)
@@ -514,6 +514,7 @@
 #log_error_verbosity = default         # terse, default, or verbose messages
 #log_hostname = off
 #log_line_prefix = '%m [%p] '          # special values:
+log_line_prefix = '%m %d %u [%p]'
                                        #   %a = application name
                                        #   %u = user name
                                        #   %d = database name
++++++ postgresql-llvm-optional.patch ++++++
--- src/Makefile.global.in.orig
+++ src/Makefile.global.in
@@ -192,7 +192,12 @@ with_krb_srvnam    = @with_krb_srvnam@
 with_ldap      = @with_ldap@
 with_libxml    = @with_libxml@
 with_libxslt   = @with_libxslt@
-with_llvm      = @with_llvm@
+# Only build for LLVM, if the core supports it and the llvm and clang packages 
are installed.
+ifeq (@with_llvm@ $(wildcard /usr/bin/clang /usr/bin/llvm-lto),yes 
/usr/bin/clang /usr/bin/llvm-lto)
+with_llvm      = yes
+else
+with_llvm      = no
+endif
 with_system_tzdata = @with_system_tzdata@
 with_uuid      = @with_uuid@
 with_zlib      = @with_zlib@
++++++ postgresql-plperl-keep-rpath.patch ++++++
This patch keeps PosgreSQL's configure script from removing the rpath from
Perl's linker options, because otherwise the PL/Perl module can't find
libperl.so (bsc#578053).

Index: config/perl.m4
===================================================================
--- config/perl.m4.orig
+++ config/perl.m4
@@ -98,9 +98,7 @@ if test "$PORTNAME" = "win32" ; then
                fi
        fi
 else
-       pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts`
-       pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
-       perl_embed_ldflags=`echo X"$pgac_tmp1" | sed -e "s/^X//" -e 
"s%$pgac_tmp2%%" -e ["s/ -arch [-a-zA-Z0-9_]*//g"]`
+       perl_embed_ldflags=`$PERL -MExtUtils::Embed -e ldopts`
 fi
 AC_SUBST(perl_embed_ldflags)dnl
 if test -z "$perl_embed_ldflags" ; then
Index: configure
===================================================================
--- configure.orig
+++ configure
@@ -9696,9 +9696,7 @@ if test "$PORTNAME" = "win32" ; then
                fi
        fi
 else
-       pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts`
-       pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
-       perl_embed_ldflags=`echo X"$pgac_tmp1" | sed -e "s/^X//" -e 
"s%$pgac_tmp2%%" -e "s/ -arch [-a-zA-Z0-9_]*//g"`
+       perl_embed_ldflags=`$PERL -MExtUtils::Embed -e ldopts`
 fi
 if test -z "$perl_embed_ldflags" ; then
        { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++++++ postgresql-rpmlintrc ++++++
addFilter("useless-explicit-provides")
addFilter("unnecessary-buildrequires")
addFilter("patch-not-applied")
addFilter("non-standard-uid")
addFilter("file-not-in-%lang")
addFilter("no-dependency-on")
addFilter("no-soname")
addFilter("devel-file-in-non-devel-package")
++++++ postgresql-testsuite-keep-results-file.patch ++++++
commit 463154c669010cffc0e96b683576f1e879b61d8b
Author: yac <y...@blesmrt.net>
Date:   Mon Mar 11 18:42:39 2013 +0100

    don't unlink the result file

Index: postgresql-12beta2/src/test/regress/pg_regress.c
===================================================================
--- postgresql-12beta2.orig/src/test/regress/pg_regress.c
+++ postgresql-12beta2/src/test/regress/pg_regress.c
@@ -2597,7 +2597,6 @@ regression_main(int argc, char *argv[],
        else
        {
                unlink(difffilename);
-               unlink(logfilename);
        }
 
        if (fail_count != 0)
++++++ postgresql-var-run-socket.patch ++++++
Change the built-in default socket directory to be /var/run/postgresql.
For backwards compatibility with (probably non-libpq-based) clients that
might still expect to find the socket in /tmp, also create a socket in
/tmp.  This is to resolve communication problems with clients operating
under systemd's PrivateTmp environment, which won't be using the same
global /tmp directory as the server; see bug #825448.

Note that we apply the socket directory change at the level of the
hard-wired defaults in the C code, not by just twiddling the setting in
postgresql.conf.sample; this is so that the change will take effect on
server package update, without requiring any existing postgresql.conf
to be updated.  (Of course, a user who dislikes this behavior can still
override it via postgresql.conf.)


--- src/backend/utils/misc/guc.c.orig
+++ src/backend/utils/misc/guc.c
@@ -4159,7 +4159,7 @@ static struct config_string ConfigureNam
                },
                &Unix_socket_directories,
 #ifdef HAVE_UNIX_SOCKETS
-               DEFAULT_PGSOCKET_DIR,
+               DEFAULT_PGSOCKET_DIR ", /tmp",
 #else
                "",
 #endif
--- src/bin/initdb/initdb.c.orig
+++ src/bin/initdb/initdb.c
@@ -1091,7 +1091,7 @@ setup_config(void)
 
 #ifdef HAVE_UNIX_SOCKETS
        snprintf(repltok, sizeof(repltok), "#unix_socket_directories = '%s'",
-                        DEFAULT_PGSOCKET_DIR);
+                        DEFAULT_PGSOCKET_DIR ", /tmp");
 #else
        snprintf(repltok, sizeof(repltok), "#unix_socket_directories = ''");
 #endif
--- src/include/pg_config_manual.h.orig
+++ src/include/pg_config_manual.h
@@ -201,7 +201,7 @@
  * support them yet.
  */
 #ifndef WIN32
-#define DEFAULT_PGSOCKET_DIR  "/tmp"
+#define DEFAULT_PGSOCKET_DIR  "/var/run/postgresql"
 #else
 #define DEFAULT_PGSOCKET_DIR ""
 #endif

Reply via email to