Bug#748918: postgrey fails to start

2014-06-26 Thread Axel Beckert
Control: tag -1 - moreinfo

Hi,

Axel Beckert wrote:
  A fresh install of postgrey on two Wheezy machines fails to start.
[...]
 I also can't reproduce this issue with my postgrey installations
 running under Wheezy (and with perl 5.14.2-21+deb7u1).
 
 Do you have any third-party APT repositories in your sources.list
 which may have updated some dependencies of postgrey? Can you run the
 which-pkg-broke tool from the debian-goodies package like this:
 
 $ which-pkg-broke postgrey

Sorry, this is unnecessary on fresh installs. No need to check this.

Will check in a VM with a virgin Wheezy if I can reproduce the issue
there.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert a...@debian.org, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


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



Bug#748918: postgrey fails to start

2014-06-26 Thread Geoff

On 26/06/14 18:52, Axel Beckert wrote:

You can find it http://snapshot.debian.org/package/perl/5.14.2-21/

A first glance at /usr/share/doc/perl/changelog.Debian.gz of
5.14.2-21+deb7u1 didn't reveal any changes which _obviously_ cause
such breakage. But it would be nice if you could check if the perl
stable update broke postgrey.


I've done that. Before I changed anything else, I reproduced the problem 
on my system by commenting out the patch I'd added, then checking if it 
still failed to start:


geoffc@skye:~$ sudo postgrey --inet 10023
2014/06/27-12:21:50 postgrey (type Net::Server::Multiplex) starting! 
pid(32321)

Resolved [localhost]:10023 to [::1]:10023, IPv6
Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
Binding to TCP port 10023 on host ::1 with IPv6
Insecure dependency in socket while running with -T switch at 
/usr/lib/perl/5.14/IO/Socket.pm line 80.



Then I downgraded perl-base and perl, and tried again.

geoffc@skye:~$ sudo dpkg -i perl*deb
dpkg: warning: downgrading perl from 5.14.2-21+deb7u1 to 5.14.2-21
(Reading database ... 49234 files and directories currently installed.)
Preparing to replace perl 5.14.2-21+deb7u1 (using 
perl_5.14.2-21_amd64.deb) ...

Unpacking replacement perl ...
dpkg: warning: downgrading perl-base from 5.14.2-21+deb7u1 to 5.14.2-21
Preparing to replace perl-base 5.14.2-21+deb7u1 (using 
perl-base_5.14.2-21_amd64.deb) ...

Unpacking replacement perl-base ...
Setting up perl-base (5.14.2-21) ...
Processing triggers for man-db ...
Setting up perl (5.14.2-21) ...

geoffc@skye:~$ sudo postgrey --inet 10023
2014/06/27-12:23:17 postgrey (type Net::Server::Multiplex) starting! 
pid(32660)

Resolved [localhost]:10023 to [::1]:10023, IPv6
Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
Binding to TCP port 10023 on host ::1 with IPv6
Insecure dependency in socket while running with -T switch at 
/usr/lib/perl/5.14/IO/Socket.pm line 80.



As we can see, the problem still existed. But when I re-upgraded 
perl-base back I noticed I'd introduced a dependency problem with the 
'perl' package. It's possible I should have downgraded both perl-base 
and perl to do an accurate test.



On 26/06/14 18:52, Axel Beckert wrote: Do you have any third-party APT 
repositories in your sources.list

 which may have updated some dependencies of postgrey? Can you run the
 which-pkg-broke tool from the debian-goodies package like this:

 $ which-pkg-broke postgrey

 and send the output to the bug report?

I have no third party repositories. I ran which-pkg-broke. I wasn't 
familiar with this tool, and now that I've run it I suspect it won't 
help, as you've already noted. But here is the output anyway:


Package perlapi-5.14.2 has no install time info
Package libmime-base64-perl has no install time info
Package debconf-2.0 has no install time info
libattr1:amd64 Sat Nov  9 
20:05:48 2013
libacl1:amd64  Sat Nov  9 
20:05:48 2013
libbz2-1.0:amd64   Sat Nov  9 
20:05:49 2013
coreutils  Sat Nov  9 
20:05:50 2013
libdb5.1:amd64 Sat Nov  9 
20:05:50 2013
debconfSat Nov  9 
20:05:51 2013
debianutilsSat Nov  9 
20:05:51 2013
libgcc1:amd64  Sat Nov  9 
20:05:55 2013
gcc-4.7-base:amd64 Sat Nov  9 
20:05:55 2013
libsemanage-common Sat Nov  9 
20:05:57 2013
libselinux1:amd64  Sat Nov  9 
20:05:57 2013
libsemanage1:amd64 Sat Nov  9 
20:05:57 2013
libsepol1:amd64Sat Nov  9 
20:05:58 2013
libpam0g:amd64 Sat Nov  9 
20:06:01 2013
libpam-modules:amd64   Sat Nov  9 
20:06:01 2013
libpam-modules-bin Sat Nov  9 
20:06:01 2013
sensible-utils Sat Nov  9 
20:06:02 2013
passwd Sat Nov  9 
20:06:03 2013
tarSat Nov  9 
20:06:05 2013
libustr-1.0-1:amd64Sat Nov  9 
20:06:05 2013
liblzma5:amd64 Sat Nov  9 
20:06:07 2013
zlib1g:amd64   Sat Nov  9 
20:06:08 2013
adduserSat Nov  9 
20:06:29 2013
libgdbm3:amd64 Sat Nov  9 
20:06:36 2013
install-info   Sat Nov  9 
20:06:59 2013
ucfSat Nov  9 
21:03:52 2013
libc-bin   Thu Mar 13 

