NetBSD Problem Report #49421

From rooster@sibs2.localdomain  Wed Nov 26 21:10:10 2014
Return-Path: <rooster@sibs2.localdomain>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id EB3DDA5864
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 26 Nov 2014 21:10:09 +0000 (UTC)
Message-Id: <20141126130645.9C1C619983C@sibs2.localdomain>
Date: Wed, 26 Nov 2014 07:06:45 -0600 (CST)
From: phabrics@phabrics.com
Reply-To: phabrics@phabrics.com
To: gnats-bugs@gnats.NetBSD.org
Subject: new package
X-Send-Pr-Version: 3.95

>Number:         49421
>Category:       pkg
>Synopsis:       tme-1.0beta_4
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bsiegert
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 26 21:15:00 +0000 2014
>Closed-Date:    
>Last-Modified:  Mon May 30 00:04:44 +0000 2016
>Originator:     phabrics@phabrics.com
>Release:        NetBSD 6.1.5
>Organization:

>Environment:


System: NetBSD sibs2 6.1.5 NetBSD 6.1.5 (GENERIC) amd64
Architecture: x86_64
Machine: amd64
>Description:
TME modified to add features like GTK3 and NPF NAT
>How-To-Repeat:

>Fix:
begin 644 tme_gtk3_npf.tgz
M'XL(`(+%=50``^U8:V_B.!3MU^976-WY,+/;D'>`E9"&H;1%6V@%5!IIM4).
MXH!%7DJ<0F>U_WVO0VAI'D6:&75VM+D"JIQC7]OQO<>W3I-8BM;+)+8EXJ<>
M9F&<2,PGBR5;:XL@<D^^W619E]N&`7\SR_XJ[:?G#%-473,T7=5USBN&IL@G
MQG<8^ZBE"<,Q0B=Q&+*W&.\_9NFQ_9?&>$U<ZI&O'T-69-G4];K]5V3%W.^_
MK,H<5]KP.9&_WS+K[7^^_[^@=Q/"/LTNW@G"Q6@VG_3'P]XI!("HM&2+,+S0
MA4%_/KRZG8Z&L][I4Y`(X_YL/IPN9J,YQU>,1;]+TF:S:44K;,743EIVZ$O"
M\/-\VA_,%[/[R\\]A%`+7G=K^T6`_J/)'+[#:>]TW^7C85]!N+X=#^_Z5\-7
MW`]NQ^/A9-X[G8^'R`\=ZE+B(!8B[#C()9BE,4F01]<$7<W_T!`.'#2YNT23
M_ERX&0V&DQEX7P:IN(P\\4$3A*O)_6)P.[D<7=U/@7HDB7`_&RYN1I_FM[<W
M.T#@#:#W?+9[57_*8O>O7P6A15WT_MW?X_[@&M:UZ$\'U_^@7@^=;3OFPM3/
M/@A/GH&\FOW6.Q5%AR;8\H@8$SMTB-`B`2R"^PIL+W4(.FNU)/@XY(%XDD<M
MCSF>9(?!`PDH"6S2\M=GI=9;19%X!DM62CW'H\%:JVSGKR4K<5J@`!G]HZ.Q
ML;>VX_I_=P.R\$UC'-%_O:WGY[]JM#55X?IOJHK:Z/\;V$=049\$[/D8L&C`
M`T!,TD`D)(I!B`\AZAQ"R4K(%84_@=HD4AKAUDN4#Q$&93#R"*,51!`0NX(@
M'N$S+:!+$A`X#OC0(F@D!4&L;5##@`*O:RC"5B0.2-V@KE5'>"&NZT3M&F)-
M'JT0QTX-[8=I4K>XQ$YH'06_V*LA&8Z*+E<X616A,&'2[GP2?1]'K]!PTA58
M&`7[74/1RKC%=*-3AFE'-;85;B@AI&WH(DY96,^&4?)ZBPHBH5X;:LXRXYN=
M8FAP=*UWV'9;0?A&1S';90(BNFT:93R)<%P,!X"_=`RM.!LO7!80']LK&A`)
MTK+($#^,'ZM>PXXI@C0I3@)*J=0KAL9NCXM@&G@D6+)BT/"0S'Y$VRFFR2$'
M:E++5B;T`5U.W&?23XKOZYFK"'NVB@EVBA(!WS)2R@\6K@G?`JC.>(7&I3)/
ML):'#U&>*2)H2@'>!^9+--]>KKHOF9=/R9.W?'IBY*5+&B0MMF6'^`(4<`%G
M/*-<"E_VR;BD`B^L8P_SA2QXY5B%0^E0B4=A0K>5#'M>XAZG]@([2D<O=>"$
MW^Y"?E03W6HB4Z`RD6M-!;'7A#+E)=34.\_[=4!E>E$!YX)1P>2*468".S:T
M3M7X&6-WJ]P!U>G:BFQ4<3L-*A,[$:K`6:3*:M4R.:-6KF>G7`4\C^0%1++Z
M"E?:GP.N-(OLQ"MBV5&W6%N<2%8XAJ)ABWF=D=6TTNQ^(M[?P/^CHE)#J^(8
M&HP^W<]J&FCBH#^=#J?]&EX7VT85Y3]FU1.L*`YWF5G1B+?8%P&O-=)$&\<Q
MB7%>H!TTS5\%%%$NY?IWK/X[7O]?#&>#Z3?5F$?J?]E0]7W];VA:=O]C*H;9
MU/]O8/,50>-=FJ%A'@#G*(P1Q,`YH@G""")L&6,?L15F_.&!.H3CV=&`/5&(
MTABDG2`76I%-&*^1"PYX@9\R$J-=7/%Z'J$)V2`:@"OP'&%[C9?D7)AQ_4'W
M'HNQ@FP<((ODG8B#-BL29+ZHMW]RB)4N^=Q8"K6Y@\"S,`KXC0_EPYR_<(^@
MG@6'T"V-G,PC"[.KH//L+B@_QOEZ`K(1H#!`^?\9:$/9"O$2RH?9V_S&".W2
M*HVSY>P:3.XNX3VY"#]@ZO&+G-9/=8MR//^AR&(T<,.O'^-8_FOR_OY7TTU5
MR^Y_%4UI\O\-[/GV=W;=5]![=GCSF]_5?D`]I)H$M^VNZK1M4\&N[NB6#ON*
M+:VC8=V5S8[5<11"A.GX0C'E>D=&U\5=*)\L0];=CJW8AFL:-IP!+KC0W$Z[
MZV!9,QUA1K^0>C>*(INF+"/KD9'DI\JXQAIKK+'&&FNLL<8::ZRQ'V/_`F18
&Z,P`*```
`
end

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->bsiegert
Responsible-Changed-By: bsiegert@NetBSD.org
Responsible-Changed-When: Sat, 17 Jan 2015 14:35:10 +0000
Responsible-Changed-Why:
Taking this.


State-Changed-From-To: open->feedback
State-Changed-By: bsiegert@NetBSD.org
State-Changed-When: Sat, 17 Jan 2015 14:35:10 +0000
State-Changed-Why:
I imported the package into wip as wip/tme. I am confused about the context
of your submission though. Are you the upstream tme developer? Is this
supposed to replace emulators/tme?

The package does not work with parallel make (MAKE_JOBS=4), which would be
good to fix. Also, it does not build for me (with clang):
Making all in tun
depbase=`echo tun-tap.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; /bin/sh ../../libtool  --tag=CC    --mode=compile clang -DHAVE_CONFIG_H  -I. -I../..  -I../.. -I. -I./../eth -I. -D_TME_IMPL -DDEV_TAP_FILENAME="\"/dev/tap\"" -DTME_NAT_NFT -DTME_NAT_NPF -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include/libdrm -DTME_NO_LOG -DTME_NO_DEBUG_LOCKS -DTME_NO_AUDIT_ATOMICS -DNDEBUG   -O2 -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include/libdrm -Wno-unused -Wno-sign-compare -Wundef -Wall -Wextra -MT tun-tap.lo -MD -MP -MF $depbase.Tpo -c -o tun-tap.lo tun-tap.c && mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  clang -DHAVE_CONFIG_H -I. -I../.. -I./../eth -D_TME_IMPL -DDEV_TAP_FILENAME=\"/dev/tap\" -DTME_NAT_NFT -DTME_NAT_NPF -I/home/pkgbuild/wip/tme/work/.buildlink/include -I/home/pkgbuild/wip/tme/work/.x11-buildlink/include -I/home/pkgbuild/wip/tme/work/.x11-buildlink/include/freetype2 -I/home/pkgbuild/wip/tme/work/.x11-buildlink/include/libdrm -DTME_NO_LOG -DTME_NO_DEBUG_LOCKS -DTME_NO_AUDIT_ATOMICS -DNDEBUG -O2 -Wno-unused -Wno-sign-compare -Wundef -Wall -Wextra -MT tun-tap.lo -MD -MP -MF .deps/tun-tap.Tpo -c tun-tap.c  -fPIC -DPIC -o .libs/tun-tap.o
tun-tap.c:139:10: fatal error: 'net/npf_ncode.h' file not found
#include <net/npf_ncode.h>
         ^
1 error generated.

edamame$ uname -a 
NetBSD edamame.mirbsd.org 7.0_BETA NetBSD 7.0_BETA (GENERIC) #0: Sun Oct 26 22:51:31 UTC 2014  root@edamame.mirbsd.org:/usr/obj/sys/arch/amd64/compile/GENERIC amd64


From: phabrics@phabrics.com
To: gnats-bugs@netbsd.org
Cc: bsiegert@netbsd.org, pkg-manager@netbsd.org, pkgsrc-bugs@netbsd.org,
 gnats-admin@netbsd.org
Subject: Re: pkg/49421 =?UTF-8?Q?=28tme-=31=2E=30beta=5F=34=29?=
Date: Sat, 17 Jan 2015 14:35:35 -0700

 Hi!

 Thank you for your interest in this.  I am not the original tme 
 developer, which is why I did not submit it as a replacement.  This 
 package just contains some "upgrades" to the original package which 
 seems to have been static for a while now (save for a few patches here & 
 there).  These were my own work to try to get it to a "working enough" 
 state on some of my other boxes, as well as enhancements for them for 
 another project of mine to use as dependency at some point.  It had 
 gotten to the point where I had made enough updates that I thought it 
 would be worth sharing, but too big to be a patch.  If this duplication 
 is undesirable, I can resubmit to replace, but I didn't want to presume 
 that because it would be a major update and I wanted it to work well 
 enough not disturb anyone else who might depend on the original.

 Thanks for trying it - I had not tested it in 7.0beta yet, only the 
 latest release 6.1.5.  I thought I had tried llvm though (but on 
 FreeBSD) and parallel builds but maybe not.  That is unfortunate; sorry 
 it did not build for you... I will look into fixing these problems in 
 wip.  I know there are a few other issues that have come to my attention 
 since the submission and a few updates beyond that as well.

 Thanks again,
 Ruben Agin

 On 2015-01-17 07:35, bsiegert@NetBSD.org wrote:
 > Synopsis: tme-1.0beta_4
 > 
 > Responsible-Changed-From-To: pkg-manager->bsiegert
 > Responsible-Changed-By: bsiegert@NetBSD.org
 > Responsible-Changed-When: Sat, 17 Jan 2015 14:35:10 +0000
 > Responsible-Changed-Why:
 > Taking this.
 > 
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: bsiegert@NetBSD.org
 > State-Changed-When: Sat, 17 Jan 2015 14:35:10 +0000
 > State-Changed-Why:
 > I imported the package into wip as wip/tme. I am confused about the 
 > context
 > of your submission though. Are you the upstream tme developer? Is this
 > supposed to replace emulators/tme?
 > 
 > The package does not work with parallel make (MAKE_JOBS=4), which would 
 > be
 > good to fix. Also, it does not build for me (with clang):
 > Making all in tun
 > depbase=`echo tun-tap.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; /bin/sh
 > ../../libtool  --tag=CC    --mode=compile clang -DHAVE_CONFIG_H  -I.
 > -I../..  -I../.. -I. -I./../eth -I. -D_TME_IMPL
 > -DDEV_TAP_FILENAME="\"/dev/tap\"" -DTME_NAT_NFT -DTME_NAT_NPF
 > -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include
 > -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include/libdrm
 > -DTME_NO_LOG -DTME_NO_DEBUG_LOCKS -DTME_NO_AUDIT_ATOMICS -DNDEBUG
 > -O2 -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include
 > -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include/libdrm -Wno-unused
 > -Wno-sign-compare -Wundef -Wall -Wextra -MT tun-tap.lo -MD -MP -MF
 > $depbase.Tpo -c -o tun-tap.lo tun-tap.c && mv -f $depbase.Tpo
 > $depbase.Plo
 > libtool: compile:  clang -DHAVE_CONFIG_H -I. -I../.. -I./../eth
 > -D_TME_IMPL -DDEV_TAP_FILENAME=\"/dev/tap\" -DTME_NAT_NFT
 > -DTME_NAT_NPF -I/home/pkgbuild/wip/tme/work/.buildlink/include
 > -I/home/pkgbuild/wip/tme/work/.x11-buildlink/include
 > -I/home/pkgbuild/wip/tme/work/.x11-buildlink/include/freetype2
 > -I/home/pkgbuild/wip/tme/work/.x11-buildlink/include/libdrm
 > -DTME_NO_LOG -DTME_NO_DEBUG_LOCKS -DTME_NO_AUDIT_ATOMICS -DNDEBUG -O2
 > -Wno-unused -Wno-sign-compare -Wundef -Wall -Wextra -MT tun-tap.lo -MD
 > -MP -MF .deps/tun-tap.Tpo -c tun-tap.c  -fPIC -DPIC -o .libs/tun-tap.o
 > tun-tap.c:139:10: fatal error: 'net/npf_ncode.h' file not found
 > #include <net/npf_ncode.h>
 >          ^
 > 1 error generated.
 > 
 > edamame$ uname -a
 > NetBSD edamame.mirbsd.org 7.0_BETA NetBSD 7.0_BETA (GENERIC) #0: Sun
 > Oct 26 22:51:31 UTC 2014
 > root@edamame.mirbsd.org:/usr/obj/sys/arch/amd64/compile/GENERIC amd64

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/49421 (tme-1.0beta_4)
Date: Sun, 18 Jan 2015 05:35:15 +0000

 On Sat, Jan 17, 2015 at 10:55:01PM +0000, phabrics@phabrics.com wrote:
  >  Thank you for your interest in this.  I am not the original tme 
  >  developer, which is why I did not submit it as a replacement.  This 
  >  package just contains some "upgrades" to the original package which 
  >  seems to have been static for a while now (save for a few patches here & 
  >  there).  These were my own work to try to get it to a "working enough" 
  >  state on some of my other boxes, as well as enhancements for them for 
  >  another project of mine to use as dependency at some point.  It had 
  >  gotten to the point where I had made enough updates that I thought it 
  >  would be worth sharing, but too big to be a patch.  If this duplication 
  >  is undesirable, I can resubmit to replace, but I didn't want to presume 
  >  that because it would be a major update and I wanted it to work well 
  >  enough not disturb anyone else who might depend on the original.

 If you're developing the thing, but you don't (yet?) want to become
 upstream, what I'd suggest is putting together upstreamable patches
 and posting them for download. Then we can add in the patch in pkgsrc,
 possibly even as a build option in the main package. And if upstream
 comes back to life, you're ready to send them what you've been doing.

 I do some of this; see http://www.netbsd.org/~dholland/patchkits/.

 -- 
 David A. Holland
 dholland@netbsd.org

From: phabrics@phabrics.com
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/49421 =?UTF-8?Q?=28tme-=31=2E=30beta=5F=34=29?=
Date: Sun, 18 Jan 2015 00:05:51 -0700

 Hi Dave,

 Thanks for the input/pointers. I'm more than willing to become upstream. 
   I didn't mean to imply otherwise, but this was my first crack at it so 
 I wasn't sure of the best way to proceed. I looked over the patches that 
 were already there for tme-0.8 and incorporated them into what I 
 submitted as well, so they are covered.  While it may be possible to 
 break the work into modular patches, I believe the better option here is 
 just to "up" the release number as I did and submit it "as is".

 One of my original goals was to expand cross-platform support: I added 
 equivalent functionality for Linux & other BSDs and made sure it worked 
 on most of the later versions of them, updating the autotools versions 
 as well.  But NetBSD is still the true home of this project, so I wanted 
 it to be incorporated here - not the least of which because NetBSD runs 
 best as an emulated guest on TME - although I'm still looking into a few 
 issues there, like X support.

 So, any help as to what to do with regards to becoming upstream is 
 greatly appreciated.  Is it just a simple matter of submitting it under 
 the original name?  Or do I need to join a team first?  Do I host the 
 code elsewhere, like wip? I guess I was hesitant, as I wasn't the 
 original developer, nor an official NetBSD contributor, but if that is 
 ok, then I will do that.  I will continue researching this option some 
 more, but any pointers are greatly appreciated.

 Regards,
 Ruben

 PS: If it becomes necessary, I can certainly submit patches or one 
 gigantic jumbo patch, but what I have is already out there, so it is 
 preferable to become upstream. I am still actively working on it, making 
 improvements where I can and documenting it better.  Unless there are 
 any objections, I would prefer to pursue this option.

 On 2015-01-17 22:40, David Holland wrote:
 > The following reply was made to PR pkg/49421; it has been noted by 
 > GNATS.
 > 
 > From: David Holland <dholland-pbugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: pkg/49421 (tme-1.0beta_4)
 > Date: Sun, 18 Jan 2015 05:35:15 +0000
 > 
 >  On Sat, Jan 17, 2015 at 10:55:01PM +0000, phabrics@phabrics.com wrote:
 >   >  Thank you for your interest in this.  I am not the original tme
 >   >  developer, which is why I did not submit it as a replacement.  
 > This
 >   >  package just contains some "upgrades" to the original package 
 > which
 >   >  seems to have been static for a while now (save for a few patches 
 > here &
 >   >  there).  These were my own work to try to get it to a "working 
 > enough"
 >   >  state on some of my other boxes, as well as enhancements for them 
 > for
 >   >  another project of mine to use as dependency at some point.  It 
 > had
 >   >  gotten to the point where I had made enough updates that I thought 
 > it
 >   >  would be worth sharing, but too big to be a patch.  If this 
 > duplication
 >   >  is undesirable, I can resubmit to replace, but I didn't want to 
 > presume
 >   >  that because it would be a major update and I wanted it to work 
 > well
 >   >  enough not disturb anyone else who might depend on the original.
 > 
 >  If you're developing the thing, but you don't (yet?) want to become
 >  upstream, what I'd suggest is putting together upstreamable patches
 >  and posting them for download. Then we can add in the patch in pkgsrc,
 >  possibly even as a build option in the main package. And if upstream
 >  comes back to life, you're ready to send them what you've been doing.
 > 
 >  I do some of this; see http://www.netbsd.org/~dholland/patchkits/.
 > 
 >  --
 >  David A. Holland
 >  dholland@netbsd.org

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 30 May 2016 00:04:44 +0000
State-Changed-Why:
Feedback was received.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.