Hello Thorsten Glaser. On Tue, Sep 08, 2015 at 09:13:00AM +0200, Thorsten Glaser wrote: > On Mon, 7 Sep 2015, Andreas Henriksson wrote: > > > Could you please try the bsdutils version from experimental > > (as the version I just uploaded to unstable has probably not > > yet reached the mirrors when you read this) to check if > > No, the version from sid was what I just installed. > > Preparing to unpack .../bsdutils_1%3a2.27-1_x32.deb ... > Unpacking bsdutils (1:2.27-1) over (1:2.26.2-9) ... > Processing triggers for man-db (2.7.2-1) ... > Setting up bsdutils (1:2.27-1) ... > > This version still exhibits the problem.
I'm not able to reproduce your problem (only tested on 2.27-1), but I'm also not using syslog (only journal). This might mean that the problem is somewhere in the syslog-specific code in logger (which is where I think the most changes has been done lately). > > > Given you have reproducible testcase, in case you're interested in > > seeing this issue resolved you could run git bisect to find out > > Hm, I guess… need to learn how to do that first though… It's quite simple.... here's a quick tutorial: cd /tmp debcheckout --git-track '*' util-linux # Syntax: git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<paths>...] # To limit the scope, we'll guess that the problem is in logger.c # (If it's in a library or whereever, just leave the paths part out.) git bisect start v2.26.2 v2.25.2 -- misc-utils/logger.c # 10: now build the checkout you where given ./autogen.sh && ./configure && make logger # is the problem reproducible (or not)? ( echo foo ; sleep 5 ; echo bar ) | ./logger .... # Assuming it's still broken: git bisect bad # or if it was ok, use: git bisect good # goto 10 In just a few build/reproduce/mark-good-or-bad git will tell you the exact commit introducing the regression (via a binary search on the git history). Good luck! Regards, Andreas Henriksson
