Bug#738704: [Debian-ha-maintainers] Bug#738704: Bug#738704: closed by wf...@niif.hu (Ferenc Wágner) (Re: pacemaker: Segfault in libhbclient.so.1.0.0)

[Christoph Berg]

Re: Ferenc Wágner 2016-02-29 <87twkrydx9@lant.ki.iif.hu>
> Philipp Marek  writes:
> 
> > I'd just like to know why Heartbeat support isn't included anymore... yes, 
> > it won't do OCFS2 or GFS2, but in exchange it has been rock-solid for me.
> 
> Ah, I see.  No principal reason, just lack of manpower.  I'll be happy
> if we can properly maintain a single stack; we're not there yet.  What's
> the upstream status of Heartbeat, anyway?  Internet suggest it's
> deprecated and no longer developed, but maintained by Linbit.  Can you
> provide an update on that?  Also, if you can bring Heartbeat expertise
> into the Debian HA team, I've got nothing against compiling support into
> Pacemaker.

3.0.5 was released at least half a decade ago, but 3.0.6 is from last
autumn. I uploaded that a few weeks ago in the upload I did to get all
the references to the no-longer-built packages dropped.

I have no idea though if that was just a one-shot get-pending-changes-out
release, or if they are really maintaining it for the future.

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

Bug#816383: [Debian-ha-maintainers] Bug#816383: pcs: diff for NMU version 0.9.148-1.1

[Christoph Berg]

Re: Cédric Boutillier 2016-03-03 <20160303145124.GA507@esfahan>
> I've prepared an NMU for pcs (versioned as 0.9.148-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Hi Cédric,

thanks for the update! I've rescheduled for earlier release.

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


signature.asc
Description: PGP signature

Bug#806775: apt-get build-dep path/to/unpacked/source disagrees with dpkg-checkbuilddeps: difference in comment parsing

[Christoph Berg]

Re: Helmut Grohne 2015-12-01 <20151201054316.ga7...@alf.mars>
> I immediately went ahead and tried the "apt-get build-dep
> path/to/source" feature now available in unstable. It worked well for a
> fair number of packages but somehow it broke on libxdmcp. It installs
> its B-D just fine, except that dpkg-checkbuilddeps didn't agree with
> that. The latter claimed xmlto and w3m to be missing. Looking into the
> debian/control file of libxdmcp, one can see a comment (a line starting
> with a "#") in the middle of the Build-Depends field. The packages xmlto
> and w3m appear after that comment. So my guess is that apt treats this
> comment as the end of Build-Depends while dpkg doesn't. I think dpkg is
> right here and hope you agree.

I can confirm the "doesn't read B-D after a comment line" analysis.
Removing the comment made apt-get build-dep ./ work.

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


signature.asc
Description: PGP signature

Bug#808806: Split "Blocked (X)" into different statuses

[Christoph Berg]

Package: piuparts.debian.org
Severity: wishlist

Hi,

at the moment the status Blocked (X) is used for several different
problems:

* dependency failed testing
* dependency uninstallable
* dependency does not exist

In the piuparts column on DDPO, all these are shown as 'X'.

As a maintainer, I'd like to see only problems on my DDPO page that I
could do something about. That means I wouldn't normally care about
dependencies failing or being uninstallable (I could see that problem
when looking at the DDPO or piuparts page for that package), but I
would certainly care about my dependencies not being there at all
because then I need to fix my package.

Could we hence make "dependency does not exist" use a different
status? What about "Missing (M)"?

The plan would be not to show Waiting (W) and Blocked (X) on DDPO
anymore by default (or less scary, W looks a lot like Warning and X
like Bad ThinXs happening), so the remaining, effectively bad status
values would receive more attention from maintainers.[*]

(I can probably try to produce a patch, but given the status values
are likely used in a gazillion of places, I would probably break more
than someone familiar with the code.)

Thanks,
Christoph

[*] I've certainly started to treat Piuparts notifications on DDPO
with less priority personally because the SNR there isn't optimal.
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#801575: [Piuparts-devel] Bug#801575: Bug#801575: piuparts.d.o (piu-slave-bm-a) fails to start PostgreSQL

[Christoph Berg]

Re: Evgeni Golov 2015-10-13 <20151013211724.ga32...@dorei.kerker.die-welt.net>
> > > Thats right, that happens if there are several packages wanting
> > > postgresql are tested in parallel because the chroots have no network
> > > separation. These logs are frequently rescheduled and will eventually
> > > succeed.
> > 
> > while this is nice, we should try to avoid temporarily false negatives 
> > completly.
> 
> So "just" unshare(1) or systemd-nspawn(1) at the right moment would 
> help, right?

The NIH department has developed "newpid -n" (aka "newnet") as an
alternative lightweight variant.