Bug#748918: postgrey fails to start

2014-06-12 Thread Antonio Radici
On Wed, Jun 11, 2014 at 04:13:28PM +0200, Axel Beckert wrote:
 Control: tag -1 + fixed-upstream
 
 Hi,
 
 Geoff Crompton wrote on 22 May 2014:
  A fresh install of postgrey on two Wheezy machines fails to start. Much like
  was the case in debian bug #722136, starting the postgrey daemon on the
  command
  line reveals the same failure mode:
  
  $ sudo postgrey --inet 10023
  2014/05/22-19:09:07 postgrey (type Net::Server::Multiplex) starting!
  pid(15633)
  Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
  Binding to TCP port 10023 on host 127.0.0.1 with IPv4
  Insecure dependency in bind while running with -T switch at
  /usr/lib/perl/5.14/IO/Socket.pm line 202.
  
  Applying the same patch,
  https://github.com/yasuhirokimura/postgrey/commit/9673b54064691a5b9c295ffea340d8a1f9ee1cb8,
  fixes this problem for me.
 
 Despite not being mentioned in the upstream changelog[1], that patch
 has been applied[2] upstream and is part of the recent 1.35 upstream
 release[3].
 
 [1] http://postgrey.schweikert.ch/pub/Changes
 [2] https://github.com/schweikert/postgrey/commits/master
 [3] http://postgrey.schweikert.ch/pub/postgrey-1.35.tar.gz
 
 So packaging the new upstream release should fix the issue in Sid and
 Jessie. Maybe a stable-update with only that patch would be a good
 idea, too.
 
 Antonio and Jon: Do you need help in maintaining postgrey in Debian?
 
 I'm a long-time postgrey user at work as well as at home, and
 occassionally contribute to upstream's default whitelist. I also know
 postgrey's upstream developer from maintaining fping in Debian which
 has the same upstream developer. I could join you as co-maintainer.

Hi Axel,
if you have time it would be great if you could prepare an NMU for the patch at
the existing release and then I can add you as co-maintainer and we can work on
the 1.35 packaging (there is already a git, you just need to be on
collab-maint).

On the long run we should run postgrey using a team rather than a single person
(me), that should make things easier in terms of maintainership and uploads.

Does it sound good to you?

Cheers
Antonio


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



Bug#748918: postgrey fails to start

2014-06-11 Thread Axel Beckert
Control: tag -1 + fixed-upstream

Hi,

Geoff Crompton wrote on 22 May 2014:
 A fresh install of postgrey on two Wheezy machines fails to start. Much like
 was the case in debian bug #722136, starting the postgrey daemon on the
 command
 line reveals the same failure mode:
 
 $ sudo postgrey --inet 10023
 2014/05/22-19:09:07 postgrey (type Net::Server::Multiplex) starting!
 pid(15633)
 Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
 Binding to TCP port 10023 on host 127.0.0.1 with IPv4
 Insecure dependency in bind while running with -T switch at
 /usr/lib/perl/5.14/IO/Socket.pm line 202.
 
 Applying the same patch,
 https://github.com/yasuhirokimura/postgrey/commit/9673b54064691a5b9c295ffea340d8a1f9ee1cb8,
 fixes this problem for me.

Despite not being mentioned in the upstream changelog[1], that patch
has been applied[2] upstream and is part of the recent 1.35 upstream
release[3].

[1] http://postgrey.schweikert.ch/pub/Changes
[2] https://github.com/schweikert/postgrey/commits/master
[3] http://postgrey.schweikert.ch/pub/postgrey-1.35.tar.gz

So packaging the new upstream release should fix the issue in Sid and
Jessie. Maybe a stable-update with only that patch would be a good
idea, too.

Antonio and Jon: Do you need help in maintaining postgrey in Debian?

I'm a long-time postgrey user at work as well as at home, and
occassionally contribute to upstream's default whitelist. I also know
postgrey's upstream developer from maintaining fping in Debian which
has the same upstream developer. I could join you as co-maintainer.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert a...@debian.org, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


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



Bug#748918: postgrey fails to start

2014-05-22 Thread Geoff Crompton
Package: postgrey
Version: 1.34-1.1
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

A fresh install of postgrey on two Wheezy machines fails to start. Much like
was the case in debian bug #722136, starting the postgrey daemon on the
command
line reveals the same failure mode:

$ sudo postgrey --inet 10023
2014/05/22-19:09:07 postgrey (type Net::Server::Multiplex) starting!
pid(15633)
Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
Binding to TCP port 10023 on host 127.0.0.1 with IPv4
Insecure dependency in bind while running with -T switch at
/usr/lib/perl/5.14/IO/Socket.pm line 202.

Applying the same patch,
https://github.com/yasuhirokimura/postgrey/commit/9673b54064691a5b9c295ffea340d8a1f9ee1cb8,
fixes this problem for me.

I wonder if the changes introduced with perl-base 5.14.2-21+deb7u1
created the problem, but I haven't found a perl-base 5.14.2-21 package
to install to see if the problem goes away.

-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages postgrey depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.49
ii  libberkeleydb-perl 0.51-1
ii  libnet-dns-perl0.66-2+b2
ii  libnet-server-perl 2.006-1+deb7u1
ii  perl   5.14.2-21+deb7u1
ii  ucf3.0025+nmu3

Versions of packages postgrey recommends:
ii  libnet-rblclient-perl  0.5-2
ii  libparse-syslog-perl   1.10-2
ii  postfix2.9.6-2

postgrey suggests no packages.

-- debconf information:
  postgrey/1.32-3_changeport:


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