Re: /usr-move: Do we support upgrades without apt?

[Christoph Berg]

Re: Helmut Grohne
> Is it ok to call upgrade scenarios failures that cannot be reproduced
> using apt unsupported until we no longer deal with aliasing?
> 
> If the answer is yes here, we'll close #1058937 (Ben's libnfsidmap1 bug)
> with no action calling the scenario unsupported.

I think we should only deal with problems that can reasonably happen
in practice. If an extra hammer is required to hit the problem, we
should not spend extra effort on it.

Christoph

Bug#1056961: transition: limesuite

[Christoph Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: limesu...@packages.debian.org
Control: affects -1 + src:limesuite

Hi,

I'm sorry that I rushed that with neglecting to ask for coordination -
perhaps the Cambridge Minidebconf was too exciting and I just
uploaded. Anyway:

There is a new limesuite version in unstable, and the 3 reverse-deps
need binnmus "Rebuild against limesuite 23.11.":

gr-limesdr
indi-limesdr
osmo-trx

https://release.debian.org/transitions/html/auto-limesuite.html

Thanks,
Christoph

Bug#1053346: bullseye-pu: package postgresql-common/225+deb11u1

[Christoph Berg]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: postgresql-com...@packages.debian.org
Control: affects -1 + src:postgresql-common

Hi,

I've uploaded a new postgresql-common package to bullseye that fixes
the autopktest tests on salsa-ci and ci.debian.net. (Test-only
changes.)

* Fix t/085 to correctly prepare the test environment
* Tell ./testsuite to continue testing even when one test fails
* Change debian/gitlab-ci.yml to use the standard pipeline

The result is mostly green:

https://salsa.debian.org/postgresql/postgresql-common/-/pipelines/585893

(The lintian error is an dependency on lsb-base that I don't want to
touch in oldstable.)

Please unblock postgresql-common/225+deb11u1

Thanks,
Christoph

Control files: lines which differ (wdiff format)

Vcs-Git: https://salsa.debian.org/postgresql/postgresql-common.git {+-b bullseye+}

diff -Nru postgresql-common-225/debian/changelog postgresql-common-225+deb11u1/debian/changelog
--- postgresql-common-225/debian/changelog	2021-02-02 15:40:25.0 +0100
+++ postgresql-common-225+deb11u1/debian/changelog	2023-10-02 10:20:47.0 +0200
@@ -1,3 +1,11 @@
+postgresql-common (225+deb11u1) bullseye; urgency=medium
+
+  * t/085_pg_ctl.conf.t: sudo and salsa-ci set the core file size hard limit
+to 0 by default, undo that. (Salsa: postgresql/postgresql#2)
+  * testsuite: Run all tests even when one is failing.
+
+ -- Christoph Berg   Mon, 02 Oct 2023 10:20:47 +0200
+
 postgresql-common (225) unstable; urgency=medium
 
   * pg_lsclusters, cluster_info: Show cluster managed by pacemaker or patroni.
diff -Nru postgresql-common-225/debian/control postgresql-common-225+deb11u1/debian/control
--- postgresql-common-225/debian/control	2020-10-22 14:15:09.0 +0200
+++ postgresql-common-225+deb11u1/debian/control	2023-10-02 10:20:47.0 +0200
@@ -8,7 +8,7 @@
  Peter Eisentraut ,
 Standards-Version: 4.4.0
 Rules-Requires-Root: no
-Vcs-Git: https://salsa.debian.org/postgresql/postgresql-common.git
+Vcs-Git: https://salsa.debian.org/postgresql/postgresql-common.git -b bullseye
 Vcs-Browser: https://salsa.debian.org/postgresql/postgresql-common
 Build-Depends:
  debhelper (>= 9),
diff -Nru postgresql-common-225/debian/gitlab-ci.yml postgresql-common-225+deb11u1/debian/gitlab-ci.yml
--- postgresql-common-225/debian/gitlab-ci.yml	2020-09-30 09:27:36.0 +0200
+++ postgresql-common-225+deb11u1/debian/gitlab-ci.yml	2023-10-02 10:20:47.0 +0200
@@ -1,44 +1,5 @@
-.debian_script: _script
-  - $SUDO apt-get update
-  - $SUDO apt-get -o DPkg::Options::=--force-confnew dist-upgrade -y
-  - $SUDO apt-get install -y build-essential fakeroot debhelper libreadline-dev dh-systemd
-  - rm -f ../*.deb ../*.dsc ../*.buildinfo ../*.changes ../*.tar.*
-  - dpkg-buildpackage -uc -us -rfakeroot
-  - ( set -x; for deb in ../*.deb; do dpkg-deb --info $deb; dpkg-deb --contents $deb; done )
-  - ( set -x; $SUDO dpkg --force-confmiss --force-confnew -i ../*.deb || { $SUDO apt-get install -fy; $SUDO dpkg --force-confmiss --force-confnew -i ../*.deb; } )
-  - dpkg -l postgresql\* | cat
-  - $SUDO ./cleanpg
-  - cd /usr/share/postgresql-common && $SUDO ./testsuite -v "$(./supported-versions)" -i
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
 
-sid:
-  image: debian:unstable
-  script: *debian_script
-  variables:
-SKIP_IPV6: 1
-
-buster:
-  tags:
-- buster
-  script: *debian_script
-  variables:
-SUDO: sudo
-
-stretch:
-  tags:
-- stretch
-  script: *debian_script
-  variables:
-SUDO: sudo
-
-centos7:
-  tags:
-- centos7
-  script:
-- sudo yum install -y rpm-build centos-release-scl epel-release # for llvm
-- make rpmremove
-- make rpmbuild
-- rpm -ql pgdg-redhat-repo > /dev/null || sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
-- sudo yum -y update
-- make rpminstall
-- sudo ./cleanpg
-- cd /usr/share/postgresql-common && sudo ./testsuite -v "$(./supported-versions)" -i
+variables:
+  RELEASE: 'bullseye'
diff -Nru postgresql-common-225/t/085_pg_ctl.conf.t postgresql-common-225+deb11u1/t/085_pg_ctl.conf.t
--- postgresql-common-225/t/085_pg_ctl.conf.t	2019-11-15 19:58:53.0 +0100
+++ postgresql-common-225+deb11u1/t/085_pg_ctl.conf.t	2023-10-02 10:20:47.0 +0200
@@ -6,7 +6,7 @@
 use TestLib;
 use PgCommon;
 
-use Test::More tests => $MAJORS[-1] >= '8.3' ? 29 : 1;
+use Test::More tests => $MAJORS[-1] >= '8.3' ? 33 : 1;
 
 # Do test with newest version
 my $v = $MAJORS[-1];
@@ -15,38 +15,37 @@
 exit 0;
 }
 
-is ((system "pg_createcluster $v main >/dev/null"), 0, "pg_createcluster $v main");
+# enable core dumps
+# sudo and salsa-ci set the hard limit to 0 by default, un

Bug#1052324: nmu: glom_1.30.4-7+b3

[Christoph Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:glom

Please binnmu glom:

nmu glom_1.30.4-7+b3 . ANY . unstable . -m "Rebuild against postgresql-16."

Thanks,
Christoph

Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?

[Christoph Berg]

Re: Luca Boccassi
> If we were to do a MBF against packages that in _Bookworm_ have
> introduced new files in /bin, /sbin or /lib*, would you accept the
> consequent mass unblock request?

Fwiw, I would restrict that to packages that didn't have files in
these directories before. Telling a maintainer that they should
continue install foo.service to /lib/systemd, but the newly introduced
bar.service needs to got to /usr/lib/systemd seems like a lot of extra
work and asking for bugs to happen.

Christoph

Bug#1036162: unblock: postgresql-mysql-fdw/2.8.0-4

[Christoph Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: postgresql-mysql-...@packages.debian.org
Control: affects -1 + src:postgresql-mysql-fdw

Please unblock package postgresql-mysql-fdw

[ Reason ]
The new version fixes the regression tests (breakage caused by changes
on the mariadb side I think).

[ Impact ]
Test-only fix, the software remains unchanged.

[ Tests ]
It's the tests themselves, there are no extra tests :)

[ Risks ]
None.

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

unblock postgresql-mysql-fdw/2.8.0-4

Christoph

No differences were encountered between the control files

diff -Nru postgresql-mysql-fdw-2.8.0/debian/changelog postgresql-mysql-fdw-2.8.0/debian/changelog
--- postgresql-mysql-fdw-2.8.0/debian/changelog	2022-10-24 16:01:20.0 +0200
+++ postgresql-mysql-fdw-2.8.0/debian/changelog	2023-05-15 15:11:37.0 +0200
@@ -1,3 +1,9 @@
+postgresql-mysql-fdw (2.8.0-4) unstable; urgency=medium
+
+  * Adjust tests for changed mysql error messages. (Closes: #1033836)
+
+ -- Christoph Berg   Mon, 15 May 2023 15:11:37 +0200
+
 postgresql-mysql-fdw (2.8.0-3) unstable; urgency=medium
 
   * Upload for PostgreSQL 15.
diff -Nru postgresql-mysql-fdw-2.8.0/debian/patches/mysql-error-text postgresql-mysql-fdw-2.8.0/debian/patches/mysql-error-text
--- postgresql-mysql-fdw-2.8.0/debian/patches/mysql-error-text	2022-10-24 16:01:20.0 +0200
+++ postgresql-mysql-fdw-2.8.0/debian/patches/mysql-error-text	2023-05-15 15:11:37.0 +0200
@@ -20,3 +20,25 @@
  	  RAISE NOTICE 'failed to connect to MySQL: Unknown MySQL server host ''localhos''';
  ELSE
  	  RAISE NOTICE '%', SQLERRM;
+--- a/expected/dml.out
 b/expected/dml.out
+@@ -83,7 +83,7 @@ $$
+ BEGIN
+   INSERT INTO fdw126_ft2 VALUES(2, 'Two');
+   EXCEPTION WHEN others THEN
+-	IF SQLERRM LIKE '%SELECT command denied to user ''%''@''%'' for table ''student''' THEN
++	IF SQLERRM LIKE '%SELECT command denied to user ''%''@''%'' for table %student%' THEN
+ 	  RAISE NOTICE E'failed to execute the MySQL query: \nUnknown database ''public''';
+ ELSE
+ 	  RAISE NOTICE '%', SQLERRM;
+--- a/sql/dml.sql
 b/sql/dml.sql
+@@ -70,7 +70,7 @@ $$
+ BEGIN
+   INSERT INTO fdw126_ft2 VALUES(2, 'Two');
+   EXCEPTION WHEN others THEN
+-	IF SQLERRM LIKE '%SELECT command denied to user ''%''@''%'' for table ''student''' THEN
++	IF SQLERRM LIKE '%SELECT command denied to user ''%''@''%'' for table %student%' THEN
+ 	  RAISE NOTICE E'failed to execute the MySQL query: \nUnknown database ''public''';
+ ELSE
+ 	  RAISE NOTICE '%', SQLERRM;

Bug#1036006: unblock: postgresql-15/15.3-0+deb12u1

[Christoph Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: postgresql...@packages.debian.org
Control: affects -1 + src:postgresql-15

Please unblock package postgresql-15.

[ Reason ]
The new version fixes CVE-2023-2454 and CVE-2023-2455.

[ Impact ]
CVE-2023-2454 and CVE-2023-2455.

[ Tests ]
The package passes all the built-in regression tests and the
postgresql-common testsuite.

[ Risks ]
New PostgreSQL upstream releases are generally accepted.

[ Checklist ]
  (No changes in debian/ except for the changelog)
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

postgresql-15 (15.3-0+deb12u1) unstable; urgency=medium

  * New upstream version.

+ Prevent CREATE SCHEMA from defeating changes in search_path
  (Report and fix by Alexander Lakhin, CVE-2023-2454)

  Within a CREATE SCHEMA command, objects in the prevailing search_path,
  as well as those in the newly-created schema, would be visible even
  within a called function or script that attempted to set a secure
  search_path.  This could allow any user having permission to create a
  schema to hijack the privileges of a security definer function or
  extension script.

+ Enforce row-level security policies correctly after inlining a
  set-returning function (Report by Wolfgang Walther, CVE-2023-2455)

  If a set-returning SQL-language function refers to a table having
  row-level security policies, and it can be inlined into a calling query,
  those RLS policies would not get enforced properly in some cases
  involving re-using a cached plan under a different role. This could
  allow a user to see or modify rows that should have been invisible.

 -- Christoph Berg   Tue, 09 May 2023 19:05:02 +0200

unblock postgresql-15/15.3-0+deb12u1

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#1034599: unblock: libcharon/4.13.0-2

[Christoph Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libcha...@packages.debian.org, Debian 3-D Printing Packages 
<3dprinter-gene...@lists.alioth.debian.org>
Control: affects -1 + src:libcharon

Please unblock package libcharon

The new version moves the .service file to /lib where debhelper can
find it. (#1034210)

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

unblock libcharon/4.13.0-2

$ debdiff python3-charon_4.13.0-1_all.deb python3-charon_4.13.0-2_all.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   /lib/systemd/system/charon.service
-rwxr-xr-x  root/root   DEBIAN/postrm

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/lib/systemd/system/charon.service

Control files: lines which differ (wdiff format)

Installed-Size: [-123-] {+126+}
Version: [-4.13.0-1-] {+4.13.0-2+}


Christoph

No differences were encountered between the control files

diff -Nru libcharon-4.13.0/debian/changelog libcharon-4.13.0/debian/changelog
--- libcharon-4.13.0/debian/changelog	2022-01-14 09:07:02.0 +0100
+++ libcharon-4.13.0/debian/changelog	2023-04-18 22:29:20.0 +0200
@@ -1,3 +1,10 @@
+libcharon (4.13.0-2) unstable; urgency=medium
+
+  [ Gregor Riepl ]
+  * Fix systemd service path. Closes: #1034210
+
+ -- Christoph Berg   Tue, 18 Apr 2023 22:29:20 +0200
+
 libcharon (4.13.0-1) unstable; urgency=medium
 
   * Fix GitHub watch file.
diff -Nru libcharon-4.13.0/debian/patches/0002-service-files-in-root.patch libcharon-4.13.0/debian/patches/0002-service-files-in-root.patch
--- libcharon-4.13.0/debian/patches/0002-service-files-in-root.patch	1970-01-01 01:00:00.0 +0100
+++ libcharon-4.13.0/debian/patches/0002-service-files-in-root.patch	2023-04-18 22:29:20.0 +0200
@@ -0,0 +1,11 @@
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -35,7 +35,7 @@ endif()
+ install(DIRECTORY Charon DESTINATION ${CHARON_INSTALL_PATH} ${_excludes})
+ 
+ if(INSTALL_SERVICE)
+-install(FILES service/charon.service DESTINATION lib/systemd/system)
++install(FILES service/charon.service DESTINATION /lib/systemd/system)
+ install(FILES service/nl.ultimaker.charon.conf DESTINATION share/dbus-1/system.d)
+ endif()
+ 
diff -Nru libcharon-4.13.0/debian/patches/series libcharon-4.13.0/debian/patches/series
--- libcharon-4.13.0/debian/patches/series	2020-09-04 09:15:51.0 +0200
+++ libcharon-4.13.0/debian/patches/series	2023-04-18 22:29:20.0 +0200
@@ -1 +1,2 @@
+0002-service-files-in-root.patch
 #2001-Allow-overriding-the-Python-version-in-CMake.patch

Bug#1033449: unblock: fbb/7.011-2

[Christoph Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: f...@packages.debian.org, Debian Hamradio Maintainers 

Control: affects -1 + src:fbb

Please unblock package fbb. The new version fixes a segfault when
listing subdirectories. (Closes: #1032223)

The diff is unfortunately quite noisy since different quilt flags were
used when refreshing the patch where the bug was in. The effective
interdiff is this:

+Index: fbb-7.011/src/ibm.c
+===
+--- fbb-7.011.orig/src/ibm.c
 fbb-7.011/src/ibm.c
-@@ -205,13 +204,10 @@
+@@ -205,13 +204,13 @@ void format_ffblk (struct ffblk *blk, st
else
sprintf (filename, "%s/%s", blk->ff_base, dir->d_name);

 -  ret = lstat (filename, );
--
++lstat (filename, );
+
if (S_ISLNK (st.st_mode))
{
/* printf ("link\n"); */
blk->ff_attrib |= FA_LINK;
 -  ret = stat (filename, );
++stat (filename, );
if (S_ISDIR (st.st_mode))
{
blk->ff_attrib |= FA_DIREC;

I.e. the original patch mistakenly removed lstat, and the new patch
restores it to the original place. "ret" is dropped since the code
doesn't use it.

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

unblock fbb/7.011-2

Christoph
diff --git a/debian/changelog b/debian/changelog
index 313edc3..4620c2c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+fbb (7.011-2) unstable; urgency=medium
+
+  * Team upload.
+  * Address segfault when listing subdirectories (Closes: #1032223)
+Thank you to Mike Quin for the bug report and patch.
+
+ -- tony mancill   Sun, 05 Mar 2023 09:53:13 -0800
+
 fbb (7.011-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/patches/05-fix-compile-warnings b/debian/patches/05-fix-compile-warnings
index 485541e..0e87f45 100644
--- a/debian/patches/05-fix-compile-warnings
+++ b/debian/patches/05-fix-compile-warnings
@@ -1,9 +1,14 @@
-Fix trivial compiler warnings, mostly unused vars
+Description: Fix trivial compiler warnings, mostly unused vars
+  Thank you to Mike Quin for patching the patch.
+  See:  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032223
 Author: Colin Tuckley col...@debian.org
+Last-Update: 2023-03-02
 
 a/src/console.c
-+++ b/src/console.c
-@@ -254,7 +254,6 @@
+Index: fbb-7.011/src/console.c
+===
+--- fbb-7.011.orig/src/console.c
 fbb-7.011/src/console.c
+@@ -254,7 +254,6 @@ void connect_fen (void)
  
  void winputs (int voie, int attr, char *ptr)
  {
@@ -11,7 +16,7 @@ Author: Colin Tuckley col...@debian.org
  	int header;
  
  	if (attr == -1)
-@@ -265,7 +264,6 @@
+@@ -265,7 +264,6 @@ void winputs (int voie, int attr, char *
  	else
  		header = 0;
  
@@ -19,9 +24,11 @@ Author: Colin Tuckley col...@debian.org
  	window_write (voie, ptr, strlen (ptr), attr, header);
  }
  
 a/src/drv_mod.c
-+++ b/src/drv_mod.c
-@@ -575,11 +575,6 @@
+Index: fbb-7.011/src/drv_mod.c
+===
+--- fbb-7.011.orig/src/drv_mod.c
 fbb-7.011/src/drv_mod.c
+@@ -575,11 +575,6 @@ int lit_port_modem (int port)
  			ioctl (ptrcom->comfd, TIOCMGET, );
  			con = (mcs & TIOCM_CAR) ? 1 : 0;
  
@@ -33,7 +40,7 @@ Author: Colin Tuckley col...@debian.org
  			if ((svoie[voie]->sta.connect > 1) && (svoie[voie]->sta.connect < 17) && (!con))
  			{
  md_no_echo (voie);
-@@ -851,10 +846,12 @@
+@@ -851,10 +846,12 @@ int lit_port_modem (int port)
  			con = (nstat & 0x80) ? 1 : 0;
  #endif
  
@@ -46,9 +53,11 @@ Author: Colin Tuckley col...@debian.org
  
  			if ((svoie[voie]->sta.connect > 1) && (svoie[voie]->sta.connect < 17) && (!con))
  			{
 a/src/fwdovl5.c
-+++ b/src/fwdovl5.c
-@@ -737,14 +737,9 @@
+Index: fbb-7.011/src/fwdovl5.c
+===
+--- fbb-7.011.orig/src/fwdovl5.c
 fbb-7.011/src/fwdovl5.c
+@@ -737,14 +737,9 @@ void init_part (void)
  	}
  	else
  	{
@@ -63,9 +72,11 @@ Author: Colin Tuckley col...@debian.org
  		if (jour < 0)
  			jour += 31;
  		if (jour > 15)
 a/src/ibm.c
-+++ b/src/ibm.c
-@@ -190,7 +190,6 @@
+Index: fbb-7.011/src/ibm.c
+===
+--- fbb-7.011.orig/src/ibm.c
 fbb-7.011/src/ibm.c
+@@ -190,7 +190,6 @@ int getftime (int fd, struct ftime *ft)
  
  void format_ffblk (struct ffblk *blk, struct dirent *dir)
  {
@@ -73,23 +84,27 @@ Author: Colin Tuckley col...@debian.org
  	int year;
  	struct stat st;
  	struct tm *tm;
-@@ -205,13 +204,10 @@
+@@ -205,13 +204,13 @@ void format_ffblk (struct ffblk *blk, st
  	else
  		sprintf (filename, "%s/%s", blk->ff_base, 

Bug#1033220: unblock: postgresql-common/248

[Christoph Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: postgresql-com...@packages.debian.org
Control: affects -1 + src:postgresql-common

Please unblock package postgresql-common.

The new version contains an updated translation and fixes a small
config file parsing issue.

[ Tests ]
The postgresql-common testsuite passes.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing
  (well, git diff)

unblock postgresql-common/248

Christoph
diff --git a/PgCommon.pm b/PgCommon.pm
index 783aa4c..e51d89e 100644
--- a/PgCommon.pm
+++ b/PgCommon.pm
@@ -340,8 +340,8 @@ sub set_conffile_value {
 # of appending
 if (!$found) {
 	for (my $i=0; $i <= $#lines; ++$i) {
-	if ($lines[$i] =~ /^\s*#\s*($key)(\s*(?:=|\s)\s*)\w+\b((?:\s*#.*)?)/i or
-		$lines[$i] =~ /^\s*#\s*($key)(\s*(?:=|\s)\s*)'[^']*'((?:\s*#.*)?)/i) {
+	if ($lines[$i] =~ /^\s*#\s*($key)(\s*(?:=|\s)\s*)\w+\b((?:\s*#.*)?)$/i or
+		$lines[$i] =~ /^\s*#\s*($key)(\s*(?:=|\s)\s*)'[^']*'((?:\s*#.*)?)$/i) {
 		$lines[$i] = "$1$2$value$3\n";
 		$found = 1;
 		last;
diff --git a/debian/changelog b/debian/changelog
index dbdbe2c..4a2306b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+postgresql-common (248) unstable; urgency=medium
+
+  [ Christoph Berg ]
+  * Update ro debconf translation, mulțumesc Remus-Gabriel Chelu!
+
+  [ Athos Ribeiro ]
+  * Fix set_conffile_value comment parsing regular expression.
+
+ -- Christoph Berg   Tue, 14 Mar 2023 15:19:01 +0100
+
 postgresql-common (247) unstable; urgency=medium
 
   [ Christoph Berg ]
diff --git a/debian/po/ro.po b/debian/po/ro.po
index 5faa387..86d4d41 100644
--- a/debian/po/ro.po
+++ b/debian/po/ro.po
@@ -1,23 +1,30 @@
-# translation of templates.po to Romanian
-# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
-# This file is distributed under the same license as the PACKAGE package.
+# Mesajele în limba română pentru pachetul postgresql-common.
+# translation of postgresql-common.po to Romanian
+# Copyright © 2008, 2023 THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the postgresql-common package.
 #
 # Igor Stirbu , 2008.
+# Remus-Gabriel Chelu , 2023.
+# NOTĂ: la sugestia lui Daniel Șerbănescu, am vrut să traduc cluster(s) = grup(uri) de servere;
+# dar în textul mesajelor, nu rezultă foarte clar dacă cluster(s) = ca mai sus(grup de servere),
+# sau este vorba de baza/bazele de date ale acestora, sau decît directorul(ele) ce găzduiesc
+# aceste baze de date. Așa că le-am lăsat în românizatul cluster(e)/clusterul(ele). Scuze...
+#
 msgid ""
 msgstr ""
-"Project-Id-Version: templates\n"
+"Project-Id-Version: postgresql-common 246\n"
 "Report-Msgid-Bugs-To: postgresql-com...@packages.debian.org\n"
 "POT-Creation-Date: 2016-03-05 11:47+0100\n"
-"PO-Revision-Date: 2008-07-21 10:32+0300\n"
-"Last-Translator: Igor Stirbu \n"
+"PO-Revision-Date: 2023-02-12 18:02+0100\n"
+"Last-Translator: Remus-Gabriel Chelu \n"
 "Language-Team: Romanian \n"
 "Language: ro\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"X-Generator: KBabel 1.11.4\n"
-"Plural-Forms:  nplurals=3; plural=n==1 ? 0 : (n==0 || (n%100 > 0 && n%100 < "
+"Plural-Forms: nplurals=3; plural=n==1 ? 0 : (n==0 || (n%100 > 0 && n%100 < "
 "20)) ? 1 : 2;\n"
+"X-Generator: Poedit 3.2.2\n"
 
 #. Type: error
 #. Description
@@ -31,38 +38,38 @@ msgstr "Versiunea majoră învechită ${old}"
 #: ../postgresql-common.templates:1001
 msgid ""
 "The PostgreSQL version ${old} is obsolete, but the server or client packages "
-"are still installed. Please install the latest packages (postgresql-"
-"${latest} and postgresql-client-${latest}) and upgrade the existing "
-"${oldversion} clusters with pg_upgradecluster (see manpage)."
+"are still installed. Please install the latest packages (postgresql-${latest} "
+"and postgresql-client-${latest}) and upgrade the existing ${oldversion} "
+"clusters with pg_upgradecluster (see manpage)."
 msgstr ""
 "Versiunea PostgreSQL ${old} este învechită, dar pachetele pentru server sau "
 "client sunt încă instalate. Instalați cele mai recente pachete (postgresql-"
 "${latest} și postgresql-client-${latest}) și actualizați clusterele "
-"${oldversion} existente cu pg_upgradecluster (a se vedea pagina de manual)."
+"${oldversion} existente cu ajutorul comenzii «pg_upgradecluster» (consultați "
+"pagina de manual)."
 
 #. Type: error

Bug#1023535: transition: protobuf

[Christoph Berg]

Re: László Böszörményi
> On the other hand I'm done with the rebuilds and patched all issues,
> this transition may start immediately at your decision. The only
> downside is that the Sid version of cura-engine is FTBFS and to fix
> it, the libarcus transition (only affecting this package) will need to
> be done.

I'll take care of cura and deps when the transition starts.
(Unfortunately the newest libarcus package doesn't work with the old
protobuf, so we can't upload that yet.)

Christoph

Re: Bug#1019335: Reconsider the egrep and fgrep deprecation

[Christoph Berg]

Re: Santiago Ruano Rincón
> Changes are ready. I'll upload on Monday.

Thanks!

Christoph

Bug#1013347: buster-pu: package postgresql-common/200+deb10u5

[Christoph Berg]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ans...@debian.org

Hi,

ftp-master has asked me to upload the fix for #933569 to buster, which
is what this upload is doing.

Failing dak test:

https://salsa.debian.org/ftp-team/dak/-/jobs/2731591#L3411

/usr/bin/pg_virtualenv: line 174: /tmp/pgpassword.wnVYr6: Permission denied

I've also cherry-picked the pg_virtualenv test that the buster package
did not have; the test verifies that the problem is gone.

Christoph
diff --git a/debian/changelog b/debian/changelog
index fa06ca4..fb31230 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+postgresql-common (200+deb10u5) buster; urgency=medium
+
+  * pg_virtualenv: Write temporary password file before chowning the file.
+(Closes: #933569)
+  * t/135_pg_virtualenv.t: Import test from master.
+
+ -- Christoph Berg   Wed, 22 Jun 2022 13:11:44 +0200
+
 postgresql-common (200+deb10u4) buster; urgency=medium
 
   * t/170_extensions.t: Don't drop plpgsql before testing extensions.
diff --git a/pg_virtualenv b/pg_virtualenv
index 7329bc9..9bfbd10 100755
--- a/pg_virtualenv
+++ b/pg_virtualenv
@@ -91,6 +91,13 @@ shift $(($OPTIND - 1))
 # if no command is given, open a shell
 [ "${1:-}" ] || set -- ${SHELL:-/bin/sh}
 
+# generate a password
+if [ -x /usr/bin/pwgen ]; then
+export PGPASSWORD=$(pwgen 20 1)
+else
+export PGPASSWORD=$(dd if=/dev/urandom bs=1k count=1 2>/dev/null | md5sum - | awk '{ print $1 }')
+fi
+
 # we are not root
 if [ "$(id -u)" != 0 ]; then
 NONROOT=1
@@ -114,6 +121,7 @@ if [ "${NONROOT:-}" ]; then
 mkdir "$PGSYSCONFDIR" "$WORKDIR/log"
 PWFILE="$PGSYSCONFDIR/pwfile"
 LOGDIR="$WORKDIR/log"
+echo "$PGPASSWORD" > "$PWFILE"
 
 cleanup () {
 	set +e
@@ -141,6 +149,7 @@ else
 
 export PGUSER="postgres"
 PWFILE=$(mktemp -t pgpassword.XX)
+echo "$PGPASSWORD" > "$PWFILE" # write password before chowning the file
 chown postgres:postgres "$PWFILE"
 
 cleanup () {
@@ -166,13 +175,6 @@ else
 fi
 
 # create postgres environments
-if [ -x /usr/bin/pwgen ]; then
-export PGPASSWORD=$(pwgen 20 1)
-else
-export PGPASSWORD=$(dd if=/dev/urandom bs=1k count=1 2>/dev/null | md5sum - | awk '{ print $1 }')
-fi
-echo "$PGPASSWORD" > "$PWFILE"
-
 for v in $PG_VERSIONS; do
 # create temporary cluster
 # we chdir to / so programs don't throw "could not change directory to ..."
diff --git a/t/135_pg_virtualenv.t b/t/135_pg_virtualenv.t
new file mode 100644
index 000..1662e5b
--- /dev/null
+++ b/t/135_pg_virtualenv.t
@@ -0,0 +1,35 @@
+# check if pg_virtualenv runs ok, even under fakeroot
+
+use strict;
+use warnings;
+
+use lib 't';
+use TestLib;
+
+use Test::More tests => 12 * @MAJORS + 8;
+
+foreach my $v (@MAJORS) {
+my $args = 'sh -c \'echo "id|$(id -un)"; psql -AtXxc "SELECT current_user"\'';
+my $virtualenv = "pg_virtualenv -v $v $args";
+
+$ENV{USER} = 'root';
+like_program_out 'root', $virtualenv, 0, qr!id.root\ncurrent_user.postgres!, "running pg_virtualenv as root";
+$ENV{USER} = 'postgres';
+like_program_out 'postgres', $virtualenv, 0, qr!id.postgres\ncurrent_user.postgres!, "running pg_virtualenv as postgres";
+$ENV{USER} = 'nobody';
+like_program_out 'nobody',   $virtualenv, 0, qr!id.nobody\ncurrent_user.nobody!, "running pg_virtualenv as nobody";
+
+SKIP: {
+skip "/usr/bin/fakeroot not available", 6 unless (-x "/usr/bin/fakeroot"); # CentOS doesn't have fakeroot
+$ENV{USER} = 'root';
+like_program_out 'root', "fakeroot $virtualenv", 0, qr!id.root\ncurrent_user.postgres!, "running fakeroot pg_virtualenv as root";
+$ENV{USER} = 'postgres';
+like_program_out 'postgres', "fakeroot $virtualenv", 0, qr!id.root\ncurrent_user.postgres!, "running fakeroot pg_virtualenv as postgres";
+$ENV{USER} = 'nobody';
+like_program_out 'nobody',   "fakeroot $virtualenv", 0, qr!id.root\ncurrent_user.nobody!,   "running fakeroot pg_virtualenv as nobody";
+}
+}
+
+check_clean;
+
+# vim: filetype=perl

Bug#990866: unblock: postgresql-13/13.3-1

[Christoph Berg]

> 
> [ Checklist ]
>   [x] attach debian/ diff against the package in testing

Now for real.

Christoph
diff --git a/debian/changelog b/debian/changelog
index 2f18705..38aedbf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,47 @@
+postgresql-13 (13.3-1) unstable; urgency=medium
+
+  * New upstream version.
+
++ Prevent integer overflows in array subscripting calculations (Tom Lane)
+
+  The array code previously did not complain about cases where an array's
+  lower bound plus length overflows an integer.  This resulted in later
+  entries in the array becoming inaccessible (since their subscripts could
+  not be written as integers), but more importantly it confused subsequent
+  assignment operations.  This could lead to memory overwrites, with
+  ensuing crashes or unwanted data modifications. (CVE-2021-32027)
+
++ Fix mishandling of junk columns in INSERT ... ON CONFLICT ... UPDATE
+  target lists (Tom Lane)
+
+  If the UPDATE list contains any multi-column sub-selects (which give
+  rise to junk columns in addition to the results proper), the UPDATE path
+  would end up storing tuples that include the values of the extra junk
+  columns. That's fairly harmless in the short run, but if new columns are
+  added to the table then the values would become accessible, possibly
+  leading to malfunctions if they don't match the datatypes of the added
+  columns.
+
+  In addition, in versions supporting cross-partition updates, a
+  cross-partition update triggered by such a case had the reverse problem:
+  the junk columns were removed from the target list, typically causing an
+  immediate crash due to malfunction of the multi-column sub-select
+  mechanism. (CVE-2021-32028)
+
++ Fix possibly-incorrect computation of UPDATE ... RETURNING outputs for
+  joined cross-partition updates (Amit Langote, Etsuro Fujita)
+
+  If an UPDATE for a partitioned table caused a row to be moved to another
+  partition with a physically different row type (for example, one with a
+  different set of dropped columns), computation of RETURNING results for
+  that row could produce errors or wrong answers.  No error is observed
+  unless the UPDATE involves other tables being joined to the target
+  table. (CVE-2021-32029)
+
+  * Mark libio-pty-perl and libipc-run-perl as . (Closes: #988121)
+
+ -- Christoph Berg   Tue, 11 May 2021 22:10:35 +0200
+
 postgresql-13 (13.2-1) unstable; urgency=medium
 
   * New upstream version.
diff --git a/debian/control b/debian/control
index ee5acf8..8913183 100644
--- a/debian/control
+++ b/debian/control
@@ -20,8 +20,8 @@ Build-Depends:
  gdb ,
  gettext,
  libicu-dev,
- libio-pty-perl,
- libipc-run-perl,
+ libio-pty-perl ,
+ libipc-run-perl ,
  libkrb5-dev,
  libldap2-dev,
  libpam0g-dev | libpam-dev,
diff --git a/debian/rules b/debian/rules
index c115945..e70a10e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -76,6 +76,7 @@ COMMON_CONFIGURE_FLAGS= \
   $(SELINUX_FLAGS) \
   $(SPINLOCK_FLAGS) \
   MKDIR_P='/bin/mkdir -p' \
+  PROVE='/usr/bin/prove' \
   TAR='/bin/tar' \
   XSLTPROC='xsltproc --nonet' \
   CFLAGS='$(CFLAGS)' \

Bug#990866: unblock: postgresql-13/13.3-1

[Christoph Berg]

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

Please unblock package postgresql-13

[ Reason ]
The new version fixes CVE-2021-32027 CVE-2021-32028 CVE-2021-32029,
and other bugs.

[ Tests ]
PG itself has an extensive testsuite running at build and autopkgtest
time, and the postgresql-common testsuite is also running on the
package.

[ Risks ]
I had thought the package would migrate by itself and hence had not
followed up. There is one crashing bug in 13.2 exposed by the 13.3
testsuite that just made me aware the migration hasn't happened yet:

SELECT i, to_char(i * interval '1mon', 'rm'),
  to_char(i * interval '1mon', 'RM')
FROM generate_series(-13, 13) i;

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

[ Other info ]
New PostgreSQL upstream versions are waived by the security team, so
this new version would have been acceptable for bullseye-security
which should make it acceptable for bullseye as well.

unblock postgresql-13/13.3-1

Christoph


signature.asc
Description: PGP signature

Bug#990723: unblock: barman/2.12-2

[Christoph Berg]

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

Please unblock package barman

[ Reason ]
The existing package does not support PG13 and users will have a hard
time actually restoring backups from archive.

[ Tests ]
The upstream git repository does contain tests, but the shipped
tarball does not. I have no idea why they thought this is a good idea,
and I'm only fixing this since Marco seems unavailable.

The fix has been confirmed to work upstream and the diff looks sane.

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

unblock barman/2.12-2

Thanks,
Christoph

No differences were encountered between the control files

diff -Nru barman-2.12/debian/changelog barman-2.12/debian/changelog
--- barman-2.12/debian/changelog	2020-11-04 10:39:52.0 +0100
+++ barman-2.12/debian/changelog	2021-07-05 17:59:18.0 +0200
@@ -1,3 +1,10 @@
+barman (2.12-2) unstable; urgency=medium
+
+  * Team upload.
+  * PG 13 expects wal_keep_size, not wal_keep_segments. (Closes: #990304)
+
+ -- Christoph Berg   Mon, 05 Jul 2021 17:59:18 +0200
+
 barman (2.12-1) unstable; urgency=medium
 
   * New upstream version 2.12
diff -Nru barman-2.12/debian/patches/pg13 barman-2.12/debian/patches/pg13
--- barman-2.12/debian/patches/pg13	1970-01-01 01:00:00.0 +0100
+++ barman-2.12/debian/patches/pg13	2021-07-05 17:59:14.0 +0200
@@ -0,0 +1,125 @@
+commit 45ccd9d2f315ec208eee778eba1333c0aa4a4460
+Author: Abhijit Menon-Sen 
+Date:   Wed Jan 20 19:47:37 2021 +0530
+
+Fetch wal_keep_size, not wal_keep_segments, from Postgres 13
+
+The `wal_keep_segments` parameter introduced in v9.0 was replaced with
+`wal_keep_size` in v13. Running Barman against Postgres 13 resulted in
+errors like the following being logged:
+
+barman ERROR:  unrecognized configuration parameter "wal_keep_segments"
+barman STATEMENT:  SHOW "wal_keep_segments"
+
+Here we change fetch_remote_status() to ask for wal_keep_size if the
+server version is >= 13. We didn't use this value anywhere, so we don't
+need any further changes to adapt to the different return value.
+
+Signed-off-by: Abhijit Menon-Sen 
+
+diff --git a/barman/postgres.py b/barman/postgres.py
+index 2414f77..6664620 100644
+--- a/barman/postgres.py
 b/barman/postgres.py
+@@ -827,7 +827,12 @@ class PostgreSQLConnection(PostgreSQL):
+ pg_settings.append('wal_level')
+ pg_settings.append('hot_standby')
+ pg_settings.append('max_wal_senders')
+-pg_settings.append('wal_keep_segments')
++# Retrieve wal_keep_segments from version 9.0 onwards, until
++# version 13.0, where it was renamed to wal_keep_size
++if self.server_version < 13:
++pg_settings.append('wal_keep_segments')
++else:
++pg_settings.append('wal_keep_size')
+ 
+ if self.server_version >= 90300:
+ pg_settings.append('data_checksums')
+diff --git a/doc/manual/42-server-commands.en.md b/doc/manual/42-server-commands.en.md
+index 90caea7..20e91d9 100644
+--- a/doc/manual/42-server-commands.en.md
 b/doc/manual/42-server-commands.en.md
+@@ -198,7 +198,8 @@ record of the transaction log. When the status file needs to be
+ cleaned, the `--reset` option can be used.
+ 
+ > **IMPORTANT:** If you are not using replication slots, you rely
+-> on the value of `wal_keep_segments`. Be aware that under high peeks
++> on the value of `wal_keep_segments` (or `wal_keep_size` from
++> PostgreSQL version 13.0 onwards). Be aware that under high peaks
+ > of workload on the database, the `receive-wal` process
+ > might fall behind and go out of sync. As a precautionary measure,
+ > Barman currently requires that users manually execute the command with the
+#diff --git a/tests/test_postgres.py b/tests/test_postgres.py
+#index 83c9f14..67636bb 100644
+#--- a/tests/test_postgres.py
+#+++ b/tests/test_postgres.py
+#@@ -822,6 +822,8 @@ class TestPostgres(object):
+#new_callable=PropertyMock)
+# @patch('barman.postgres.PostgreSQLConnection.is_in_recovery',
+#new_callable=PropertyMock)
+#+@patch('barman.postgres.PostgreSQLConnection.has_backup_privileges',
+#+   new_callable=PropertyMock)
+# @patch('barman.postgres.PostgreSQLConnection.is_superuser',
+#new_callable=PropertyMock)
+# @patch('barman.postgres.PostgreSQLConnection.server_txt_version',
+#@@ -847,6 +849,7 @@ class TestPostgres(object):
+#has_pgespresso_mock,
+#server_txt_version_mock,
+#is_superuser_mock,
+#+   

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Christoph Berg]

Re: Sebastiaan Couwenberg
> Since the upgrade procedure documented in the release notes includes
> purging removed and obsolete packages, users are not expected to keep
> libgda20 around after the distribution upgrade.

To avoid exactly this problem, postgresql-common is maintaining a list
of PG versions that have clusters on the system:

/etc/apt/apt.conf.d/01autoremove-postgresql

APT
{
  NeverAutoRemove
  {
"^postgresql.*-11";
"^postgresql.*-13";
  };
};

... so libgdal20 will not be autoremoved because
postgresql-11-postgis-2.5 is not autoremoved. The list is updated once
you `pg_dropcluster 11 main`.

> There is much less need for gdal-data breaking libgdal20 for us than
> there is in the UbuntuGIS PPA use case. I'm not aware of any packages
> that use gdal in the maintainer scripts that would be using the old gdal
> on their removal. So there shouldn't be any actual expected breakage.

I don't know the GIS world enough to be able to say what the data
files in gdal-data are good for, but my guess would be that for the
"read geometry data from an old postgresql-11 cluster", which is what
we need for pg_upgradecluster, they aren't relevant, and just making
libgdal20 co-installable is enough.

People shouldn't be expecting to be able to use the old postgis to do
complex data type (gdal?) or coordinate system (proj?) transformations
on a system that has already been upgraded to the new library versions
anyway.

> This change is minimal, doesn't require NEW packages, nor introduces
> divergence from upstream (as when the files would be moved to
> u/s/gdal/ in libgdal28), hence it's my preferred solution.
> 
> If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the
> changes from the debdiff to unstable.

Sounds good to me, thanks!

Christoph

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Christoph Berg]

Re: Andreas Beckmann
> > modulo the problem I ran into. (I still have to retry it.)
> 
> Didn't see this on my side.
> Your --force-depends probably affected more than just libgdal20.

Found the problem, I had not restarted postgresql-11 after the
upgrade, so it was still linked against the old libc, but dlopening
the various postgis libs failed as these want the new libc. After
restarting, the geometry data is still there.

> So co-installable libgdal20/libgdal28 simplifies postgis data migration
> because postgresql-11+postgis from buster remains installed and accessible
> along postgresql-13+postgis.

Yes.

Christoph

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Christoph Berg]

Re: Andreas Beckmann
> So packaging wise this looks good. But I have no idea about the postgresql
> side:
> * how do I get some tables using the postgis extension into the database to
> start with? Is there a package in buster that "does that for me" by just
> installing it (postgis with --install-recommends pulls in
> postgresql-postgis, but does not populate a database)?

sudo -u postgres psql -vON_ERROR_STOP=1 < * how do I "verify" that? (SELECT foo FROM bar ...)

select * from test;

geom


 
01030001000500F03FF03FF03F0040004000400040F03FF03FF03F

> * how do I correctly migrate the database (with postgis stuff) from 11 to 13

As said in my mail: pg_dumpall, then dist-upgrade, and load the dump
again.

Once gdal is fixed, pg_upgradecluster should work, modulo the problem
I ran into. (I still have to retry it.)

> * how do I verify that it worked ?

Do that select again.

> There should be a real package postgresql-postgis, not a virtual one.

Yes, but in the general case of other PG extension packages which are
usually quite small, I'm reluctant to add yet another micro-package
just for the dependencies. Though maybe that's the way to go...

> PS: @Christoph: In piuparts I'm using this receipe to upgrade postgresql
> clusters after dist-upgrades - is this the correct approach?
> 
> echo "Upgrading PostgreSQL Cluster from ${from} to ${to}"
> pg_dropcluster ${to} main --stop
> pg_upgradecluster -v ${to} ${from} main
> echo "Dropping old PostgreSQL ${from} Cluster"
> pg_dropcluster ${from} main

Yes. (Though pg_upgradecluster is bad at reporting errors during the
upgrade, so you'd have to check if all tables/data arrived manually.)

Christoph

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Christoph Berg]

Re: Adrian Bunk
> > FEHLER:  XX000: konnte Bibliothek 
> > »/usr/lib/postgresql/11/lib/postgis-2.5.so« nicht laden: 
> > /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required 
> > by /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1)
> > 
> > So there seems to be some additional incompatibility in libsfcgal1 -> libc6.
> >...
> 
> It's already in the package dependencies:
> 
> Package: libsfcgal1
> Version: 1.3.9-2
> Depends: ..., libc6 (>= 2.29),...
> 
> This won't work unless you upgrade libc6 to the bullseye version.

I think had dist-upgraded to sid at that point. Though I can repeat
the test tomorrow to be sure.

Christoph

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Christoph Berg]

Re: Sebastiaan Couwenberg
> Options for a working postgis database after distribution upgrade
> include recreating the databases by running your ETL process on the new
> cluster after upgrade, or using symlink hacks to workaround the
> version-in-extension-filename issue:
> 
>  http://blog.cleverelephant.ca/2016/08/postgis-upgrade.html

This is the infamous "symlink" hack that was occasionally needed in
the past, but I don't think it is necessary for this issue sind we are
talking about proper "CREATE EXTENSION postgis" installed, not the old
wild-west style with 1000 free-floating functions create in the
database.

> The hard upgrade procedure from the upstream docs may be an option too:
> 
>  http://postgis.net/docs/manual-3.1/postgis_administration.html#upgrading
> 
> In my experience, recreating the database is the simplest solution.

Before I answer this, I gave upgrading buster with
postgresql-11-postgis-2.5{,-scripts} to sid with postgresql-13-postgis-3
a try. As expected, libgdal20 and postgresql-11-postgis-2.5 were
removed during the process, and trying to access geometry data in the
old postgresql-11 database fails:

# select geom from country where geom is not null limit 1;
FEHLER:  58P01: konnte nicht auf Datei »$libdir/postgis-2.5« zugreifen: Datei 
oder Verzeichnis nicht gefunden


To see what would happen if we made libgdal20 and libgdal28
co-installable, I force-installed the old packages:

$ sudo dpkg -i --force-depends 
/var/cache/apt/archives/libgdal20_2.4.0+dfsg-1+b1_amd64.deb  
/var/cache/apt/archives/postgresql-11-postgis-2.5_2.5.1+dfsg-1_amd64.deb
[...]
Entpacken von postgresql-11-postgis-2.5 (2.5.1+dfsg-1) ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von libgdal20:
 gdal-data (3.2.2+dfsg-1) beschädigt libgdal20 (<< 2.5.0~) und ist installiert.
  Zu konfigurierende Version von libgdal20 auf dem System ist 2.4.0+dfsg-1+b1.

dpkg: Fehler beim Bearbeiten des Paketes libgdal20 (--install):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: postgresql-11-postgis-2.5: Abhängigkeitsprobleme, wird aber trotzdem wie 
gefordert konfiguriert:
 postgresql-11-postgis-2.5 hängt ab von libgdal20 (>= 2.0.1); aber:
  Paket libgdal20 ist noch nicht konfiguriert.

postgresql-11-postgis-2.5 (2.5.1+dfsg-1) wird eingerichtet ...
Trigger für libc-bin (2.31-12) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
 libgdal20

Ignoring these errors I proceeded to try reading the old geometry data:

$ psql cb
psql (13.3 (Debian 13.3-1), Server 11.12 (Debian 11.12-0+deb10u1))

17:38 cbe@cb =# select geom from country where geom is not null limit 1;
FEHLER:  XX000: konnte Bibliothek »/usr/lib/postgresql/11/lib/postgis-2.5.so« 
nicht laden: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found 
(required by /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1)

So there seems to be some additional incompatibility in libsfcgal1 -> libc6.


At that point, I think fixing that isn't feasible, and we should
instead put proper upgrade instructions into the release notes. My
plan would be the following:

sudo -u postgres pg_dumpall -f postgres11.dump
... do the upgrade
sudo apt install postgresql-13-postgis-3
#sudo pg_createcluster 13 main --start  # automatically created by postgresql-13
sudo -u postgres psql -p 5433 -Xf postgres11.dump

# select geom from country where geom is not null limit 1;
geom
──
 010620E6100100010

Would such instructions in the release notes be an acceptable
resolution for this bug? We can additionally point to the "hard"
upgrade instruction mentioned above for people still using the
non-extension installation methode.


> > If I am not mistaken, Andreas proposed in another thread to introduce a
> > postgis-2.5-built-against-postgresql-13 package to help with the
> > upgrades. Would this be a viable option?
> 
> No. I'm not going to maintain multiple versions of postgis.

postgis-2.5-built-against-postgresql-13 wouldn't help since we need to
get the data out of the old postgresql-11 first.

> It will be one less package I have to maintain in Debian, I can just
> chuck in my personal repo and not bother any further.

Please don't, you are doing useful work here. I appreciate your
efforts.

Christoph

Bug#988293: unblock: hamlib/4.0-5

[Christoph Berg]

Re: Sebastian Ramacher
> On 2021-05-09 22:35:48, Christoph Berg wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > 
> > Please unblock package hamlib.
> 
> If the autopkgtest on i386 wouldn't fail, hamlib would be able to
> migrate without an unblock. Could you please fix the autopkgtest? Thanks

Fixed (well, worked around, the issue is minor) in 4.0-6.

(DDPO still shows amd64 autopkgtest problems only, so I had not seen
the i386 problem before, I need to update it to take the others into
account.)

Thanks,
Christoph

Control files: lines which differ (wdiff format)

{+Breaks:+}
{+ libhamlib2-perl (<< 4.0),+}
{+Breaks:+}
{+ libhamlib2-tcl (<< 4.0),+}
{+Breaks:+}
{+ lua-hamlib2 (<< 4.0),+}
{+Breaks:+}
{+ python3-libhamlib2 (<< 4.0),+}

diff -Nru hamlib-4.0/debian/changelog hamlib-4.0/debian/changelog
--- hamlib-4.0/debian/changelog	2021-01-12 10:52:31.0 +0100
+++ hamlib-4.0/debian/changelog	2021-05-11 19:03:12.0 +0200
@@ -1,3 +1,15 @@
+hamlib (4.0-6) unstable; urgency=medium
+
+  * Paper over a minor precision difference in dec2dms on i386.
+
+ -- Christoph Berg   Tue, 11 May 2021 19:03:12 +0200
+
+hamlib (4.0-5) unstable; urgency=medium
+
+  * Add Breaks to module packages renamed in 4.0-1. (Closes: #988290)
+
+ -- Christoph Berg   Sun, 09 May 2021 22:00:33 +0200
+
 hamlib (4.0-4) unstable; urgency=medium
 
   * Pull patches from upstream to fix issues with Icom (IC706 in particular)
diff -Nru hamlib-4.0/debian/control hamlib-4.0/debian/control
--- hamlib-4.0/debian/control	2021-01-12 09:48:48.0 +0100
+++ hamlib-4.0/debian/control	2021-05-11 19:00:25.0 +0200
@@ -132,6 +132,8 @@
  libhamlib2-perl,
 Replaces:
  libhamlib2-perl (<< 4.0),
+Breaks:
+ libhamlib2-perl (<< 4.0),
 Description: Run-time perl library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their
  functions through a computer interface. Unfortunately, control commands are
@@ -165,6 +167,8 @@
  libhamlib2-tcl,
 Replaces:
  libhamlib2-tcl (<< 4.0),
+Breaks:
+ libhamlib2-tcl (<< 4.0),
 Description: Run-time Tcl library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their
  functions through a computer interface. Unfortunately, control commands are
@@ -200,6 +204,8 @@
  ${python3:Provides},
 Replaces:
  python3-libhamlib2 (<< 4.0),
+Breaks:
+ python3-libhamlib2 (<< 4.0),
 Description: Run-time Python3 library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their
  functions through a computer interface. Unfortunately, control commands are
@@ -275,6 +281,8 @@
  ${lua:Provides},
 Replaces:
  lua-hamlib2 (<< 4.0),
+Breaks:
+ lua-hamlib2 (<< 4.0),
 XB-Lua-Version: ${lua:Versions}
 Description: Run-time Lua library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their
diff -Nru hamlib-4.0/debian/tests/perltest hamlib-4.0/debian/tests/perltest
--- hamlib-4.0/debian/tests/perltest	2021-01-12 09:48:48.0 +0100
+++ hamlib-4.0/debian/tests/perltest	2021-05-11 19:03:12.0 +0200
@@ -5,4 +5,6 @@
 trap "rm -f perltest.out" EXIT
 
 perl /usr/share/doc/libhamlib-perl/examples/perltest.pl > perltest.out
-diff -u debian/tests/perltest.out perltest.out
+diff -u debian/tests/perltest.out perltest.out || diff -u debian/tests/perltest.out32 perltest.out
+
+# perltest.out32: Paper over a minor precision difference in dec2dms on i386.
diff -Nru hamlib-4.0/debian/tests/perltest.out32 hamlib-4.0/debian/tests/perltest.out32
--- hamlib-4.0/debian/tests/perltest.out32	1970-01-01 01:00:00.0 +0100
+++ hamlib-4.0/debian/tests/perltest.out32	2021-05-11 19:00:51.0 +0200
@@ -0,0 +1,24 @@
+get_conf:		path = "/dev/Rig", retry = 50
+freq:			14266000
+get_mode:		FM
+width:			15000
+get_vfo:		VFOA
+Backend copyright:	LGPL
+Model:			Dummy
+Manufacturer:		Hamlib
+Backend version:	20200606.0
+get_info:		Nothing much (dummy)
+VOX delay:		0
+VOX delay:		5
+get_channel status:	0 = Command completed successfully
+VFO:			VFOA, 14266000
+Attenuators:		10 20 30 0 0 0 0 0
+
+Sending Morse, '73'
+
+Some static functions:
+Loc1:		IN98XC ->   -0.0417,   48.1042-> IN98XC
+Loc1:		DM33DX -> -113.7083,   33.9792-> DM33DX
+Distance:	8765.814 km, azimuth 309.00, long path: 31266.186 km
+Longitude:	  -0.0417,0°  2' 29" W	recoded:   -0.0414
+Latitude:	  48.1042,   48°  6' 14" N	recoded:   48.1039

Bug#988293: unblock: hamlib/4.0-5

[Christoph Berg]

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

Please unblock package hamlib.

[ Reason ]
The update fixes #988290.

[ Risks ]
debian/control-only change.

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

unblock hamlib/4.0-5

Thanks,
Christoph

Control files: lines which differ (wdiff format)

{+Breaks:+}
{+ libhamlib2-perl (<< 4.0),+}
{+Breaks:+}
{+ libhamlib2-tcl (<< 4.0),+}
{+Breaks:+}
{+ lua-hamlib2 (<< 4.0),+}
{+Breaks:+}
{+ python3-libhamlib2 (<< 4.0),+}

diff -Nru hamlib-4.0/debian/changelog hamlib-4.0/debian/changelog
--- hamlib-4.0/debian/changelog	2021-01-12 10:52:31.0 +0100
+++ hamlib-4.0/debian/changelog	2021-05-09 22:00:33.0 +0200
@@ -1,3 +1,9 @@
+hamlib (4.0-5) unstable; urgency=medium
+
+  * Add Breaks to module packages renamed in 4.0-1. (Closes: #988290)
+
+ -- Christoph Berg   Sun, 09 May 2021 22:00:33 +0200
+
 hamlib (4.0-4) unstable; urgency=medium
 
   * Pull patches from upstream to fix issues with Icom (IC706 in particular)
diff -Nru hamlib-4.0/debian/control hamlib-4.0/debian/control
--- hamlib-4.0/debian/control	2021-01-12 09:48:48.0 +0100
+++ hamlib-4.0/debian/control	2021-05-09 22:00:33.0 +0200
@@ -132,6 +132,8 @@
  libhamlib2-perl,
 Replaces:
  libhamlib2-perl (<< 4.0),
+Breaks:
+ libhamlib2-perl (<< 4.0),
 Description: Run-time perl library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their
  functions through a computer interface. Unfortunately, control commands are
@@ -165,6 +167,8 @@
  libhamlib2-tcl,
 Replaces:
  libhamlib2-tcl (<< 4.0),
+Breaks:
+ libhamlib2-tcl (<< 4.0),
 Description: Run-time Tcl library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their
  functions through a computer interface. Unfortunately, control commands are
@@ -200,6 +204,8 @@
  ${python3:Provides},
 Replaces:
  python3-libhamlib2 (<< 4.0),
+Breaks:
+ python3-libhamlib2 (<< 4.0),
 Description: Run-time Python3 library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their
  functions through a computer interface. Unfortunately, control commands are
@@ -275,6 +281,8 @@
  ${lua:Provides},
 Replaces:
  lua-hamlib2 (<< 4.0),
+Breaks:
+ lua-hamlib2 (<< 4.0),
 XB-Lua-Version: ${lua:Versions}
 Description: Run-time Lua library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their

Bug#987510: unblock: cqrlog/2.5.1-2

[Christoph Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Debian Hamradio Maintainers 

Please unblock package cqrlog.

[ Reason ]
The new version fixes import of .adif files which is the standard
hamradio logbook interchange format. (#987032)

[ Impact ]
This logbook program wouldn't be able to read logbooks.

[ Tests ]
Manual testing by Federico Grau.

[ Risks ]
The change was tested and the patch is small.

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

unblock cqrlog/2.5.1-2

Thanks,
Christoph

No differences were encountered between the control files

diff -Nru cqrlog-2.5.1/debian/changelog cqrlog-2.5.1/debian/changelog
--- cqrlog-2.5.1/debian/changelog	2021-02-02 12:46:56.0 +0100
+++ cqrlog-2.5.1/debian/changelog	2021-04-17 20:23:46.0 +0200
@@ -1,3 +1,10 @@
+cqrlog (2.5.1-2) unstable; urgency=medium
+
+  * Team upload.
+  * Patch from upstream commits to fix ADIF import (Closes: #987032)
+
+ -- Federico Grau   Sat, 17 Apr 2021 14:23:46 -0400
+
 cqrlog (2.5.1-1) unstable; urgency=medium
 
   * New upstream version 2.5.1.
diff -Nru cqrlog-2.5.1/debian/patches/adif_import_regex_fix_2021-04-17.patch cqrlog-2.5.1/debian/patches/adif_import_regex_fix_2021-04-17.patch
--- cqrlog-2.5.1/debian/patches/adif_import_regex_fix_2021-04-17.patch	1970-01-01 01:00:00.0 +0100
+++ cqrlog-2.5.1/debian/patches/adif_import_regex_fix_2021-04-17.patch	2021-04-17 20:23:46.0 +0200
@@ -0,0 +1,27 @@
+Patch to fix Debian#987032: cqrlog: Importing ADIF-logs results in 0 byte logs - https://bugs.debian.org/987032
+Applies upstream commits:
+42d1ad402affd0af0f3087562c101fc34940ffc5
+Original_Author: Petr Hlozek 
+Date:   Sun Feb 7 07:19:57 2021 +0100
+
+fix: workaround for 'TRegExpr exec: empty input string' error in fpc compiler
+Author: donf...@casagrau.org
+diff --git a/src/fAdifImport.pas b/src/fAdifImport.pas
+index 2481086..934b158 100644
+--- a/src/fAdifImport.pas
 b/src/fAdifImport.pas
+@@ -420,8 +420,12 @@ begin
+ d.IOTA  := UpperCase(d.IOTA);
+ d.NAME  := Copy(d.NAME, 1 ,40);
+ d.QTH   := Copy(d.QTH, 1, 60);
+-d.DARC_DOK := ReplaceRegExpr('Ø', d.DARC_DOK, '0', True);
+-d.DARC_DOK := LeftStr(Uppercase(ReplaceRegExpr('[^a-zA-Z0-9]',d.DARC_DOK, '', True)), 12);
++//workaround for 'TRegExpr exec: empty input string' error in fpc compiler
++if (trim(d.DARC_DOK) <> '') then
++begin
++  d.DARC_DOK := ReplaceRegExpr('Ø', d.DARC_DOK, '0', True);
++  d.DARC_DOK := LeftStr(Uppercase(ReplaceRegExpr('[^a-zA-Z0-9]',d.DARC_DOK, '', True)), 12);
++end;
+ 
+ d.QSL_VIA := UpperCase(d.QSL_VIA);
+ if Pos('QSL VIA',d.QSL_VIA) > 0 then
diff -Nru cqrlog-2.5.1/debian/patches/series cqrlog-2.5.1/debian/patches/series
--- cqrlog-2.5.1/debian/patches/series	2021-02-02 12:46:56.0 +0100
+++ cqrlog-2.5.1/debian/patches/series	2021-04-17 20:23:46.0 +0200
@@ -1,2 +1,3 @@
 apparmor-fix.patch
 icon-patch
+adif_import_regex_fix_2021-04-17.patch

Bug#987311: unblock: pgpool2/4.1.4-3

[Christoph Berg]

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

Please unblock package pgpool2.

[ Reason ]
The new version fixes a bug which prevents the counter of open
connection from being reduced when a query is canceled.

[ Impact ]
If the bug is not fixed, connection pools will become unavailable.

[ Tests ]
The package passes the "jdbc" smoke tests exercising a connection
through the pool. (The upstream test system is unfortunately quite
involved and doesn't easily run at build time.)

[ Risks ]
The fix is a trivial one-liner.

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

unblock pgpool2/4.1.4-3

Christoph

No differences were encountered between the control files

diff -Nru pgpool2-4.1.4/debian/changelog pgpool2-4.1.4/debian/changelog
--- pgpool2-4.1.4/debian/changelog	2020-10-09 16:48:13.0 +0200
+++ pgpool2-4.1.4/debian/changelog	2021-04-19 17:43:35.0 +0200
@@ -1,3 +1,10 @@
+pgpool2 (4.1.4-3) unstable; urgency=medium
+
+  * Fix connection count when query is canceled. (Closes: #987183,
+upstream #656, git 6d6e4cc3).
+
+ -- Christoph Berg   Mon, 19 Apr 2021 17:43:35 +0200
+
 pgpool2 (4.1.4-2) unstable; urgency=medium
 
   * Bump test-dependency on pg-common for `pg_buildext psql`.
diff -Nru pgpool2-4.1.4/debian/patches/987183 pgpool2-4.1.4/debian/patches/987183
--- pgpool2-4.1.4/debian/patches/987183	1970-01-01 01:00:00.0 +0100
+++ pgpool2-4.1.4/debian/patches/987183	2021-04-19 17:42:41.0 +0200
@@ -0,0 +1,25 @@
+From: Tatsuo Ishii 
+Date: Thu, 29 Oct 2020 20:59:23 + (+0900)
+Subject: Fix connection count when query is canceled.
+X-Git-Tag: V4_1_5~5
+X-Git-Url: http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff_plain;h=6d6e4cc3d7ce0cdfcf9b2b6ea3ac5dc04b366aec
+
+Fix connection count when query is canceled.
+
+Connection counter was not counted down when a query is canceled.
+
+Per bug 656.
+---
+
+diff --git a/src/protocol/child.c b/src/protocol/child.c
+index af1dd50b..47482f61 100644
+--- a/src/protocol/child.c
 b/src/protocol/child.c
+@@ -2302,6 +2302,7 @@ retry_startup:
+ 	{
+ 		cancel_request((CancelPacket *) sp->startup_packet);
+ 		pool_free_startup_packet(sp);
++		connection_count_down();
+ 		return NULL;
+ 	}
+ 
diff -Nru pgpool2-4.1.4/debian/patches/series pgpool2-4.1.4/debian/patches/series
--- pgpool2-4.1.4/debian/patches/series	2020-10-06 15:42:58.0 +0200
+++ pgpool2-4.1.4/debian/patches/series	2021-04-19 17:42:41.0 +0200
@@ -1,2 +1,3 @@
 pgpool2-debian-config.patch
 sbin-paths
+987183

Re: Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

[Christoph Berg]

Re: Julian Andres Klode
> > We're getting close to the release of bullseye and it has been brought
> > to my attention that this bug is still unfixed in buster. Once we
> > release bullseye, this bug is going to run havoc for our buster users.
> 
> That's not accurate. This is _only_ a problem for users of testing,
> where the codename changes from time to time.

This *is* a problem for users of "buster" where the suite will be
changing from "stable" to "oldstable". (Yes, we do release buster
twice, once as stable and then as oldstable.)

Unless the fix that has closed #931566 is also applied to the apt
version in buster, things will explode horribly.

Changed-By: Julian Andres Klode 
Changes:
 apt (2.1.10) unstable; urgency=medium
 .
   * Default Acquire::AllowReleaseInfoChange::Suite to "true" (Closes: #931566)

Notably, that needs to happen well before the bullseye release or else
systems will not be able to "apt-get update" non-interactively to
actually see the updated package.

> For stable users, this is not a problem at all, more the opposite. Those
> poor souls who have stable in their sources.list won't suddenly get
> upgraded to bullseye.

Yes, this part of the change is the good one. Pinning suite for
"buster" users is not.

> > Can we somehow come up with a plan on how to handle this? Can we have a
> > fix in the next point release? Are there faster options than just
> > waiting some time after the next point release before we can release
> > bullseye, e.g. could the SRM allow an update to stable for the change of
> > an apt default to have the change earlier than the next point release?
> 
> I have no intention of issuing a stable update.

On 2020-08-10 you said:

17:04  juliank: is #931566 going to be fixed in buster as well?
17:04 -zwiebelbot- Debian#931566: Don't complain about suite changes 
(Acquire::AllowReleaseInfoChange::Suite should be "true") - 
https://bugs.debian.org/931566
17:04  Myon: yes
17:04  cool
17:04  thanks

Christoph

Bug#979106: transition: limesuite

[Christoph Berg]

Re: Sebastian Ramacher
> > There is a new version of limesuite in experimental, the driver for
> > the Limesdr software defined radios.
> 
> The old packages got removed from testing. Closing

Thanks!

Christoph

Bug#979084: transition: hamlib

[Christoph Berg]

Re: To 979...@bugs.debian.org
> I'll upload the two rdeps needing source changes and then provide a
> list for binnmus for the rest.

Here we go:

cubicsdr
direwolf
fldigi
freedv
klog
qsstv
soapyaudio
soundmodem
tucnak
xlog

Plus for the limesuite transition:

gr-limesdr
osmo-trx

Thanks,
Christoph

Bug#979084: transition: hamlib

[Christoph Berg]

Re: To Debian Bug Tracking System
> Are we ok to go ahead?

Not hearing any objections I went ahead. I'll upload the two rdeps
needing source changes and then provide a list for binnmus for the
rest.

Christoph

Bug#979106: transition: limesuite

[Christoph Berg]

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

There is a new version of limesuite in experimental, the driver for
the Limesdr software defined radios.

There are only 2 rdepends external to the source package, gr-limesdr
and osmo-trx. Both build fine with the new version, and I also tested
with sdrangel (an ITP which should finally upload).

Ben file:

title = "limesuite";
is_affected = .depends ~ "liblimesuite20.01-1" | .depends ~ 
"liblimesuite20.10-1";
is_good = .depends ~ "liblimesuite20.10-1";
is_bad = .depends ~ "liblimesuite20.01-1";

Are we ok to upload to unstable?

Thanks,
Christoph

Bug#979084: transition: hamlib

[Christoph Berg]

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

Hi,

hamlib has finally released a new version which would be very valuable
to have in Debian/bullseye since the old version is missing support
for any hamradio transceivers sold in the last two years.

The new version has been uploaded to experimental. There are 15
reverse dependencies, all within the Debian Hamradio Team. I
recompiled these, and the only one failing is "grig" which is dead
upstream and should likely be removed anyway. Manual tests have
revealed no problems either. (There is one minor glitch in wsjtx but I
hope to address that.)

I'm sorry for this very late change but upstream has released this
only two days ago...

Ben file:

title = "hamlib";
is_affected = .depends ~ "libhamlib2" | .depends ~ "libhamlib2++c2" | .depends 
~ "libhamlib4" | .depends ~ "libhamlib++4";
is_good = .depends ~ "libhamlib4" | .depends ~ "libhamlib++4";
is_bad = .depends ~ "libhamlib2" | .depends ~ "libhamlib2++c2";

(Unsure if the ++ signs need quoting.)

Are we ok to go ahead?

Thanks,
Christoph

Re: [SUA 189-1] Upcoming Debian 10 Update (10.7)

[Christoph Berg]

Re: Adam D. Barratt
> Upcoming Debian 10 Update (10.7)

I delayed that for too long, but now I uploaded postgresql-11 which is
fixing some minor CVEs:

postgresql-11 (11.10-0+deb10u1) buster; urgency=medium

  * New upstream version.
+ Fixes timetz regression test failures. (Closes: #974063)

+ Block DECLARE CURSOR ... WITH HOLD and firing of deferred triggers
  within index expressions and materialized view queries (Noah Misch)

  This is essentially a leak in the security restricted operation sandbox
  mechanism.  An attacker having permission to create non-temporary SQL
  objects could parlay this leak to execute arbitrary SQL code as a
  superuser.

  The PostgreSQL Project thanks Etienne Stalmans for reporting this
  problem. (CVE-2020-25695)

+ Fix usage of complex connection-string parameters in pg_dump,
  pg_restore, clusterdb, reindexdb, and vacuumdb (Tom Lane)

  The -d parameter of pg_dump and pg_restore, or the --maintenance-db
  parameter of the other programs mentioned, can be a connection string
  containing multiple connection parameters rather than just a database
  name.  In cases where these programs need to initiate additional
  connections, such as parallel processing or processing of multiple
  databases, the connection string was forgotten and just the basic
  connection parameters (database name, host, port, and username) were
  used for the additional connections.  This could lead to connection
  failures if the connection string included any other essential
  information, such as non-default SSL or GSS parameters. Worse, the
  connection might succeed but not be encrypted as intended, or be
  vulnerable to man-in-the-middle attacks that the intended connection
  parameters would have prevented. (CVE-2020-25694)

+ When psql's \connect command re-uses connection parameters, ensure that
  all non-overridden parameters from a previous connection string are
  re-used (Tom Lane)

  This avoids cases where reconnection might fail due to omission of
  relevant parameters, such as non-default SSL or GSS options. Worse, the
  reconnection might succeed but not be encrypted as intended, or be
  vulnerable to man-in-the-middle attacks that the intended connection
  parameters would have prevented. This is largely the same problem as
  just cited for pg_dump et al, although psql's behavior is more complex
  since the user may intentionally override some connection parameters.
  (CVE-2020-25694)

+ Prevent psql's \gset command from modifying specially-treated variables
  (Noah Misch)

  \gset without a prefix would overwrite whatever variables the server
  told it to.  Thus, a compromised server could set specially-treated
  variables such as PROMPT1, giving the ability to execute arbitrary shell
  code in the user's session.

  The PostgreSQL Project thanks Nick Cleaton for reporting this problem.
  (CVE-2020-25696)

 -- Christoph Berg   Tue, 01 Dec 2020 10:04:12 +0100

Christoph

PostgreSQL 13 binnmu wishlist

[Christoph Berg]

Hi,

it would be nice if "rebuild on buildd" binnmus could be scheduled
for:

extra-window-functions
icu-ext
pgpointcloud
pg-rational
pg-similarity
plpgsql-check
postgresql-debversion
postgresql-plsh
postgresql-rum
prefix
tds-fdw
toastinfo
wal2json

Thanks,
Christoph

Bug#972255: transition: postgresql-common/221

[Christoph Berg]

Re: Sebastian Ramacher
> > autopkgtest for omnidb/2.17.0+ds-2: amd64: Regression ♻ (reference ♻), 
> > arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> > Regression ♻ (reference ♻)
> 
> The autopkgtests for omnidb 2.17.0+ds-4 also fails:
> https://ci.debian.net/data/autopkgtest/testing/amd64/o/omnidb/7482609/log.gz
> The tests is using postgresql-common from testing. Is that missing a
> tighter dependency somewhere?

Right, sorry for missing that. Fix uploaded as 2.17.0+ds-5.

Christoph

Bug#972255: transition: postgresql-common/221

[Christoph Berg]

Re: Sebastian Ramacher
> Removal hint added. Could you please file an RC bug against
> postgresql-multicorn so that once removed from testing britney doesn't
> try to migrate?

Thanks.

Bug: #972285

Christoph

Bug#972255: transition: postgresql-common/221

[Christoph Berg]

Re: Christian Marillat
> Bug #971586 against postgresql-debversion is not fixed (missing a
> package for postgresql 13). 

That is not related to the first step of the transition. The remaining
modules will follow once the first step is through.

Christoph

Bug#972255: transition: postgresql-common/221

[Christoph Berg]

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

Hi,

I think I have put everything in place that needs to be done to have
postgresql-common/221 migrate to testing, which makes the switch from
PostgreSQL 12 to 13 as the "supported" version concerning extension
module packages.

In the first round of extension I uploaded everything that was listed
as regression on the postgresql-common excuses page.

https://qa.debian.org/excuses.php?package=postgresql-common

Remaining issues listed there are:

autopkgtest for check-postgres/2.25.0-1: amd64: Pass, arm64: Pass, armhf: 
Regression ♻ (reference ♻), i386: Pass

-> The testsuite is flaky and the armhf problem hopefully goes away by
retrying (I already clicked the button). In any case, the regression
is test-only.

autopkgtest for gvmd/9.0.1-4: amd64: Regression ♻ (reference ♻), arm64: 
Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression 
♻ (reference ♻)

-> Fixed in -4.1 in unstable

autopkgtest for osm2pgrouting/2.3.6-1: amd64: Regression ♻ (reference ♻), 
arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
Regression ♻ (reference ♻)

-> I believe I fixed that in -2 in unstable, but debci is currently
still picking up the old postgis packages from unstable for the test.
In any case, the regression is test-only.

autopkgtest for omnidb/2.17.0+ds-2: amd64: Regression ♻ (reference ♻), arm64: 
Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression 
♻ (reference ♻)
autopkgtest for pg-checksums/1.0-3: amd64: Regression ♻ (reference ♻), arm64: 
Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression 
♻ (reference ♻)
autopkgtest for pgtap/1.1.0-2: amd64: Regression ♻ (reference ♻), arm64: 
Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression 
♻ (reference ♻)

-> I added Breaks: for these in the last postgresql-common upload, the
issues are all fixed in unstable. (But the packages can only
transition along with postgresql-common.)

autopkgtest for postgresql-multicorn/1.4.0-2: amd64: Regression ♻ (reference 
♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
Regression ♻ (reference ♻)

-> The only real problem, upstream has not yet released a fix for PG13
yet. Please remove postgresql-multicorn/1.4.0-2 from testing so we can
proceed.

(I have probably missed a few "not built on buildd" blockers on some of
the extension packages. Please schedule binnmus there, thanks.)

So, in summary: please
* remove postgresql-multicorn/1.4.0-2 from testing
* unblock postgresql-common/221

Thanks,
Christoph

Bug#950734: Remove postgresql-11 from testing

[Christoph Berg]

Package: postgresql-11
Version: 11.6-2~sid1
Severity: serious

postgresql-11 should not be part of testing, please remove it, and all
reverse-dependencies. The upstreams of the reverse-dependencies have
all been pinged plenty of times, and have had enough time to fix their
stuff.

Thanks,
Christoph

Bug#946557: buster-pu: package clamav/0.102.1+dfsg-0+deb10u1

[Christoph Berg]

Re: Sebastian Andrzej Siewior 2019-12-10 <20191210224647.dk4svg65hleftr7r@flow>
> +clamav (0.101.4+dfsg-0+deb10u1) buster; urgency=medium
> +
> +   - update symbols file (bump to 101.4 and drop unused cli_strnstr).

Did all these symbols change semantics? I'm surprised to see so many
symbols bumped.

> diff -Nru clamav-0.101.2+dfsg/debian/libclamav9.symbols 
> clamav-0.101.4+dfsg/debian/libclamav9.symbols
> --- clamav-0.101.2+dfsg/debian/libclamav9.symbols 2019-08-06 
> 22:02:44.0 +0200
> +++ clamav-0.101.4+dfsg/debian/libclamav9.symbols 2019-08-25 
> 12:53:19.0 +0200
> @@ -1,16 +1,16 @@
>  libclamav.so.9 libclamav9 #MINVER#
>  * Build-Depends-Package: libclamav-dev
> - CLAMAV_PRIVATE@CLAMAV_PRIVATE 0.101.2
> + CLAMAV_PRIVATE@CLAMAV_PRIVATE 0.101.4
>   CLAMAV_PUBLIC@CLAMAV_PUBLIC 0.101.0
> - base64Flush@CLAMAV_PRIVATE 0.101.2
> - blobAddData@CLAMAV_PRIVATE 0.101.2
> - blobCreate@CLAMAV_PRIVATE 0.101.2
> - blobDestroy@CLAMAV_PRIVATE 0.101.2
> - cl_ASN1_GetTimeT@CLAMAV_PRIVATE 0.101.2
> + base64Flush@CLAMAV_PRIVATE 0.101.4
> + blobAddData@CLAMAV_PRIVATE 0.101.4
> + blobCreate@CLAMAV_PRIVATE 0.101.4
> + blobDestroy@CLAMAV_PRIVATE 0.101.4
> + cl_ASN1_GetTimeT@CLAMAV_PRIVATE 0.101.4
>   cl_always_gen_section_hash@CLAMAV_PUBLIC 0.101.0
> - cl_base64_decode@CLAMAV_PRIVATE 0.101.2
> - cl_base64_encode@CLAMAV_PRIVATE 0.101.2
> - cl_cleanup_crypto@CLAMAV_PRIVATE 0.101.2
> + cl_base64_decode@CLAMAV_PRIVATE 0.101.4
> + cl_base64_encode@CLAMAV_PRIVATE 0.101.4
> + cl_cleanup_crypto@CLAMAV_PRIVATE 0.101.4
>   cl_countsigs@CLAMAV_PUBLIC 0.101.0
>   cl_cvdfree@CLAMAV_PUBLIC 0.101.0
>   cl_cvdhead@CLAMAV_PUBLIC 0.101.0
> @@ -39,7 +39,7 @@
>   cl_engine_set_clcb_stats_remove_sample@CLAMAV_PUBLIC 0.101.0
>   cl_engine_set_clcb_stats_submit@CLAMAV_PUBLIC 0.101.0
>   cl_engine_set_clcb_virus_found@CLAMAV_PUBLIC 0.101.0
> - cl_engine_set_num@CLAMAV_PUBLIC 0.101.0
> + cl_engine_set_num@CLAMAV_PUBLIC 0.101.4
>   cl_engine_set_stats_set_cbdata@CLAMAV_PUBLIC 0.101.0
>   cl_engine_set_str@CLAMAV_PUBLIC 0.101.0
>   cl_engine_settings_apply@CLAMAV_PUBLIC 0.101.0
> @@ -50,21 +50,21 @@
>   cl_fmap_close@CLAMAV_PUBLIC 0.101.0
>   cl_fmap_open_handle@CLAMAV_PUBLIC 0.101.0
>   cl_fmap_open_memory@CLAMAV_PUBLIC 0.101.0
> - cl_get_pkey_file@CLAMAV_PRIVATE 0.101.2
> - cl_get_x509_from_mem@CLAMAV_PRIVATE 0.101.2
> - cl_hash_data@CLAMAV_PRIVATE 0.101.2
> + cl_get_pkey_file@CLAMAV_PRIVATE 0.101.4
> + cl_get_x509_from_mem@CLAMAV_PRIVATE 0.101.4
> + cl_hash_data@CLAMAV_PRIVATE 0.101.4
>   cl_hash_destroy@CLAMAV_PUBLIC 0.101.0
> - cl_hash_file_fd@CLAMAV_PRIVATE 0.101.2
> - cl_hash_file_fd_ctx@CLAMAV_PRIVATE 0.101.2
> - cl_hash_file_fp@CLAMAV_PRIVATE 0.101.2
> + cl_hash_file_fd@CLAMAV_PRIVATE 0.101.4
> + cl_hash_file_fd_ctx@CLAMAV_PRIVATE 0.101.4
> + cl_hash_file_fp@CLAMAV_PRIVATE 0.101.4
>   cl_hash_init@CLAMAV_PUBLIC 0.101.0
>   cl_init@CLAMAV_PUBLIC 0.101.0
> - cl_initialize_crypto@CLAMAV_PRIVATE 0.101.2
> + cl_initialize_crypto@CLAMAV_PRIVATE 0.101.4
>   cl_load@CLAMAV_PUBLIC 0.101.0
> - cl_load_cert@CLAMAV_PRIVATE 0.101.2
> - cl_load_crl@CLAMAV_PRIVATE 0.101.2
> + cl_load_cert@CLAMAV_PRIVATE 0.101.4
> + cl_load_crl@CLAMAV_PRIVATE 0.101.4
>   cl_retdbdir@CLAMAV_PUBLIC 0.101.0
> - cl_retflevel@CLAMAV_PUBLIC 0.101.1
> + cl_retflevel@CLAMAV_PUBLIC 0.101.4
>   cl_retver@CLAMAV_PUBLIC 0.101.0
>   cl_scandesc@CLAMAV_PUBLIC 0.101.0
>   cl_scandesc_callback@CLAMAV_PUBLIC 0.101.0
> @@ -72,185 +72,184 @@
>   cl_scanfile_callback@CLAMAV_PUBLIC 0.101.0
>   cl_scanmap_callback@CLAMAV_PUBLIC 0.101.0
>   cl_set_clcb_msg@CLAMAV_PUBLIC 0.101.0
> - cl_sha1@CLAMAV_PRIVATE 0.101.2
> - cl_sha256@CLAMAV_PRIVATE 0.101.2
> - cl_sign_data@CLAMAV_PRIVATE 0.101.2
> - cl_sign_data_keyfile@CLAMAV_PRIVATE 0.101.2
> - cl_sign_file_fd@CLAMAV_PRIVATE 0.101.2
> - cl_sign_file_fp@CLAMAV_PRIVATE 0.101.2
> + cl_sha1@CLAMAV_PRIVATE 0.101.4
> + cl_sha256@CLAMAV_PRIVATE 0.101.4
> + cl_sign_data@CLAMAV_PRIVATE 0.101.4
> + cl_sign_data_keyfile@CLAMAV_PRIVATE 0.101.4
> + cl_sign_file_fd@CLAMAV_PRIVATE 0.101.4
> + cl_sign_file_fp@CLAMAV_PRIVATE 0.101.4
>   cl_statchkdir@CLAMAV_PUBLIC 0.101.0
>   cl_statfree@CLAMAV_PUBLIC 0.101.0
>   cl_statinidir@CLAMAV_PUBLIC 0.101.0
>   cl_strerror@CLAMAV_PUBLIC 0.101.0
>   cl_update_hash@CLAMAV_PUBLIC 0.101.0
> - cl_validate_certificate_chain@CLAMAV_PRIVATE 0.101.2
> - cl_validate_certificate_chain_ts_dir@CLAMAV_PRIVATE 0.101.2
> - cl_verify_signature@CLAMAV_PRIVATE 0.101.2
> - cl_verify_signature_fd@CLAMAV_PRIVATE 0.101.2
> - cl_verify_signature_fd_x509@CLAMAV_PRIVATE 0.101.2
> - cl_verify_signature_fd_x509_keyfile@CLAMAV_PRIVATE 0.101.2
> - cl_verify_signature_hash@CLAMAV_PRIVATE 0.101.2
> - cl_verify_signature_hash_x509@CLAMAV_PRIVATE 0.101.2
> - cl_verify_signature_hash_x509_keyfile@CLAMAV_PRIVATE 0.101.2
> - cl_verify_signature_x509@CLAMAV_PRIVATE 0.101.2
> - cl_verify_signature_x509_keyfile@CLAMAV_PRIVATE 0.101.2
> - cli_ac_buildtrie@CLAMAV_PRIVATE 0.101.2
> - cli_ac_chklsig@CLAMAV_PRIVATE 0.101.2
> - 

Bug#941078: transition: postgresql-12

[Christoph Berg]

Re: Paul Gevers 2019-11-13 
> Scheduled.

Thanks!

Not sure why my last list missed a few, but here's three more:

postgresql-multicorn
pldebugger
first-last-agg

Christoph

Bug#941078: transition: postgresql-12

[Christoph Berg]

Re: Paul Gevers 2019-11-09 <10dd87e2-5aa6-84eb-a41a-b9a038dd6...@debian.org>
> ^ This just got uploaded moments ago, binNMU'ed on the buildd.

Hi Paul,

thanks for handling this.

Here's the list of remaining packages that need a "rebuild on buildd"
binnmu:

bgw-replstatus
ip4r
jsquery
orafce
pg-cron
pg-dirtyread
pgextwlist
pgfincore
pgmemcache
pg-partman
pgq
pg-qualstats
pg-rage-terminator
pg-rational
pg-similarity
pg-snakeoil
pgsql-asn1oid
pg-stat-kcache
plr
postgresql-debversion
postgresql-hll
postgresql-mysql-fdw
postgresql-numeral
postgresql-periods
postgresql-pgmp
postgresql-pllua
postgresql-plproxy
postgresql-plsh
postgresql-prioritize
postgresql-rum
postgresql-unit
powa-archivist
prefix
preprepare
toastinfo
vip-manager

Christoph

Bug#941078: transition: postgresql-12

[Christoph Berg]

Here's the situation as of now, looking at 
https://qa.debian.org/excuses.php?package=postgresql-common

Issues preventing migration:

Fix waiting in NEW:

autopkgtest for pg-rage-terminator/0.1.7-2: amd64: Regression ♻
autopkgtest for postgresql-multicorn/1.3.4-18-g99ea772-2: amd64: Regression ♻

Fix just uploaded:

autopkgtest for check-postgres/2.24.0-3: amd64: Regression ♻
autopkgtest for pgsphere/1.1.1+2018.10.13-1: amd64: Regression ♻ (Fix in 
postgresql-common)

Need fixing upstream (and should be ignored and/or removed from
testing until that happens):

autopkgtest for cstore-fdw/1.6.2-1: amd64: Regression ♻
autopkgtest for hypopg/1.1.2-1: amd64: Regression ♻
autopkgtest for pgaudit/1.4.0-1: amd64: Regression ♻
autopkgtest for pglogical/2.2.2-1: amd64: Regression ♻
autopkgtest for pglogical-ticker/1.4.0-1: amd64: Regression ♻
autopkgtest for repmgr/5.0.0-2: amd64: Regression ♻
autopkgtest for wal2json/1.0-5: amd64: Regression ♻

To be investigated:

autopkgtest for postgresql-q3c/1.8.0-1: amd64: Regression ♻

These are OK and need to migrate in parallel with postgresql-common so
the list of supported PG versions is in sync:

autopkgtest for omnidb/2.16.0+ds-2: amd64: Regression ♻
autopkgtest for pg-checksums/1.0-1: amd64: Regression ♻
autopkgtest for pg-repack/1.4.5-2: amd64: Regression ♻
autopkgtest for pg-similarity/1.0-2: amd64: Regression ♻
autopkgtest for pgagent/4.0.0-5: amd64: Regression ♻
autopkgtest for pgpool2/4.0.6-1: amd64: Regression ♻
autopkgtest for pgrouting/2.6.3-1: amd64: Regression ♻
autopkgtest for postgis/3.0.0+dfsg-1: amd64: Regression ♻
autopkgtest for rdkit/201903.1-2: amd64: Regression ♻
autopkgtest for slony1-2/2.2.8-1: amd64: Regression ♻


So the ideal solution would be to have this last bunch tested+migrated
along with postgresql-common. (If that's not possible, one possible
solution could be to just force postgresql-common into testing, and have
that bunch follow on its own because the the tests should pass.)

Most of these also need amd64 "rebuild on buildd" binnmus. Do you want
me to compile a list, or do you have that at hand anyway?

Thanks,
Christoph

Bug#941078: transition: postgresql-12

[Christoph Berg]

Re: Paul Gevers 2019-11-05 <75a8a466-6338-b4c3-13bf-494498644...@debian.org>
> Hi Christoph,
> 
> Did I see correctly that not much changed in the status of the
> postgresql-12 transition? Are you done uploading and do the other
> packages need binNMU's? Or are you just busy?

Most of the "easy" work is done. The remaining packages need upstream
fixes, which I have started hunting for, but I was pretty busy over
the past days.

I'll try to get some more sorted out tomorrow, and then post a list
here which packages I think should be either ignored, or removed from
testing for now. From there, the way forward would be to ask debci to
test all "good" packages together, or simply to force
postgresql-common into testing and have everything else migrate by the
usual means.

Christoph

Bug#941078: transition: postgresql-12

[Christoph Berg]

Re: Paul Gevers 2019-10-13 
> The migration is currently blocked on the regression of repmgr. I just
> triggered a reference run as I think the postgresql-11 migration in the
> perl transition will have caused the current state in testing to be bad
> already. If that's not the case, and it's really postgresql-12 related,
> how do you propose we treat the situation?

Fwiw, I believe the situation is as follows: libpq5 didn't break ABI,
so the existing postgresql-11-repmgr packages are fine, both in
testing and in unstable.

What did change however is that some API juggling happened, which
means repmgr needs to be updated to cope with mixed PostgreSQL
versions in postgresql-server-dev-11 and libpq-dev 12.

Unfortunately repmgr's autopkgtest is marked "build-needed" so we get
to see the API problem, while there's no actual problem with the
binaries. I've pushed a change to git to fix that.

Christoph

Bug#941078: transition: postgresql-12

[Christoph Berg]

Re: Paul Gevers 2019-10-13 
> The migration is currently blocked on the regression of repmgr. I just
> triggered a reference run as I think the postgresql-11 migration in the
> perl transition will have caused the current state in testing to be bad
> already. If that's not the case, and it's really postgresql-12 related,
> how do you propose we treat the situation?

Marco said there would be a new repmgr release tomorrow. That can
transition to testing independently first, and then PG12 will be good
to go.

Christoph

Bug#941078: transition: postgresql-12

[Christoph Berg]

Re: Emilio Pozuelo Monfort 2019-10-12 
<09c44ee4-1bee-bc9a-43fd-64fbbdf5c...@debian.org>
> Go ahead.

Thanks. We'll start as soon as postgresql-12 is in testing to minimize
any possible entanglement with other transitions.

Christoph

Bug#941078: transition: postgresql-12

[Christoph Berg]

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

Hi,

PostgreSQL 12 rc1 is due to be released this week. Ben patch attached.

As usual the transition will be done using sourceful uploads, so
little release team interaction is expected to be needed.

Christoph
>From dc20c59f948622dc761f06aa0d5da7d6813c3811 Mon Sep 17 00:00:00 2001
From: Christoph Berg 
Date: Tue, 24 Sep 2019 12:44:26 +0200
Subject: [PATCH] Add postgresql-12 tracker

---
 config/ongoing/postgresql-12.ben | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 config/ongoing/postgresql-12.ben

diff --git a/config/ongoing/postgresql-12.ben b/config/ongoing/postgresql-12.ben
new file mode 100644
index 000..4ac60b1
--- /dev/null
+++ b/config/ongoing/postgresql-12.ben
@@ -0,0 +1,5 @@
+title = "postgresql-12";
+is_affected = .depends ~ /postgresql.*-1[012].*/ | .build-depends ~ /postgresql.*-1[012].*/ | .recommends ~ /postgresql.*-1[012].*/ | .suggests ~ /postgresql.*-1[012].*/;
+is_good = .depends ~ /postgresql.*-12.*/ | .build-depends ~ /postgresql.*-12.*/ | .recommends ~ /postgresql.*-12.*/ | .suggests ~ /postgresql.*-12.*/;
+is_bad =  .depends ~ /postgresql.*-1[01].*/  | .build-depends ~ /postgresql.*-1[01].*/  | .recommends ~ /postgresql.*-1[01].*/  | .suggests ~ /postgresql.*-1[01].*/;
+export = false;
-- 
2.23.0

Bug#933036: buster-pu: package postgresql-common/200+deb10u2

[Christoph Berg]

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

Please consider postgresql-common 200+deb10u2 for buster. It fixes a
critical problem when pg_upgradecluster is used *twice* on the same
cluster. (The first upgrade is ok, but the second upgrade will
maneuver the system into a state where pg_dropcluster will delete the
data of the wrong cluster.) #931635.

The actual update is small (don't update postgresql.auto.conf, and
when postgresql.auto.conf is already bad, don't read data_directory
from it), but the diff also includes test coverage for the problem.

Debdiff:

No differences were encountered between the control files

diff -Nru postgresql-common-200+deb10u1/debian/changelog 
postgresql-common-200+deb10u2/debian/changelog
--- postgresql-common-200+deb10u1/debian/changelog  2019-04-12 
14:32:52.0 +0200
+++ postgresql-common-200+deb10u2/debian/changelog  2019-07-25 
23:04:54.0 +0200
@@ -1,3 +1,21 @@
+postgresql-common (200+deb10u2) buster; urgency=high
+
+  DATA LOSS WARNING: pg_upgradecluster from postgresql-common 200,
+  200+deb10u1, 201, and 202 will corrupt the data_directory setting when used
+  *twice* to upgrade a cluster (e.g. 9.6 -> 10 -> 11). This update fixes the
+  original problem, and also heals affected clusters on the next upgrade. No
+  additional steps are required.
+
+  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931635
+
+  * pg_upgradecluster: Don't accidentally set (the wrong!) data_directory in
+postgresql.auto.conf. (Closes: #931635)
+  * PgCommon.pm: Ignore data_directory when set in postgresql.auto.conf.
+  * pg_upgradecluster: Delete data_directory from postgresql.auto.conf in new
+cluster.
+
+ -- Christoph Berg   Thu, 25 Jul 2019 23:04:54 +0200
+
 postgresql-common (200+deb10u1) unstable; urgency=medium
 
   * When upgrading from stretch to buster, all text indexes need to be
diff -Nru postgresql-common-200+deb10u1/PgCommon.pm 
postgresql-common-200+deb10u2/PgCommon.pm
--- postgresql-common-200+deb10u1/PgCommon.pm   2019-03-01 15:17:21.0 
+0100
+++ postgresql-common-200+deb10u2/PgCommon.pm   2019-07-25 23:00:10.0 
+0200
@@ -210,6 +210,7 @@
 my $data_directory = cluster_data_directory($version, $cluster, 
\%conf);
 my %auto_conf = read_conf_file "$data_directory/postgresql.auto.conf";
 foreach my $guc (keys %auto_conf) {
+next if ($guc eq 'data_directory'); # defend against 
pg_upgradecluster bug in 200..202
 $conf{$guc} = $auto_conf{$guc};
 }
 }
diff -Nru postgresql-common-200+deb10u1/pg_upgradecluster 
postgresql-common-200+deb10u2/pg_upgradecluster
--- postgresql-common-200+deb10u1/pg_upgradecluster 2019-04-12 
14:32:49.0 +0200
+++ postgresql-common-200+deb10u2/pg_upgradecluster 2019-07-25 
23:00:10.0 +0200
@@ -67,7 +67,12 @@
 };
 
 # adapt paths to configuration files
-$set->('data_directory', $newinfo{'pgdata'});
+if ($configfile eq 'postgresql.conf') {
+$set->('data_directory', $newinfo{'pgdata'});
+} else {
+# fix bug in pg_upgradecluster 200..202
+$deprecate->(\%c, 'data_directory', 'not valid in 
postgresql.auto.conf');
+}
 for my $guc (qw(hba_file ident_file external_pid_file 
stats_temp_directory)) {
 next unless (defined $c{$guc});
 my $val = $c{$guc};
@@ -154,7 +159,7 @@
 if ($newversion >= '9.4') {
 $deprecate->(\%c, 'krb_srvname', 'native krb5 authentication 
deprecated in favor of GSSAPI');
 # grab dsmt from the new config just written by initdb
-unless ($c{dynamic_shared_memory_type}) {
+if (not $c{dynamic_shared_memory_type} and $configfile eq 
'postgresql.conf') {
 $set->('dynamic_shared_memory_type', 
($newinfo{config}->{dynamic_shared_memory_type} || 'mmap'));
 }
 }
diff -Nru postgresql-common-200+deb10u1/t/040_upgrade.t 
postgresql-common-200+deb10u2/t/040_upgrade.t
--- postgresql-common-200+deb10u1/t/040_upgrade.t   2019-04-12 
14:32:49.0 +0200
+++ postgresql-common-200+deb10u2/t/040_upgrade.t   2019-07-25 
23:00:10.0 +0200
@@ -11,7 +11,7 @@
 use TestLib;
 use PgCommon;
 
-use Test::More tests => (@MAJORS == 1) ? 1 : 115 * 3;
+use Test::More tests => (@MAJORS == 1) ? 1 : 121 * 3;
 
 if (@MAJORS == 1) {
 pass 'only one major version installed, skipping upgrade tests';
@@ -113,9 +113,12 @@
 is_program_out 'postgres', "pg_conftool $MAJORS[0] upgr set log_statement all",
 0, '', 'set postgresql.conf parameter';
 SKIP: {
-skip 'postgresql.auto.conf not supported before 9.4', 2 if ($MAJORS[0] < 
9.4);
+skip 'postgresql.auto.conf not supported before 9.4', 6 if ($MAJORS[0] < 
9.4);
+is_program_out 'postgres', "psql -qc \"ALTER SYSTEM SET ident_file = 
'/etc/postgresql/$MAJORS[0]/upgr/pg_ident.conf'\"",
+   

Bug#931001: unblock: xkeycaps/2.47-7

[Christoph Berg]

Re: Paul Gevers 2019-06-27 <9333738b-2b40-1c11-4ea4-1a968ed33...@debian.org>
> It's too late to fix this now. The deadline was Tuesday, for packages
> ready to migrate and AFAICT, this bug isn't serious enough to warrant an
> exception.

Ok, thanks for looking anyway!

Christoph

Bug#931001: unblock: xkeycaps/2.47-7

[Christoph Berg]

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

Please consider unblocking package xkeycaps. The new version properly
cross-builds, and also passes LDFLAGS to the final linker command
(previously, "-Wl,-z,relro" was missing).

I tested the package manually since there's no automated testsuite.

unblock xkeycaps/2.47-7

diff --git a/debian/changelog b/debian/changelog
index 28182fd..e6b0d09 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,22 @@
+xkeycaps (2.47-7) unstable; urgency=medium
+
+  * Imakefile: teach ComplexProgramTarget about LDFLAGS. Spotted by blhc.
+
+ -- Christoph Berg   Mon, 24 Jun 2019 11:56:50 +0200
+
+xkeycaps (2.47-6) unstable; urgency=medium
+
+  [ Ondřej Nový ]
+  * d/changelog: Remove trailing whitespaces
+
+  [ Nguyen Hoang Tung ]
+  * Use dh_auto_build to fix FTCBFS. (Closes: #930845)
+
+  [ Christoph Berg ]
+  * Add debian/gitlab-ci.yml.
+
+ -- Christoph Berg   Mon, 24 Jun 2019 09:49:31 +0200
+
 xkeycaps (2.47-5) unstable; urgency=medium
 
   * Prevent segfault in commands.c when more than 8 keysyms per key are
@@ -124,7 +143,7 @@ xkeycaps (2.46-5.1) unstable; urgency=low
 
 xkeycaps (2.46-5) unstable; urgency=low
 
-  * [Imakefile] Do HP-UX specific stuff on HPPA in general, but only if not 
+  * [Imakefile] Do HP-UX specific stuff on HPPA in general, but only if not
 on Linux. (Closes: #105075)
   * Added build dependencies.
   * Marked the app-defaults file as a conffile.
diff --git a/debian/gitlab-ci.yml b/debian/gitlab-ci.yml
new file mode 100644
index 000..ac7bc44
--- /dev/null
+++ b/debian/gitlab-ci.yml
@@ -0,0 +1,6 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+  RELEASE: 'unstable'
diff --git a/debian/patches/ldflags b/debian/patches/ldflags
new file mode 100644
index 000..f5f623d
--- /dev/null
+++ b/debian/patches/ldflags
@@ -0,0 +1,11 @@
+--- a/Imakefile
 b/Imakefile
+@@ -356,6 +356,8 @@ LOCAL_LIBRARIES = $(XAWLIB) $(XTOOLLIB)
+ /**/#  COMPRESS = gzip --verbose --best
+ /**/#  COMPRESS_EXT = gz
+ 
++# teach ComplexProgramTarget about LDFLAGS
++LDOPTIONS += $(LDFLAGS)
+ ComplexProgramTarget(xkeycaps)
+ 
+ all-kbds.o:  kbddef.h $(KBDIR)/all-kbds.h $(ALL_KBDS)
diff --git a/debian/patches/series b/debian/patches/series
index ae55bab..436989d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
+ldflags
 man.patch
 max8
diff --git a/debian/rules b/debian/rules
index 3ca9ceb..71a9664 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,7 +5,7 @@ include /usr/share/dpkg/buildflags.mk
 
 override_dh_auto_build:
xmkmf
-   $(MAKE) CDEBUGFLAGS="$(CFLAGS)"
+   dh_auto_build -- CDEBUGFLAGS="$(CFLAGS)"
 
 override_dh_auto_install:
dh_auto_install

Thanks,
Christoph

Bug#930799: unblock: postgresql-11/11.4-1

[Christoph Berg]

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

Please unblock package postgresql-11. The new version fixes
CVE-2019-10164.

debian/* diff:

diff --git a/debian/changelog b/debian/changelog
index d9bedcb..2f7e899 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,23 @@
+postgresql-11 (11.4-1) unstable; urgency=medium
+
+  * New upstream version.
++ Fix buffer-overflow hazards in SCRAM verifier parsing
+  (Jonathan Katz, Heikki Linnakangas, Michael Paquier)
+
+  Any authenticated user could cause a stack-based buffer overflow by
+  changing their own password to a purpose-crafted value.  In addition to
+  the ability to crash the PostgreSQL server, this could suffice for
+  executing arbitrary code as the PostgreSQL operating system account.
+
+  A similar overflow hazard existed in libpq, which could allow a rogue
+  server to crash a client or perhaps execute arbitrary code as the
+  client's operating system account.
+
+  The PostgreSQL Project thanks Alexander Lakhin for reporting this
+  problem.  (CVE-2019-10164)
+
+ -- Christoph Berg   Tue, 18 Jun 2019 11:03:14 +0200
+
 postgresql-11 (11.3-1) unstable; urgency=medium

   * New upstream version.

unblock postgresql-11/11.4-1

Christoph

Bug#928933: unblock: xdx/2.5.0-2

[Christoph Berg]

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

Please unblock package xdx. The new version updates the French
upstream translation. I had to add some code to actually build the
.gmo files; I tested that the new version actually ships the same set
of files, and that the new French strings are actually used.

unblock xdx/2.5.0-2

Thanks,
Christoph


Control files: lines which differ (wdiff format)

[-#Vcs-Browser: http://git.debian.org/?p=collab-maint/xdx.git;a=summary-]
[--]
[-#Vcs-Git: git://git.debian.org/collab-maint/xdx.git-]Architecture: any
{+Vcs-Browser: https://salsa.debian.org/debian-hamradio-team/xdx+}
{++}
{+Vcs-Git: https://salsa.debian.org/debian-hamradio-team/xdx.git+}

diff -Nru xdx-2.5.0/debian/changelog xdx-2.5.0/debian/changelog
--- xdx-2.5.0/debian/changelog  2015-05-20 13:14:52.0 +0200
+++ xdx-2.5.0/debian/changelog  2019-05-13 09:59:55.0 +0200
@@ -1,3 +1,14 @@
+xdx (2.5.0-2) unstable; urgency=medium
+
+  * Team upload.
+  * Updated French upstream translation by Jean-Pierre Giraud, merci!
+(Closes: #928817)
+  * Force rebuild of .gmo files since we patch the .po files.
+  * Create git repository on salsa.
+  * Add debian/gitlab-ci.yml.
+
+ -- Christoph Berg   Mon, 13 May 2019 09:59:55 +0200
+
 xdx (2.5.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru xdx-2.5.0/debian/clean xdx-2.5.0/debian/clean
--- xdx-2.5.0/debian/clean  1970-01-01 01:00:00.0 +0100
+++ xdx-2.5.0/debian/clean  2019-05-13 09:48:47.0 +0200
@@ -0,0 +1 @@
+po/*.gmo
diff -Nru xdx-2.5.0/debian/control xdx-2.5.0/debian/control
--- xdx-2.5.0/debian/control2015-05-11 14:33:35.0 +0200
+++ xdx-2.5.0/debian/control2019-05-13 09:32:39.0 +0200
@@ -6,8 +6,8 @@
 Build-Depends: debhelper (>= 9), autotools-dev, pkg-config, libgtk2.0-dev 
(>=2.20.0)
 Standards-Version: 3.9.6
 Homepage: http://sourceforge.net/projects/xdxclusterclient/
-#Vcs-Git: git://git.debian.org/collab-maint/xdx.git
-#Vcs-Browser: http://git.debian.org/?p=collab-maint/xdx.git;a=summary
+Vcs-Git: https://salsa.debian.org/debian-hamradio-team/xdx.git
+Vcs-Browser: https://salsa.debian.org/debian-hamradio-team/xdx
 
 Package: xdx
 Architecture: any
diff -Nru xdx-2.5.0/debian/gitlab-ci.yml xdx-2.5.0/debian/gitlab-ci.yml
--- xdx-2.5.0/debian/gitlab-ci.yml  1970-01-01 01:00:00.0 +0100
+++ xdx-2.5.0/debian/gitlab-ci.yml  2019-05-13 09:51:19.0 +0200
@@ -0,0 +1,6 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+  RELEASE: 'unstable'
diff -Nru xdx-2.5.0/debian/patches/po-fr xdx-2.5.0/debian/patches/po-fr
--- xdx-2.5.0/debian/patches/po-fr  1970-01-01 01:00:00.0 +0100
+++ xdx-2.5.0/debian/patches/po-fr  2019-05-13 09:47:40.0 +0200
@@ -0,0 +1,195 @@
+--- a/po/fr.po
 b/po/fr.po
+@@ -1,26 +1,27 @@
+-# xdx - GTK+ DX-cluster client for amateur radio
++# Messages français xdx - GTK+ DX-cluster client for amateur radio
+ # Copyright (C) 2002-2006 Joop Stakenborg 
+ # This file is distributed under the same license as the xdx package.
+-# Jean-Luc  Coulon , 2006.
+-#
+ #
++#Jean-Luc Coulon , 2006.
++# Jean-Pierre Giraud , 2019.
+ msgid ""
+ msgstr ""
+ "Project-Id-Version: xdx 2.0\n"
+ "Report-Msgid-Bugs-To: n...@n0nb.us\n"
+ "POT-Creation-Date: 2015-05-17 06:22-0500\n"
+-"PO-Revision-Date: 2006-04-27 10:59+0200\n"
+-"Last-Translator: Jean-Luc Coulon (f5ibh) \n"
++"PO-Revision-Date: 2019-04-28 09:20+0100\n"
++"Last-Translator: Jean-Pierre Giraud \n"
+ "Language-Team: French \n"
+ "Language: fr\n"
+ "MIME-Version: 1.0\n"
+ "Content-Type: text/plain; charset=UTF-8\n"
+ "Content-Transfer-Encoding: 8bit\n"
++"Plural-Forms: nplurals=2; plural=(n > 1);\n"
++"X-Generator: Lokalize 2.0\n"
+ 
+ #: src/gui_aboutdialog.c:128
+-#, fuzzy
+ msgid "TCP/IP DX-cluster and ON4KST chat client for amateur radio operators"
+-msgstr "Client de chat DX-Cluster TCP/IP et ON4KST pour radioamateur"
++msgstr "Client de chat DX-Cluster TCP/IP et ON4KST pour radioamateurs"
+ 
+ #: src/gui.c:121
+ msgid "_Program"
+@@ -72,7 +73,7 @@ msgstr "_À propos"
+ 
+ #: src/gui.c:160
+ msgid "Function keys bar"
+-msgstr ""
++msgstr "Barre de touches de fonction"
+ 
+ #: src/gui.c:164
+ msgid "Auto Reconnect"
+@@ -80,7 +81,7 @@ msgstr "Reconnexion _automatique"
+ 
+ #: src/gui.c:168
+ msgid "Chat sidebar"
+-msgstr "_Barre latérale de messagerie instantannée"
++msgstr "_Barre latérale de messagerie instantanée"
+ 
+ #: src/gui.c:244
+ #, c-format
+@@ 

Bug#928719: unblock: postgresql-11/11.3-1

[Christoph Berg]

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

Please unblock package postgresql-11. The new version fixes two
security bugs, and various other issues. (This is a new upstream minor
release, which would have pushed by the security team if buster was
already released.)

unblock postgresql-11/11.3-1

Christoph


postgresql-11 (11.3-1) unstable; urgency=medium

  * New upstream version.
+ Prevent row-level security policies from being bypassed via selectivity
  estimators (Dean Rasheed)

  Some of the planner's selectivity estimators apply user-defined
  operators to values found in pg_statistic (e.g., most-common values).
  A leaky operator therefore can disclose some of the entries in a data
  column, even if the calling user lacks permission to read that column.
  In CVE-2017-7484 we added restrictions to forestall that, but we failed
  to consider the effects of row-level security.  A user who has SQL
  permission to read a column, but who is forbidden to see certain rows
  due to RLS policy, might still learn something about those rows'
  contents via a leaky operator.  This patch further tightens the rules,
  allowing leaky operators to be applied to statistics data only when
  there is no relevant RLS policy.  (CVE-2019-10130)

+ Avoid access to already-freed memory during partition routing error
  reports (Michael Paquier)

  This mistake could lead to a crash, and in principle it might be
  possible to use it to disclose server memory contents. (CVE-2019-10129)

 -- Christoph Berg   Tue, 07 May 2019 12:04:34 +0200

Bug#927129: unblock: postgresql-common/200+deb10u1

[Christoph Berg]

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

Please unblock package postgresql-common. The new version contains in
NEWS.Debian the same message that was added to the release notes as
#926627. Thanks.

commit b7ded1188f8605fc815149018d44766d2c302bd2
Author: Christoph Berg 
Date:   Fri Apr 12 15:18:36 2019 +0200

postgresql-common.NEWS: Warn users about glibc collation changes

The same message will appear in the release-notes: #926627

diff --git a/debian/changelog b/debian/changelog
index 58f61b0..427c1d8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+postgresql-common (200+deb10u1) unstable; urgency=medium
+
+  * When upgrading from stretch to buster, all text indexes need to be
+reindexed. Warn users about that in NEWS.Debian.
+
+ -- Christoph Berg   Fri, 12 Apr 2019 14:32:52 +0200
+
 postgresql-common (200) unstable; urgency=medium
 
   * pg_createcluster: Don't refuse explicit -p argument even when port is
diff --git a/debian/postgresql-common.NEWS b/debian/postgresql-common.NEWS
index fca02fd..7db0799 100644
--- a/debian/postgresql-common.NEWS
+++ b/debian/postgresql-common.NEWS
@@ -1,3 +1,25 @@
+postgresql-common (200+deb10u1) buster; urgency=high
+
+  Existing PostgreSQL databases need to be reindexed
+
+  When upgrading from stretch to buster, the glibc locale data is upgraded.
+  Specifically, this changes how PostgreSQL sorts data in text indexes. To
+  avoid corruption, such indexes need to be REINDEXed immediately after
+  upgrading the locales or locales-all packages, before putting back the
+  database into production.
+
+  Suggested command: sudo -u postgres reindexdb --all
+
+  Alternatively, upgrade the databases to PostgreSQL 11 using
+  pg_upgradecluster. (This uses pg_dump by default which will rebuild all
+  indexes. Using -m upgrade or pg_upgrade is not safe because it preserves
+  the now-wrong index ordering.)
+
+  Refer to the PostgreSQL Wiki for more information:
+https://wiki.postgresql.org/wiki/Locale_data_changes
+
+ -- Christoph Berg   Fri, 12 Apr 2019 14:32:52 +0200
+
 postgresql-common (161) unstable; urgency=medium
 
   pg_ctlcluster is now enforcing stricter file ownership on the cluster config

unblock postgresql-common/200+deb10u1

Christoph

Bug#926918: unblock: xastir/2.1.0-5

[Christoph Berg]

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

Please unblock package xastir. The new version fixes a FTBFS against
imagemagick, and cleans debian/ properly so building twice doesn't
leave crap around that kills the next build (see the -4 build logs).

Thanks.

Christoph

No differences were encountered between the control files

diff -Nru xastir-2.1.0/debian/changelog xastir-2.1.0/debian/changelog
--- xastir-2.1.0/debian/changelog	2019-01-15 00:41:09.0 +0100
+++ xastir-2.1.0/debian/changelog	2019-04-11 15:48:39.0 +0200
@@ -1,3 +1,20 @@
+xastir (2.1.0-5) unstable; urgency=medium
+
+  * Team upload.
+  * Remove bogus "clean" target that leaves cruft in debian/ behind,
+preventing building twice, and even caused FTBFS for the last upload.
+(Closes: #926848)
+
+ -- Christoph Berg   Thu, 11 Apr 2019 15:48:39 +0200
+
+xastir (2.1.0-4) unstable; urgency=medium
+
+  * Team upload.
+  * Fix FTBFS with recent imagemagick. (Closes: #924329)
+  * Add debian/gitlab-ci.yml.
+
+ -- Christoph Berg   Thu, 11 Apr 2019 11:39:42 +0200
+
 xastir (2.1.0-3) unstable; urgency=medium
 
   * Added Breaks & Replaces to control file (Closes: #919066)
diff -Nru xastir-2.1.0/debian/gitlab-ci.yml xastir-2.1.0/debian/gitlab-ci.yml
--- xastir-2.1.0/debian/gitlab-ci.yml	1970-01-01 01:00:00.0 +0100
+++ xastir-2.1.0/debian/gitlab-ci.yml	2019-04-11 11:39:25.0 +0200
@@ -0,0 +1,6 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+  RELEASE: 'unstable'
diff -Nru xastir-2.1.0/debian/patches/no-magick-implementation xastir-2.1.0/debian/patches/no-magick-implementation
--- xastir-2.1.0/debian/patches/no-magick-implementation	1970-01-01 01:00:00.0 +0100
+++ xastir-2.1.0/debian/patches/no-magick-implementation	2019-04-11 11:34:35.0 +0200
@@ -0,0 +1,11 @@
+--- a/src/map_geo.c
 b/src/map_geo.c
+@@ -133,7 +133,7 @@
+  * now (9/28/2010) being seen on some distros (Ubuntu 10.04 and
+  * OpenSuSE-11.3)
+  */
+-#define MAGICK_IMPLEMENTATION
++//#define MAGICK_IMPLEMENTATION
+ #include 
+ #else   // HAVE_GRAPHICSMAGICK
+ #include 
diff -Nru xastir-2.1.0/debian/patches/series xastir-2.1.0/debian/patches/series
--- xastir-2.1.0/debian/patches/series	2019-01-15 00:04:28.0 +0100
+++ xastir-2.1.0/debian/patches/series	2019-04-11 11:34:10.0 +0200
@@ -4,3 +4,4 @@
 OSM_config.patch
 simple_db.patch
 reproducible_build.patch
+no-magick-implementation
diff -Nru xastir-2.1.0/debian/rules xastir-2.1.0/debian/rules
--- xastir-2.1.0/debian/rules	2019-01-09 22:48:26.0 +0100
+++ xastir-2.1.0/debian/rules	2019-04-11 15:46:04.0 +0200
@@ -7,8 +7,3 @@
 
 override_dh_auto_installchangelogs:
 	dh_installchangelogs ChangeLog
-
-clean:
-	-rm -f src/callpass/Makefile
-	-rm -f config.log config.cache summary.log
-	dh_auto_clean

Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)

[Christoph Berg]

Re: Paul Gevers 2019-04-06 
> Regarding this PostgreSQL reindexing issue, is there anything we need to
> mention in the release-notes? If this isn't fleshed out, but the most
> likely answer is yes, than I'd appreciate it to receive a bug against
> release-notes to remind us about it later on. Text can come later when
> it is clear what needs to be done.

Opened #926627 for that.

Note that I still need input on how to raise the message on the
packaging side.

Christoph

Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)

[Christoph Berg]

Re: Philipp Kern 2019-03-26 <66988de0-f9be-14c0-6b64-df64261fe...@philkern.de>
> I suspect this is why MySQL keeps a whole zoo of collations internally
> that never change.

DB2 and Oracle bundle ICU for that reason, afaict. (But bundling
software has other problems, as we all know...)

> Is there a way upon next (re)start to have a startup script check for
> this case and reindex automatically then - at the expense of a hugely
> enlarged downtime? Say, with a flag file that keeps the glibc major
> version at last restart time around - for the first iteration on this?

We were thinking about doing something like that, but that doesn't
work for the general case - most libc upgrades do not break
everything, and reindexing would be overkill. It might help for the
2.28 upgrade, but getting this to work consistently would require lots
of scripting with lots of cornercases to cover. I don't think it is
possible to get this working reliably now, especially as we would need
to push that "fix" into stretch-proposed-updates as well. (Because
libc6 will likely be upgraded first, before the new postgresql-common
version could take action.)

> That's at least better than silent data corruption, even if still
> disruptive. On the other hand I guess you'd need to start the cluster
> for serving anyway for reindex to work and would then serve broken data
> in the meantime, too?

That's part of the problem, yes.

Christoph

Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)

[Christoph Berg]

Re: Florian Weimer 2019-03-25 <87o95yhp3h@mid.deneb.enyo.de>
> > For PostgreSQL, this means that the ordering of indexes on disk is
> > becoming corrupt, and all "text" (varchar, char, ...) indexes need to
> > be rebuilt. (And worse, if that is not done immediately, the tables
> > might become corrupt because some tuples aren't index-visible anymore
> > due to the incorrect btree ordering.)
> 
> That's fairly normal in a glibc update.  glibc upstream prefers it
> this way.  I've discussed it several times with other glibc
> maintainers.

Changes are normal. What's not normal here is the scale of the
changes, indexes will break for virtually all users.

> My understanding is that ICU provides versioned collation tables,
> which would allow you to avoid this issue.
> 
>   

Unfortunately not. PostgreSQL supports ICU, but not as the global
locale for clusters/databases, which is still libc only. And even if
it was supported, it's not the default, and we are still breaking all
installations.

> > I've been thinking about this for some time, and the best I could come
> > up so far is "raise a debconf note that people need to invoke REINDEX
> > DATABASE". The open question about this plan is, how should this note
> > be triggered.
> 
> That might not work for unique indices because locale data changes
> could cause strings to sort the same that were distinct before the
> update.

Well, that's not an argument for silently doing nothing. And I doubt
that this case even exists, for any two distinct strings, the
collation should output a consistent "less than" or "greater than"
answer.

I forgot to mention Plan 3: Mention this in the release notes.
That should be done anyway, the question being if that is enough.
My suspicion is that few people actually read the release notes, so
some notification from inside the system would be needed as well.
Be it a debconf note, and/or a NEWS.Debian entry somewhere.

I deem this to be release-critical for PostgreSQL users. The reason
I'm asking here is to get input which plan is the best.

Christoph

Glibc 2.28 breaks collation for PostgreSQL (and others?)

[Christoph Berg]

Hi,

with the update to glibc 2.28, collation aka sort ordering is
changing:

$ echo $LANG
de_DE.utf8
$ (echo 'a-a'; echo 'a a'; echo 'a+a'; echo 'aa') | sort

stretch:
  aa
  a a
  a-a
  a+a

buster:
  a a
  a+a
  a-a
  aa

A vast number of locales is affected, including en_US, possibly all of
them.

For PostgreSQL, this means that the ordering of indexes on disk is
becoming corrupt, and all "text" (varchar, char, ...) indexes need to
be rebuilt. (And worse, if that is not done immediately, the tables
might become corrupt because some tuples aren't index-visible anymore
due to the incorrect btree ordering.)

https://postgresql.verite.pro/blog/2018/08/27/glibc-upgrade.html
https://www.postgresql.org/message-id/9cbd8ba7-899f-4ed3-92b1-902b0d245...@manitou-mail.org

The PostgreSQL project is discussing how this could be handled inside
the database, but a) it's totally unclear how this could be detected
generically, not just for this set of test strings, and b) Debian
needs a fix now, not something that might appear in PostgreSQL 12 or 13.

I've been thinking about this for some time, and the best I could come
up so far is "raise a debconf note that people need to invoke REINDEX
DATABASE". The open question about this plan is, how should this note
be triggered.

Plan 1: Add a check if there are any postgresql clusters in
/etc/postgresql/, and raise the warning from locales.postinst and
locales-all.postinst.

Plan 2: Add a trigger to postgresql-common that checks if
locales(-all) are being upgraded, and raise the warning from there.
(This plan has the downside that we'd need to fix postgresql-common in
stretch to have the same check.)

Plan 1 looks much better.

I'm sorry that I didn't raise that earlier because I had hoped to come
up with some smarter solution that would take some burden from the
user having to run commands manually.

Does that make sense? Are there any options that I missed? Are there
any other packages affected? How do we proceed?

Christoph

Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies

[Christoph Berg]

Control: tag -1 = help

Re: Robie Basak 2019-03-20 <20190320142403.ge30...@mal.justgohome.co.uk>
> > > It is well understood that the OpenSSL license is not "compatible" with
> > > the GPL (either version 2 or 3); and furthermore, Debian has long taken
> > > the position that, unless a license exception is granted by the
> > > copyright holders, a package which is distributed under the GPL must
> > > only link to libraries whose licenses are also GPL-compatible in order
> > > for it to be included in Debian.
> > 
> > How is that a problem in libpq5, and not in the other packages?
> 
> libpq5 seemed like a reasonable place to file this bug in the first
> instance. I don't intend to dictate how or where this must be resolved.
> 
> To help put this into perpspective:
> 
> There are 140 source packages that build a binary that depends on
> libpq5.
> 
> 84 of these mention GPL in debian/copyright, but apparently have no
> linking exception (heuristically and not checked but this is hopefully
> enough for an indication).

PostgreSQL is BSD-licensed, so there is no problem in PostgreSQL
itself. (We use libedit instead of libreadline in psql to avoid the
libssl problem.) Also unlike the mariadb case, we have been shipping
libpq linked against libssl for at least a decade, so there is no
regression. Upstream is working on supporting alternate crypto
providers, but that will not happen before PostgreSQL 13.

What is less clear is if we have a giant problem now, or if we can get
out of the situation by claiming that the reverse dependencies do not
use libssl directly. Theoretically, we could ship a libpq5-nossl.deb
which I believe would have the same symbol signature.

Input from ftp-master, debian-release, and/or debian-legal on this is
needed, I cannot say what to do with licensing terms in all those
reverse-dependers.

> Of these 84, based on my glance at their debian/copyright files
> manually, and without deeper investigation:
> 
>   * 12[1] appear to be GPL-2 only, so are affected today and will
> continue to be affected in the upcoming OpenSSL upstream
> relicensing.
> 
>   * 27[2] look like they're GPL-2+, GPL-3 or GPL-3+, so are affected
> today but can be expected to become compatible in the future with a
> newer release of OpenSSL upstream. However this does not help for
> buster.
> 
> So that's at least approximately 39 of 140 reverse dependencies that
> appear affected based on a quick glance through. I've been fairly
> conservative in my superficial analysis - I skipped reverse dependencies
> where I couldn't see any compatibility problem from a quick glance.
> 
> [1] bandwidthd-pgsql dballe inspircd libnss-pgsql2 libodb-pgsql-2.4
> pmacct r-cran-rpostgresql saga sphinxsearch tora ulogd2-pgsql
> yubikey-server-c
> 
> [2] clisp cvm cyphesis-cpp gammu gnokii gnu-smalltalk gnunet grass
> libpg-perl libpreludedb motion newlisp osm2pgrouting osm2pgsql pam-pgsql
> libzdb perdition pgmodeler postgis pspp pvpgn qgis repmgr sqlsmith
> sysbench w1retap zabbix

Christoph


signature.asc
Description: PGP signature

Bug#914265: stretch-pu: package xkeycaps/2.47-4.1+deb9u1

[Christoph Berg]

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

Hi,

please unblock xkeycaps/2.47-4.1+deb9u1. It fixes a segfault if more
than 8 keysyms per key are present, which is apparently the case in
the default setup nowadays.

Christoph

No differences were encountered between the control files

diff -Nru xkeycaps-2.47/commands.c xkeycaps-2.47/commands.c
--- xkeycaps-2.47/commands.c	2005-02-22 23:33:15.0 +0100
+++ xkeycaps-2.47/commands.c	2018-11-21 10:08:41.0 +0100
@@ -440,6 +440,7 @@
 	  keysyms = XGetKeyboardMapping (XtDisplay (widget),
 	 key->key.keycode,
 	 1, );
+	  if (count > 8) count = 8; /* FIXME: we are only prepared for 8 names per key, clip here */
 	  if (! keysyms) count = 0;
 	  all [all_count].key = key;
 	  for (; count > 0; count--)
diff -Nru xkeycaps-2.47/debian/changelog xkeycaps-2.47/debian/changelog
--- xkeycaps-2.47/debian/changelog	2018-11-21 10:08:41.0 +0100
+++ xkeycaps-2.47/debian/changelog	2018-11-21 10:08:41.0 +0100
@@ -1,3 +1,10 @@
+xkeycaps (2.47-4.1+deb9u1) stretch; urgency=medium
+
+  * Prevent segfault in commands.c when more than 8 keysyms per key are
+present. (Closes: #914262)
+
+ -- Christoph Berg   Wed, 21 Nov 2018 09:47:46 +0100
+
 xkeycaps (2.47-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.


signature.asc
Description: PGP signature

Bug#910232: transition: postgresql-11

[Christoph Berg]

Re: Emilio Pozuelo Monfort 2018-10-10 
<8581a475-abc9-3af1-2885-c8e7b6764...@debian.org>
> This has started now, marking it as such.

All packages have been migrated, with only postgresql-10 pending
removal from unstable. (#913353)

The tracker can be closed. (The remaining packages listed are false
positives from un-anchored, broad regexps. E.g. nurpawiki is listed
because it depends on "libpostgresql-ocaml-so955" =~ /postgresql.*9/.)

Thanks,
Christoph

Bug#910232: transition: postgresql-11

[Christoph Berg]

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

PostgreSQL 11 RC1 will be released next week, and 11.0 will follow one
week later if everything goes well. I plan to target unstable with RC1.
PG 11 is the version that will be released with buster; PG 10 will be
removed once all packages have been migrated.

As usual, there should be little release team coordination needed, the
PostgreSQL team will be doing the necessary sourceful uploads for the
PostgreSQL module packages.

Ben file attached.

Thanks,
Christoph
>From db8cff538aed040c2da313b208ba343ddf1a1541 Mon Sep 17 00:00:00 2001
From: Christoph Berg 
Date: Wed, 3 Oct 2018 19:19:02 +0200
Subject: [PATCH] Add postgresql-11 tracker

---
 config/ongoing/postgresql-11.ben | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 config/ongoing/postgresql-11.ben

diff --git a/config/ongoing/postgresql-11.ben b/config/ongoing/postgresql-11.ben
new file mode 100644
index 000..aabd6d5
--- /dev/null
+++ b/config/ongoing/postgresql-11.ben
@@ -0,0 +1,5 @@
+title = "postgresql-11";
+is_affected = .depends ~ /postgresql.*-[19].*/   | .build-depends ~ /postgresql.*-[19].*/   | .recommends ~ /postgresql.*-[19].*/   | .suggests ~ /postgresql.*-[19].*/;
+is_good = .depends ~ /postgresql.*-11.*/ | .build-depends ~ /postgresql.*-11.*/ | .recommends ~ /postgresql.*-11.*/ | .suggests ~ /postgresql.*-11.*/;
+is_bad =  .depends ~ /postgresql.*-(9|10).*/ | .build-depends ~ /postgresql.*-(9|10).*/ | .recommends ~ /postgresql.*-(9|10).*/ | .suggests ~ /postgresql.*-(9|10).*/;
+export = false;
-- 
2.19.0.329.g76f2f5c1e3

Bug#903052: stretch-pu: package check-postgres/2.22.0-2+deb9u1

[Christoph Berg]

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

Please unblock check-postgres/2.22.0-2+deb9u1. The new version fixes a
FTBFS caused by the last PostgreSQL security update.


diff -Nru check-postgres-2.22.0/debian/changelog 
check-postgres-2.22.0/debian/changelog
--- check-postgres-2.22.0/debian/changelog  2016-09-22 15:18:36.0 
+0200
+++ check-postgres-2.22.0/debian/changelog  2018-07-05 14:45:54.0 
+0200
@@ -1,3 +1,10 @@
+check-postgres (2.22.0-2+deb9u1) stretch; urgency=high
+
+  * PostgreSQL 9.6.8 changes pg_get_indexdef() to always include the schema
+name. Cope with that in the testsuite.  Closes: #897523.
+
+ -- Christoph Berg   Thu, 05 Jul 2018 14:45:54 
+0200
+
 check-postgres (2.22.0-2) unstable; urgency=medium
 
   * t/02_disk_space.t: Relax requirements on device name.
diff -Nru 
check-postgres-2.22.0/debian/patches/798d696ccb8297da233bcc6ab796071c7b35374c 
check-postgres-2.22.0/debian/patches/798d696ccb8297da233bcc6ab796071c7b35374c
--- 
check-postgres-2.22.0/debian/patches/798d696ccb8297da233bcc6ab796071c7b35374c   
1970-01-01 01:00:00.0 +0100
+++ 
check-postgres-2.22.0/debian/patches/798d696ccb8297da233bcc6ab796071c7b35374c   
2018-07-05 14:45:54.0 +0200
@@ -0,0 +1,26 @@
+PostgreSQL 9.6.8 changes pg_get_indexdef() to always include the schema name.
+Cope with that in the testsuite.
+
+Closes: #897523
+
+commit 798d696ccb8297da233bcc6ab796071c7b35374c
+Author: David Christensen 
+Date:   Thu Apr 5 11:46:49 2018 -0500
+
+Allow public-qualified difference (fixes issue with Pg 10)
+
+diff --git a/t/02_same_schema.t b/t/02_same_schema.t
+index e5517d1..218712e 100644
+--- a/t/02_same_schema.t
 b/t/02_same_schema.t
+@@ -621,8 +621,8 @@ like ($cp1->run($connect2),
+   qr{^$label CRITICAL.*Items not matched: 1 .*
+ \s*Index "public.valen":
+ \s*"indexdef" is different:
+-\s*Database 1: CREATE INDEX valen ON gkar USING btree \(garibaldi\)
+-\s*Database 2: CREATE UNIQUE INDEX valen ON gkar USING btree \(garibaldi\)
++\s*Database 1: CREATE INDEX valen ON (?:public\.)?gkar USING btree 
\(garibaldi\)
++\s*Database 2: CREATE UNIQUE INDEX valen ON (?:public\.)?gkar USING btree 
\(garibaldi\)
+ \s*"indisunique" is different:
+ \s*Database 1: f
+ \s*Database 2: t\s*$}s,
diff -Nru check-postgres-2.22.0/debian/patches/series 
check-postgres-2.22.0/debian/patches/series
--- check-postgres-2.22.0/debian/patches/series 2016-09-22 15:18:31.0 
+0200
+++ check-postgres-2.22.0/debian/patches/series 2018-07-05 14:45:54.0 
+0200
@@ -1,3 +1,4 @@
 no-tests-on-clean
 disable_replicate_row
 disk_space
+798d696ccb8297da233bcc6ab796071c7b35374c

Christoph

Bug#901033: stretch-pu: package postgresql-common/181+deb9u2

[Christoph Berg]

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

Please accept postgresql-common/181+deb9u2 for stretch. It fixes the
problem that removing the old postgresql server packages after
completing the upgrade will also shut down the server running the new
version. (#809811)

The package passes the built-in testsuite and has also been tested
manually.

Thanks,
Christoph


diff -Nru postgresql-common-181+deb9u1/debian/changelog 
postgresql-common-181+deb9u2/debian/changelog
--- postgresql-common-181+deb9u1/debian/changelog   2017-11-07 
20:54:52.0 +0100
+++ postgresql-common-181+deb9u2/debian/changelog   2018-06-08 
11:16:28.0 +0200
@@ -1,3 +1,13 @@
+postgresql-common (181+deb9u2) stretch; urgency=medium
+
+  * maintscripts-functions: Use 'deb-systemd-invoke stop "postgresql@$ver-*"'
+to prevent upgrading/removing server packages from stopping other major
+version clusters when running systemd. (Closes: #809811)
+(Use deb-systemd-invoke instead of invoke-rc.d; jessie's invoke-rc.d does
+not support service patterns.)
+
+ -- Christoph Berg   Fri, 08 Jun 2018 11:16:28 
+0200
+
 postgresql-common (181+deb9u1) stretch-security; urgency=medium
 
   * pg_ctlcluster, pg_createcluster, pg_upgradecluster: Use lchown instead
diff -Nru postgresql-common-181+deb9u1/debian/control 
postgresql-common-181+deb9u2/debian/control
--- postgresql-common-181+deb9u1/debian/control 2017-11-07 20:54:52.0 
+0100
+++ postgresql-common-181+deb9u2/debian/control 2018-06-08 11:16:28.0 
+0200
@@ -7,8 +7,8 @@
  Christoph Berg ,
  Peter Eisentraut ,
 Standards-Version: 3.9.8
-Vcs-Git: git://anonscm.debian.org/pkg-postgresql/postgresql-common.git
-Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git
+Vcs-Git: https://salsa.debian.org/postgresql/postgresql-common.git
+Vcs-Browser: https://salsa.debian.org/postgresql/postgresql-common
 Build-Depends:
  debhelper (>= 9),
  dh-systemd (>= 1.19) | sysvinit (<< 2.88dsf-42),
diff -Nru postgresql-common-181+deb9u1/debian/maintscripts-functions 
postgresql-common-181+deb9u2/debian/maintscripts-functions
--- postgresql-common-181+deb9u1/debian/maintscripts-functions  2017-11-07 
20:54:52.0 +0100
+++ postgresql-common-181+deb9u2/debian/maintscripts-functions  2018-06-08 
10:54:42.0 +0200
@@ -111,7 +111,11 @@
 stop_version() {
 if [ -x /etc/init.d/postgresql ] && [ ! -x /etc/init.d/postgresql-$1 ]; 
then
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
+if [ -d /run/systemd/system ]; then
+deb-systemd-invoke stop "postgresql@$1-*" || exit $?
+else
 invoke-rc.d postgresql stop $1 || exit $?
+fi
 else
 /etc/init.d/postgresql stop $1 || exit $?
 fi


signature.asc
Description: PGP signature

Bug#891120: RM: pgmodeler/0.8.2-1

[Christoph Berg]

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

As by #891049 the pgmodeler version in stretch is incompatible with
the PostgreSQL version in stretch. (It doesn't even connect, but
outright refuses to talk to the server.)

Please remove pgmodeler from stretch.

Christoph


signature.asc
Description: PGP signature

Bug#878852: Remove postgresql-9.6 from testing

[Christoph Berg]

Package: postgresql-9.6
Version: 9.6.5-1
Severity: serious

postgresql-9.6 is being replaced by postgresql-10, it can already be
removed from testing.

There's a few dependencies that are updated in unstable, but have not
transitioned yet:
  postgresql-mysql-fdw
  orafce
  postgresql-pllua

Waiting for NEW processing:
  pgextwlist

Fixed in experimental:
  repmgr

Unfixed, but in the works:
  skytools3

Release team:
For the unblocking the python3.6-as-default transition, please
consider removing postgresql-9.6 pgextwlist repmgr skytools3 from
testing, and speeding up the transition of postgresql-mysql-fdw orafce 
postgresql-pllua

Thanks,
Christoph

Bug#864379: unblock: pgloader/3.3.2+dfsg-1.1

[Christoph Berg]

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

Please unblock package pgloader. The new version fixes a missing
run-time dependency on libssl1.0.2.

(Unfortunately there is a second SSL-related bug in pgloader via
cl-plus-ssl - when loading from MS SQL-Server, it is trying to call
SSLv3_client_method which was only part of libssl1.0.0 in jessie, but
is not present anymore in libssl1.0.2. This is #864363, fixed some
hours ago. pgloader will have this bug until recompiled against
cl-plus-ssl 20160421-2.

This could be accomplished by a binnmu, but I guess that means
cl-plus-ssl needs an unblock as well, and it was uploaded only after
the deadline. I guess we'll just wait for the next point release with
that, and downgrade #864363 to important.)


diff -Nru pgloader-3.3.2+dfsg/debian/changelog 
pgloader-3.3.2+dfsg/debian/changelog
--- pgloader-3.3.2+dfsg/debian/changelog2016-12-03 17:36:56.0 
+0100
+++ pgloader-3.3.2+dfsg/debian/changelog2017-06-07 12:19:48.0 
+0200
@@ -1,3 +1,11 @@
+pgloader (3.3.2+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * pgloader: Add Depends: libssl1.0.2, dlopen()ed at runtime.
+(Closes: #864309)
+
+ -- Andreas Beckmann   Wed, 07 Jun 2017 12:19:48 +0200
+
 pgloader (3.3.2+dfsg-1) unstable; urgency=medium
 
   * Fixes github issue 453 (Closes: #843555)
diff -Nru pgloader-3.3.2+dfsg/debian/control pgloader-3.3.2+dfsg/debian/control
--- pgloader-3.3.2+dfsg/debian/control  2016-11-20 17:02:18.0 +0100
+++ pgloader-3.3.2+dfsg/debian/control  2017-06-07 12:06:20.0 +0200
@@ -11,7 +11,7 @@
 
 Package: pgloader
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, freetds-dev
+Depends: ${shlibs:Depends}, ${misc:Depends}, freetds-dev, libssl1.0.2
 Description: extract, transform and load data into PostgreSQL
  pgloader imports data from different kind of sources and COPY it into
  PostgreSQL.

unblock pgloader/3.3.2+dfsg-1.1


Thanks,
Christoph

Bug#864199: unblock: resource-agents/1:4.0.0~rc1-4

[Christoph Berg]

Re: Niels Thykier 2017-06-05 
> > unblock resource-agents/1:4.0.0~rc1-4
> 
> Unblocked, thanks.

The second after I had sent the mail, I noticed via DDPO that you had
already unblocked the package. Thanks for the awesome service :)

Christoph

Bug#864199: unblock: resource-agents/1:4.0.0~rc1-4

[Christoph Berg]

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

Please unblock package resource-agents. The new version fixes a
regression from jessie [*]. In PostgreSQL 9.6 synchronous replication
setups, setting the synchronous replication target failed if the
hostnames contained dashes ("pg-node-1"). The new version cherry-picks
changes from upstream.

[*] Strictly speaking, pacemaker is not in jessie, but it is in
jessie-backports and wheezy (no backports), so sync rep users would be
affected anyway.

Problem verified as existing in 1:4.0.0~rc1-3 and fixed in
1:4.0.0~rc1-4 in a manual test setup. (Hard to test automatically
because it needs two corosync nodes.)


diff -Nru resource-agents-4.0.0~rc1/debian/changelog 
resource-agents-4.0.0~rc1/debian/changelog
--- resource-agents-4.0.0~rc1/debian/changelog  2017-03-14 08:36:06.0 
+0100
+++ resource-agents-4.0.0~rc1/debian/changelog  2017-06-04 09:30:30.0 
+0200
@@ -1,3 +1,10 @@
+resource-agents (1:4.0.0~rc1-4) unstable; urgency=medium
+
+  * pgsql: postgresql-9.6 treats the contents of synchronous_standby_names as
+SQL identifiers, they need to be quoted for dashes etc. (Closes: #862719)
+
+ -- Christoph Berg <m...@debian.org>  Sun, 04 Jun 2017 09:30:30 +0200
+
 resource-agents (1:4.0.0~rc1-3) unstable; urgency=medium
 
   * debian/control: add net-tools to Recommends (Closes: #857368)
diff -Nru resource-agents-4.0.0~rc1/debian/patches/pgsql-9.6 
resource-agents-4.0.0~rc1/debian/patches/pgsql-9.6
--- resource-agents-4.0.0~rc1/debian/patches/pgsql-9.6  1970-01-01 
01:00:00.0 +0100
+++ resource-agents-4.0.0~rc1/debian/patches/pgsql-9.6  2017-06-04 
09:28:07.0 +0200
@@ -0,0 +1,47 @@
+commit 6e91193f0e4d3f72d22564e1fe393e7391691f9d
+Author: Andreas Ntaflos <andreas.ntaf...@rise-world.com>
+Date:   Mon Dec 12 14:43:59 2016 +0100
+
+Double-quote value of synchronous_standby_names in rep_mode.conf
+
+PostgreSQL 9.6 introduced a new syntax for specifying
+synchronous_standby_names. The old syntax, used by the pgsql RA, is
+still valid but PostgreSQL now treats the standby-names in
+synchronous_standby_names as SQL identifiers. This means such values
+need to be double-quoted since they can easily contain dashes or other
+characters that are not valid in a bare SQL identifier.
+
+See the docs for synchronous_standby_names in
+https://www.postgresql.org/docs/9.6/static/runtime-config-replication.html
+for confirmation and
+https://www.postgresql.org/message-id/21183.1481253534%40sss.pgh.pa.us
+for a short discussion.
+
+commit 6ad25cf64e00cebe5d90ec96430d94a38b240d31
+Author: Gianluca De Cicco <gnlcd...@gmail.com>
+Date:   Thu Mar 23 15:12:24 2017 +0100
+
+fix regex in set async mode
+
+Index: resource-agents/heartbeat/pgsql
+===
+--- resource-agents.orig/heartbeat/pgsql
 resource-agents/heartbeat/pgsql
+@@ -1474,7 +1474,7 @@ set_async_mode_all() {
+ }
+ 
+ set_async_mode() {
+-cat $REP_MODE_CONF |  grep -q -e "[,' ]$1[,' ]"
++cat $REP_MODE_CONF |  grep -q -E "(\"$1\")|([,' ]$1[,' ])"
+ if [ $? -eq 0 ]; then
+ ocf_log info "Setup $1 into async mode."
+ runasowner -q err "echo \"synchronous_standby_names = ''\" > 
\"$REP_MODE_CONF\""
+@@ -1493,7 +1493,7 @@ set_sync_mode() {
+ ocf_log debug "$sync_node_in_conf is already sync mode."
+ else
+ ocf_log info "Setup $1 into sync mode."
+-runasowner -q err "echo \"synchronous_standby_names = '$1'\" > 
\"$REP_MODE_CONF\""
++runasowner -q err "echo \"synchronous_standby_names = '\\\"$1\\\"'\" 
> \"$REP_MODE_CONF\""
+ [ "$RE_CONTROL_SLAVE" = "false" ] && RE_CONTROL_SLAVE="true"
+ exec_with_retry 0 reload_conf
+ fi
diff -Nru resource-agents-4.0.0~rc1/debian/patches/series 
resource-agents-4.0.0~rc1/debian/patches/series
--- resource-agents-4.0.0~rc1/debian/patches/series 2017-01-18 
14:38:11.0 +0100
+++ resource-agents-4.0.0~rc1/debian/patches/series 2017-06-04 
09:28:07.0 +0200
@@ -5,3 +5,4 @@
 ipv6-linux-only
 850787-fix-typo
 ocft-configs.patch
+pgsql-9.6


unblock resource-agents/1:4.0.0~rc1-4


Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#864019: unblock: dacs/1.4.38a-2

[Christoph Berg]

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

Please unblock package dacs. Testing by Jonas Smedegaard revealed that
the apache module is not loadable anymore because it tries to access a
private openssl symbol. We had been patching out that code part in
earlier package versions, but the patch got dropped recently because
it seemed not necessary anymore; unfortunately that was wrong, so this
upload reverts to the code that has been in wheezy and jessie.

We also switch back to libssl1.0 because it seems safer to use the SSL
version that apache2 itself is using.

Sorry for not catching this earlier via automated tests; a basic one
is added now.

Control files: lines which differ (wdiff format)

 apache2-dev, [-libssl-dev,-] {+apache2-ssl-dev,+} libexpat1-dev, chrpath,
 groff-base, xsltproc, docbook-xsl, [-libxmlsec1-dev,-] libpam0g-dev

diff -Nru dacs-1.4.38a/debian/changelog dacs-1.4.38a/debian/changelog
--- dacs-1.4.38a/debian/changelog   2017-01-12 16:22:08.0 +0100
+++ dacs-1.4.38a/debian/changelog   2017-05-28 20:42:21.0 +0200
@@ -1,3 +1,21 @@
+dacs (1.4.38a-2) unstable; urgency=medium
+
+  * Reintroduce debian/patches/ssl_hook_Fixup. Otherwise, the module tries to
+access the non-public ssl_hook_Fixup() function which is not resolvable
+anymore in recent openssl versions. Practical history in Debian (the patch
+had been there since the package was first uploaded in 2012, and even
+earlier in private packages), and code comments indicate the function call
+is not necessary, so remove it. Thanks to Jonas Smedegaard for spotting!
+(Closes: #863395)
+  * Build-Depend on apache2-ssl-dev instead of libssl-dev to match the openssl
+version apache2 is using.
+  * Add test case using a2enmod/apache2ctl configtest.
+  * Remove Build-Depends on libxmlsec1-dev which was only needed for the
+already disabled infocard support. (Additionally, libxmlsec1-dev depends
+on libssl-dev, so it was not co-installable with libssl1.0-dev anyway.)
+
+ -- Christoph Berg <m...@debian.org>  Sun, 28 May 2017 20:42:21 +0200
+
 dacs (1.4.38a-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru dacs-1.4.38a/debian/control dacs-1.4.38a/debian/control
--- dacs-1.4.38a/debian/control 2016-11-19 12:36:26.0 +0100
+++ dacs-1.4.38a/debian/control 2017-05-28 20:42:21.0 +0200
@@ -4,9 +4,9 @@
 Maintainer: Christoph Berg <christoph.b...@credativ.de>
 Uploaders: Martin Zobel-Helas <zo...@debian.org>
 Build-Depends: debhelper (>= 9),
- apache2-dev, libssl-dev, libexpat1-dev, chrpath,
+ apache2-dev, apache2-ssl-dev, libexpat1-dev, chrpath,
  libsasl2-dev, libperl-dev, libldap2-dev, autotools-dev,
- groff-base, xsltproc, docbook-xsl, libxmlsec1-dev, libpam0g-dev
+ groff-base, xsltproc, docbook-xsl, libpam0g-dev
 Standards-Version: 3.9.8
 Homepage: https://dacs.dss.ca/
 Vcs-Git: https://alioth.debian.org/anonscm/git/collab-maint/dacs.git
diff -Nru dacs-1.4.38a/debian/patches/series dacs-1.4.38a/debian/patches/series
--- dacs-1.4.38a/debian/patches/series  2016-11-19 12:36:26.0 +0100
+++ dacs-1.4.38a/debian/patches/series  2017-05-28 20:42:21.0 +0200
@@ -1,3 +1,4 @@
+ssl_hook_Fixup
 libtool-shell
 shared-library-linkage
 reproducible-build
diff -Nru dacs-1.4.38a/debian/patches/ssl_hook_Fixup 
dacs-1.4.38a/debian/patches/ssl_hook_Fixup
--- dacs-1.4.38a/debian/patches/ssl_hook_Fixup  1970-01-01 01:00:00.0 
+0100
+++ dacs-1.4.38a/debian/patches/ssl_hook_Fixup  2017-05-28 20:42:21.0 
+0200
@@ -0,0 +1,22 @@
+--- a/apache/mod_auth_dacs.c
 b/apache/mod_auth_dacs.c
+@@ -195,9 +195,6 @@ static int is_apache_2_2_build = 1;
+ /* For getpid() */
+ #include 
+ 
+-/* In modules/ssl/ssl_engine_kernel.c */
+-extern int ssl_hook_Fixup(request_rec *);
+-
+ #if defined(__DATE__) && defined(__TIME__)
+ static const char module_built[] = __DATE__ " " __TIME__;
+ #else
+@@ -1572,9 +1569,6 @@ exec_dacs_acs(request_rec *r, const char
+   ap_add_common_vars(r);
+   dacs_add_cgi_vars(r);   /* -bjb 21-Jan-2015 */
+ 
+-  if (ssl_is_ssl_request(r))
+-  ssl_hook_Fixup(r);  /* XXX This probably wasn't intended 
usage */
+-
+   /*
+* DACS cookies are always removed from the environment before invoking
+* dacs_acs so that they are not visible and easily copied.
diff -Nru dacs-1.4.38a/debian/tests/a2enmod dacs-1.4.38a/debian/tests/a2enmod
--- dacs-1.4.38a/debian/tests/a2enmod   1970-01-01 01:00:00.0 +0100
+++ dacs-1.4.38a/debian/tests/a2enmod   2017-05-28 20:42:21.0 +0200
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+set -e
+
+a2enmod auth_dacs
+apache2ctl configtest
diff -Nru dacs-1.4.38a/debian/tests/control dacs-1.4.38a/debian/tests/control
--- dacs-1.4.38a/debian/tests/control   1970-01-01 01:00:00.0 +0100
+++ dacs-1.4.38a/debian/tests/control   2017-05-2

Bug#862615: unblock: postgresql-9.6/9.6.3-1

[Christoph Berg]

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

Please unblock package postgresql-9.6:

postgresql-9.6 (9.6.3-1) unstable; urgency=medium

  * Team upload.
  * New upstream version.

+ Restrict visibility of pg_user_mappings.umoptions, to protect passwords
  stored as user mapping options (CVE-2017-7486)
+ Prevent exposure of statistical information via leaky operators
  (CVE-2017-7484)
+ Restore libpq's recognition of the PGREQUIRESSL environment variable
  (CVE-2017-7485)

  * debian/rules: Add stub to enable cassert builds (disabled by default).

 -- Christoph Berg <christoph.b...@credativ.de>  Tue, 09 May 2017 13:00:11 +0200


unblock postgresql-9.6/9.6.3-1


Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#861688: unblock: newpid/8

[Christoph Berg]

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

Please unblock package newpid. The new version mainly fixes postinst
installation failures on filesystems that do not support capabilities
(#860031).

The remaining changes are a trivial shell script update and
documentation/testsuite updates. (Needless to say, the testsuite is
passing, both on travis-ci.com and ci.debian.net.)


Control files: lines which differ (wdiff format)

Standards-Version: [-3.9.6-] {+3.9.8+}

diff -Nru newpid-7/debian/changelog newpid-8/debian/changelog
--- newpid-7/debian/changelog   2015-12-23 11:33:14.0 +0100
+++ newpid-8/debian/changelog   2017-05-01 18:15:30.0 +0200
@@ -1,3 +1,15 @@
+newpid (8) unstable; urgency=medium
+
+  * If setcap fails (because the filesystem or namespace lacks support for
+capabilities), fall back to setuid, so the installation doesn't fail.
+Thanks to Adam Conrad for the patch! Closes: #860031
+  * newpid: More verbose usage output.
+  * newnet: Guard arguments with --.
+  * README: Note required kernel and glibc version.
+  * Bump Standards-Version.
+
+ -- Christoph Berg <m...@debian.org>  Mon, 01 May 2017 18:15:30 +0200
+
 newpid (7) unstable; urgency=medium
 
   * Add support for joining network namespaces (newpid -N).
diff -Nru newpid-7/debian/control newpid-8/debian/control
--- newpid-7/debian/control 2015-09-30 16:20:10.0 +0200
+++ newpid-8/debian/control 2017-05-01 18:15:30.0 +0200
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Christoph Berg <m...@debian.org>
-Standards-Version: 3.9.6
+Standards-Version: 3.9.8
 Build-Depends: debhelper (>= 9~)
 Vcs-Browser: https://github.com/ChristophBerg/newpid
 Vcs-Git: git://github.com/ChristophBerg/newpid.git
diff -Nru newpid-7/debian/newpid.postinst newpid-8/debian/newpid.postinst
--- newpid-7/debian/newpid.postinst 2015-09-30 16:29:52.0 +0200
+++ newpid-8/debian/newpid.postinst 2017-05-01 18:13:17.0 +0200
@@ -4,7 +4,13 @@
 
 case $1 in
configure)
-   setcap "CAP_SYS_ADMIN,CAP_NET_ADMIN=pe" /usr/bin/newpid
+   # Code cargo-culted from iputils-ping postinst:
+   if setcap "CAP_SYS_ADMIN,CAP_NET_ADMIN=pe" /usr/bin/newpid; then
+   chmod u-s /usr/bin/newpid
+   else
+   echo "Setcap failed on /usr/bin/newpid, falling back to 
setuid" >&2
+   chmod u+s /usr/bin/newpid
+   fi
;;
 esac
 
diff -Nru newpid-7/newnet newpid-8/newnet
--- newpid-7/newnet 2015-10-07 10:01:32.0 +0200
+++ newpid-8/newnet 2015-12-26 18:15:24.0 +0100
@@ -1,3 +1,3 @@
 #!/bin/sh
 
-exec newpid -inu "$@"
+exec newpid -inu -- "$@"
diff -Nru newpid-7/newpid.c newpid-8/newpid.c
--- newpid-7/newpid.c   2015-12-17 17:06:21.0 +0100
+++ newpid-8/newpid.c   2017-05-01 18:14:45.0 +0200
@@ -214,8 +214,13 @@
cloneflags |= CLONE_NEWUTS;
break;
default: /* '?' */
-   fprintf(stderr, "Usage: %s [-inu] [command args 
...]\n",
+   fprintf(stderr, "Usage: %s [options] [command 
args ...]\n",
argv[0]);
+   fprintf(stderr, "Options:\n");
+   fprintf(stderr, "  -i   request new IPC 
namespace (CLONE_NEWIPC)\n");
+   fprintf(stderr, "  -n   request new 
network namespace (CLONE_NEWNET)\n");
+   fprintf(stderr, "  -N newpidns  join named 
network namespace\n");
+   fprintf(stderr, "  -u   request new UTS 
namespace (CLONE_NEWUTS)\n");
exit(EXIT_FAILURE);
}
}
diff -Nru newpid-7/README.md newpid-8/README.md
--- newpid-7/README.md  2015-12-17 16:45:51.0 +0100
+++ newpid-8/README.md  2017-05-01 18:15:30.0 +0200
@@ -1,6 +1,8 @@
 newpid
 ==
 
+[![Build 
Status](https://travis-ci.org/ChristophBerg/newpid.svg?branch=master)](https://travis-ci.org/ChristophBerg/newpid)
+
 Newpid is a wrapper around clone(CLONE_NEWPID) that launches a command
 in a new PID namespace. Child processes exiting are properly reaped so no
 zombie processes stay around. /proc is also remounted so it sees the new
@@ -57,4 +59,10 @@
 ip netns exec newpidns1 ip link set veth1 up
 
 
+Requirements
+----
+
+The setns() system call first appeared in Linux in kernel 3.0; library support
+was added to glibc in version 2.14.
+
  -- Christoph Berg <m...@debian.org>
diff -Nru newpid-7/.travis.yml newpid-8

Bug#858650: unblock: plv8/1:1.4.9.ds-1

[Christoph Berg]

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

Please unblock package plv8. The new version fixes a security problem.


diff -Nru plv8-1.4.8.ds/debian/changelog plv8-1.4.9.ds/debian/changelog
--- plv8-1.4.8.ds/debian/changelog  2017-01-14 21:15:06.0 +0100
+++ plv8-1.4.9.ds/debian/changelog  2017-03-22 19:01:08.0 +0100
@@ -1,3 +1,9 @@
+plv8 (1:1.4.9.ds-1) unstable; urgency=medium
+
+  * Security bugfix release: Check for permission to call functions.
+
+ -- Christoph Berg <m...@debian.org>  Wed, 22 Mar 2017 19:01:08 +0100
+
 plv8 (1:1.4.8.ds-3) unstable; urgency=medium
 
   * Remove Evgeni from Uploaders. Thanks!
diff -Nru plv8-1.4.8.ds/expected/startup.out plv8-1.4.9.ds/expected/startup.out
--- plv8-1.4.8.ds/expected/startup.out  2013-06-20 16:49:58.0 +0200
+++ plv8-1.4.9.ds/expected/startup.out  2017-03-22 19:01:01.0 +0100
@@ -1,7 +1,7 @@
 -- test startup failure
 set plv8.start_proc = foo;
 do $$ plv8.elog(NOTICE, 'foo = ' + foo) $$ language plv8;
-WARNING:  failed to find js function function "foo" does not exist
+WARNING:  failed to find js function function "foo()" does not exist
 ERROR:  ReferenceError: foo is not defined
 DETAIL:  undefined() LINE 1:  plv8.elog(NOTICE, 'foo = ' + foo) 
 \c
diff -Nru plv8-1.4.8.ds/Makefile plv8-1.4.9.ds/Makefile
--- plv8-1.4.8.ds/Makefile  2016-04-21 11:00:49.0 +0200
+++ plv8-1.4.9.ds/Makefile  2017-03-22 19:01:01.0 +0100
@@ -12,7 +12,7 @@
 #   'make static' will download v8 and build, then statically link to it.
 #
 #-#
-PLV8_VERSION = 1.4.8
+PLV8_VERSION = 1.4.9
 
 PG_CONFIG = pg_config
 PGXS := $(shell $(PG_CONFIG) --pgxs)
diff -Nru plv8-1.4.8.ds/META.json plv8-1.4.9.ds/META.json
--- plv8-1.4.8.ds/META.json 2016-04-21 11:00:49.0 +0200
+++ plv8-1.4.9.ds/META.json 2017-03-22 19:01:01.0 +0100
@@ -2,7 +2,7 @@
 "name": "plv8",
 "abstract": "A procedural language in JavaScript powered by V8",
 "description": "plv8 is a trusted procedural language that is safe to use, 
fast to run and easy to develop.",
-"version": "1.4.8",
+"version": "1.4.9",
 "maintainer": [
 "Jerry Sievert <c...@legitimatesounding.com>",
 "Hitoshi Harada <umi.tan...@gmail.com>"
@@ -24,21 +24,21 @@
 },
 "provides": {
 "plv8": {
-"file": "plv8--1.4.8.sql",
+"file": "plv8--1.4.9.sql",
 "docfile": "doc/plv8.md",
-"version": "1.4.8",
+"version": "1.4.9",
 "abstract": "A procedural language in JavaScript"
  },
 "plcoffee": {
-"file": "plcoffee--1.4.8.sql",
+"file": "plcoffee--1.4.9.sql",
 "docfile": "doc/plv8.md",
-"version": "1.4.8",
+"version": "1.4.9",
 "abstract": "A procedural language in CoffeeScript"
  },
 "plls": {
-"file": "plls--1.4.8.sql",
+"file": "plls--1.4.9.sql",
 "docfile": "doc/plv8.md",
-"version": "1.4.8",
+"version": "1.4.9",
 "abstract": "A procedural language in LiveScript"
  }
 },
diff -Nru plv8-1.4.8.ds/plv8.cc plv8-1.4.9.ds/plv8.cc
--- plv8-1.4.8.ds/plv8.cc   2016-04-21 10:59:10.0 +0200
+++ plv8-1.4.9.ds/plv8.cc   2017-03-22 19:01:01.0 +0100
@@ -191,7 +191,7 @@
 _PG_init(void)
 {
HASHCTLhash_ctl = { 0 };
-   
+
hash_ctl.keysize = sizeof(Oid);
hash_ctl.entrysize = sizeof(plv8_proc_cache);
hash_ctl.hash = oid_hash;
@@ -1263,6 +1263,18 @@
return ThrowException(Exception::Error(String::New(message)));
 }
 
+static text *
+charToText(char *string)
+{
+   int len = strlen(string);
+   text *result = (text *) palloc(len + 1 + VARHDRSZ);
+
+   SET_VARSIZE(result, len + VARHDRSZ);
+   memcpy(VARDATA(result), string, len + 1);
+
+   return result;
+}
+
 static Persistent
 GetGlobalContext()
 {
@@ -1307,10 +1319,40 @@
Context::Scope  context_scope(global_context);
TryCatchtry_catch;
MemoryContext   ctx = CurrentMemoryContext;
+   text *arg1, *

Bug#858649: unblock: postgresql-filedump/9.6.0-2

[Christoph Berg]

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

Please unblock package postgresql-filedump. The version currently in
testing FTBFSed on armhf in the +b1 binnmu round.

https://buildd.debian.org/status/logs.php?pkg=postgresql-filedump=armhf

Diff:

commit 7c97dcd25d2f5f051b400d97a6ef692f9e118bff
Author: Christoph Berg <m...@debian.org>
Date:   Sat Mar 18 14:32:18 2017 +0100

Disable PIE on 32bit archs; cf. #797530.

diff --git a/debian/changelog b/debian/changelog
index dac0cbd..a96d51e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+postgresql-filedump (9.6.0-2) unstable; urgency=medium
+
+  * Disable PIE on 32bit archs; cf. #797530.
+
+ -- Christoph Berg <m...@debian.org>  Sat, 18 Mar 2017 14:28:04 +0100
+
 postgresql-filedump (9.6.0-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/rules b/debian/rules
index ca4bbea..d6c4c9f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,13 @@
 #!/usr/bin/make -f
 
+# disable PIE on 32bit because it's disabled in PostgreSQL's libpgport.a
+# as well, cf. comments in postgresql-9.6's debian/rules and #797530
+ifneq ($(shell dpkg-architecture -qDEB_HOST_ARCH_BITS || :),32)
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+else
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
+endif
+
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 

unblock postgresql-filedump/9.6.0-2

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#858547: jessie-pu: package plv8/1.4.2.ds-2+deb8u1

[Christoph Berg]

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

Hi,

I would like to upload plv8 to jessie. Is that acceptable?

As per [1], a security upload is not applicable.

[1] 
https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#libv8

diff -Nru plv8-1.4.2.ds/debian/changelog plv8-1.4.2.ds/debian/changelog
--- plv8-1.4.2.ds/debian/changelog  2014-07-28 12:58:12.0 +0200
+++ plv8-1.4.2.ds/debian/changelog  2017-03-23 10:59:59.0 +0100
@@ -1,3 +1,9 @@
+plv8 (1.4.2.ds-2+deb8u1) jessie; urgency=high
+
+  * Security bugfix picked from 1.4.9: Check for permission to call functions.
+
+ -- Christoph Berg <christoph.b...@credativ.de>  Thu, 23 Mar 2017 10:59:59 
+0100
+
 plv8 (1.4.2.ds-2) unstable; urgency=medium
 
   * Pull patches from upstream to support PostgreSQL 9.4.
diff -Nru plv8-1.4.2.ds/debian/patches/90a57729abb488bf830c2f9783353dfe353ca4f0 
plv8-1.4.2.ds/debian/patches/90a57729abb488bf830c2f9783353dfe353ca4f0
--- plv8-1.4.2.ds/debian/patches/90a57729abb488bf830c2f9783353dfe353ca4f0   
1970-01-01 01:00:00.0 +0100
+++ plv8-1.4.2.ds/debian/patches/90a57729abb488bf830c2f9783353dfe353ca4f0   
2017-03-23 10:58:46.0 +0100
@@ -0,0 +1,78 @@
+diff --git a/expected/startup.out b/expected/startup.out
+index 0cd9941..0bc62d1 100644
+--- a/expected/startup.out
 b/expected/startup.out
+@@ -1,7 +1,7 @@
+ -- test startup failure
+ set plv8.start_proc = foo;
+ do $$ plv8.elog(NOTICE, 'foo = ' + foo) $$ language plv8;
+-WARNING:  failed to find js function function "foo" does not exist
++WARNING:  failed to find js function function "foo()" does not exist
+ ERROR:  ReferenceError: foo is not defined
+ DETAIL:  undefined() LINE 1:  plv8.elog(NOTICE, 'foo = ' + foo) 
+ \c
+diff --git a/plv8.cc b/plv8.cc
+index 54d4f3a..d0a81e3 100644
+--- a/plv8.cc
 b/plv8.cc
+@@ -1263,6 +1263,18 @@ ThrowError(const char *message) throw()
+   return ThrowException(Exception::Error(String::New(message)));
+ }
+ 
++static text *
++charToText(char *string)
++{
++  int len = strlen(string);
++  text *result = (text *) palloc(len + 1 + VARHDRSZ);
++
++  SET_VARSIZE(result, len + VARHDRSZ);
++  memcpy(VARDATA(result), string, len + 1);
++
++  return result;
++}
++
+ static Persistent
+ GetGlobalContext()
+ {
+@@ -1307,10 +1319,40 @@ GetGlobalContext()
+   Context::Scope  context_scope(global_context);
+   TryCatchtry_catch;
+   MemoryContext   ctx = CurrentMemoryContext;
++  text *arg1, *arg2;
++  FunctionCallInfoData fake_fcinfo;
++  FmgrInfoflinfo;
++
++  char proc[NAMEDATALEN + 32];
++  strcpy(proc, plv8_start_proc);
++  strcat(proc, "()");
++  char perm[16];
++  strcpy(perm, "EXECUTE");
++  arg1 = charToText(proc);
++  arg2 = charToText(perm);
++
++  MemSet(_fcinfo, 0, sizeof(fake_fcinfo));
++  MemSet(, 0, sizeof(flinfo));
++  fake_fcinfo.flinfo = 
++  flinfo.fn_oid = InvalidOid;
++  flinfo.fn_mcxt = CurrentMemoryContext;
++  fake_fcinfo.nargs = 2;
++  fake_fcinfo.arg[0] = CStringGetDatum(arg1);
++  fake_fcinfo.arg[1] = CStringGetDatum(arg2);
+ 
+   PG_TRY();
+   {
+-  func = 
find_js_function_by_name(plv8_start_proc);
++  Datum ret = 
has_function_privilege_name(_fcinfo);
++
++  if (ret == 0) {
++  elog(WARNING, "failed to find js 
function %s", plv8_start_proc);
++  } else {
++  if (DatumGetBool(ret)) {
++  func = 
find_js_function_by_name(plv8_start_proc);
++  } else {
++  elog(WARNING, "no permission to 
execute js function %s", plv8_start_proc);
++  }
++  }
+   }
+   PG_CATCH();
+   {
diff -Nru plv8-1.4.2.ds/debian/patches/series 
plv8-1.4.2.ds/debian/patches/series
--- plv8-1.4.2.ds/debian/patches/series 2014-07-28 12:55:57.0 +0200
+++ plv8-1.4.2.ds/debian/patches/series 2017-03-23 10:58:55.0 +0100
@@ -5,3 +5,4 @@
 094df45dce2a879d1814b792aeb46b38f0f0ef87
 0163635ecab45ec53419b9a3ea4ea890495ce3cc
 aedc9e64ba18d591f0a4afadecc936d778282bde
+90a57729abb488bf830c2f9783353dfe353ca4f0

Christoph


signature.asc
Description: PGP signature

Bug#858244: unblock: postgresql-mysql-fdw/2.2.0-2

[Christoph Berg]

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

Please unblock package postgresql-mysql-fdw. The new version fixes the
autopkgtest for stretch which doesn't have "mysql-server" (it works in
sid, so it's not visible on ci.debian.net).

diff -Nru postgresql-mysql-fdw-2.2.0/debian/changelog 
postgresql-mysql-fdw-2.2.0/debian/changelog
--- postgresql-mysql-fdw-2.2.0/debian/changelog 2017-01-12 10:02:48.0 
+0100
+++ postgresql-mysql-fdw-2.2.0/debian/changelog 2017-03-19 20:57:02.0 
+0100
@@ -1,3 +1,10 @@
+postgresql-mysql-fdw (2.2.0-2) unstable; urgency=medium
+
+  * Use default-mysql-server in test dependencies, stretch doesn't have
+mysql-server.
+
+ -- Christoph Berg <m...@debian.org>  Sun, 19 Mar 2017 20:57:02 +0100
+
 postgresql-mysql-fdw (2.2.0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru postgresql-mysql-fdw-2.2.0/debian/tests/control 
postgresql-mysql-fdw-2.2.0/debian/tests/control
--- postgresql-mysql-fdw-2.2.0/debian/tests/control 2017-01-12 
10:02:12.0 +0100
+++ postgresql-mysql-fdw-2.2.0/debian/tests/control 2017-03-19 
20:55:10.0 +0100
@@ -1,3 +1,3 @@
-Depends: @, postgresql-server-dev-all, mysql-server
+Depends: @, postgresql-server-dev-all, default-mysql-server | mysql-server
 Tests: installcheck
 Restrictions: needs-root allow-stderr


unblock postgresql-mysql-fdw/2.2.0-2

Thanks,
Christoph

Bug#855691: unblock: pg-repack/1.3.4-3

[Christoph Berg]

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

Please unblock package pg-repack, it fixes autopkgtest failures.

diff --git a/debian/changelog b/debian/changelog
index 84bd269..86e1726 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pg-repack (1.3.4-3) unstable; urgency=medium
+
+  * Team upload.
+  * Fix tablespace testcase to work with latest microrelease (Closes: #854997)
+
+ -- Christian Ehrhardt   Wed, 15 Feb 2017 
11:59:14 +0100
+
 pg-repack (1.3.4-2) unstable; urgency=medium
 
   * Team upload for PostgreSQL 9.6.
diff --git a/debian/patches/series b/debian/patches/series
index 72c53ff..0fe9787 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 libs
 tablespace
+tablespace-microrelease
diff --git a/debian/patches/tablespace-microrelease 
b/debian/patches/tablespace-microrelease
new file mode 100644
index 000..4b1b00c
--- /dev/null
+++ b/debian/patches/tablespace-microrelease
@@ -0,0 +1,245 @@
+Description: Add a variant expected output for the 'tablespace' regression test
+  The latest stable release changed output, but not behavior.
+  Need to add another set of accepted test output.
+Forwarded: yes, https://github.com/reorg/pg_repack/pull/115
+Bug-Debian: http://bugs.debian.org/854997
+Author: Christian Ehrhardt 
+
+--- /dev/null
 b/regress/expected/tablespace_2.out
+@@ -0,0 +1,235 @@
++SET client_min_messages = warning;
++--
++-- Tablespace features tests
++--
++-- Note: in order to pass this test you must create a tablespace called 
'testts'
++--
++CREATE TABLESPACE testts LOCATION '/tmp/pg-repack-tablespace';
++SELECT spcname FROM pg_tablespace WHERE spcname = 'testts';
++ spcname 
++-
++ testts
++(1 row)
++
++-- If the query above failed you must create the 'testts' tablespace;
++CREATE TABLE testts1 (id serial primary key, data text);
++CREATE INDEX testts1_partial_idx on testts1 (id) where (id > 0);
++CREATE INDEX testts1_with_idx on testts1 (id) with (fillfactor=80);
++INSERT INTO testts1 (data) values ('a');
++INSERT INTO testts1 (data) values ('b');
++INSERT INTO testts1 (data) values ('c');
++-- check the indexes definitions
++SELECT regexp_replace(
++repack.repack_indexdef(indexrelid, 'testts1'::regclass, NULL, false),
++'_[0-9]+', '_OID', 'g')
++FROM pg_index i join pg_class c ON c.oid = indexrelid
++WHERE indrelid = 'testts1'::regclass ORDER BY relname;
++  regexp_replace  

++--
++ CREATE INDEX index_OID ON repack.table_OID USING btree (id) TABLESPACE 
pg_default WHERE (id > 0)
++ CREATE UNIQUE INDEX index_OID ON repack.table_OID USING btree (id) 
TABLESPACE pg_default
++ CREATE INDEX index_OID ON repack.table_OID USING btree (id) WITH 
(fillfactor='80') TABLESPACE pg_default
++(3 rows)
++
++SELECT regexp_replace(
++repack.repack_indexdef(indexrelid, 'testts1'::regclass, 'foo', false),
++'_[0-9]+', '_OID', 'g')
++FROM pg_index i join pg_class c ON c.oid = indexrelid
++WHERE indrelid = 'testts1'::regclass ORDER BY relname;
++  regexp_replace  
 
++---
++ CREATE INDEX index_OID ON repack.table_OID USING btree (id) TABLESPACE foo 
WHERE (id > 0)
++ CREATE UNIQUE INDEX index_OID ON repack.table_OID USING btree (id) 
TABLESPACE foo
++ CREATE INDEX index_OID ON repack.table_OID USING btree (id) WITH 
(fillfactor='80') TABLESPACE foo
++(3 rows)
++
++SELECT regexp_replace(
++repack.repack_indexdef(indexrelid, 'testts1'::regclass, NULL, true),
++'_[0-9]+', '_OID', 'g')
++FROM pg_index i join pg_class c ON c.oid = indexrelid
++WHERE indrelid = 'testts1'::regclass ORDER BY relname;
++regexp_replace

++--
++ CREATE INDEX CONCURRENTLY index_OID ON testts1 USING btree (id) TABLESPACE 
pg_default WHERE (id > 0)
++ CREATE UNIQUE INDEX CONCURRENTLY index_OID ON testts1 USING btree (id) 
TABLESPACE pg_default
++ CREATE INDEX CONCURRENTLY index_OID ON testts1 USING btree (id) WITH 
(fillfactor='80') TABLESPACE pg_default
++(3 rows)
++
++SELECT regexp_replace(
++repack.repack_indexdef(indexrelid, 'testts1'::regclass, 'foo', true),
++'_[0-9]+', '_OID', 'g')
++FROM pg_index i join pg_class c ON c.oid = indexrelid
++WHERE indrelid = 'testts1'::regclass ORDER BY relname;
++regexp_replace
 

Bug#855599: unblock: postgresql-9.6/9.6.2-1

[Christoph Berg]

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

Please unblock package postgresql-9.6.

Debian/ part of the debdiff:

 2004 files changed, 69144 insertions(+), 30899 deletions(-)
diff -Nru postgresql-9.6-9.6.1/debian/changelog 
postgresql-9.6-9.6.2/debian/changelog
--- postgresql-9.6-9.6.1/debian/changelog   2016-11-02 11:04:52.0 
+0100
+++ postgresql-9.6-9.6.2/debian/changelog   2017-02-07 12:02:33.0 
+0100
@@ -1,3 +1,22 @@
+postgresql-9.6 (9.6.2-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream version.
+
++ Fix a race condition that could cause indexes built with CREATE INDEX
+  CONCURRENTLY to be corrupt (Pavan Deolasee, Tom Lane)
+
+  If CREATE INDEX CONCURRENTLY was used to build an index that depends on
+  a column not previously indexed, then rows inserted or updated by
+  transactions that ran concurrently with the CREATE INDEX command could
+  have received incorrect index entries.  If you suspect this may have
+  happened, the most reliable solution is to rebuild affected indexes
+  after installing this update.
+
+  * Update watch file to use https.
+
+ -- Christoph Berg <christoph.b...@credativ.de>  Tue, 07 Feb 2017 12:02:33 
+0100
+
 postgresql-9.6 (9.6.1-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru postgresql-9.6-9.6.1/debian/watch postgresql-9.6-9.6.2/debian/watch
--- postgresql-9.6-9.6.1/debian/watch   2015-08-28 19:09:45.0 +0200
+++ postgresql-9.6-9.6.2/debian/watch   2016-12-09 10:27:44.0 +0100
@@ -1,4 +1,4 @@
 version=3
 opts=uversionmangle=s/alpha/~alpha/;s/beta/~beta/;s/rc/~rc/ \
-ftp://ftp.postgresql.org/pub/source/v(9.6.*)/postgresql-(9.6.*).tar.bz2
+https://ftp.postgresql.org/pub/source/v(9.6.*)/postgresql-(9.6.*).tar.bz2
 

unblock postgresql-9.6/9.6.2-1.pgdg+1


Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#849865: jessie-pu: package postgresql-common/165+deb8u2

[Christoph Berg]

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

Hi,

I would like to upload postgresql-common/165+deb8u2 with the diff
quoted below to jessie. It's fixing a data-loss bug, and a security
issue. The issues are already addresses in unstable (both in 178).

Is that ok?

diff --git a/debian/changelog b/debian/changelog
index 0d6bd4f..1d583cb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+postgresql-common (165+deb8u2) jessie; urgency=medium
+
+  * pg_upgradecluster: Properly upgrade databases with non-login role owners.
+(Closes: #614374, #838812)
+  * pg_ctlcluster, t/020_create_sql_remove.t: Protect against symlink in
+/var/log/postgresql/ allowing the creation of arbitrary files elsewhere.
+Discovered by Dawid Golunski, thanks! (CVE-2016-1255)
+  * t/TestLib.pm: Cherry-pick program_ok() from master for use in
+t/020_create_sql_remove.t.
+
+ -- Christoph Berg <m...@debian.org>  Sun, 01 Jan 2017 18:48:30 +0100
+
 postgresql-common (165+deb8u1) jessie; urgency=medium
 
   * pg_upgradecluster: Set default dynamic_shared_memory_type = mmap.
diff --git a/pg_ctlcluster b/pg_ctlcluster
index 924f878..d2bb897 100755
--- a/pg_ctlcluster
+++ b/pg_ctlcluster
@@ -23,7 +23,7 @@ use warnings;
 use Getopt::Long;
 use POSIX qw/setsid dup2 setlocale LC_ALL :sys_wait_h/;
 use PgCommon;
-use Fcntl 'SEEK_SET';
+use Fcntl qw(SEEK_SET O_RDWR O_CREAT O_EXCL);
 
 my ($version, $cluster, $pg_ctl, $force);
 my (@postmaster_auxoptions, @pg_ctl_opts_from_cli);
@@ -394,17 +394,20 @@ if ($> == 0 && ! -e '/var/log/postgresql' &&
 
 # recreate missing log file
 if ($action ne 'stop' && $info{'logfile'} && ! -e $info{'logfile'}) {
-open L, '>', $info{'logfile'} or 
+if ($> == 0) { # drop privileges; this is important if logfile
+# was determined via an /etc/postgresql/.../log symlink
+change_ugid $info{'owneruid'}, $info{'ownergid'};
+}
+sysopen (L, $info{'logfile'}, O_RDWR|O_CREAT|O_EXCL) or
error 'Could not create log file ' . $info{'logfile'};
+close L;
 chmod 0640, $info{'logfile'};
-my $g;
+$< = $> = 0; # will silently fail if we were not root before, that's 
intended
+$( = $) = 0;
 if ($info{'owneruid'} < 500) {
-   $g = (getgrnam 'adm')[2];
-} else {
-   $g = $info{'ownergid'};
+my $g = (getgrnam 'adm')[2];
+chown $info{'owneruid'}, $g, $info{'logfile'} if (defined $g);
 }
-chown $info{'owneruid'}, $g, $info{'logfile'};
-close L;
 }
 
 # recreate /var/run/postgresql
diff --git a/pg_upgradecluster b/pg_upgradecluster
index 876a0af..04c59c6 100755
--- a/pg_upgradecluster
+++ b/pg_upgradecluster
@@ -433,18 +433,16 @@ if (!fork) {
error 'automatic upgrade of tablespaces is not supported';
}
 
-   # get list of databases, owners, and allowed connections
+   # get list of databases (value = datallowconn)
my %databases;
open F, '-|', $oldpsql, '-h', $oldsocket, '-p', $info{'port'}, 
'-F|', '-d', 'template1', '-Atc', 
-   'SELECT datname, datallowconn, 
pg_catalog.pg_encoding_to_char(encoding), usename FROM pg_database, pg_user 
WHERE datdba = usesysid' or 
+   'SELECT datname, datallowconn FROM pg_database' or
error 'Could not get pg_database list';
while () {
chomp;
-   my ($n, $a, $e, $o) = split '\|';
-   ($o) = $o =~ /^(.*)$/; # untaint
-   ($e) = $e =~ /^([\w_]+)$/; # untaint
-   $databases{$n} = [$a eq 't', $o, $e];
+   my ($n, $a) = split '\|';
+   $databases{$n} = ($a eq 't');
}
close F;
error 'could not get list of databases' if $?;
@@ -453,7 +451,7 @@ if (!fork) {
for my $db (keys %databases) {
next if $db eq 'template0';
 
-   unless (${$databases{$db}}[0]) {
+   unless ($databases{$db}) {
print "Temporarily enabling access to database $db\n";
(system $oldpsql, '-h', $oldsocket, '-p', $info{'port'}, '-q', 
'-d', 'template1', '-c', 
@@ -546,8 +544,8 @@ if (!fork) {
'-d', $db, '-c', 'ANALYZE') == 0 or
error 'Could not ANALZYE database';
 
-   unless (${$databases{$db}}[0]) {
-   print "Disabling access to database $db\n";
+   unless ($databases{$db}) {
+   print "Disabling access to database $db again\n";
(system $oldpsql, '-h', $oldsocket, '-p', $info{'port'}, '-q', 
'-d', 'template1', '-c', 
"BEGIN READ WRITE; UPDATE pg_database SET datallowconn = 
'f' where datname = '$db'; COMMIT") == 0 or
diff --git a/t/020_create_sql_remove.t b/t/020_create_sql_remove.t
index 457bf9a..f71b4cf 100644
--- a/t/020_create_sql_remove.t
+++ b/t/020_create_

Bug#827061: transition: openssl

[Christoph Berg]

Re: Kurt Roeckx 2016-09-16 <20160916054549.2wjl4xzb2eyg6...@roeckx.be>
> > do you expect the transition to be done for stretch?
> 
> I really would like to have it in stretch.  I don't want to have
> the same situtation like we had with 1.0.2 that didn't make it it
> to jessie.

Nod, thanks for confirming.

> > I'm asking because the PostgreSQL people want to know if they need to
> > add support for OpenSSL 1.1 in the older release branches (9.2 ..
> > 9.4), or if patching 9.5 .. 10 is enough for now.
> 
> I guess they want to provide binaries for all their releases on
> apt.postgresql.org?

That's exactly the reason, yes. (And "they" is me ;)

Christoph


signature.asc
Description: PGP signature

Bug#827061: transition: openssl

[Christoph Berg]

Re: Kurt Roeckx 2016-06-11 <20160611194259.ga6...@roeckx.be>
> > > If I'm ready to upload it to unstable, can I start this
> > > transition?  Are there things you want me to do?
> > 
> > Please upload to experimental first and let us know when that's happened.
> 
> It's in experimental already.  The test suite only fails
> on hurd, for some reason it's not finding the engine.  I still
> need to look at that.

Hi,

do you expect the transition to be done for stretch?

I'm asking because the PostgreSQL people want to know if they need to
add support for OpenSSL 1.1 in the older release branches (9.2 ..
9.4), or if patching 9.5 .. 10 is enough for now.

(Alternatively, would stretch have OpenSSL 1.0 next to 1.1? This seems
unlikely, but just to confirm?)

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#825533: jessie-pu: package postgresql-9.1/9.1.22-0+deb8u1

[Christoph Berg]

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

Hi,

please consider postgresql-9.1/9.1.22-0+deb8u1:

postgresql-9.1 (9.1.22-0+deb8u1) jessie; urgency=medium

  * New upstream release: No effective changes for PL/Perl, the version must
just be higher than the one in wheezy.

 -- Christoph Berg <christoph.b...@credativ.de>  Fri, 27 May 2016 16:03:59 +0200

Christoph


signature.asc
Description: PGP signature

Bug#825530: jessie-pu: package postgresql-9.4/9.4.8-0+deb8u1

[Christoph Berg]

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

Hi,

please consider postgresql-9.4/9.4.8-0+deb8u1:

postgresql-9.4 (9.4.8-0+deb8u1) jessie; urgency=medium

  * New upstream bugfix release.

 -- Christoph Berg <christoph.b...@credativ.de>  Fri, 27 May 2016 14:29:53 +0200

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#819912: jessie-pu: package postgresql-9.1/9.1.21-0+deb8u1

[Christoph Berg]

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

Hi,

I've uploaded postgresql-9.1/9.1.21-0+deb8u1 for inclusion into
jessie. As usual, that upload is needed to follow the
postgresql-9.1/9.1.21-0+deb7u1 upload in wheezy-pu (see #819805).


postgresql-9.1 (9.1.21-0+deb8u1) jessie; urgency=medium

  * New upstream version, relevant PL/Perl change:
+ Correctly handle empty arrays in plperl_ref_from_pg_array.

 -- Christoph Berg <m...@debian.org>  Sat, 02 Apr 2016 16:16:53 +0200


(The good news is that we won't be doing the plperl dance anymore in
future releases, tests have shown that PostgreSQL clusters are
upgradeable even without plperl.so present. I guess we could even
remove postgresql-(plperl-)9.1 from jessie if we adjusted the release
notes.)

Christoph

Bug#819805: wheezy-pu: package postgresql-9.1/9.1.21-0+deb7u1

[Christoph Berg]

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

Hi,

I've just uploaded postgresql-9.1/9.1.21-0+deb7u1 for inclusion in
Wheezy.

As in 9.4, there are no security fixes or major bugfixes, but given
that any future release including any of these would include the
9.1.21 fixes, I'd think uploading now makes sense.


postgresql-9.1 (9.1.21-0+deb7u1) wheezy; urgency=medium

  * New upstream bugfix release.

 -- Christoph Berg <m...@debian.org>  Sat, 02 Apr 2016 14:02:53 +0200


Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#819801: jessie-pu: package postgresql-9.4/9.4.7-0+deb8u1

[Christoph Berg]

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

Hi,

I've just uploaded postgresql-9.4/9.4.7-0+deb8u1 for inclusion in
Jessie 8.4.

There are no security fixes or major bugfixes, but given that any
future release including any of these would include the 9.4.7 fixes,
I'd think uploading now makes sense.


postgresql-9.4 (9.4.7-0+deb8u1) jessie; urgency=medium

  * New upstream bugfix release.
  * Remove obsolete .bzr-builddeb/default.conf.

 -- Christoph Berg <m...@debian.org>  Sat, 02 Apr 2016 13:22:58 +0200


Christoph


signature.asc
Description: PGP signature

Bug#819326: jessie-pu: package postgresql-common/165+deb8u1

[Christoph Berg]

Re: Adam D. Barratt 2016-03-26 <1459017534.2441.115.ca...@adam-barratt.org.uk>
> Control: tags -1 + confirmed
> 
> On Sat, 2016-03-26 at 19:07 +0100, Christoph Berg wrote:
> > +postgresql-common (165+deb8u1) jessie; urgency=medium
> > +
> > +  * pg_upgradecluster: Set default dynamic_shared_memory_type = mmap.
> > +(Closes: #784005, #812206)
> 
> This looks okay to me, thanks. Please feel free to upload, bearing in
> mind that the window for getting fixes into 8.4 closes this weekend.

It took me a few seconds to realize that 8.4 is *not* a PostgreSQL
version number here :)

Uploaded, thanks for the approval!

Christoph


signature.asc
Description: PGP signature

Bug#819326: jessie-pu: package postgresql-common/165+deb8u1

[Christoph Berg]

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

Hi,

I'd like to include the patch quoted below in jessie, would this be
ok?

diff --git a/debian/changelog b/debian/changelog
index 7751170..0d6bd4f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,24 @@
+postgresql-common (165+deb8u1) jessie; urgency=medium
+
+  * pg_upgradecluster: Set default dynamic_shared_memory_type = mmap.
+(Closes: #784005, #812206)
+
+This primarily avoids problems with upgrading existing clusters in a LXC
+container. As earlier PG versions did not have d_s_m_t, the upgraded
+postgresql.conf won't have this setting either, yielding the compiled-in
+default of 'posix' which doesn't work in LXC. Pick something else here to
+avoid that problem. Notably, it's important that this problem is fixed in
+pg_upgradecluster itself because working around the problem is hard as the
+upgrade will fail early without the possibility of manually fixing the
+config. (Newly created clusters do not have that problem because initdb
+probes for a method working in the given system.)
+
+  * t/040_upgrade.t: Skip testing pg_upgrade with datallowconn = f, it does
+not support that anymore as of May 2015.
+(Cherry-pick from master to allow testing the pg_upgradecluster fix)
+
+ -- Christoph Berg <m...@debian.org>  Sat, 26 Mar 2016 16:52:30 +0100
+
 postgresql-common (165) unstable; urgency=medium
 
   * Debconf translation updates, thanks!
diff --git a/pg_upgradecluster b/pg_upgradecluster
index db541be..876a0af 100755
--- a/pg_upgradecluster
+++ b/pg_upgradecluster
@@ -170,6 +170,11 @@ sub adapt_conffiles {
 
 if ($newversion >= '9.4') {
 deprecate \%c, 'krb_srvname', 'native krb5 authentication deprecated 
in favor of GSSAPI';
+# d_s_m_t defaults to 'posix', but that has various problems. Pick a 
safer variant here
+unless ($c{dynamic_shared_memory_type}) {
+PgCommon::set_conf_value $newversion, $cluster, 'postgresql.conf',
+'dynamic_shared_memory_type', 'mmap';
+}
 }
 }
 
diff --git a/t/040_upgrade.t b/t/040_upgrade.t
index 00c1c17..5edf305 100644
--- a/t/040_upgrade.t
+++ b/t/040_upgrade.t
@@ -32,8 +32,11 @@ is ((exec_as 'postgres', 'createuser nobody -D -R -s && 
createdb -O nobody test
 is ((exec_as 'nobody', 'psql test -c "CREATE TABLE phone (name varchar(255) 
PRIMARY KEY, tel int NOT NULL)"'), 
 0, 'create table');
 is ((exec_as 'nobody', 'psql test -c "INSERT INTO phone VALUES (\'Alice\', 
2)"'), 0, 'insert Alice into phone table');
-is ((exec_as 'postgres', 'psql template1 -c "UPDATE pg_database SET 
datallowconn = \'f\' WHERE datname = \'testnc\'"'), 
-0, 'disallow connection to testnc');
+SKIP: {
+skip 'datallowconn = f not supported with pg_upgrade', 1 if 
$upgrade_options =~ /upgrade/;
+is ((exec_as 'postgres', 'psql template1 -c "UPDATE pg_database SET 
datallowconn = \'f\' WHERE datname = \'testnc\'"'),
+0, 'disallow connection to testnc');
+}
 is ((exec_as 'nobody', 'psql testro -c "CREATE TABLE nums (num int NOT NULL); 
INSERT INTO nums VALUES (1)"'), 0, 'create table in testro');
 SKIP: {
 skip 'read-only not supported with pg_upgrade', 2 if $upgrade_options =~ 
/upgrade/;
@@ -195,14 +198,15 @@ SKIP: {
 skip 'upgrading databases with datallowcon = false not supported by 
pg_upgrade', 2 if $upgrade_options =~ /upgrade/;
 
 # Check connection permissions
+my $testnc_conn = $upgrade_options =~ /upgrade/ ? 't' : 'f';
 is_program_out 'nobody', 'psql -tAc "SELECT datname, datallowconn FROM 
pg_database ORDER BY datname" template1', 0,
-'postgres|t
+"postgres|t
 template0|f
 template1|t
 test|t
-testnc|f
+testnc|$testnc_conn
 testro|t
-', 'dataallowconn values';
+", 'dataallowconn values';
 }
 
 # check ACLs

Christoph


signature.asc
Description: PGP signature

Bug#814442: jessie-pu: package postgresql-9.1/9.1.20-0+deb8u1

[Christoph Berg]

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

Hi,

with today's postgresql-9.1 9.1.20-0+deb7u1 security update in wheezy,
the package version in wheezy is now greater than the one in jessie.
This no-change (in pl/perl) upload fixes that.

diff --git a/debian/changelog b/debian/changelog
index 75248e4..d0934de 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+postgresql-9.1 (9.1.20-0+deb8u1) jessie; urgency=medium
+
+  * New upstream release: No effective changes for PL/Perl, the version must
+just be higher than the one in wheezy.
+
+ -- Christoph Berg <christoph.b...@credativ.de>  Thu, 11 Feb 2016 15:47:54 
+0100
+
 postgresql-9.1 (9.1.19-0+deb8u1) jessie; urgency=medium
 
   * New upstream version, relevant PL/Perl change:


Thanks,
Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#796345: [Debian-ha-maintainers] Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Christoph Berg]

Re: Ferenc Wagner 2015-12-22 <874mfbfh6y@lant.ki.iif.hu>
> Emilio Pozuelo Monfort  writes:
> 
> > This is the last blocker for the perl transition. Packages should be
> > installable now in unstable. Please let us know if you make progress
> > with this or if you hit any blockers.
> 
> Short progress report: no blockers.
> 
> I encountered unexpected problems, but they are mostly solved by now.
> While waiting for the review of my sponsor, I'm doing QA tests.

pacemaker 1.1.13-1 is now in NEW.

Thanks to Feri for preparing this release!

Merry Christmas,
Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#801317: wheezy-pu: package postgresql-9.1/9.1.19-0+deb7u1

[Christoph Berg]

Re: Adam D. Barratt 2015-10-10 <1444502159.22375.10.ca...@adam-barratt.org.uk>
> This appears to have been rejected by dak:
> 
> adsb@franck:~$ cat 
> queue/reject/postgresql-9.1_9.1.19-0+deb7u1_source.changes.reason 
> 
> postgresql-9.1_9.1.19-0+deb7u1.dsc: Refers to non-existing file 
> 'postgresql-9.1_9.1.19-0+deb7u1.debian.tar.gz'
> Perhaps you need to include the file in your upload?

Interesting. No idea why the .dsc didn't get rebuilt (xz vs. gz).

Reuploaded now.

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 (0)21 61 / 46 43-187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

Bug#801317: wheezy-pu: package postgresql-9.1/9.1.19-0+deb7u1

[Christoph Berg]

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

Hi,

please consider postgresql-9.1/9.1.19-0+deb7u1 for the next wheezy
point release:

postgresql-9.1 (9.1.19-0+deb7u1) wheezy; urgency=medium

  * New upstream version.

+ Fix contrib/pgcrypto to detect and report too-short crypt() salts
  (Josh Kupershmidt)

  Certain invalid salt arguments crashed the server or disclosed a few
  bytes of server memory.  We have not ruled out the viability of attacks
  that arrange for presence of confidential information in the disclosed
  bytes, but they seem unlikely.  (CVE-2015-5288)

 -- Christoph Berg <christoph.b...@credativ.de>  Thu, 08 Oct 2015 14:30:41 +0200

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#801318: jessie-pu: package postgresql-9.1/9.1.19-0+deb8u1

[Christoph Berg]

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

Hi,

please consider postgresql-9.1/9.1.19-0+deb8u1 for the next jessie
point release:

postgresql-9.1 (9.1.19-0+deb8u1) jessie; urgency=medium

  * New upstream version, relevant PL/Perl change:
+ Fix plperl to handle non-ASCII error message texts correctly.

 -- Christoph Berg <christoph.b...@credativ.de>  Thu, 08 Oct 2015 15:17:23 +0200

As usual, this upload is to mirror an upload of postgresql-9.1 to
wheezy to keep the version number higher. (The good news is that
libperl is said to be coinstallable in the future so we will hopefully
not to have to do this versioning dance for jessie.)

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#788608: jessie-pu: package postgresql-9.1/9.1.18-0+deb8u1

[Christoph Berg]

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

9.1.18 is now out, two weeks after 9.1.17 (cf #787642):

postgresql-9.1 (9.1.18-0+deb8u1) jessie; urgency=medium

  * New upstream release: No effective changes for PL/Perl, the version must
just be higher than the one in wheezy.

 -- Christoph Berg m...@debian.org  Fri, 12 Jun 2015 18:57:57 +0200


Sorry for submitting is via the wrong bug in the first attempt, I got
lost in the series of retitles/clones. (About which I'm not entirely
innocent.)

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#788531: jessie-pu: package postgresql-9.4/9.4.4-0+deb8u1

[Christoph Berg]

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

Hi,

postgresql minor releases are just being released. Here's the new
package for jessie:

postgresql-9.4 (9.4.4-0+deb8u1) jessie; urgency=medium

  * New upstream version.
+ Fix possible failure to recover from an inconsistent database state
+ Fix rare failure to invalidate relation cache init file

 -- Christoph Berg m...@debian.org  Thu, 11 Jun 2015 20:35:19 +0200


Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#787636: jessie-pu: package postgresql-9.1/9.1.18-0+deb8u1

[Christoph Berg]

Control: retitle -1 jessie-pu: package postgresql-9.1/9.1.18-0+deb8u1

9.1.18 is now out:

postgresql-9.1 (9.1.18-0+deb8u1) jessie; urgency=medium

  * New upstream release: No effective changes for PL/Perl, the version must
just be higher than the one in wheezy.

 -- Christoph Berg m...@debian.org  Fri, 12 Jun 2015 18:57:57 +0200

(Not sure if I need to change any tags on this preexisting bug.)

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#788558: wheezy-pu: package postgresql-9.1/9.1.18-0+deb7u1

[Christoph Berg]

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

Here's the wheezy/9.1 part of the PostgreSQL release round:

postgresql-9.1 (9.1.18-0+deb7u1) wheezy; urgency=medium

  * New upstream version.
+ Fix rare failure to invalidate relation cache init file
  * Remove obsolete .bzr-builddeb/.

 -- Christoph Berg m...@debian.org  Thu, 11 Jun 2015 22:50:12 +0200


Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#787636: jessie-pu: package postgresql-9.4/9.4.3-0+deb8u1

[Christoph Berg]

Re: Adam D. Barratt 2015-06-03 1433354441.11603.12.ca...@adam-barratt.org.uk
  It'd be nice if at least the 9.4 package would make it into the next
  point release, #786874 is pretty nasty. (In wheezy, it was fixed for
  9.1 via a DSA update.)
 
 I have to admit that it's unclear to me why the 9.4 update for jessie
 wasn't released via an updated DSA, rather than a
 rare-as-hens-teeth(ish) p-u-freeze exception, given that the bug was
 introduced via the security archive in the first place.

Hi Adam,

the reasoning was that #786874 affects 9.1 even in the default install
(because of the SSL cert symlinks installed in the data directory), so
we cherry-picked the fixing upstream commit to release a -2 DSA
because we didn't want to wait for the upstream release.

For 9.4, the problem only manifests if you manually put unwritable
files into the data directory, but that situation is also pretty
common, like lost+found from mountpoints, or root-owned vim .swp
files.

Now upstream has released an updated version, including this fix,
along with 3 other minor points.

There is still a data-loss problem being worked on (which is half an
old bug, and half an incomplete fix in the last releases (but not a
regression)), so there will be another releases round in about two
weeks :( That will probably be targeting jessie-updates.


Re: Adam D. Barratt 2015-06-03 1433358799.11603.15.ca...@adam-barratt.org.uk
 In the interests of getting this fixed, I've (slightly unhappily)
 flagged the 9.4 package for acceptance. This is very much an exception,
 please do not rely on it happening next time. :-)

Thanks!

It's pretty unlikely that this scenario (regression in DSA with
re-release from upstream with yet more important fixes pending) will
happen right around the freeze again, so no worries ;)

 Given that we don't ship the affected code for 9.1 in Jessie, that will
 get processed after the point release.

Ok.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#787636: jessie-pu: package postgresql-9.4/9.4.3-0+deb8u1

[Christoph Berg]

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

Hi,

a new series of PostgreSQL minor releases is being released tomorrow.

jessie: 9.4 + 9.1 (plperl only)
wheezy: 9.1

postgresql-9.4 (9.4.3-0+deb8u1) jessie; urgency=medium

  * New upstream version:
Avoid failures while fsync'ing data directory during crash restart
(Abhijit Menon-Sen, Tom Lane; Closes: #786874)

 -- Christoph Berg christoph.b...@credativ.de  Wed, 03 Jun 2015 11:53:43 +0200

I'll be uploading the packages later tonight and also file the other
two unblock bugs.

It'd be nice if at least the 9.4 package would make it into the next
point release, #786874 is pretty nasty. (In wheezy, it was fixed for
9.1 via a DSA update.)

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature