Bug 205191 - mail/dcc-dccd: Fails stage-qa
Summary: mail/dcc-dccd: Fails stage-qa
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2015-12-10 13:42 UTC by Yuri Victorovich
Modified: 2016-08-22 14:36 UTC (History)
3 users (show)

See Also:
pkubaj: maintainer-feedback+


Attachments
patch (3.29 KB, patch)
2015-12-17 21:54 UTC, Yuri Victorovich
no flags Details | Diff
patch (3.29 KB, patch)
2015-12-17 21:55 UTC, Yuri Victorovich
no flags Details | Diff
patch (1.53 KB, patch)
2015-12-17 23:03 UTC, Yuri Victorovich
no flags Details | Diff
[patch] alternate method for stripping installed binaries (859 bytes, patch)
2016-02-26 20:55 UTC, John Hein
pkubaj: maintainer-approval-
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer 2015-12-10 13:42:04 UTC
Options set: DCCD DCCGREY DCCIFD IPV6 DCCM

# make stage-qa
====> Running Q/A tests (stage-qa)
Warning: 'bin/cdcc' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'bin/dccif-test' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'bin/dccproc' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/dns-helper' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/ck2ip' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/dbclean' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/dccd' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/dump-clients' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/dblist' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/dccm' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/dccifd' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/dccsight' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/wlist' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'dcc/libexec/check_ip_range' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Error: Bad linking on [libedit.so.7] please add USES=libedit
Error: Bad linking on [libedit.so.7] please add USES=libedit
Error: Bad linking on [libedit.so.7] please add USES=libedit
*** Error code 1

10.2-STABLE
Comment 1 Mathieu Arnold freebsd_committer 2015-12-17 14:54:44 UTC
I've tried a few things, I can't seem to make it see reason and use the ports installed libedit. Can you provide a patch ?
Comment 2 Yuri Victorovich freebsd_committer 2015-12-17 21:54:21 UTC
Created attachment 164331 [details]
patch

The patch fixes stage-qa, though causes some extra compile warnings.
I don't think it is easy to fix that.
Comment 3 Yuri Victorovich freebsd_committer 2015-12-17 21:55:36 UTC
Created attachment 164332 [details]
patch
Comment 4 Yuri Victorovich freebsd_committer 2015-12-17 22:00:23 UTC
mat@ When I made it to link with the ports libedit.so, port tests messed up the terminal, which indicates that this is the wrong libedit.so. There are several versions floating round, and these two might be incompatible.
Comment 5 Yuri Victorovich freebsd_committer 2015-12-17 23:03:56 UTC
Created attachment 164334 [details]
patch

Minimal patch performing these actions:
* Disable libedit
* Strips executables
Comment 6 John Hein 2016-02-26 19:53:23 UTC
(In reply to yuri from comment #4)
Can you clarify what you mean by 'port tests messed up the terminal' when you linked with the libedit port?  I'm looking into getting this working with the ports version of libedit.
Comment 7 Yuri Victorovich freebsd_committer 2016-02-26 20:16:32 UTC
When I enabled the ports version of libedit, the terminal settings were getting changed after the build or test, so that I had to run /usr/bin/reset to bring them back.
Comment 8 John Hein 2016-02-26 20:55:31 UTC
Created attachment 167457 [details]
[patch] alternate method for stripping installed binaries

Attached is a different method for getting the binaries stripped.  It's a bit simpler and is a possible candidate for submitting upstream.
Comment 9 John Hein 2016-02-26 21:43:05 UTC
(In reply to yuri from comment #7)
I narrowed it down a bit.

In my xterm the following line from dcc-1.3.158/homedir/fix-map changes my baud rate (as seen by stty -a) from 38400 to 50:

USING_DCC=`$CDCC_CMD info                       \
    | sed -n -e 's/^\([-a-z0-9]*\.dcc-servers\.net\),-.*/\1/p'`


CDCC_CMD is ../cdcc/cdcc.  Just running '../cdcc/cdcc info' doesn't cause the problem.  But piping it to something ('| cat' will do) perturbs the terminal settings as described.

That seems to be enough to mess up the xterm.  For example, if I 'vi' a file after that I only see the top 8 lines.  'stty speed 38400' "fixes" the issue.

This is after manually replacing -ledit in Makefile.inc with /usr/local/lib/libedit.so before 'make build'.

ldd ../cdcc/cdcc
../cdcc/cdcc:
        libmd.so.5 => /lib/libmd.so.5 (0x33c98000)
        libm.so.5 => /lib/libm.so.5 (0x33cb0000)
        libedit.so.0 => /usr/local/lib/libedit.so.0 (0x33ccb000)
        libncurses.so.8 => /lib/libncurses.so.8 (0x33cf9000)
        libc.so.7 => /lib/libc.so.7 (0x33d3a000)


This doesn't trigger the issue:

env LD_PRELOAD=/lib/libedit.so.7 ../cdcc/cdcc info | cat


I don't have a fix or deeper analysis at the moment.  But it's not clear that this edge case bug is enough to avoid the ports version of libedit or not.  Seems like it might be helpful to narrow it down even a little more and possibly engage upstream maintainer of devel/libedit.  But I don't know if it matters enough for deciding whether to link with it for mail/dcc-dccd.  The basic line editing capability works fine when running cdcc at the command line when linked with the ports libedit.
Comment 10 John Hein 2016-02-27 17:01:01 UTC
I tracked it down.  This program reproduces it:

==================
% cat foo.c
#include <stdio.h>
#include <histedit.h>

static EditLine *el_e = 0;

int
main(int argc, char **argv)
{
        printf("start\n");
        el_e = el_init("foo", stdin, stdout, stderr);
        if (el_e)
                el_end(el_e);
        else
                printf("el_init failed\n");
        printf("end\n");
        printf("end\n");
        return 0;
}
====================

cc foo.c /usr/local/lib/libedit.so -o foo && ./foo | cat

'stty -a' shows the baud rate at 50.

If you look in the devel/libedit code, it looks like there's a case where code in el_end() tries to restore the original tty settings.  But if the output is not a tty, the original tty settings were never saved.  So it restores invalid termios settings.

It's possible cdcc should check for isatty() on the output file descriptor and not used libedit (it currently checks for the input file descriptor).  But libedit should not try to use termios settings for a structure that was never correctly populated.  So that's definitely a bug in libedit.

The [older] base version of libedit in freebsd just doesn't have the check for isatty() in tty_setup, so it doesn't short circuit the initialization code that populates the original termios settings structure.
Comment 11 John Hein 2016-02-27 17:50:02 UTC
upstream report for libedit bug:

http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50863
Comment 12 John Hein 2016-02-28 00:32:10 UTC
(In reply to John Hein from comment #11)
Fix committed upstream in netbsd libedit.  Now we just need the "mid-stream" portable package of libedit used by devel/libedit to sync with netbsd upstream.

But I wouldn't let this minor quibble of a bug to stop anyone from getting mail/dcc-dccd to use ports' libedit rather than the base version.  Or patch libedit with the upstream commit if you really want to.
Comment 13 Yuri Victorovich freebsd_committer 2016-02-28 21:39:40 UTC
Thanks for getting to the root of the problem!
Comment 14 Piotr Kubaj freebsd_committer 2016-03-07 10:27:44 UTC
I don't see any reason why this port couldn't use libedit from ports. The diff is simple:
Index: Makefile
===================================================================
--- Makefile	(revision 410510)
+++ Makefile	(working copy)
@@ -22,7 +22,7 @@
 
 HAS_CONFIGURE=	yes
 
-USES=	gmake tar:Z
+USES=	gmake libedit tar:Z
 
 OPTIONS_DEFINE=	DCCIFD DCCD DCCGREY IPV6 ALT_HOME
 OPTIONS_DEFAULT=	DCCIFD DCCM DCCD DCCGREY

It compiles fine on Poudriere with 10.2-RELEASE/amd64.
Comment 15 Piotr Kubaj freebsd_committer 2016-03-07 10:46:56 UTC
Actually, PORTREVISION should also be bumped.
Comment 16 John Marino freebsd_committer 2016-08-19 04:44:18 UTC
Piotr,
Just adding USES+=libedit will not fix stage-qa, I still see a bad linking message (I checked with synth).

I suggest that you make both attached patches "obsolete" and attach your own patch set that fixes it after testing with either "synth test" or "poudriere testport".  From what I can tell, none of the suggested fixed attached or in the comments fully/correctly addresses the issue.
Comment 17 Piotr Kubaj freebsd_committer 2016-08-22 12:14:45 UTC
(In reply to John Marino from comment #16)
Actually, the patch provided by Yuri fixes the issue (output from Poudriere):
===========================================================================
====> Running Q/A tests (stage-qa)
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
===> Checking for items in pkg-plist which are not in STAGEDIR
===> No pkg-plist issues found (check-plist)
====>> Checking for staging violations... done
=======================<phase: package        >============================
===>  Building package for dcc-dccd-1.3.158_1

I think we can commit it.
Comment 18 Piotr Kubaj freebsd_committer 2016-08-22 12:17:54 UTC
(In reply to Piotr Kubaj from comment #17)
Hmm, I try to set maintainer-approval+, but nothing is set and I get:

Changes to attachment 164334 [details] of bug 205191 submitted

    Email sent to:
        no one 




It seems to be some bug in Bugzilla, anyway, I approve it.
Comment 19 John Marino freebsd_committer 2016-08-22 12:57:32 UTC
Piotr, Yuri's patch isn't good.

The first part of the patch, the stripping, is done better by John Hein's patch.

The second part of the patch, is attempted to break the detection for libedit.
1) The method to this this is a complete hack, that can be done by setting CONFIGURE_ARG+= ac_cv_header_histedit_h=no
2) It removes the functionality that libedit would provide

It appears your criteria for "good" is that the error message goes away, but I don't share the same opinion on the patch.

I would start by changing the configure script to add -L$(prefix)/lib before -ledit and changing -ltermcap to -lncurses  and I would use John's patch to fix the stripping.  Let's fix the actual problem, rather than cripple this to satisfy a qa message.
Comment 20 John Marino freebsd_committer 2016-08-22 14:03:20 UTC
actually john's patch isn't right either because it strips unconditionally which is wrong when stripping is disabled.
Comment 21 commit-hook freebsd_committer 2016-08-22 14:32:36 UTC
A commit references this bug:

Author: marino
Date: Mon Aug 22 14:31:40 UTC 2016
New revision: 420617
URL: https://svnweb.freebsd.org/changeset/ports/420617

Log:
  mail/dcc-dccd: fix stage-qa issues

  1) implements stripping of executable binaries
  2) disables libedit detection and linking

  dcc-dccd keeps trying to link to the base libedit instead of the
  required ports version (when USES+=libedit is added).  For now, just
  build without until somebody finds a way get libedit linkage correct.
  This solves both issues seen with stage-qa

  PR:		205191
  Reported by:	Yuri (rawbw.com)
  Utimate fix:	marino@
  Approved by:	maintainer (conceptually)

Changes:
  head/mail/dcc-dccd/Makefile
  head/mail/dcc-dccd/files/patch-Makefile.inc2.in
  head/mail/dcc-dccd/files/patch-homedir_Makefile.in
  head/mail/dcc-dccd/files/patch-misc_Makefile.in
Comment 22 John Marino freebsd_committer 2016-08-22 14:36:00 UTC
i tried a few times to make USES=libedit work, but I wasn't success.  I only fiddled with the configure script but apparently the linking is done differently.

Since it was indicated disabling libedit was desired, that's what I did (but without a patch, I just used CONFIGURE_ENV in the port makefile).

The *correct* fixing of installing binaries required 3 patches.  Internally it's using one install command for both scripts and executables and those have to be separated because you can't strip a script without error messages.