Version 7 I'll be uploading in a minute supports "newpid -N newpidns1"
to join a network namespace that can allow network access (plain
"unshare -n" doesn't even have localhost by default). I'm using that
for simple separation of several testsuites running in parallel in the
apt.postgresql.org Jenkins setup. "newpid -N ... piuparts" should run
pretty transparently with that.

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


signature.asc
Description: PGP signature

Bug#801575: [Piuparts-devel] Bug#801575: Bug#801575: piuparts.d.o (piu-slave-bm-a) fails to start PostgreSQL

[Christoph Berg]

Re: Holger Levsen 2015-12-23 <201512231148.51484.hol...@layer-acht.org>
> sounds cool! do you plan to maintain this in jessie-bpo too?

If it actually gets used, I can do that, sure. (For my own purposes
I'm self-hosting it on apt.pg.o.)

Also welcome would be feedback on how to set up namespaced networking
automatically, without introducing any security problems (it allows
all users to run it and uses CAP_SYS_ADMIN and CAP_NET_ADMIN to work).

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#809764: [Debian-ha-maintainers] Bug#809764: libqb6-dev and libqb-dev: error when trying to install together

[Christoph Berg]

Re: Herbert Fortes (hpfn) 2016-01-04 <5689ac0b.4050...@ig.com.br>
> >This is a serious bug as it makes installation fail, and violates
> >sections 7.6.1 and 10.1 of the policy. An optimal solution would
> >consist in only one of the packages installing that file, and renaming
> >or removing the file in the other package. Depending on the
> >circumstances you might also consider Replace relations or file
> >diversions. If the conflicting situation cannot be resolved then, as a
> >last resort, the two packages have to declare a mutual
> >Conflict. Please take into account that Replaces, Conflicts and
> >diversions should only be used when packages provide different
> >implementations for the same functionality.
> 
> As I understand, 'Conflicts' can be a solution. The packages
> are for complete different use. And they are *-dev packages.

Policy says Conflicts should be avoided if the packages are doing
something different. It would be bad user experience if a system
running pacemaker/corosync couldn't have the webcamoid stuff installed
in parallel.

Though given the problem is only between -dev packages, I'd guess
using Conflicts would be okayish.

As webcamoid is the newer package, the problem should probably first
fixed on that side. Herbert, can you arrange that?

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


signature.asc
Description: PGP signature

Bug#809764: [Debian-ha-maintainers] Bug#809764: libqb6-dev and libqb-dev: error when trying to install together

[Christoph Berg]

Re: Herbert Fortes 2016-01-04 
<20160104143601.f6eaed358afd42577db72...@ig.com.br>
> > I agree that webcamoid is who should be adapted.
> > 
> > Using 'Conflicts' is the easy way for me. I'm not sure
> > in how to put the file in something like /usr/lib/*/webcamoid/
> > (it was suggested). How do I do to the file be found.
> > 
> 
> I have this on Qb/commons.pri:
> isEmpty(PREFIX): PREFIX = /usr
> isEmpty(EXECPREFIX): EXECPREFIX = $${PREFIX}
> isEmpty(LIBDIR): LIBDIR = $${EXECPREFIX}/lib
> 
> And in debian/rules:
> "LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)"
> 
> Is the search recursive ?

If there are "external" users of that library, you need to keep it in
/usr/lib or /usr/lib/$triplet.

If there's only "internal" users like plugins built from the same
source or the like, you could move it to a sub directory and then use
linker magic (rpath, etc) to point the loader there, but that's all
going to be a maintenance burden.

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


signature.asc
Description: PGP signature

Bug#811248: Error in manpage: --arch should be --deb-native-arch

[Christoph Berg]

Package: dose-builddebcheck
Version: 4.0.2-2
Severity: normal

Hi,

I'm just working on using the dose tools to test installability of the
packages on apt.postgresql.org. This will prove very useful to track
e.g. if I need to recompile something there because perl or python
just changed sonames in sid. Thanks for this great tool suite!

Now for the bug: dose-builddebcheck(1), under EXAMPLES:

dose-builddebcheck -v -f -e --arch amd64 \

That should be --deb-native-arch=amd64.

Also, the manpage title is BUILDCHECK(1).

Thirdly, the manpage doesn't mention that dose-builddebcheck is able
to read compressed Sources.gz files. That could maybe save some people
some decompression shell scripts.

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


signature.asc
Description: PGP signature

Bug#757770: RFH: pgadmin3 -- graphical administration tool for PostgreSQL

[Christoph Berg]

Re: Denis Briand 2016-01-15 <20160115201632.GA27428@emachines>
> Hello Christoph,
> 
> Any volunteer?
> I could help you if you are OK.
> I could start by bug triage.
> 
> I use pgadmin3 for my IT studies and I'm debian maintainer:
> https://qa.debian.org/developer.php?login=debian%40denis-briand.fr

Hi Denis,

as said on the mailing list and IRC, thanks, and welcome!

Christoph
-- 
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#811567: Support reading multiple patterns from file

[Christoph Berg]

Package: dctrl-tools
Version: 2.24-1
Severity: wishlist

Hi,

it would be nice if grep-dctrl supported -f --file like grep:

  -f FILE, --file=FILE
 Obtain patterns from FILE, one per line.  The empty file contains
 zero patterns, and therefore matches nothing.

My use case is that I have a list of package names that I want to
extract from a Packages file (-P --file=pkg.list), and inversely, want
to remove from a Packages file (-P --not --file=pkg.list). At the
moment I have to resort to ugly for loops in shell to invoke
grep-dctrl N times, or try to construct a regexp pattern to match the
list of package names at onces, which isn't handy to do in shell
either.

(An alternative solution would be to allow --pattern to be passed
multiple times. I guess if either is implemented, the other isn't much
extra effort.)

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


signature.asc
Description: PGP signature

Bug#790422: Parsing.Parse_error

[Christoph Berg]

Re: Johannes Schauer 2015-07-01 <20150701114957.2789.95115@hoothoot>
> Hi,
> 
> Quoting Ralf Treinen (2015-06-30 19:22:43)
> > On Mon, Jun 29, 2015 at 03:29:51PM +0200, Johannes Schauer wrote:
> > 
> > > As for the second problem (the empty Packages file) I was annoyed by this
> > > myself for a long time and would like to get to know a use case where an
> > > empty input file would make sense. Currently I'm working around this by
> > > conditionally only running dose3 in my scripts when the input is not empty
> > > but I'd like to get rid of these checks. So I'm curious: what is your use
> > > case to use an empty Packages file?
> > 
> > A possible use case for having one empty input file (along with some others
> > that are not empty) is that a file is generated by a script. For instance,
> > you might have as background all the packages in your distribution, and a
> > script that creates pseudo-packages implementing that you want to have
> > certain packages installed thogether while some others are required to be 
> > not
> > installed.

My use case is that I have postgresql-9.{0..6} on apt.postgresql.org,
which are all separate source packages building a host of
postgresql-9.X binaries with different names. These go to the main
component in the repository. However, all these source packages build
libpq5.deb as well, and only one of these (for the latest stable
branch) can go to main. The other libpq5.deb versions are redirected
to components called "9.X".

On the reverse side that means that the 9.X component corresponding to
the latest stable branch is empty. (I can't just disable it because of
symmetry reasons in the config, and because it will get filled if the
stable branch is upgraded to 9.X+1.)


> Pietro just fixed this in git master \o/
> 
> So now empty input files will just represent a package list of zero length :)

Long story, but that's the real-world example here. In fact I'm
considering upgrading the apt.pg.o build host to stretch just because
of this bugfix, and because a backport of the current dose-debcheck
version to jessie looks too hard.

Christoph

PS: I think this bug can be closed now?
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#811569: More forgiving parser on bad input fields

[Christoph Berg]

Package: dose-distcheck
Version: 4.0.2-2
Severity: normal

Ubuntu wily and trusty's "universe" Packages files have a weird python
header for python-tempest:

Package: python-tempest
[...]
Description: Openstack integration test suite
Python_version: 2.7
[...]

dose-debcheck doesn't like it:

$ dose-debcheck -v -f -e 
/home/chroot/wily-amd64/var/lib/apt/lists/de.archive.ubuntu.com_ubuntu_dists_wily_universe_binary-amd64_Packages
(I)StdLoaders: Parsing and normalizing...
(I)Packages: Parsing Packages file 
/home/chroot/wily-amd64/var/lib/apt/lists/de.archive.ubuntu.com_ubuntu_dists_wily_universe_binary-amd64_Packages...
Fatal error in module common/format822.ml: 
 Parse error lines 700601:0--700601:1:
unexpected RFC 822 token : 'P'

As the header is irrelevant to the installability problem, it would be
nice if the tools would just ignore the field. At the moment I'm
working around the problem using sed -e 's/^Python_/Python-/'.

(Not sure if this is a bug or just wishlist, filing as normal as apt
and friends seem to work just fine with this Packages file.)

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


signature.asc
Description: PGP signature

Bug#812202: dose-distcheck, dose-builddebcheck: --exclude option

[Christoph Berg]

Source: dose3
Severity: wishlist

Hi,

it would be nice if there was an --exclude counterpart to the existing
--checkonly option that excludes the named packages from being
checked.

My use case is that in my repositories I have some packages that
require backports to be installed, and I would like to do this:

dose-(build)debcheck debian_main_binaries my_repo_binaries/sources --exclude 
'a, b, c'
dose-(build)debcheck debian_main_binaries debian_backports_binaries 
my_repo_binaries/sources --checkonly 'a, b, c'

I'm currently working around by filtering the package lists with
grep-dctrl on the fly, but the tempfiles handling is annoying.

(--checkonly-file packagelist.txt and --exlude-file could maybe also
make sense to have, where packagelist.txt has one package name per
line.)

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

Bug#812203: dose-deb-coinstall mentioned as "dose-coinstall" in dose-extra description

[Christoph Berg]

Package: dose-extra
Version: 4.1-3
Severity: minor

Hi,

dose-extra's Description mentions the dose-deb-coinstall binary as
"dose-coinstall". Of course I tried the wrong name first... ;)

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

Bug#811136: FTBFS: debian/control needs updating from debian/control.in

[Christoph Berg]

Control: tags -1 upstream
Control: retitle -1 Incompatible with PostgreSQL 9.5

I've updated the package to 1.1.13 (found on github, released April 2015),
and tweaked bin/Makefile to support 9.5. Unfortunately this isn't enough:

--- 109,127 
  -- do reorg
  --
  \! pg_reorg --dbname=contrib_regression --no-order
! Segmentation fault (core dumped)
  \! pg_reorg --dbname=contrib_regression

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


signature.asc
Description: PGP signature

Bug#790422: Parsing.Parse_error

[Christoph Berg]

Re: Mehdi Dogguy 2016-01-21 <696fb80d6c0023c5e54ecfb56e670...@dogguy.org>
> Updated patch, without the changes in "applications/distcheck.ml".

Hi Mehdi,

thanks for your efforts. I'm afraid backporting extlib isn't trivial:

dose3
  -> librpm-dev (>= 4.12) already in jessie-backports
  -> ocamlgraph-1.8.6 backporting was ok
  -> extlib-1.7.0
 -> findlib-1.5.5
-> ocaml-nox (>= 4.02.1) ... at which point I gave up :(

I have a working setup with the dose3 jessie version now, it's just
that the shell scripts are uglier than they could be. I'll keep
looking forward to stretch. :)

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


signature.asc
Description: PGP signature

Bug#772519: closed by Christoph Berg (Re: Bug#772519: phppgadmin: During the process of install it removed everything from debian)

[Christoph Berg]

Re: Jowanderly Rodríguez 2014-12-13 

> Sure.
> Here they are

Hi,

I've tried to make sense of the logs, but unfortunately they don't say
anything about why it started removing stuff. It looks like all of
gnome got removed, but I don't see any problem with gnome when I try
to install phppgadmin here.

My bet would be that you have (had?) some old or non-standard package
installed that somehow cross-depends on a low-level gnome lib but
conflicts with something phppgadmin needs which then made all these
other packages go away. There's nothing obvious in the logs about
that, though.

Sorry, I'm afraid there's nothing I can do here...

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


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

Bug#773740: unblock: postgresql-9.4/9.4.0-1

[Christoph Berg]

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

Please unblock package postgresql-9.4. This is the first production
version of the package, namely version 9.4.0.

The function PQhostaddr got removed since rc1, but as that was new in
the 9.4 series, it is very unlikely that there are any users of it out
there. That was also upstream's reasoning for making such a change
post-rc, and indeed, sources.debian.net doesn't know any source with
that symbol.

unblock postgresql-9.4/9.4.0-1

Debian part of the changes:

diff -Nru postgresql-9.4-9.4~rc1/debian/changelog 
postgresql-9.4-9.4.0/debian/changelog
--- postgresql-9.4-9.4~rc1/debian/changelog 2014-11-20 14:51:11.0 
+0100
+++ postgresql-9.4-9.4.0/debian/changelog   2014-12-17 22:21:24.0 
+0100
@@ -1,3 +1,10 @@
+postgresql-9.4 (9.4.0-1) unstable; urgency=medium
+
+  * 9.4 released.
+  * libpq5.symbols: PQhostaddr removed; it was new in 9.4.
+
+ -- Christoph Berg   Wed, 17 Dec 2014 22:21:22 +0100
+
 postgresql-9.4 (9.4~rc1-1) unstable; urgency=medium
 
   * First 9.4 RC release.
diff -Nru postgresql-9.4-9.4~rc1/debian/libpq5.symbols 
postgresql-9.4-9.4.0/debian/libpq5.symbols
--- postgresql-9.4-9.4~rc1/debian/libpq5.symbols2014-11-20 
14:51:11.0 +0100
+++ postgresql-9.4-9.4.0/debian/libpq5.symbols  2014-12-14 21:03:54.0 
+0100
@@ -62,7 +62,6 @@
  PQgetssl@Base 0
  PQgetvalue@Base 0
  PQhost@Base 0
- PQhostaddr@Base 9.4~
  PQinitOpenSSL@Base 8.4~
  PQinitSSL@Base 0
  PQinstanceData@Base 8.4~

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


signature.asc
Description: Digital signature

Bug#773745: unblock: postgresql-common/164

[Christoph Berg]

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

Please unblock package postgresql-common.

Version 164 has a fix for the init script, as well as a few tweaks to
really support jessie in our "supported-versions" script. The debdiff
below has detailed comments about the changes.

unblock postgresql-common/164

diff -Nru postgresql-common-163/debian/changelog 
postgresql-common-164/debian/changelog
--- postgresql-common-163/debian/changelog  2014-10-26 12:05:03.0 
+0100
+++ postgresql-common-164/debian/changelog  2014-12-17 20:00:07.0 
+0100
@@ -1,3 +1,18 @@
+postgresql-common (164) unstable; urgency=medium
+
+  * Init script: Always create /var/run/postgresql on start.
+(Closes: #772824)
+  * Debconf translation updates, thanks!
++ pt by Ricardo Silva. (Closes: #767399)
+  * t/100_upgrade_scripts.t: Incompatible with eatmydata, remove from
+LD_PRELOAD when detected.
+  * t/170_extensions.t: Catch warning with chkpass on 9.5.
+  * debian/supported-versions: Support jessie in backports and
+apt.postgresql.org, with 9.4 as default.
+  * pgdg/apt.postgresql.org.sh: Support jessie.
+
+ -- Christoph Berg   Wed, 17 Dec 2014 20:00:04 +0100
+
 postgresql-common (163) unstable; urgency=medium
 
   [ Martin Pitt ]


The next two hunks introduce a function create_socket_directory to fix
#772824:

diff -Nru postgresql-common-163/debian/init.d-functions 
postgresql-common-164/debian/init.d-functions
--- postgresql-common-163/debian/init.d-functions   2014-07-26 
18:48:05.0 +0200
+++ postgresql-common-164/debian/init.d-functions   2014-12-13 
21:14:28.0 +0100
@@ -51,17 +51,19 @@
 return $status
 }
 
-# start all clusters of version $1
-# output according to Debian Policy for init scripts
-start() {
-# create socket directory
+# create /var/run/postgresql
+create_socket_directory() {
 if [ -d /var/run/postgresql ]; then
chmod 2775 /var/run/postgresql
 else
install -d -m 2775 -o postgres -g postgres /var/run/postgresql
[ -x /sbin/restorecon ] && restorecon -R /var/run/postgresql || true
 fi
+}
 
+# start all clusters of version $1
+# output according to Debian Policy for init scripts
+start() {
 do_ctl_all start "$1" "Starting PostgreSQL $1 database server"
 }
diff -Nru postgresql-common-163/debian/postgresql-common.postgresql.init 
postgresql-common-164/debian/postgresql-common.postgresql.init
--- postgresql-common-163/debian/postgresql-common.postgresql.init  
2013-04-26 10:43:40.0 +0200
+++ postgresql-common-164/debian/postgresql-common.postgresql.init  
2014-12-13 21:14:28.0 +0100
@@ -28,6 +28,9 @@
 
 case "$1" in
 start|stop|restart|reload)
+if [ "$1" = "start" ]; then
+create_socket_directory
+fi
if [ -z "`pg_lsclusters -h`" ]; then
log_warning_msg 'No PostgreSQL clusters exist; see "man 
pg_createcluster"'
exit 0

i18n updated, contents omitted:

diff -Nru postgresql-common-163/debian/po/pt.po 
postgresql-common-164/debian/po/pt.po
--- postgresql-common-163/debian/po/pt.po   2014-05-20 11:52:01.0 
+0200
+++ postgresql-common-164/debian/po/pt.po   2014-11-08 16:51:50.0 
+0100


Set 9.4 as default, and recognize jessie as Debian version:
(The second and third hunks only concern the pgdg packages on
apt.postgresql.org, so are a no-op on Debian.)

diff -Nru postgresql-common-163/debian/supported-versions 
postgresql-common-164/debian/supported-versions
--- postgresql-common-163/debian/supported-versions 2014-10-26 
12:03:02.0 +0100
+++ postgresql-common-164/debian/supported-versions 2014-12-17 
19:58:16.0 +0100
@@ -47,7 +47,7 @@
 . /usr/share/postgresql-common/pgcommon.sh
 fi
 
-DEFAULT="9.3"
+DEFAULT="9.4"
 
 # functions
 
@@ -134,8 +134,11 @@
 7|7.*) # Wheezy
 /bin/echo -e "9.1"
 ;;
+8|8.*) # Jessie
+/bin/echo -e "9.4"
+;;
 testing | unstable)
-/bin/echo -e "9.3"
+/bin/echo -e "9.4"
 ;;
 *)
 echo "supported-versions: WARNING: Unknown Debian release: $1" >&2
@@ -146,11 +149,11 @@
 
 pgdg() {
 case $1 in
-testing | unstable | 14.10)
+testing | unstable)
 /bin/echo -e "8.4\n9.0\n9.1\n9.2\n9.3\n9.4" # 9.4 default
 ;;
 *)
-/bin/echo -e "8.4\n9.0\n9.1\n9.2\n9.4\n9.3" # 9.3 default
+/bin/echo -e "8.4\n9.0\n9.1\n9.2\n9.3\n9.4" # 9.4 default
 ;;
 esac
 }
diff -Nru postgresql-common-163/pgdg/apt.postgresql.org.sh 
postgresql-common-164/pgdg/apt.postgresql.org.sh
--- postgresql-common-163/pgdg/a

Bug#773754: reverse recommends order

[Christoph Berg]

Package: slony1-2-bin
Version: 2.2.1-1
Severity: normal

The ordering of the postgresql-x.y-slony1-2 modules in Recommends
should be reversed, or else this happens:

# apt-get install slony1-2-bin/trusty-pgdg
Selected version '2.2.2-1.pgdg14.04+1' (PostgreSQL for Debian/Ubuntu 
repository:trusty-pgdg [amd64]) for 'slony1-2-bin'
The following extra packages will be installed: libdbd-pg-perl libdbi-perl 
libopts25 ntp postgresql-8.4 postgresql-8.4-slony1-2 postgresql-client-8.4

Package: slony1-2-bin
Version: 2.2.1-1
Recommends: postgresql-8.4-slony1-2 | postgresql-9.0-slony1-2 | 
postgresql-9.1-slony1-2 | postgresql-9.2-slony1-2 | postgresql-9.3-slony1-2, 
libdbd-pg-perl, ntp | openntpd | chrony

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


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

Bug#771184: unblock: postgresql-9.4/9.4~rc1-1.pgdg+1

[Christoph Berg]

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

Please unblock package postgresql-9.4. This is now finally an RC
version of the 9.4 series. The PostgreSQL people were planning to
release 9.4.0 next week, but this hasn't been finalized yet, so it
might well be a bit later.

I'm sorry my original plan of putting 9.4 beta into testing early so
we'd have a released version in there by the time of the freeze didn't
work out nicely. The code quality should be pretty high, though,
there's a ton of new tests and test suites in 9.4, and needless to
say, the package also passes our own postgresql-common testsuite [1].
The catalog version number change between beta2 and beta3 was
unexpected, too, leading to a number of complaints about having to
dump-reload the database, which we addressed by detailed instructions.
In previous releases, beta2 was the last version to do the catversion
bump. The lesson learned is of course not to include beta versions in
testing again, even if they look stable.

[1] http://ci.debian.net/packages/p/postgresql-9.4/unstable/amd64/

unblock postgresql-9.4/9.4~rc1-1.pgdg+1

(In the diff below, I'm only including the debian/ part, as the number
of files changed upstream is fairly high.)

--- postgresql-9.4-9.4~beta3/debian/changelog   2014-10-16 09:32:39.0 
+0200
+++ postgresql-9.4-9.4~rc1/debian/changelog 2014-11-20 14:51:11.0 
+0100
@@ -1,3 +1,11 @@
+postgresql-9.4 (9.4~rc1-1) unstable; urgency=medium
+
+  * First 9.4 RC release.
+  * Update psql call in dump-reload instructions.
+  * Reenable 010_pg_basebackup.t tests, fixed upstream.
+
+ -- Christoph Berg   Tue, 18 Nov 2014 09:49:04 +0100
+
 postgresql-9.4 (9.4~beta3-3) unstable; urgency=medium
 
   * Temporarily disable failing test in 010_pg_basebackup.t.
--- postgresql-9.4-9.4~beta3/debian/patches/99-debug-taptests   2014-10-16 
09:31:51.0 +0200
+++ postgresql-9.4-9.4~rc1/debian/patches/99-debug-taptests 1970-01-01 
01:00:00.0 +0100
@@ -1,13 +0,0 @@
 a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
-+++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
-@@ -68,8 +68,9 @@ command_ok(
-   "-T$tempdir/tblspc1=$tempdir/tbackup/tblspc1" ],
-   'plain format with tablespaces succeeds with tablespace mapping');
- ok(-d "$tempdir/tbackup/tblspc1", 'tablespace was relocated');
-+system "ls -al $tempdir/pgdata/pg_tblspc";
- opendir(my $dh, "$tempdir/pgdata/pg_tblspc") or die;
--ok( (   grep
-+ok( 1 || (   grep
-   {
-   -l "$tempdir/backup1/pg_tblspc/$_"
- and readlink "$tempdir/backup1/pg_tblspc/$_" eq
--- postgresql-9.4-9.4~beta3/debian/patches/series  2014-10-16 
09:30:32.0 +0200
+++ postgresql-9.4-9.4~rc1/debian/patches/series2014-11-20 
14:51:11.0 +0100
@@ -6,4 +6,3 @@
 54-debian-alternatives-for-external-tools.patch
 64-pg_upgrade-sockdir
 70-history
-99-debug-taptests
--- postgresql-9.4-9.4~beta3/debian/postgresql-9.4.NEWS 2014-10-16 
09:22:15.0 +0200
+++ postgresql-9.4-9.4~rc1/debian/postgresql-9.4.NEWS   2014-11-20 
14:51:11.0 +0100
@@ -24,8 +24,7 @@
   $ pg_createcluster 9.4 main
   $ cp 9.4-main.config/* /etc/postgresql/9.4/main
   $ pg_ctlcluster 9.4 main start
-  $ zcat 9.4-main.dump.gz | psql -q
+  $ zcat 9.4-main.dump.gz | psql -q --cluster 9.4/main
   $ rm -rf 9.4-main.config 9.4-main.dump.gz
 
-
  -- Christoph Berg   Tue, 14 Oct 2014 16:33:09 
+0200
--- postgresql-9.4-9.4~beta3/debian/postgresql-9.4.preinst  2014-10-16 
09:22:15.0 +0200
+++ postgresql-9.4-9.4~rc1/debian/postgresql-9.4.preinst2014-11-20 
14:51:11.0 +0100
@@ -31,7 +31,7 @@
 $ pg_createcluster 9.4 main
 $ cp 9.4-main.config/* /etc/postgresql/9.4/main
 $ pg_ctlcluster 9.4 main start
-$ zcat 9.4-main.dump.gz | psql -q
+$ zcat 9.4-main.dump.gz | psql -q --cluster 9.4/main
 $ rm -rf 9.4-main.config 9.4-main.dump.gz
 
 EOF


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


signature.asc
Description: Digital signature

Bug#771184: unblock: postgresql-9.4/9.4~rc1-1

[Christoph Berg]

Control: retitle -1 unblock: postgresql-9.4/9.4~rc1-1

Re: To Debian Bug Tracking System 2014-11-27 
<20141127115117.ga10...@msg.df7cb.de>
> unblock postgresql-9.4/9.4~rc1-1.pgdg+1

Err, of course that should have been:

unblock postgresql-9.4/9.4~rc1-1

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


signature.asc
Description: Digital signature

Bug#767901: xymonclient-linux.sh is missing ROOTFS

[Christoph Berg]

Re: To Debian Bug Tracking System 2014-11-03 
<20141103115859.ga10...@msg.df7cb.de>
> In xymonclient-linux.sh the line
> 
> ROOTFS=`readlink -m /dev/root`
> 
> got lost during the last hobbitclient-tmpfs patch update.
> 
> It needs to be put back or else the client disk reports are garbled:
> 
> Filesystem 1024-blocks  Used 
> Available Capacity Mounted on
>   721616405324
> 279636  60% /
> udev 10240 0  
>10240   0% /dev
> 
> The second line there is missing the device name at the beginning.

The problem is actually more involved than that, once the / entry is
fixed, it conflicts with the second / mount that most Debian systems
have:

FilesystemSize  Used Avail Use% Mounted on
rootfs9.2G  4.3G  4.5G  50% /
/dev/mapper/feynman-root  9.2G  4.3G  4.5G  50% /

That makes the RRD files produced contain gaps.

I'll add a trivial patch that ignores the second / mount.

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


signature.asc
Description: Digital signature

Bug#863256: Enable dtrace

[Christoph Berg]

Package: postgresql-10
Version: 10~beta1-1
Severity: wishlist

We should think about --enable-dtrace.

Asked about by sebl on #postgresql-apt.

Christoph

Bug#862719: resource-agents: pgsql RA needs update for default stretch Postgres version

[Christoph Berg]

Re: Ferenc Wágner 2017-05-23 <87wp98gfv3@lant.ki.iif.hu>
> Hi Christoph,
> 
> You seem to have stakes with PostgreSQL and also upload resource-agents
> now and then: have you got plans for dealing with this issue?

Hi Feri,

basically yes, but in real life I was/am busy with other stuff.
I'll try to allocate some cycles to it over the weekend.

Christoph

Bug#863616: dacs: effectively built with DACS_HOME=/usr => violates FHS

[Christoph Berg]

Control: severity -1 important

Re: Jonas Smedegaard 2017-05-29 
<149605453260.7326.14516673213625304...@auryn.jones.dk>
> Quoting Jonas Smedegaard (2017-05-29 12:35:02)
> > Upstream autoconf oddly ties the --prefix option with a custom - 
> > --dacs_home option which gets hardwired into the installed tools and 
> > is a root directory for both static and variable parts.
> > 
> > dacs 1.4.38a-1 sets --prefix which effectively tells the build 
> > routines to use /usr as the root of both binaries, configuration files 
> > (e.g. debugging hint file debug_dacs_acs), admin-editable web content 
> > (dtds) and variable data (e.g. a sequence file).
> > 
> > In other words, setting --prefix=/usr violates FHS!  Weird, yes.
> 
> It seems like upstream warned about the oddity: When setting --prefix to 
> a short path, the build routines apparently spews this:

Hi Jonas,

I definitely agree that this is pretty weird should likely be fixed,
but I don't think that the bug is RC - the package works if we get the
SSL woes sorted out, so I'm downgrading to important. We can sort this
out for buster.

> > The prefix path ("$prefix") really should specify a"
> > directory name of the form "/blah/blah/.../dacs*",
> > such as /usr/local/dacs or /usr/local/dacs-xxx.
> > If you insist on using this prefix, please rerun configure with
> > the --disable-prefix-check option
> 
> ...except the package silences that warning by use of 
> --disable-prefix-check :-/

To be revisited, yes.

Christoph

Bug#863395: ssl_hook_Fixup needed? (fwd)

[Christoph Berg]

- Forwarded message from Barry Brachman  -

Date: Sun, 28 May 2017 12:35:44 -0700
From: Barry Brachman 
Reply-to: barry.brach...@gmail.com
To: Christoph Berg 
Subject: Re: ssl_hook_Fixup needed?


Hi Christoph --

>Debian has again run into the "undefined symbol: ssl_hook_Fixup"
>problem. Historically, we've simply been removing the function call
>and I'm not aware of any problems with the instances we are running at
>a customer and on debian.org.
>
>I have to admit though that I don't have any idea what that code is
>supposed to be doing. Is it ok to remove it? After all, it's a
>non-exported private function in openssl.

This problem has shown up from time to time, although I don't see it
on my development system anymore.

It is mentioned in dacs.install(7) along with some solutions.
https://dacs.dss.ca/man/dacs.install.7.html

The call to ssl_hook_Fixup (see Apache's modules/ssl/ssl_engine_kernel.c)
has been in DACS for a very long time.  That function call from
mod_auth_dacs.c appears to ensure that SSL/TLS environment variables for an
HTTP request have been initialized so that DACS can export them to
dacs_acs(8) so that access control rules can inspect them if they desire.
https://dacs.dss.ca/man/dacs_acs.8.html

If you make an SSL/TLS request to a DACS wrapped resource, such as
dacs_prenv(8), you should see a large number of environment variables
associated with SSL/TLS processing.
https://dacs.dss.ca/man/dacs_prenv.8.html
(I'll paste some sample output at the end of this.)

So if you remove the function call I'm not sure if those variables will
still be available to mod_auth_dacs at that instant.  It may depend on some
random processing order within Apache.  But if you don't care about the
ability to inspect these variables you can give it a try.


>Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863395
>
>Patch: https://anonscm.debian.org/cgit/collab-maint/dacs.git/tree/debian/patch
> es/ssl_hook_Fixup

I hope this helps.  Let me know if you have anymore questions.

Barry


SSL_CIPHER="ECDHE-RSA-AES128-GCM-SHA256"
SSL_CIPHER_ALGKEYSIZE="128"
SSL_CIPHER_EXPORT="false"
SSL_CIPHER_USEKEYSIZE="128"
SSL_CLIENT_A_KEY="rsaEncryption"
SSL_CLIENT_A_SIG="sha256WithRSAEncryption"
SSL_CLIENT_CERT="-BEGIN CERTIFICATE-
MIIE+jCCA+KgAwIBAgIBGTANBgkqhkiG9w0BAQsFADCBpTELMAkGA1UEBhMCQ0Ex
...
-END CERTIFICATE-
"
SSL_CLIENT_CERT_RFC4523_CEA="{ serialNumber 25, issuer 
rdnSequence:"CN=Distributed Systems Software Certificate 
Authority,O=Distributed Systems Software Inc.,L=Victoria,ST=British 
Columbia,C=CA" }"
SSL_CLIENT_I_DN="CN=Distributed Systems Software Certificate 
Authority,O=Distributed Systems Software Inc.,L=Victoria,ST=British 
Columbia,C=CA"
SSL_CLIENT_I_DN_C="CA"
SSL_CLIENT_I_DN_CN="Distributed Systems Software Certificate Authority"
SSL_CLIENT_I_DN_L="Victoria"
SSL_CLIENT_I_DN_O="Distributed Systems Software Inc."
SSL_CLIENT_I_DN_ST="British Columbia"
SSL_CLIENT_M_SERIAL="19"
SSL_CLIENT_M_VERSION="3"
SSL_CLIENT_SAN_Email_0="brach...@dss.ca"
SSL_CLIENT_S_DN="CN=Barry Brachman,O=Distributed Systems Software 
Inc.,L=Victoria,ST=British Columbia,C=CA"
SSL_CLIENT_S_DN_C="CA"
SSL_CLIENT_S_DN_CN="Barry Brachman"
SSL_CLIENT_S_DN_L="Victoria"
SSL_CLIENT_S_DN_O="Distributed Systems Software Inc."
SSL_CLIENT_S_DN_ST="British Columbia"
SSL_CLIENT_VERIFY="SUCCESS"
SSL_CLIENT_V_END="Mar  1 01:06:08 2025 GMT"
SSL_CLIENT_V_REMAIN="2834"
SSL_CLIENT_V_START="Mar  4 01:06:08 2015 GMT"
SSL_COMPRESS_METHOD="NULL"
SSL_PROTOCOL="TLSv1.2"
SSL_SECURE_RENEG="true"
SSL_SERVER_A_KEY="rsaEncryption"
SSL_SERVER_A_SIG="sha256WithRSAEncryption"
SSL_SERVER_CERT="-BEGIN CERTIFICATE-
MIIE7zCCA9egAwIBAgIBFzANBgkqhkiG9w0BAQsFADCBpTELMAkGA1UEBhMCQ0Ex
GTAXBgNVBAgTEEJyaXRpc2ggQ29sdW1iaWExEjAQBgNVBAcTCVZhbmNvdXZlcjEq
MCgGA1UEChMhRGlzdHJpYnV0ZWQgU3lzdGVtcyBTb2Z0d2FyZSBJbmMuMTswOQYD
VQQDEzJEaXN0cmlidXRlZCBTeXN0ZW1zIFNvZnR3YXJlIENlcnRpZmljYXRlIEF1
dGhvcml0eTAeFw0xNTAzMDQwMTAxNTBaFw0yNTAzMDEwMTAxNTBaMGoxCzAJBgNV
BAYTAkNBMRkwFwYDVQQIExBCcml0aXNoIENvbHVtYmlhMSowKAYDVQQKEyFEaXN0
cmlidXRlZCBTeXN0ZW1zIFNvZnR3YXJlIEluYy4xFDASBgNVBAMTC2JzZDkuZHNz
LmNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqFb/oHVOK2gKlLp/
Ig0qVySH5Ym3Tn13jBjcoJ8aLs1x4FkfRCLqXnuBUr/7RA1hJdpC/LY8sQ1ehhw9
4ct+GmkjbxXe5yD7MoiUA81p7iDxwD/7odfytOMD0+/npPQwgufP2OhrYQ333xWQ
du12g1uqymWb8riF6C9rPo+F/z95Z8x37TwA+G+Mc5KH5XwRyr0JYu08MC3xaSY8
a23a3zIvOZtyovGPkFOZGpsYUU9tPEnePpjjSjSXw3w4OTYXtTEwKeCnBxmNwq2n
untuMMIJulklKKvglQBy5pXgerwffRO1EILIXUNPCcxjPWM8QSKk3H1imoL0jJM2
2k/eRwIDAQABo4IBYjCCAV4wCQYD

Bug#863928: postgresql-9.6: FTBFS: test failures

[Christoph Berg]

Control: tags -1 moreinfo

Re: Lucas Nussbaum 2017-06-02 <20170602020100.unhbpb6fzyyfw...@xanadu.blop.info>
> > pg_regress: initdb failed
> > Examine /<>/build/src/test/regress/log/initdb.log for the 
> > reason.
> > Command was: "initdb" -D 
> > "/<>/build/src/test/regress/./tmp_check/data" --noclean 
> > --nosync > "/<>/build/src/test/regress/log/initdb.log" 2>&1

Hi Lucas,

I can't reproduce the problem on stretch/i386 here. Unfortunately the
logic in debian/rules for printing initdb.log on failure doesn't
really work - I've pushed a change to git that would fix it, but I'm
unsure if that alone warrants a new upload.

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/commit/?h=9.6&id=0bbd694b81d0ddb0fe218798288067fe24113af7

> LANG=en_US.UTF-8
> LC_ALL=POSIX

Does the en_US.UTF-8 locale exist in the build environment? (LC_ALL
should overwrite it, but that's my best guess at the moment.)

Christoph

Bug#850457: pspp 0.10.2-1 FTBS randomly

[Christoph Berg]

Re: John Darrington 2017-06-03 <20170603061903.GA30068@jocasta.intra>
> If I'm reading that log file correctly, the issue is simply that initdb is 
> dumping that
> message on stderr. Our test considers that a failure.  
> 
> This would seem to suggest a problem with debian's postgres package.

Hi,

this is not a PostgreSQL problem. Make sure the locale settings are
valid in the build environment. (This is either a problem with the
build daemon, or a problem with pspp's testsuite or debian/rules
file.)

>  I think the problem is due to locale settings in the environment. The
>  critical message is:
>  
>  +locale: Cannot set LC_MESSAGES to default locale: No such file or 
> directory

Christoph

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   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 
 Uploaders: Martin Zobel-Helas 
 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-28 20:42:21.0 +0200
@@ -0,0 +1,3 @@
+Depends: @, apache2
+Tests: a2enmod

Bug#806481: Backport etcd to Stretch

[Christoph Berg]

Re: Matthew Dawson 2015-11-28 <1478545.P9uMUQs38u@cwmtaff>
> On November 28, 2015 03:14:16 PM Dmitry Smirnov wrote:
> > On Friday 27 November 2015 21:56:36 Paul Tagliamonte wrote:
> > > Mind if I do it?
> > 
> > Not at all, if you have time... I have no objections. :)
> > 
> > > After it's in Jessie, it might be easier to keep up to date, too.
> > 
> > Unfortunately I can't promise that I will be of help with maintaining
> > backport...
> Hi Paul,
> 
> If I can help with this effort, let me know as I'm also interested in having 
> etcd in Jessie.  I already started trying to get everything to compile 
> against 
> a stock Jessie, and was mostly successful.  To get everything working did 
> require a newer golang (1.4 in my case).  I'm not currently a Debian project 
> member, so I'm not sure how I can help.  Let me know either way.

It looks like etcd won't be part of stretch either - is anyone looking
into backporting it?

Christoph


signature.asc
Description: PGP signature

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   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 
+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 
+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#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#864363: Undefined alien: "SSLv3_client_method"

[Christoph Berg]

Package: cl-plus-ssl
Version: 20160421-1
Severity: grave
Tags: pending

$ pgloader mssql://sa:pass@foobar.server.local/db 
postgresql://postgres:pass@localhost:5432/db
2017-06-07T15:06:17.139000Z LOG Main logs in '/tmp/pgloader/pgloader.log'
2017-06-07T15:06:17.145000Z LOG Data errors in '/tmp/pgloader/'
2017-06-07T15:06:17.345000Z FATAL An unhandled error condition has been 
signalled:
   Undefined alien: "SSLv3_client_method"

cl-plus-ssl seems to default to using SSLv3_client_method, but that is missing 
libssl.so.1.0.2:

/usr/lib/x86_64-linux-gnu $ nm -AD libssl.so.1.* | grep client_method
libssl.so.1.0.0:000374c0 T DTLS_client_method
libssl.so.1.0.0:00037480 T DTLSv1_2_client_method
libssl.so.1.0.0:00037470 T DTLSv1_client_method
libssl.so.1.0.0:0002b810 T SSLv23_client_method
libssl.so.1.0.0:0001cba0 T SSLv3_client_method
libssl.so.1.0.0:0002ca60 T TLSv1_1_client_method
libssl.so.1.0.0:0002ca50 T TLSv1_2_client_method
libssl.so.1.0.0:0002ca70 T TLSv1_client_method
libssl.so.1.0.2:00037260 T DTLS_client_method
libssl.so.1.0.2:00037250 T DTLSv1_2_client_method
libssl.so.1.0.2:00037240 T DTLSv1_client_method
libssl.so.1.0.2:0002b1c0 T SSLv23_client_method
libssl.so.1.0.2:000165a0 T SSLv2_client_method
libssl.so.1.0.2:0002c440 T TLSv1_1_client_method
libssl.so.1.0.2:0002c430 T TLSv1_2_client_method
libssl.so.1.0.2:0002c450 T TLSv1_client_method
libssl.so.1.1:0001b400 T DTLS_client_method
libssl.so.1.1:0001b4c0 T DTLSv1_2_client_method
libssl.so.1.1:0001b4f0 T DTLSv1_client_method
libssl.so.1.1:0001b330 T TLS_client_method
libssl.so.1.1:0001b460 T TLSv1_1_client_method
libssl.so.1.1:0001b430 T TLSv1_2_client_method
libssl.so.1.1:0001b490 T TLSv1_client_method

Christoph


signature.asc
Description: PGP signature

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#668929: irssi: cert validation requires reverse-lookup-found hostname to be in CN or subjectAltNames

[Christoph Berg]

Re: Raphael Geissert 2012-04-15 <201204151316.25456.geiss...@debian.org>
> irssi seems to be doing a reverse-lookup on the IP it is connecting to, and 
> when the x509 certificate for ssl is validated, it wants the hostname it 
> found via the reverse-lookup. Not that of the original hostname.

Hi,

this seems to be the case when `resolve_reverse_lookup` is set. The
default for this setting is OFF, so there shouldn't be any issue
verifying certificates that do not contain the PTR name in the default
config. (If there was, OFTC would have heard about it over the past
decade.)

I suggest closing this bug.

Christoph

Bug#871986: [Pkg-postgresql-public] Bug#871986: postgresql-9.6: PostgreSQL fails to start after upgrade

[Christoph Berg]

Control: tags -1 moreinfo

Re: Jacob Sparre Andersen 2017-08-13 
<150261237312.2459.10119247764903837989.report...@franka.jacob-sparre.dk>
> Last night I upgraded "postgresql-9.6" to the most recent version
> (went from 9.6.3-3 to 9.6.4-0+deb9u1).
> 
> As a part of the upgrade PostgreSQL was shut down, and it has not come
> up since then.

Hi Jacob,

can we see the output of "systemctl status postgresql@9.6-main"?

Is /etc/postgresql/9.6/main/start.conf set to "auto"?
Do you have /usr/sbin/policy-rc.d installed?

> I've tried "sudo service postgresql restart" without any visible effect.

postgresql.service is just a stub which forwards all actions to the
individual services like postgresql@9.6-main.service. Unfortunately
systemctl doesn't really relay any errors back if there's any.

Christoph

Bug#759725: postgresql-common: non-synchronous service postgresql stop

[Christoph Berg]

Re: Ludovic Gasc 2017-08-22 

> Apparently, postgresql has now a sd_notify integration:
> https://www.postgresql.org/docs/9.6/static/server-start.html
> 
> But it's with postgres process directly, not with pg_ctlcluster.
> 
> Is it planned to have an integration with sd_notify in pg_ctlcluster ?

I haven't thought about it yet (or rather, dismissed the idea as
default when --with-systemd was added to the ./configure call because
only one PostgreSQL version supported it at the time), but we should
reevaluate the idea now. Thanks for the suggestion!

Christoph

Bug#872915: Bug#759725: postgresql-common: non-synchronous service postgresql stop

[Christoph Berg]

(Moving to #872915 because #759725 was about stopping PostgreSQL, not
starting it)

Re: Ludovic Gasc 2017-08-22 

> Do you see a drawback problem if I disable the actual systemd service from
> Debian and use the example from PostgreSQL documentation, the time you find
> a clean solution with pg_ctlcluster ?

I think you can simply use a drop-in config file:

/etc/systemd/system/postgresql@.service.d/type.conf:
[Service]
Type=notify

Christoph

Bug#682347: mark 'editor' virtual package name as obsolete

[Christoph Berg]

Re: Russ Allbery 2017-08-24 <87efs1lyc7@hope.eyrie.org>
> Oh, thank you!  For some reason, apt-cache rdepends didn't show any of
> those packages.  All of them except dnsvi are Suggests, which basically
> doesn't accomplish anything.
> 
> Copying myon on this message as maintainer of dnsvi, which has a
> dependency on "vim | editor".  Christoph, we're proposing finally removing
> the editor virtual package completely, with the patch included here:

Thanks for the notice. I'm quite surprised that my dnsvi seems to be
the only package in Debian that requires a text editor. Given that our
base doesn't really include one, and getting dependencies Just Right
is among the things that Debian is really good at, dropping the
existing "editor" virtual package seems Just Wrong to me.

Even if "editor" was de-officialized in 1996, it is very much used
today. Bill's original list from 2015 was incomplete (it is much
longer now, but given that even emacs was missing, I'd think the grep
command used back then was wrong):

$ grep-dctrl -F Provides editor -nsPackage 
/var/lib/apt/lists/deb_debian_dists_sid_main_binary-amd64_Packages | xargs
deutex edbrowse emacs25 emacs25-lucid emacs25-nox fte-console
fte-terminal fte-xwindow jed xjed jove jupp le ledit levee lpe mg
xul-ext-password-editor nano nano-tiny ne pluma rlfe rlwrap scite
vigor vile xvile vim vim-athena vim-gtk vim-gtk3 vim-nox vim-tiny vis
xul-ext-exteditor

Wouldn't it much better (cleaner, more correct, more userfriendly) to
promote "editor" to official status instead?

Christoph

Bug#682347: mark 'editor' virtual package name as obsolete

[Christoph Berg]

Re: To Russ Allbery 2017-08-24 <20170824171653.r24gyar5mikyj...@msg.df7cb.de>
> $ grep-dctrl -F Provides editor -nsPackage 
> /var/lib/apt/lists/deb_debian_dists_sid_main_binary-amd64_Packages | xargs
> deutex edbrowse emacs25 emacs25-lucid emacs25-nox fte-console
> fte-terminal fte-xwindow jed xjed jove jupp le ledit levee lpe mg
> xul-ext-password-editor nano nano-tiny ne pluma rlfe rlwrap scite
> vigor vile xvile vim vim-athena vim-gtk vim-gtk3 vim-nox vim-tiny vis
> xul-ext-exteditor

There are some false positives in that list (deutex, ledit, pluma,
rlwrap, xul-ext-exteditor; "Provides: readline-editor" and similar),
but the list is still pretty long, I'd conclude.

Christoph

Bug#864879: Vcs-Git contents in wrong order, put branch at the end

[Christoph Berg]

Package: libmodule-install-rtx-perl
Version: 0.38-1
Severity: minor

Hi,

libmodule-install-rtx-perl's Vcs-Git header is a tad unorthodox:

Vcs-Git: -b dpkg 
https://anonscm.debian.org/git/pkg-request-tracker/libmodule-install-rtx-perl.git

Would you consider moving the -b part to the end?

Vcs-Git: 
https://anonscm.debian.org/git/pkg-request-tracker/libmodule-install-rtx-perl.git
 -b dpkg

vcswatch was unhappy about it; I temporarily edited the URL to make it
work, but this will be overwritten with the next upload.

https://qa.debian.org/cgi-bin/vcswatch?package=libmodule-install-rtx-perl

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#865020: [Pkg-postgresql-public] Bug#865020: Bug#865020: postgresql-9.6: FTBFS with Perl 5.26: hstore_plperlu differences

[Christoph Berg]

Re: Niko Tyni 2017-06-20 <20170620113058.ga5...@hagar.it.helsinki.fi>
> > So it's perhaps not worth patching around in it before then.
> 
> Your call, though I'd certainly appreciate if you included it
> if there's to be another 9.6.3 upload in between.

I don't think there would be an upload, but we'd of course include the
fix if there's one.

> We're tracking sid with the unofficial binNMU repo at perl.debian.net,
> and this shows up on the radar of packages that can't currently be
> rebuilt. I don't think it's blocking other packages atm though.

There should be no relevant reverse dependencies that wouldn't just
work with the existing 9.6.3 packages as well.

> We don't have a schedule for 5.26 in sid yet, but things are looking
> quite good this time [at least compared to some previous years :) ]

I'm especially looking forward to libperl5.26 being co-installable
with libperl5.24, this will save postgresql-plperl some upgrade
headaches :)

Christoph

Bug#865738: apt: progress bar broken by full-screen maintainer script actions

[Christoph Berg]

Package: apt
Version: 1.4.6
Severity: normal

Hi,

during the unpack phase, any full-screen terminal output (ucf, dialog,
less) from maintainer scripts seems to reset the term layout such that
the progress bar isn't properly displayed anymore. dpkg's messages use
the last terminal line as well, and the progress bar is only
flickering. Resizing the window fixes it.

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (800, 'stable'), (600, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de:en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2017.5
ii  gpgv2.1.18-6
ii  init-system-helpers 1.48
ii  libapt-pkg5.0   1.4.6
ii  libc6   2.24-11+deb9u1
ii  libgcc1 1:6.3.0-18
ii  libstdc++6  6.3.0-18

Versions of packages apt recommends:
ii  gnupg   2.1.18-6
ii  gnupg1  1.4.21-4
ii  gnupg2  2.1.18-6

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.18.24
ii  powermgmt-base   1.31+nmu1
ii  python-apt   1.4.0~beta3

-- no debconf information

Christoph

Bug#857770: [Pkg-postgresql-public] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Christoph Berg]

Re: Ole Streicher 2017-08-30 
> For Debian (single Postgresql version) this works well; I don't know
> if "pg_buildext supported-versions" returns them line by line (what I assumed)
> or space-separated (then it needs some adjustments). One should also discuss
> which Postgresql version should be the first (which installed by default).

It's line-separated.

Re the default version, the convention is that
/usr/share/postgresql-common/supported-versions returns the default
version /last/. (Try calling
  PG_SUPPORTED_VERSIONS=pgdg /usr/share/postgresql-common/supported-versions
).

I'm not sure if "pg_buildext supported-versions" preserves that
ordering in all cases; but we can fix it to do so if it's not already
the case. Then there is the question what to do if the default version
is not in the intersection of "debian/pgversions"
`/usr/share/postgresql-common/supported-versions`, which is what
`pg_buildext supported-versions` really computes.

> Ideally the dependency generation could be integrated into pg_buildext.

Right.

> If a new Postgresql version is uploaded (or an old one is removed), a
> binNMU can be requested, resulting in a new package with the new list of
> Postgresql objects built in. As it is done for Python or others.

BinNMUs would work for updating the ${postgresql:Depends} part. What
doesn't work is changing the set of binaries built from
debian/control, because it's forbidden by Debian policy. This is why
"pg_buildext checkcontrol" raises an error if the file changes.
Possibly we could make it smarter, but in most cases, changing the
default version will mean the list of supported versions changes as
well.

Christoph

Bug#857770: [Pkg-postgresql-public] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Christoph Berg]

Re: Ole Streicher 2017-08-30 
> The idea here is to have just one binary package, containing the shared
> libraries for all supported versions. Extensions are usually small, so
> combining them in one package will not hurt. So, there would no
> "postgresql-9.6-q3c" package anymore, d/control.in is removed, and
> d/control is fixed (for one release). For convenience, I just attach the
> complete d/control for postgresql-q3c.
> 
> In that case, changing the supported postgresql versions will not change
> the list of binary packages, but just the dependencies, which is IMO not
> forbidden.

That is true, but it's totally different from what we have been doing
so far. We would need to update all packages, and providing the
necessary (?) transitional packages for existing users will be
difficult.

If a PG version goes out of support, the new package version wouldn't
contain the module anymore, even if users are still using that PG
version on their system. (Think Debian dist-upgrades.)

It would also prevent (easily) building packages against beta/devel PG
versions (10 and 11 at the moment). Or these packages would need to
include the "normal" PG versions from the normal packages, plus the
extra versions.

The idea is intriguing, though. Maybe these problems have cute
solutions and could be fixed.

Christoph


signature.asc
Description: PGP signature

Bug#874427: /usr/bin/pg_config in multiple packages

[Christoph Berg]

Control: tags -1 moreinfo

Re: Bryan Henderson 2017-09-06 <98655.bry...@giraffe-data.com>
> Package: postgresql-common
> Version: 165+deb8u2
> 
> Both postgresql-common and libpq-dev install the file /usr/bin/pg_config .
> That's a bug, isn't it?  dpkg --install seems to think so.

Hi Bryan,

that's not a bug, the /usr/bin/pg_config from libpq-dev is moved aside
by postgresql-common's preinst script via dpkg-divert:

diversion by postgresql-common from: /usr/bin/pg_config
diversion by postgresql-common to: /usr/bin/pg_config.libpq-dev
libpq-dev, postgresql-common: /usr/bin/pg_config

> This was not a problem for me before an attempted update a few days ago; Now I
> have broken dependencies that I cannot fix because I cannot install the
> current libpq-dev because of the file conflict.  I don't know what changed.

If the diversion didn't work for you, something is messed up. Does
"apt-get install --reinstall postgresql-common" fix things?

If there's still problems, please attach the terminal output of
apt and dpkg so we can have a look.

Christoph


signature.asc
Description: PGP signature

Bug#682347: mark 'editor' virtual package name as obsolete

[Christoph Berg]

Re: Russ Allbery 2017-08-30 <87k21lj7id@hope.eyrie.org>
> Paride Legovini  writes:
> > On Fri, 25 Aug 2017 10:09:34 +0200 Jeroen Dekkers  wrote:
> 
> >> Nano is priority important which means it will be installed by default
> >> and someone who explicitly uninstalls nano will probably also install
> >> another editor. I doubt a dependency on editor will make any difference
> >> in practice.
> 
> > I agree, I see no advantage in adding a default-editor: if we have to
> > add complexity then it's better to just keep the virtual package.
> 
> On the technical front, I think keeping the editor virtual package as it's
> currently (occasionally) used is not really viable, because it doesn't
> have well-defined behavior.  Depending directly on a virtual package that
> provides as wildly varying functionality as editor does results in
> essentially random experience for users if the dependency is ever used.

Is that true? Invoking "editor $filename" works, and that's what
expected user interface is. It is true that there's two not-quite
orthogonal systems in action here, /etc/alternatives/editor and
/usr/bin/sensible-editor, but that doesn't mean that the existing
"editor" virtual package needs to be removed.

> We had a long discussion about this over MTAs, and I think if we want to
> keep the editor virtual package structure, we would need to add
> default-editor just so that we can get reliable and predictable behavior,
> similar to what we did with default-mta.  We could, of course, do that;
> the question is whether it's worth it.

The problem with MTAs is that only one can be installed at a time, so
it really makes a difference which one is installed. With editors,
several can be installed, and things will still Just Work.

Again, the fact that apt doesn't easily allow to predict which
alternative is chosen shouldn't mean the "editor" virtual package is
bad. It is still useful, apt frontends can let the user choose which
editor they want installed. (In practice, we don't really need a
default-editor package to make the result predictable, because "nano"
should be there as part of the base system. (While base doesn't have
any MTA.))

> > I maintain 'vis', which Provides 'editor', and I prepared a new version
> > where this is not done anymore, but I still have to publish it. Is this
> > issue to be considered as settled? I see that 'nano' already dropped its
> > Provides line, so I guess it is.

Even if the outcome is that "editor" isn't an official virtual package
anymore, does that really mean that packages should stop announcing
it?

> Ideally I'd like myon to feel comfortable with this proposed outcome, and
> the proposed wording hasn't gotten enough seconds yet.

I'm not vetoing any outcome - I'm just expressing my astonishment
here. To me, the situation looks like that the current implementation
of "editor" is like 80% ok, and because reaching 100% is hard (to
which I agree), the whole thing is instead torn down. Can't we just
stick with the 80%, given there's no actual problem with it?

Christoph


signature.asc
Description: PGP signature

Bug#873623: sudo: occasionally stalls infinitely instead of running command

[Christoph Berg]

Re: Thorsten Glaser 2017-08-29 
<150402112366.4803.7797051343542216967.report...@tglase.lan.tarent.de>
> Package: sudo
> Version: 1.8.21-1
> Severity: grave
> Justification: renders package unusable
> 
> After an upgrade from 1.8.20p2-1 sudo became somewhat unusable:

Confirmed. It's very easy to reproduce:

$ while date; do sudo true; done
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
Mi 6. Sep 19:42:54 CEST 2017
^CMi 6. Sep 19:42:58 CEST 2017
Mi 6. Sep 19:42:58 CEST 2017
^CMi 6. Sep 19:42:59 CEST 2017

strace: Process 20436 attached
restart_syscall(<... resuming interrupted poll ...>

Christoph

Bug#876360: copyright-year-in-future false positive: "252.227-7013 (c) (1) of DFARs"

[Christoph Berg]

Package: lintian
Version: 2.5.52
Severity: normal

Hi,

postgresql-10's debian/copyright is triggering a false positive
copyright-year-in-future warning:

W: postgresql-10: copyright-year-in-future 7013 > 2017 (line 311, column 10)

The line in question has this context:

 Government shall have only "Restricted Rights" as defined in Clause
 252.227-7013 (c) (1) of DFARs.  Notwithstanding the foregoing, the

Christoph

Bug#868232: [Pkg-postgresql-public] Bug#868232: lost (unintentionally) unconditional pg_updatedicts on postinst

[Christoph Berg]

Re: Christian Ehrhardt 2017-07-13 

> The reason is the dropping of the following statement that was considered
> to be no more needed:
> if dpkg --compare-versions "$2" lt 94; then
> pg_updatedicts || true
> fi
> 
> I agree version 94 is long ago.
> But since then, due to a mistake, this always was an unconditional
> pg_updatedicts call on first install.

Good analysis, thanks!

> Ok, long story short - we should make sure the base directory is created
> correctly on postinst.
> Therefor I suggest really adding an unconditional pg_updatedicts in there.
> The postrm already has the matching rm to clean the dir up btw.

Makes sense I think. Will have a look at it later.

Christoph

Bug#846019: pgadmin3: SIGABRT after fatal error complaint regarding libwxgtx ABI mismatch

[Christoph Berg]

Control: tags -1 moreinfo

Re: Björn Harrtell 2016-11-27 
<148028258038.23222.11913331484102576149.report...@bjorn-desktop.wololo.org>
> Fatal Error: Mismatch between the program and library build versions detected.
> The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx 
> containers,compatible with 2.8),
> and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,wx 
> containers,compatible with 2.8).
> Avbruten (SIGABRT)
> 
> Perhaps related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844486.

Hi,

this "Fatal Error" should actually just be a warning with the Debian
WX packages. Do you have any idea why it is fatal for you?

Christoph


signature.asc
Description: PGP signature

Bug#846019: pgadmin3: SIGABRT after fatal error complaint regarding libwxgtx ABI mismatch

[Christoph Berg]

Re: Björn Harrtell 2016-12-08 

> > this "Fatal Error" should actually just be a warning with the Debian
> > WX packages. Do you have any idea why it is fatal for you?
> 
> Sorry no real idea. I've tried removing/installing
> pgadmin3, libwxbase3.0-0v5 and libwxgtk3.0-0v5 with no change.

Hmm. Maybe a local libwx installation in /usr/local/lib or the like?

> I did notice today that I also have the exact same error for other
> applications that depend on libwxgtk3.0-0v5 (tested with audacity and
> poedit).

Do these also exit fatally?

Christoph

Bug#846019: pgadmin3: SIGABRT after fatal error complaint regarding libwxgtx ABI mismatch

[Christoph Berg]

Re: Björn Harrtell 2016-12-10 

> You where right, I had totally forgot that I compiled and installed a
> custom libwx a while ago which was the cause of my problems. Sorry for the
> noise. :(

No worries, and thanks for confirming!

Christoph

Bug#833038: Please support pool-like structure for --morguedir

[Christoph Berg]

Package: reprepro
Version: 4.17.1-1
Severity: wishlist

Hi,

for apt.postgresql.org, I have a morgue directory with currently 36k
files. I'd like to serve that over http so people can pick up older
package versions. The directory index for that is a 9MB html output
that needs 5s to download (and almost 30s to render).

The obvious fix for that would be to structure the morgue directory
using the same $initial/$package layout that is used in the pool
directory. Would you consider supporting this?

(On a sidenote, it would be nice if MorgueDir was a config option that
doesn't just apply to incoming, but to all operations. Currently I
have a /usr/local/bin/reprepro shell script that adds the --morguedir
option.)

Thanks,
Christoph

Bug#832282: [Pkg-postgresql-public] Bug#832282: postgresql-common: [INTL:nl] Dutch translation of debconf messages

[Christoph Berg]

Re: Frans Spiesschaert 2016-07-28 <1469704552.14058.29.ca...@yucom.be>
> I was given the wrong idea that an update of the Dutch po file was
> needed because of
> https://www.debian.org/international/l10n/po-debconf/nl (look on that
> page for postgresql-common where it says that there is one string
> untranslated).
> There is a warning explanation (behind the exclamation mark) that says
> that the debian/po/templates.pot has not been synced with the templates
> files and that it can be fixed by adding debconf-updatepo to the
> Makefile rule 'clean' in debian/rules.

Oh ok, I was wondering how you actually saw that chunk, thanks for the
URL!

At the moment the templates.pot file is intentionally not 100% synced
(lintian warns about it as well). I'm still not sure what the best way
to proceed here is. If only gettext would support an "empty msgstr is
ok" tag...

Christoph


signature.asc
Description: PGP signature

Bug#832282: [Pkg-postgresql-public] Bug#832282: postgresql-common: [INTL:nl] Dutch translation of debconf messages

[Christoph Berg]

Re: To Frans Spiesschaert 2016-08-01 
<20160801095452.h3apq4qihllb3...@msg.df7cb.de>
> At the moment the templates.pot file is intentionally not 100% synced
> (lintian warns about it as well). I'm still not sure what the best way
> to proceed here is. If only gettext would support an "empty msgstr is
> ok" tag...

Rhonda pointed me to the correct solution:

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git/commit/?id=cdce881bf074cd2adfcc07fe58d30e0daa434e48

Will upload soonish.

Christoph


signature.asc
Description: PGP signature

Bug#833262: libval14: irssi started crashing when connecting to OFTC with SSL

[Christoph Berg]

Re: Timo Jyrinki 2016-08-02 <20160802092651.3264.46335.report...@verkko.lan>
> Package: libval14
> Version: 2.0-1.1
> Severity: normal
> 
> Dear Maintainer,
> 
> An hour ago, irssi segfaulted (when idle) for me and then refused to start
> any longer. I found out it's down to the OFTC connection and using SSL. I can
> still use Freenode with SSL.
> 
> Now I can reproduce it every time with irssi config options:
> 
> { address = "irc.oftc.net"; chatnet = "OFTC"; port = "6697";
> use_ssl = "yes"; ssl_cert = "~/.irssi/mirv.pem"; ssl_verify = "yes"; },
> 
> after typing in /connect OFTC.
> 
> I've rebooted and tried switching irssi to a newer jessie backport
> (0.8.19-1~bpo8+1), but nothing changes.
> 
> The backtrace is:
> 
> Program received signal SIGSEGV, Segmentation fault.
> get_dane_from_result (results=, dres=dres@entry=0xbefff208, 
> dparam=0xbefff208) at val_dane.c:116
> 116 val_dane.c: Tiedostoa tai hakemistoa ei ole.
> (gdb) bt
> #0  get_dane_from_result (results=, 
> dres=dres@entry=0xbefff208, dparam=0xbefff208) at val_dane.c:116

OFTC implemented DNSSEC + DANE around July 14th.

Christoph


signature.asc
Description: PGP signature

Bug#833341: Change default fallback locale to C.UTF-8

[Christoph Berg]

Package: postgresql-common
Version: 175
Severity: normal

Too many people end up with SQL_ASCII clusters when they didn't have
any specific OS locale configured. We should change the default locale
to C.UTF-8.

Christoph

Bug#851793: hobbit-plugins: False positives in the apt plugin: "dpkg -l" since recently shows some removed packages as "ic" instead of "rc"

[Christoph Berg]

Re: Axel Beckert 2017-01-18 <87d1fkkuur@c-cactus.ontheroad.deuxchevaux.org>
> It's yet unclear what triggers that situation, but those packages are
> clearly neither broken nor unconfigured. So I see two possible solutions:
> 
> * Ignore them.
> * List them as (either yellow or green, maybe configurable) not fully
>   removed.

Let's not mark "removed but config files left" as an error (yellow) by
default. It's not a problem on the system, and hinting people to purge
removed packages will lead to cases of data loss that would otherwise
just not have happened.

Just showing the list is of course ok, or making it an optional config
option to report removed-but-not-purged packages as yellow.

Christoph

Bug#851874: pg_upgradecluster: allow configuring the maintenance database

[Christoph Berg]

Package: postgresql-common
Version: 178
Severity: wishlist

pg_upgradecluster hard-codes "template1" as the database to connect
for maintenance operations. There might be some value in allowing the
user to specify a different one with some switch, e.g. "postgres".

Christoph

Bug#659102: Problem with the apache resource solved

[Christoph Berg]

Version: 1:3.9.6-1

Re: Michal Vyoral 2012-02-22 <20120222141253.gd2...@osit-vyoral.chmi.cz>
> Hello,
> I have solved the problem by adding the parameter
> 
>   statusurl="http://127.0.0.1/server-status";

Re: Harald Dunkel 2012-08-01 <5018d7fc.9000...@aixigo.de>
> Explicitly setting the statusurl is a workaround, but it
> doesn't fix the problem.
> 
> The problem is that the apache resource script fails to
> guess the server-status url from the config file. It uses
> 
>   http://localhost:

Hi,

there's been various fixes upstream in that area, I'm closing the
Debian bug now. Thanks for the reports!

Christoph


signature.asc
Description: PGP signature

Bug#853868: pg_ctlcluster should error out if it finds a recovery.conf in /etc

[Christoph Berg]

Package: postgresql-common
Version: 179
Severity: wishlist

>From #postgresql:

 Myon: I wonder if pg_ctlcluster should error out if it finds a 
recovery.conf in /etc
 possibly, yes
 I see this mistake all the time, and it's a 100% natural mistake to 
make

Christoph

Bug#848869: Error: could not create default cluster. Please create it manually with

[Christoph Berg]

Control: tags -1 moreinfo

Re: Darshaka Pathirana 2016-12-20 
<20161220110151.19348.48480.reportbug@invincible>
>   Error: The locale requested by the environment is invalid.

> Locale looks like this:
> 
>   % locale
>   LANG=en_US.UTF-8
>   LANGUAGE=en_US:en

Hi,

on package installation (only), the locale used for pg_createcluster
(= initdb) is not determined by your environment (which "locale" looks
at), but by the system configuration in /etc/environment and
/etc/default/locale.

Could you check what you have configured in these files?

Christoph

Bug#818961: [Debian-ha-maintainers] Freeze status, Heartbeat plans

[Christoph Berg]

Re: Patrick Matthäi 2016-12-21 <89f2fc7d-a3a0-a01f-8105-7f795b0d2...@debian.org>
> We tried out many test cases, workarounds, debugging on this issue and
> the result was, that the v1 mode of heartbeat can not deal with the
> dependency system of systemd and will never support it.

Hmm, I don't get what the dependency system has to do with it, versus
a plain "heartbeat invoking systemctl via init scripts" breakage, or
something like that.

> I still think, this is the best solution (since only v1 mode is affected):
> "IMO the package should warn (debconf dialog prio high?) the user if he
> upgrades heartbeat and systemd+v1 config is in use."

That still requires someone to understand the problem and explain it
in the warning. Just saying "it might be broken but we don't know
which bits you need to check" won't work.

> Removing the whole heartbeat package would not be a good solution, since
> it is still required?

It doesn't have any reverse dependencies anymore. At the moment it's
the only HA package not in testing, so it isn't holding back any other
package. Effectively, it is already removed now (from testing).

Christoph

Bug#847698: pgloader FTBFS on arm64: The value 64 is not of type (INTEGER -32 63)

[Christoph Berg]

Re: Adrian Bunk 2016-12-10 
<148139247737.5151.15852766254365495913.reportbug@localhost>
> ;; loading system "pgloader"
> Fatal TYPE-ERROR:
>   The value
> 64
>   is not of type
> (INTEGER -32 63)

After some poking this turned out to be a bug in sbcl on arm64.
Upstream plans to fix it tomorrow.

Christoph

Bug#797530: 32bit pie memory layout leaves only ~100MB between heap and stack

[Christoph Berg]

More details:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483

Christoph

Bug#797530: 32bit pie memory layout leaves only ~100MB between heap and stack

[Christoph Berg]

Re: Florian Weimer 2016-10-28 <87r3708aah@mid.deneb.enyo.de>
> * Christoph Berg:
> 
> > More details:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483
> 
> Why do you consider this a security issue?  Do you consider it an
> availability issue?
> 
> I'm a bit confused why this shows up as a userspace allocation
> failure.  glibc should switch to mmap (creating another arena) if sbrk
> fails.  I thought we had logic for that in malloc, but the whole code
> is kind of convoluted, so it is difficult to be sure.

For PostgreSQL, it's an availability issue. Any user can create the
following function: (this is the exact failing reason for [1])

create function infinite_recurse() returns int as
'select infinite_recurse()' language sql;
select infinite_recurse();

[1] https://buildd.debian.org/status/logs.php?pkg=postgresql-9.6&ver=9.6.1-1

Without ASLR, or on 64 bit, or with the fix in place, PostgreSQL will
correctly detect that the stack is overflowing the default
max_stack_depth of 2MB, and will safely abort the query.

With the bug, heap and stack are overwriting each other even before
2MB stack have been consumed (or the 8MB default stack ulimit has been
reached), leading to a segfault, presumably because the heap is
trapping into the stack guard page, or something like that.

In the past we fixed in PostgreSQL that by not enabling PIE on 32bit,
but with PIE enabled by default, we will have to switch to actively
disabling it.


I think this is also exploitable because it would allow heap accesses
to write to the stack if both get so close. (Iirc the memory layout at
the time of the crash doesn't even have a guard page at the end of the
stack anymore, but that needs closer inspection.)

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 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


signature.asc
Description: PGP signature

Bug#842739: Enable CONFIG_INET_DIAG_DESTROY for "ss -K"

[Christoph Berg]

Source: linux
Version: 4.8.5-1
Severity: wishlist

OFTC would like to be able to use "ss -K" for selectively killing
individual network connections on long-running daemons like ircd.
The functionality is available in Linux 4.6+, but is currently
disabled:

/boot/config-4.8.0-1-amd64:# CONFIG_INET_DIAG_DESTROY is not set

Would you consider enabling it? Unstable's iproute2/ss has the support
for it already.

https://lwn.net/Articles/668090/

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#842752: [Pkg-postgresql-public] Bug#842752: postgresql-9.6: FTBFS: test failures on i386/armel/armhf

[Christoph Berg]

Re: Emilio Pozuelo Monfort 2016-11-01 
<147795902108.24771.17991504514045017206.reportbug@tatooine>
> Source: postgresql-9.6
> Version: 9.6.1-1
> Severity: serious
> 
> Your package failed to build on i386, armel and armhf with test errors.
> 
> See the logs at https://buildd.debian.org/status/package.php?p=postgresql-9.6

Fwiw, the real bug is in Linux, which manifests because the buildds
are using a jessie kernel:
#797530: 32bit pie memory layout leaves only ~100MB between heap and stack.

We'll work around it in PostgreSQL by explicitly disabling PIE on
32bit. (The previous workaround was to not enable it there, but the
default has changed.)

I'd prefer a proper fix in the kernel, though.

Christoph


signature.asc
Description: PGP signature

Bug#819442: [Pkg-postgresql-public] Bug#819442: postgresql-common: pg_ctlcluster fails if data directory is not in the standard place

[Christoph Berg]

Control: tags -1 moreinfo
Control: severity -1 normal

Re: Oliver Elphick 2016-03-28 
<145917708743.17099.3256500088838331355.report...@phoenix.lfix.co.uk>
> pg_ctlcluster reads the config files and appears to launch the pg_ctl command
> with '-D /lvhome/postgresql//'.  However the -D option to
> pg_ctl specifies where the config file is to be found. (Its brief description
> is misleading.)  Therefore postgresql does not start from the init script or
> from systemctl.
> 
> Debugging pg_ctlcluster:
> DB<12> p $pg_ctl," ", @options
> /usr/lib/postgresql/9.5/bin/pg_ctl
> /usr/lib/postgresql/9.5/bin/pg_ctlstart-D/lvhome/postgresql/9.5/main-l/var/log/postgresql/postgresql-9.5-main.log-s-o
> -c config_file="/etc/postgresql/9.5/main/postgresql.conf"

Hi Oliver,

thanks for the report.

pg_ctlcluster does pass "-c config_file" to pg_ctl (and in turn to
postgres), which I believe has been the state of affairs since
postgresql-common was invented (and possibly even before that, when
your name was still on the postgresql packages :D). Non-standard
PGDATA locations are supported and generally work.

So the problem must have been elsewhere in the interaction of
postgresql-common with your setup. Can you still reproduce it?

> Specifying 'pg_ctl -D /etc/postgresql//' does work.
> 
> The solution is not to parse 
> /etc/postgresql//postgresql.conf
> for the data directory, since this is unnecessary.

That said, I believe the "-c config_file" invocation dates back from
the time when data_directory didn't exist yet, and could well be
replaced by what you are suggesting now. I'll likely implement that
after doing some testing.

> Apart from the fix, I suggest that some other logging of errors be
> done where the server fails to start. 
> 
> in this case, there was no log anywhere, since the server failed to
> find its configuration file.

It's actually supposed to do that, but there's so many corner cases...
Will check.

Christoph


signature.asc
Description: PGP signature

Bug#838236: libpam-runtime: pam_getenv emits perl warning "Unescaped left brace in regex..."

[Christoph Berg]

Re: Andreas Koenig 2016-09-18 <87poo1knbh.fsf@k85.linux.bogus>
> % /usr/sbin/pam_getenv foo   
> Unescaped left brace in regex is deprecated, passed through in regex; marked 
> by <-- HERE in m/(? 78.

> On my system I saw this warning during the installation of postgresql-9.5.

Is there a chance to get this fixed for stretch? I'm pondering to NMU
because this bug keeps getting reported on the PostgreSQL packages
every other week.

Christoph

Bug#847207: [pkg-uWSGI-devel] Bug#847207: uwsgi: FTBFS on multiple architectures with undefined references to uwsgi_* symbols

[Christoph Berg]

Re: Raphael Hertzog 2016-12-06 <20161206172047.5jz4tg6nmjded...@home.ouaza.com>
> On Tue, 06 Dec 2016, Jonas Smedegaard wrote:
> > Excerpts from Raphaël Hertzog's message of December 6, 2016 3:25 pm:
> > > I have the feeling that this is all related to the "-Wl,-z,now" flag but 
> > > I don't know what
> > > is injecting this flag here...
> > 
> > Seems to come from LDFLAGS setting of /usr/lib/postgresql/9.6/bin/pg_config 
> > in package
> > postgresql-server-dev-9.6.
> > 
> > Is that a bug in that postgreql package?
> 
> Maybe. It's certainly not a required flag to make the build succeed...
> so it could be dropped there but if it was added in the first place,
> it's for a purpose (hardening I guess).

Hi,

half of the pg_config output bits are more informational and not
really supposed to be used for building other pieces of software.
pg_config(1) says:

--ldflags
   Print the value of the LDFLAGS variable that was used for building
   PostgreSQL. This shows linker switches.

The same holds for CFLAGS:

--cflags
   Print the value of the CFLAGS variable that was used for building
   PostgreSQL. This shows C compiler switches.

I think these bits should simply be dropped from
plugins/emperor_pg/uwsgiplugin.py.

Its usage of `pg_config --includedir` is correct. (The usage of
`pg_config --libdir` is correct, but useless in Debian because it's
just the default lib dir.)

Admittedly the fact that "usable" options like "--includedir-server"
are intermixed with informational options like "--configure" is
confusing.

Christoph

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Christoph Berg]

Control: tag -1 patch pending

Re: Vladimír Čunát 2016-09-27 

> I'm curious: will there be a fix for 2.6.1?

I've just uploaded flex_2.6.1-1.2_source.changes fixing this to
delayed/5, patch attached.

 debian/NEWS.Debian |2 +-
 debian/changelog   |   12 +
 src/flex.skl   |   10 
 src/gen.c  |2 +-
 src/skel.c |   70 ++--
 5 files changed, 54 insertions(+), 42 deletions(-)

The net change is in flex.skl + gen.c; skel.c is generated from these.

Christoph

No differences were encountered between the control files

diff -Nru flex-2.6.1/debian/changelog flex-2.6.1/debian/changelog
--- flex-2.6.1/debian/changelog	2016-12-30 23:28:29.0 +0100
+++ flex-2.6.1/debian/changelog	2016-12-30 23:28:29.0 +0100
@@ -1,3 +1,15 @@
+flex (2.6.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick 1da19feba7c957e0f0af0c3eeadc29e8c82b0ca3,
+cf4121fa97abac8aeaa5e08b8fc0b2380228494e and
+8c098febc9a599397921e9b6938b7fb85e38cc7e from upstream to fix comparison
+between signed and unsigned integer expressions in generated lexer
+(Closes: #835542).
+  * Fix distribution in last upload's NEWS.Debian.
+
+ -- Christoph Berg   Fri, 30 Dec 2016 20:29:41 +0100
+
 flex (2.6.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru flex-2.6.1/debian/NEWS.Debian flex-2.6.1/debian/NEWS.Debian
--- flex-2.6.1/debian/NEWS.Debian	2016-12-30 23:28:29.0 +0100
+++ flex-2.6.1/debian/NEWS.Debian	2016-12-30 23:28:29.0 +0100
@@ -1,4 +1,4 @@
-flex (2.6.1-1.1) UNRELEASED; urgency=medium
+flex (2.6.1-1.1) unstable; urgency=medium
 
In this upload, the flex package drops its dependency on libfl-dev, because
it is impossible to forward the correct architecture constraint. It contains
diff -Nru flex-2.6.1/src/flex.skl flex-2.6.1/src/flex.skl
--- flex-2.6.1/src/flex.skl	2016-12-30 23:28:29.0 +0100
+++ flex-2.6.1/src/flex.skl	2016-12-30 23:28:29.0 +0100
@@ -1661,7 +1661,7 @@
 M4_YY_DECL_GUTS_VAR();
 	char *dest = YY_CURRENT_BUFFER_LVALUE->yy_ch_buf;
 	char *source = YY_G(yytext_ptr);
-	yy_size_t number_to_move, i;
+	int number_to_move, i;
 	int ret_val;
 
 	if ( YY_G(yy_c_buf_p) > &YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[YY_G(yy_n_chars) + 1] )
@@ -1690,7 +1690,7 @@
 	/* Try to read more data. */
 
 	/* First move last chars to start of buffer. */
-	number_to_move = (yy_size_t) (YY_G(yy_c_buf_p) - YY_G(yytext_ptr)) - 1;
+	number_to_move = (int) (YY_G(yy_c_buf_p) - YY_G(yytext_ptr) - 1);
 
 	for ( i = 0; i < number_to_move; ++i )
 		*(dest++) = *(source++);
@@ -1778,7 +1778,7 @@
 	else
 		ret_val = EOB_ACT_CONTINUE_SCAN;
 
-	if ((int) (YY_G(yy_n_chars) + number_to_move) > YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
+	if ((YY_G(yy_n_chars) + number_to_move) > YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
 		/* Extend the array by 50%, plus the number we really need. */
 		int new_size = YY_G(yy_n_chars) + number_to_move + (YY_G(yy_n_chars) >> 1);
 		YY_CURRENT_BUFFER_LVALUE->yy_ch_buf = (char *) yyrealloc(
@@ -2451,11 +2451,11 @@
 	YY_BUFFER_STATE b;
 	char *buf;
 	yy_size_t n;
-	yy_size_t i;
+	int i;
 m4_dnl M4_YY_DECL_GUTS_VAR();
 
 	/* Get memory for full buffer, including space for trailing EOB's. */
-	n = (yy_size_t) _yybytes_len + 2;
+	n = (yy_size_t) (_yybytes_len + 2);
 	buf = (char *) yyalloc( n M4_YY_CALL_LAST_ARG );
 	if ( ! buf )
 		YY_FATAL_ERROR( "out of dynamic memory in yy_scan_bytes()" );
diff -Nru flex-2.6.1/src/gen.c flex-2.6.1/src/gen.c
--- flex-2.6.1/src/gen.c	2016-03-01 12:08:30.0 +0100
+++ flex-2.6.1/src/gen.c	2016-12-30 23:28:29.0 +0100
@@ -1973,7 +1973,7 @@
 		("if ( yy_act != YY_END_OF_BUFFER && yy_rule_can_match_eol[yy_act] )");
 	++indent_level;
 	indent_puts ("{");
-	indent_puts ("yy_size_t yyl;");
+	indent_puts ("int yyl;");
 	do_indent ();
 	out_str ("for ( yyl = %s; yyl < yyleng; ++yyl )\n",
 		 yymore_used ? (yytext_is_array ? "YY_G(yy_prev_more_offset)" :
diff -Nru flex-2.6.1/src/skel.c flex-2.6.1/src/skel.c
--- flex-2.6.1/src/skel.c	2016-03-02 01:54:10.0 +0100
+++ flex-2.6.1/src/skel.c	2016-12-30 23:28:29.0 +0100
@@ -18,10 +18,10 @@
   "%#  through m4. Macros beginning with `m4_' will be processed.",
   "%#  The quoting is \"[[\" and \"]]\" so we don't interfere with",
   "%#  user code.",
-  "%# ",
+  "%#",
   "%# All generate macros for the m4 stage contain the text \"m4\" or \"M4\"",
   "%# in them. This is to distinguish them from CPP macros.",
-  "%# The exception to this rule is YY_G, which is an m4 macro, ",
+  "%# The exception to this rule is YY_G, which is an m4 macro,",
   "%# but it need

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   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}) {

Bug#838133: flex: FTBFS on hurd-i386

[Christoph Berg]

NMU diff attached.

Christoph

No differences were encountered between the control files

diff -Nru flex-2.6.1/debian/changelog flex-2.6.1/debian/changelog
--- flex-2.6.1/debian/changelog	2017-01-04 20:24:42.0 +0100
+++ flex-2.6.1/debian/changelog	2017-01-04 20:24:42.0 +0100
@@ -1,3 +1,11 @@
+flex (2.6.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on hurd (upstream 7975c43384d766ca12cb3f292754dbdc34168886).
+(Closes: 838133).
+
+ -- Christoph Berg   Wed, 04 Jan 2017 19:53:51 +0100
+
 flex (2.6.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru flex-2.6.1/src/main.c flex-2.6.1/src/main.c
--- flex-2.6.1/src/main.c	2016-03-01 01:06:56.0 +0100
+++ flex-2.6.1/src/main.c	2017-01-04 20:24:42.0 +0100
@@ -358,8 +358,8 @@
 			if (!path) {
 m4 = M4;
 			} else {
+int m4_length = strlen(m4);
 do {
-	char m4_path[PATH_MAX];
 	int length = strlen(path);
 	struct stat sbuf;
 
@@ -367,19 +367,17 @@
 	if (!endOfDir)
 		endOfDir = path+length;
 
-	if ((endOfDir-path+2) >= sizeof(m4_path)) {
-	path = endOfDir+1;
-		continue;
-	}
+	{
+		char m4_path[endOfDir-path + 1 + m4_length + 1];
 
-	strncpy(m4_path, path, sizeof(m4_path));
-	m4_path[endOfDir-path] = '/';
-	m4_path[endOfDir-path+1] = '\0';
-	strncat(m4_path, m4, sizeof(m4_path));
-	if (stat(m4_path, &sbuf) == 0 &&
-		(S_ISREG(sbuf.st_mode)) && sbuf.st_mode & S_IXUSR) {
-		m4 = strdup(m4_path);
-		break;
+		memcpy(m4_path, path, endOfDir-path);
+		m4_path[endOfDir-path] = '/';
+		memcpy(m4_path + (endOfDir-path) + 1, m4, m4_length + 1);
+		if (stat(m4_path, &sbuf) == 0 &&
+			(S_ISREG(sbuf.st_mode)) && sbuf.st_mode & S_IXUSR) {
+			m4 = strdup(m4_path);
+			break;
+		}
 	}
 	path = endOfDir+1;
 } while (path[0]);


signature.asc
Description: PGP signature

Bug#850253: retty doesn't work anymore

[Christoph Berg]

Package: retty
Version: 1.0-2
Severity: grave

Hi,

while looking at fixing #817652 I tried to use retty but couldn't get
it to work. In the second terminal, nothing happens:

$ retty 3733
codesize: 138 codeaddr: ff99840c
stack: ff9983fc eip: ff998414 sub:48
^C
^\Verlassen

^C doesn't quit retty; on hitting ^\ the to-be-attached-to process
segfaults.

Kernel: amd64 4.7.6-1, in a i386 chroot (with linux32 personality).

Maybe it's time to RM retty?

(The packaging repo is now at
ssh://git.debian.org/git/collab-maint/pkg-retty.git if someone manages
to fix it.)

Christoph


signature.asc
Description: PGP signature

Bug#828556: sslscan: FTBFS with openssl 1.1.0

[Christoph Berg]

Re: Adrian Bunk 2016-12-21 <20161221212734.64mvgghokxot7...@bunk.spdns.de>
> On Wed, Nov 30, 2016 at 04:53:58PM +0100, Marvin Stark wrote:
> > Am 2016-11-10 23:33, schrieb Sebastian Andrzej Siewior:
> >...
> > > Marvin: unless Adrian pulls out a patch I suggest you prepare a package
> > > to build against libssl1.0-dev. I have currently no better suggestion. I
> > > can sponsor the upload if you want me to.
> > 
> > Yes please. I'll prepare a new package these days.
> 
> ping

NMU diff:


Control files: lines which differ (wdiff format)

Build-Depends: debhelper (>= 9), {+libssl1.0-dev |+} libssl-dev {+(<< 1.1.0~)+}

diff -Nru sslscan-1.11.5-rbsec/debian/changelog 
sslscan-1.11.5-rbsec/debian/changelog
--- sslscan-1.11.5-rbsec/debian/changelog   2016-04-01 10:33:03.0 
+0200
+++ sslscan-1.11.5-rbsec/debian/changelog   2017-01-05 15:02:51.0 
+0100
@@ -1,3 +1,10 @@
+sslscan (1.11.5-rbsec-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build against openssl 1.0. (Closes: #828556)
+
+ -- Christoph Berg   Thu, 05 Jan 2017 15:02:51 +0100
+
 sslscan (1.11.5-rbsec-1) unstable; urgency=medium
 
   * New Upstream release (Closes: #804616)
diff -Nru sslscan-1.11.5-rbsec/debian/control 
sslscan-1.11.5-rbsec/debian/control
--- sslscan-1.11.5-rbsec/debian/control 2016-04-01 10:33:03.0 +0200
+++ sslscan-1.11.5-rbsec/debian/control 2017-01-05 15:02:51.0 +0100
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Marvin Stark 
 Homepage: https://github.com/rbsec/sslscan
-Build-Depends: debhelper (>= 9), libssl-dev
+Build-Depends: debhelper (>= 9), libssl1.0-dev | libssl-dev (<< 1.1.0~)
 Standards-Version: 3.9.7.0
 
 Package: sslscan


Christoph


signature.asc
Description: PGP signature

Bug#828556: sslscan: FTBFS with openssl 1.1.0

[Christoph Berg]

Re: Sebastian Andrzej Siewior 2017-01-05 
<20170105203350.67bp6zhioblxu...@breakpoint.cc>
> On 2017-01-05 15:08:00 [+0100], Christoph Berg wrote:
> > NMU diff:
> > 
> > 
> > Control files: lines which differ (wdiff format)
> > 
> > Build-Depends: debhelper (>= 9), {+libssl1.0-dev |+} libssl-dev {+(<< 
> > 1.1.0~)+}
> 
> why on libssl-dev (<< 1.1.0~)?

The | libssl-dev (<< 1.1.0~) part is there to enable backporting to
jessie without having to revert libssl1.0-dev back to libssl-dev.

> Otherwise I'm fine with it. I asked the release team & security if they
> object adding openssl's source to sslscan and the release was not too
> happy about it. With latest libssl1.0 upload sslscan won't be able to
> detect 3des ciphers…

I guess with openssl 1.1 that would also be the case so it doesn't
make a difference.

Christoph

Bug#850308: [Debian-ha-maintainers] Bug#850308: drbd-doc: Move from asciidoc to asciidoc-base as build dependency

[Christoph Berg]

Re: Joseph Herlant 2017-01-05 

> In addition to that, the xmlto package has been added to the
> recommends of the asciidoc-base package in #692274, so it might not be
> mandatory to have it in the buid-depends if you currently have it.

Assuming Recommends to be automatically installed as Build-Depends is
wrong.

Christoph

Bug#839954: PostgreSQL packages in Debian, problems on startup

[Christoph Berg]

Package: postgresql-common

Re: deavid 2016-10-05 

> Hello Cristoph,
> 
> First of all, thank you a lot for your hard work on your tools for
> postgresql clusters. It is very helpful indeed. PostgreSQL is a lot easier
> to work with in Debian & Ubuntu thanks to those tools.
> 
> I want to inform you about an issue, maybe because several bugs or misuse
> for my part. I don't know.
> 
> The issue itself can be explained as: init.d scripts manage a list of
> servers/clusters different than the one in pg_lscluster.
> 
> The effect is always the same, I end with some special cluster which
> doesn't start or stop when called from /etc/init.d/postgresql start/stop.
> When I try to manually start it, it does without problems.
> 
> I had several talks in IRC on #postgres channel of Freenode, also i asked
> on #debian and #debian-next and no one had a clue.
> 
> Finally I traced the problem. And it seems to be a lack of documentation,
> and maybe some bugs. I could trace it thanks to your documentation in
> README files of postgresql-common package, but I think it could be better
> explained.
> 
> The problem lies in that init.d files rely on systemctl, which I don't know
> how it works. Seems the second list is in
> /var/run/systemd/generator/postgresql.service.wants/
> 
> I would recommend to add a tool to check this folder and do some repair,
> and output a log of possible problems.
> 
> I've found 3 ways to get a broken list in systemd:
> 
> 1) Failed pg_upgradecluster due to failure on postgresql.conf migration:
> From 9.3 to 9.5 several options have changed and older options are no
> longer supported. If you have modified those options then they are
> uncommented. Most notable is checkpoint_segments, which the default is too
> low, and disappears in newer versions. When the script tries to finally
> "start" the cluster, it fails, and forgots to update systemd services; so
> when you manually fix postgresql.conf there's no way to "resume" the
> upgrade.

> On the pg_upgradecluster failure, is an old problem now. I believe it was
> wheezy, so it should be version 134wheezy4 or similar.
> For the other two, they ocurred this week on an updated Jessie system, so
> they should be version 165+deb8u1

Hi deavid,

both the unknown options and the systemd integration with
pg_upgradecluster have been fixed in the meantime; unfortunately not
in the jessie version of postgresql-common. Though if you say
9.5, is that from apt.postgresql.org? If so, make sure to upgrade to
the postgresql-common version from there as well.

> 2) Placing a dash (-) in the cluster name. Seems its a separator for your
> scripts. When you do this, pg_createcluster doesn't notice and continues,
> leaving you with a working cluster that doesn't start on boot.

This has also been, well, addressed. It's not really fixable, see
/lib/systemd/system/postgresql\@.service because of the way how
instanced systemd service units work. pg_createcluster will now warn
if you create a cluster with a dash in the name.

> 3) Using pg_renamecluster. It leaves old names in systemd.

That item is still open, thanks for spotting.

> I would recommend:
> * Add --skip-systemctl-redirect to the man page of pg_ctlcluster. It is
> useful for debug problems. I had to drill down through the perl scripts to
> find the option. (I do not know perl)

Aye.

> * Document in pg_ctlcluster how to fix if one cluster doesn't start on boot.

Possibly, will think about it.

> What I did manually to fix this:
> * Modified the names of symlinks in
> /var/run/systemd/generator/postgresql.service.wants/

"systemctl daemon-reload" should have done that (that's what was
missing in the old pg_upgradecluster version).

> * systemctl daemon-reload
> * systemctl stop postgresql
> * pg_lsclusters to see if anyone is still runing, and stop it with
> "pg_ctlcluster --skip-systemctl-redirect"

That was the other half of the breakage; the cluster would not be
started via systemd during the upgrade.

> * systemctl start postgresql
> * pg_lsclusters to see if every cluster is running again.
> 
> I've checked a dozen times /etc/postgresql/9.5/*/start.conf ; but it has
> its original contents. I tried "manual" and it doesn't help, so i put
> "auto" again on it.

If you change start.conf, you need to "systemctl daemon-reload" to get
the generator symlinks updated.

Christoph

Bug#807428: [Debian-ha-maintainers] Bug#807428: Bug#807428: csync2: socket activation and running as system user

[Christoph Berg]

Re: Valentin Vidic 2016-10-16 
<20161016081037.btwvht6ol4ro2...@gavran.carpriv.carnet.hr>
> On Wed, Jun 22, 2016 at 09:39:22AM +0200, Christoph Berg wrote:
> > Don't get me wrong, I would also like to see it handled via systemd,
> > but at the moment I think it would cause more trouble than it would
> > solve.
> 
> What if we move inetd to recommends and ship systemd service in disabled
> state?  It should not break the upgrade and still allow users to remove
> inetd if this is the only inet daemon they need to run.

That might work, I guess.

Christoph

Bug#794103: Processed: apr-util has unsatisfiable cross Build-Depends

[Christoph Berg]

Re: Debian Bug Tracking System 2016-10-15 

> Processing control commands:
> 
> > affects 794103 + src:apr-util
> Bug #794103 [libpq-dev] please support cross compilation using libpq-dev as a 
> build-dependency
> Added indication that 794103 affects src:apr-util

Hi,

While I still agree that pg_config shouldn't get in the way of
cross-compilation, I'll note that apr-util's use of pg_config looks
like it could easily be replaced by "pkg-config libpq --cflags"
(pg_config --includedir) and "pkg-config libpq --libs-only-L"
(pg_config --libdir).

I'm not sure what it does with pg_config --libs, that flag is
basically only useful when linking the PG server itself.

Christoph

Bug#836647: [Pkg-postgresql-public] Bug#836647: postgresql-9.5: please drop the build dependency on hardening-wrapper

[Christoph Berg]

Re: Matthias Klose 2016-09-04 
> Package: postgresql-9.5
> Version: 9.5.4-1
> Severity: important
> Tags: sid stretch
> User: debian-...@lists.debian.org
> Usertags: hardening-wrapper
> 
> This package builds using the hardening-wrapper package, which
> is now replaced by dpkg-dev's DEB_BUILD_MAINT_OPTIONS settings.
> 
> Please consider dropping the build dependency of hardening-wrapper
> and use the DEB_BUILD_MAINT_OPTIONS settings.

The actual dependency here is

Build-Depends: dpkg-dev (>= 1.16.1~) | hardening-wrapper

i.e. hardening-wrapper is only there as an alternative build-
dependency for older distributions. Given that both wheezy and
precise have at least that dpkg version, we'll remove it.

Christoph


signature.asc
Description: PGP signature

Bug#833748: [Pkg-postgresql-public] Bug#833748: postgresql: postgresql should wait for openvpn on boot

[Christoph Berg]

Control: tags -1 moreinfo

Re: Michal Palenik 2016-08-08 
<147065968559.21769.7310622273041887833.reportbug@localhost>
> Package: postgresql-9.5
> Version: 9.5.3-1
> Severity: normal
> File: postgresql
> 
> Dear Maintainer,
> 
> on boot postgresql server should have openvpn (or any other VPN server) 
> loaded and ready before starting postgresql server.
> 
> if postgresql server is listening on a vpn device (tun, tap) and if this 
> device does not exist (because the vpn server is not started yet), 
> the postgresql server starts but it listens only on the available 
> devices/sockets. 
> 
> probably adding "openvpn" into Required-Start: of /etc/init.d/postgresql 
> should do the trick (but I have no box without openvpn)

Hi Michal,

thanks for the suggestion.

Adding a specific VPN solution (openvpn) to the init script of some
other daemon seems like the wrong solution to me. I'd be more in
favour if there was a generic $vpn_networking target, but even that
would likely just fix the problem for your case, but not in general.
What if openvpn is configured to authenticate users via a PostgreSQL
database (directly or via pam)? Then the dependency would need to
point in the other direction.

(Does systemd offer any help here?)

Other solutions for your case would be to listen on "*" instead, or to
configure ipv4.ip_nonlocal_bind or ipv6.ip_nonlocal_bind in the kernel
to allow daemons to bind to an IP before that IP is actually
configured on the system.

Christoph


signature.asc
Description: PGP signature

Bug#255208: [Pkg-postgresql-public] Bug#255208: obsolete?

[Christoph Berg]

Re: Peter Eisentraut 2016-08-08 
<1e904e8c-0abc-71ac-6d19-bb7255cec...@debian.org>
> On 8/8/16 10:05 AM, Christoph Berg wrote:
> > I'm still curious why PG doesn't just cancel the query by itself on
> > SIGPIPE. Is there any value in running queries to completion when the
> > user has already left? Are these queries even committed?
> 
> I haven't tested this in detail for local socket connections, but for
> TCP/IP, the backend carries on if the client disappears.  The
> server-side TCP keepalive settings are there to control this to some extent.

I mean... why? If PG receives SIGPIPE in that case (I haven't tested
it, but I believe it does), why carry on?

(Of course TCP keepalive is still useful for the cases where the remote
OS didn't send a RST, but when it does, why not use it?)

Christoph


signature.asc
Description: PGP signature

Bug#834129: RFP: pgadmin4 -- graphical administration tool for PostgreSQL, generation 4

[Christoph Berg]

Package: wnpp
Severity: wishlist

* Package name: pgadmin4
  Version : 1.0
* URL : https://www.pgadmin.org/
* License : PostgreSQL (BSD)
  Programming Lang: python, javascript, jquery
  Description : graphical administration tool for PostgreSQL, generation 4

  pgAdmin 4 is a complete rewrite of pgAdmin, built using Python and
  Javascript/jQuery. A desktop runtime written in C++ with Qt allows
  it to run standalone for individual users, or the web application
  code may be deployed directly on a webserver for use by one or more
  users through their web browser. The application has the look and
  feel of a modern desktop application whatever the runtime
  environment is, and vastly improves on pgAdmin 3 with improved user
  interface elements, multi-user/web deployment options, dashboards
  and a much more modern design.


The PostgreSQL packaging team is looking for help creating and
maintaining this package under the team umbrella. Please get in touch
with us if you are interested.

Christoph


signature.asc
Description: PGP signature

Bug#837730: [Pkg-postgresql-public] Bug#837730: postgresql: Debian should package pglogical

[Christoph Berg]

Re: cl...@jhcloos.com 2016-09-14 
<147380902566.26602.11492487930589170944.report...@ore.jhcloos.com>
> pglogical  provides
> very useful replication capabilities lacking from pg and does so in an
> arguably better way than packages like slony.

Hi,

thanks for the suggestion.

If anyone want to work on this, please get in touch with me so we can
arrange to the pkg-postgresql group on alioth.

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#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#838582: ITP: python-testing.postgresql -- Python unit testing helper for temporary PostgreSQL databases

[Christoph Berg]

> The testing.postgresql package is a helper module for unit testing Python
> database applications. It provides methods for setting up, maintaing,
> and cleaning up a PostgreSQL database server that can be used within a test
> suite. A real PostgreSQL server is started as an instance in a temporary
> directory and removed after running the tests.
> 
> The package would enable Debian package builds to use it and to enable
> unit tests of Python packages that use databases. Right now, the only
> way to build packages that do is to disable the tests.

Hi,

fwiw, if you wrap the build in `pg_virtualenv`, you'll also get a
temporary database cluster that would be thrown away at the end.

Christoph


signature.asc
Description: PGP signature

Bug#830888: PostgreSQL question due to dbconfig bug #830888

[Christoph Berg]

Hi,

I was on vacation last week and couldn't answer earlier here.

Re: Paul Gevers 2016-08-19 
> Would you agree with me, i.e. do you know the following to be true, that
> peer authentication requires Unix socket (localhost)

This is true.

> and that Unix socket requires peer identification for PostgreSQL?

This is true in the default config (pg_createcluster), but can be set
to various other authentication mechanisms, the most widely used next
to "peer" being "md5", but it could also be "pam", "ldap", and others.

> I tried the other day to have password authentication via the Unix
> socket, but that failed:
> root@sid:/# psql -U icinga234 -W
> Password for user icinga234:
> psql: FATAL:  Peer authentication failed for user "icinga234"

You can't force the use of password authentication, the server will
always use the authentication method configured in pg_hba.conf, based
on the client connection parameters (unix vs tcp/ip, user name,
database name, IP address). The psql -W parameter is mostly useless in
practise.

> If this is true, I think it warrants some improved logic during config.
> 
> By the way, I see that PostgreSQL has a lot more authentication
> possibilities than when Sean invented dbconfig. I don't think I am going
> to support this on the short/mid term, but it may warrant improved
> messages here and there.

I don't think you should be trying to implement too much logic on the
dbconfig-common side here. I'd suggest this:

simple mode: assume a default config cluster, i.e. OS user "postgres",
database user "postgres", unix socket in /var/run/postgresql/.

advanced mode: Ask the user for
 * database hostname, or blank for default "/var/run/postgresql" or a
   full path name for different UNIX socket
 * database (super)user (default postgres)
 * database password (default blank which suits peer authentication)
 * whatever other parameters dbconfig-common wants (DB to create, DB
   user to create if not existing)

You can prompt the user which way they want; simple mode should be the
default.

If you unconditionally run the database commands as OS user
"postgres", you don't even need to prompt the user for that variable.
(The case of non-postgres clusters using peer UNIX socket
authentication would be left unsupported, but that's rare, and the
user can easily provide a password that works via TCP/IP on
localhost.)

Note that in the above scheme you don't need to know which
authentication method the server is using, or if the connection is
TCP/IP or a UNIX socket, everything should Just Work.

Christoph


signature.asc
Description: PGP signature

Bug#830888: PostgreSQL question due to dbconfig bug #830888

[Christoph Berg]

Re: Paul Gevers 2016-08-23 <08bfe08d-1fb9-c8cc-9a35-1f309dce1...@debian.org>
> Hi Christoph(s),

:)

> > simple mode: assume a default config cluster, i.e. OS user "postgres",
> > database user "postgres", unix socket in /var/run/postgresql/.
> 
> Sure, this works for setting up things and is what is being done, but
> most programs will not be the postgres user when connecting (and mapping
> to postgres also sounds like a bad idea). So the simple mode has to
> still set things up correctly for the final (system) user. Currently it
> uses TCP/IP and password authentication as default because (quoting the
> template): "typically the system username doesn't match the database
> username". It seems this default works OK(ish). I haven't seen complains
> on this front yet.

Oh right, I was only thinking about the initial connection for
creating that user. (Though I guess if you create that user yourself,
you don't need to prompt for anything in the "simple and fast" mode.)

> > If you unconditionally run the database commands as OS user
> > "postgres", you don't even need to prompt the user for that variable.
> 
> On local systems, postgres it detected and used (by default). However, I
> need the prompt because the database may be on a different host. Or do
> you mean to say that even for remote connections, I could just make the
> connection as postgres user. How about (yes unsafe) ident authentication?

IMHO forget about "ident" please, I haven't seen anyone use that since
the 90ies (and that was for IRC back then). The local OS user
shouldn't matter for remote connections.

Christoph

Bug#820427: Show non-debug packages first in output

[Christoph Berg]

Source: diffoscope
Version: 51
Severity: wishlist

Hi,

looking at
https://tests.reproducible-builds.org/dbd/unstable/amd64/heartbeat_3.0.6-3.diffoscope.html
I first had to scroll over a lot of uninformative (?) debug symbols
stuff, only to see that the "real" difference in the packages had been
cut off from the output due to "Max output size reached".

Even if the output is not truncated, I've frequently had the case in
the past that the interesting part was hidden at the end or (worse)
somewhere in the middle, because -dbgsym packages were checked first.

So the idea would be simply to reorder the output to show the -dbgsym
and -dbg package differences last.


More ideas:

* Apply the max size filter also to subsections, e.g. cut off and
  overly lengthy debug diff and still allow for other things to be
  shown

* Add a table of contents at the top to show which objects are diffed.
  (The html anchors for jumping to the objects are already there :)

* Maybe add "collapse this section" knobs to allow hiding
  uninteresting or already-read sections

  * Maybe collapse some sections by default, e.g. the md5sums file
diff is neither helpful (there are just hashes) nor informative
(well there are differences elsewhere, so these are differing) in
normal cirumstances

* Drop the outmost table border, my browser already has a window
  border of its own :)


Thanks!
Christoph

Bug#820494: origtargz: leaves "upstream" files in "master" after invocation

[Christoph Berg]

Control: tags -1 moreinfo

Re: Dmitry Smirnov 2016-04-09 <4233478.bJBLRpzaE8@deblab>
> When "pristine-tar" and "upstream" branches are present, "origtargz" leaves 
> upstream files in "master" after tarball generation.
> 
> This is a quite annoying behaviour for repositories where "master" tracks 
> only Debian packaging without upstream files (e.g. gbp.conf/import-orig/
> merge=False).
> 
> For example if I run "origtargz" in "cadvisor" repository I have to remove 
> files from "upstream" branch that "origtargz" left in "master"...

Hi,

did you meant to report this for mk-origtargz instead?

Though both origtargz and mk-origtargz don't do anything directly with
git and branches, so I'm wondering where you got that connection from?

Christoph

Bug#820494: origtargz: leaves "upstream" files in "master" after invocation

[Christoph Berg]

Re: Dmitry Smirnov 2016-04-09 <2265949.YxrWVc7PcZ@deblab>
> > Though both origtargz and mk-origtargz don't do anything directly with
> > git and branches, so I'm wondering where you got that connection from?
> 
> From "origtargz" functionality of course. One can checkout package repository 
> with upstream and pristine-tar branches and generate orig tarball using 
> "origtargz" even if package is not uploaded yet in which case tarball is 
> generated straight from repository.
> origtargz(1) man page says "The main use for origtargz is with debian-dir-
> only repository checkouts" which IMHO is precisely what does not work as 
> expected.
> 
> I did not have much time to investigate root cause of the problem. Perhaps 
> you know better what exactly is not working properly. It could be "pristine-
> tar" or something else... Please feel free to reassign.
> 
> I think I've described symptoms precisely so it should be easy to reproduce.

Hi,

I think your idea from what the program is doing is just wrong.
There's two parts:

1) tarball downloading - that makes sure there is a
../foo_1.0.orig.tar.* file for the current version of your package.
The version number is determined from debian/changelog. There's a few
methods to download the package, apt-get source, pristine-tar, and
uscan. Neither of these are supposed to mess with the current
directory. (Possibly uscan will try to upgrade the current directory,
depending on your ~/.devscripts.)

What method was used to download the file is shown on "origtargz"
invocation

2) unpacking - if the current directory contains debian/ only, or
--unpack is passed, origtargz does the equivalent of "rm -rf
*-except-debian", and unpacks the orig tarball to the current
directory.

Neither of these steps touch anything git-related, so I don't see how
you got the connection to the "upstream" branch.

What differences exactly are you seeing after unpacking?

Christoph

Bug#820494: origtargz: leaves "upstream" files in "master" after invocation

[Christoph Berg]

Re: Dmitry Smirnov 2016-04-09 <2265949.YxrWVc7PcZ@deblab>
> From "origtargz" functionality of course. One can checkout package repository 
> with upstream and pristine-tar branches and generate orig tarball using 
> "origtargz" even if package is not uploaded yet in which case tarball is 
> generated straight from repository.

Btw, origtargz does not generate any tarballs, it just tries to copy
them from various locations (including pristine-tar).

Christoph

Bug#820494: origtargz: leaves "upstream" files in "master" after invocation

[Christoph Berg]

Re: Dmitry Smirnov 2016-04-09 <1740755.tD23JeLo3f@deblab>
> Sometimes "upstream" branch is the only place where "origtargz" can get 
> sources for orig tarball. This is exactly the case where it leaves contents 
> of tarball (or upstream branch) behind.

Sorry, this is just plain wrong. origtargz does not look into git
branches. If any of the backends used do that, which backend is used?

> > What differences exactly are you seeing after unpacking?
> 
> Contents of orig.tar left behind.

Where? How do they look like? Paste an example please.

Christoph