Hello community,
here is the log from the commit of package postgresql96.13471 for
openSUSE:Leap:15.2:Update checked in at 2020-08-17 16:19:09
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Leap:15.2:Update/postgresql96.13471 (Old)
and /work/SRC/openSUSE:Leap:15.2:Update/.postgresql96.13471.new.3399 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "postgresql96.13471"
Mon Aug 17 16:19:09 2020 rev:1 rq:826671 version:9.6.19
Changes:
--------
New Changes file:
--- /dev/null 2020-08-06 00:20:10.149648038 +0200
+++
/work/SRC/openSUSE:Leap:15.2:Update/.postgresql96.13471.new.3399/postgresql96.changes
2020-08-17 16:19:10.757232352 +0200
@@ -0,0 +1,3188 @@
+-------------------------------------------------------------------
+Thu Aug 13 11:14:43 UTC 2020 - Reinhard Max <m...@suse.com>
+
+- update to 9.6.19:
+ * CVE-2020-14350, bsc#1175194: Make contrib modules' installation
+ scripts more secure.
+ * https://www.postgresql.org/docs/9.6/release-9-6-19.html
+- Remove postgresql-regress.patch, it does not apply anymore and
+ it does not seem to be needed anymore.
+- Pack the /usr/lib/postgresql symlink only into the main package.
+
+-------------------------------------------------------------------
+Tue Jun 16 12:21:43 UTC 2020 - Reinhard Max <m...@suse.com>
+
+- Let postgresqlXX conflict with postgresql-noarch < 12.0.1 to get
+ a clean and complete cutover to the new packaging schema.
+
+-------------------------------------------------------------------
+Wed Jun 3 17:29:52 UTC 2020 - Reinhard Max <m...@suse.com>
+
+- update to 9.6.18 (bsc#1171924).
+ https://www.postgresql.org/about/news/2038/
+ https://www.postgresql.org/docs/9.6/release-9-6-18.html
+- Unify the spec file to work across all current PostgreSQL
+ versions to simplify future maintenance.
+- Move from the "libs" build flavour to a "mini" package that will
+ only be used inside the build service and not get shipped, to
+ avoid confusion with the debuginfo packages (bsc#1148643).
+
+-------------------------------------------------------------------
+Sat Feb 15 03:23:25 UTC 2020 - Marcus Rueckert <mrueck...@suse.de>
+
+- update to 9.6.17 (CVE-2020-1720, bsc#1163985)
+ https://www.postgresql.org/about/news/2011/
+ https://www.postgresql.org/docs/9.6/release-9-6-17.html
+
+-------------------------------------------------------------------
+Sun Dec 29 17:11:56 UTC 2019 - Lars Vogdt <l...@linux-schulserver.de>
+
+- use and package the sha256 checksum for for source
+
+-------------------------------------------------------------------
+Fri Dec 20 15:02:14 UTC 2019 - Marcus Rueckert <mrueck...@suse.de>
+
+- update to 9.6.16:
+ https://www.postgresql.org/about/news/1994/
+ https://www.postgresql.org/docs/9.6/release-9-6-16.html
+
+-------------------------------------------------------------------
+Tue Oct 22 17:02:45 UTC 2019 - Marcus Rueckert <mrueck...@suse.de>
+
+- add requires to the devel package for the libs that are returned
+ by pg_config --libs
+
+-------------------------------------------------------------------
+Mon Aug 12 14:42:26 UTC 2019 - Reinhard Max <m...@suse.com>
+
+- Update to 9.6.15:
+ * https://www.postgresql.org/about/news/1960/
+ * https://www.postgresql.org/docs/9.6/release-9-6-15.html
+ * CVE-2019-10208, bsc#1145092: TYPE in pg_temp executes arbitrary
+ SQL during SECURITY DEFINER execution.
+
+-------------------------------------------------------------------
+Fri Aug 2 08:54:34 UTC 2019 - Martin Liška <mli...@suse.cz>
+
+- Use FAT LTO objects in order to provide proper static library.
+
+-------------------------------------------------------------------
+Fri Jun 21 14:37:09 UTC 2019 - Marcus Rueckert <mrueck...@suse.de>
+
+- Update to 9.6.14:
+ https://www.postgresql.org/docs/9.6/release-9-6-14.html
+
+-------------------------------------------------------------------
+Fri May 10 14:14:11 UTC 2019 - Reinhard Max <m...@suse.com>
+
+- Update to 9.6.13:
+ * https://www.postgresql.org/docs/9.6/release-9-6-13.html
+ * https://www.postgresql.org/about/news/1939/
+ * CVE-2019-10130, bsc#1134689: Prevent row-level security
+ policies from being bypassed via selectivity estimators.
+
+-------------------------------------------------------------------
+Tue Mar 5 10:36:31 UTC 2019 - Reinhard Max <m...@suse.com>
+
+- Make the server-devel package exclusive across versions.
+
+-------------------------------------------------------------------
+Mon Feb 25 13:30:52 UTC 2019 - Reinhard Max <m...@suse.com>
+
+- Update to 9.6.12:
+ * https://www.postgresql.org/docs/9.6/release-9-6-12.html
+ * https://www.postgresql.org/about/news/1920/
+ * By default, panic instead of retrying after fsync() failure,
+ to avoid possible data corruption.
+ * Numerous other bug fixes.
+- Overhaul README.SUSE
+
+-------------------------------------------------------------------
+Fri Nov 9 09:12:43 UTC 2018 - Reinhard Max <m...@suse.com>
+
+- Update to 9.6.11:
+ * Numerous bug fixes, see the release notes:
+ https://www.postgresql.org/docs/9.6/release-9-6-11.html
+ * Remove unneeded library dependencies from PGXS.
+
+-------------------------------------------------------------------
+Wed Oct 17 16:23:19 UTC 2018 - Marcus Rueckert <mrueck...@suse.de>
+
+- add provides for the new server-devel package that will be
+ introduced in postgresql 11
+
+-------------------------------------------------------------------
+Fri Aug 10 16:07:48 UTC 2018 - m...@suse.com
+
+- Update to 9.6.10:
+ https://www.postgresql.org/docs/current/static/release-9-6-10.html
+
+ * CVE-2018-10915, bsc#1104199: Fix failure to reset libpq's state
+ fully between connection attempts.
+
+ * CVE-2018-10925, bsc#1104202: Fix INSERT ... ON CONFLICT UPDATE
+ through a view that isn't just SELECT * FROM ...
+
+-------------------------------------------------------------------
+Wed May 16 09:21:53 UTC 2018 - m...@suse.com
+
+- Update to 9.6.9:
+ https://www.postgresql.org/about/news/1851/
+ https://www.postgresql.org/docs/current/static/release-9-6-9.html
+
+ A dump/restore is not required for those running 9.6.X.
+
+ However, if you use the adminpack extension, you should update
+ it as per the first changelog entry below.
+
+ Also, if the function marking mistakes mentioned in the second
+ and third changelog entries below affect you, you will want to
+ take steps to correct your database catalogs.
+
+ * CVE-2018-1115, bsc#1091610: Remove public execute privilege
+ from contrib/adminpack's pg_logfile_rotate() function
+
+ pg_logfile_rotate() is a deprecated wrapper for the core
+ function pg_rotate_logfile(). When that function was changed
+ to rely on SQL privileges for access control rather than a
+ hard-coded superuser check, pg_logfile_rotate() should have
+ been updated as well, but the need for this was missed. Hence,
+ if adminpack is installed, any user could request a logfile
+ rotation, creating a minor security issue.
+
+ After installing this update, administrators should update
+ adminpack by performing ALTER EXTENSION adminpack UPDATE in
+ each database in which adminpack is installed.
+
+ * Fix incorrect volatility markings on a few built-in functions
+
+ * Fix incorrect parallel-safety markings on a few built-in
+ functions.
+
+-------------------------------------------------------------------
+Sat Mar 10 00:33:05 UTC 2018 - mrueck...@suse.de
+
+- Update to PostgreSQL 9.6.8
+ * https://www.postgresql.org/docs/9.6/static/release-9-6-8.html
+ A dump/restore is not required for those running 9.6.X.
+
+ However, if you run an installation in which not all users are
+ mutually trusting, or if you maintain an application or
+ extension that is intended for use in arbitrary situations, it
+ is strongly recommended that you read the documentation changes
+ described in the first changelog entry in the link above, and
+ take suitable steps to ensure that your installation or code is
+ secure.
+
+ Also, the changes described in the second changelog entry in
+ the link above may cause functions used in index expressions or
+ materialized views to fail during auto-analyze, or when
+ reloading from a dump. After upgrading, monitor the server logs
+ for such problems, and fix affected functions.
+ * CVE-2018-1058 bsc#1081925 Uncontrolled search path element in
+ pg_dump and other client applications
+
+-------------------------------------------------------------------
+Fri Feb 9 10:00:53 UTC 2018 - m...@suse.com
+
+- Update to PostgreSQL 9.6.7
+ * https://www.postgresql.org/docs/9.6/static/release-9-6-7.html
+ * CVE-2018-1053, bsc#1077983: Ensure that all temporary files
+ made by pg_upgrade are non-world-readable.
+ * bsc#1079757: Rename pg_rewind's copy_file_range function to
+ avoid conflict with new Linux system call of that name.
+- Don't %config the symlinks to /etc/alternatives to avoid rpmlint
+ warnings.
+
+-------------------------------------------------------------------
++++ 2991 more lines (skipped)
++++ between /dev/null
++++ and
/work/SRC/openSUSE:Leap:15.2:Update/.postgresql96.13471.new.3399/postgresql96.changes
New:
----
baselibs.conf
postgresql-9.6.19.tar.bz2
postgresql-9.6.19.tar.bz2.sha256
postgresql-README.SUSE
postgresql-conf.patch
postgresql-plperl-keep-rpath.patch
postgresql-rpmlintrc
postgresql-testsuite-int8.sql.patch
postgresql-testsuite-keep-results-file.patch
postgresql-var-run-socket.patch
postgresql96.changes
postgresql96.spec
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ postgresql96.spec ++++++
++++ 940 lines (skipped)
++++++ baselibs.conf ++++++
libpq5
provides "postgresql-libs-<targettype> = <version>"
obsoletes "postgresql-libs-<targettype> < <version>"
conflicts "postgresql-libs-<targettype> < 9.1.6"
libecpg6
++++++ postgresql-9.6.19.tar.bz2.sha256 ++++++
61f93a94ccddbe0b2d1afaf03f04ba605d8af5b774ff9b830e5adeb50ab55cb0
postgresql-9.6.19.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
@@ -330,13 +330,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)
@@ -430,7 +430,8 @@
#log_duration = off
#log_error_verbosity = default # terse, default, or verbose messages
#log_hostname = off
-#log_line_prefix = '' # special values:
+log_line_prefix = '%t %d %u '
+ # special values:
# %a = application name
# %u = user name
# %d = database name
++++++ 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).
--- config/perl.m4.orig
+++ config/perl.m4
@@ -100,9 +100,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
--- configure.orig
+++ configure
@@ -7537,9 +7537,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-int8.sql.patch ++++++
commit a210bee6273041cf9773383e2dda58a7d7c84be4
Author: yac <y...@blesmrt.net>
Date: Fri Mar 8 17:56:58 2013 +0100
+ SET LC_
--- src/test/regress/expected/int8.out.orig
+++ src/test/regress/expected/int8.out
@@ -580,6 +580,7 @@ SELECT '' AS to_char_12, to_char(q2, 'FM
| -4567890123456789.000
(5 rows)
+SET LC_MONETARY='C';
SELECT '' AS to_char_13, to_char(q2, 'L9999999999999999.000') FROM INT8_TBL;
to_char_13 | to_char
------------+------------------------
--- src/test/regress/expected/numeric.out.orig
+++ src/test/regress/expected/numeric.out
@@ -1079,6 +1079,7 @@ SELECT '' AS to_char_15, to_char(val, 'F
| -24926804.04504742
(10 rows)
+SET LC_MONETARY='C';
SELECT '' AS to_char_16, to_char(val, 'L9999999999999999.099999999999999')
FROM num_data;
to_char_16 | to_char
------------+------------------------------------
--- src/test/regress/sql/int8.sql.orig
+++ src/test/regress/sql/int8.sql
@@ -116,6 +116,7 @@ SELECT '' AS to_char_9, to_char(q2, '09
SELECT '' AS to_char_10, to_char(q2, 'S0999999999999999') FROM INT8_TBL;
SELECT '' AS to_char_11, to_char(q2, 'FM0999999999999999') FROM INT8_TBL;
SELECT '' AS to_char_12, to_char(q2, 'FM9999999999999999.000') FROM INT8_TBL;
+SET LC_MONETARY='C';
SELECT '' AS to_char_13, to_char(q2, 'L9999999999999999.000') FROM INT8_TBL;
SELECT '' AS to_char_14, to_char(q2, 'FM9999999999999999.999') FROM INT8_TBL;
SELECT '' AS to_char_15, to_char(q2, 'S 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 . 9 9
9') FROM INT8_TBL;
--- src/test/regress/sql/numeric.sql.orig
+++ src/test/regress/sql/numeric.sql
@@ -773,6 +773,7 @@ SELECT '' AS to_char_12, to_char(val, 'F
SELECT '' AS to_char_13, to_char(val, 'FM9999999999990999.990999999999999')
FROM num_data;
SELECT '' AS to_char_14, to_char(val, 'FM0999999999999999.999909999999999')
FROM num_data;
SELECT '' AS to_char_15, to_char(val, 'FM9999999990999999.099999999999999')
FROM num_data;
+SET LC_MONETARY='C';
SELECT '' AS to_char_16, to_char(val, 'L9999999999999999.099999999999999')
FROM num_data;
SELECT '' AS to_char_17, to_char(val, 'FM9999999999999999.99999999999999')
FROM num_data;
SELECT '' AS to_char_18, to_char(val, 'S 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 . 9 9
9 9 9 9 9 9 9 9 9 9 9 9 9 9 9') FROM num_data;
++++++ 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-9.6beta1/src/test/regress/pg_regress.c
===================================================================
--- postgresql-9.6beta1.orig/src/test/regress/pg_regress.c
+++ postgresql-9.6beta1/src/test/regress/pg_regress.c
@@ -2520,7 +2520,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/bin/pg_upgrade/test.sh.orig
+++ src/bin/pg_upgrade/test.sh
@@ -159,6 +159,12 @@ done
EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
export EXTRA_REGRESS_OPTS
+# we want the Unix sockets in $temp_root
+PGHOST=$temp_root
+export PGHOST
+
+POSTMASTER_OPTS="$POSTMASTER_OPTS -c unix_socket_directories='$PGHOST'"
+
standard_initdb "$oldbindir"/initdb
"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
--- src/backend/utils/misc/guc.c.orig
+++ src/backend/utils/misc/guc.c
@@ -3360,7 +3360,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
@@ -1229,7 +1229,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
@@ -182,7 +182,7 @@
* here's where to twiddle it. You can also override this at runtime
* with the postmaster's -k switch.
*/
-#define DEFAULT_PGSOCKET_DIR "/tmp"
+#define DEFAULT_PGSOCKET_DIR "/var/run/postgresql"
/*
* This is the default event source for Windows event log.
