Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Mar 2015 07:33:11 -0700
From:      "Chris H" <bsd-lists@bsdforge.com>
To:        <freebsd-ports@freebsd.org>
Subject:   Re: devel/hub build failed on 8.4, how to proceed?
Message-ID:  <2f9b32561bce9916b208f3a6d3e5c200@ultimatedns.net>
In-Reply-To: <CAJzNPXXX%2Bn-usp1umqXzR99VODSp3mb8oBDmS0k55L9q%2BfuQ=Q@mail.gmail.com>
References:  <CAJzNPXXX%2Bn-usp1umqXzR99VODSp3mb8oBDmS0k55L9q%2BfuQ=Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Mar 2015 13:25:47 +0300 Kostantinos Koukopoulos
<koukopoulos@gmail.com> wrote

> Hello,
> I'm maintaining devel/hub, and for the first time while doing so, a build
> has failed:
> 
> http://beefy5.nyi.freebsd.org/data/84i386-default/382532/logs/hub-2.2.0.log
> 
> I have a couple of questions about how I should proceed. First: are we
> (port maintainers) responsible for addressing this type of issue, where the
> build fails only on a legacy release of FreeBSD? Second, assuming we don't
> have the time to investigate the cause ourselves, is it acceptable to
> simply open an issue with the upstream provider? Third, if and when we have
> the time, is running a 8.4 jail on poudriere the easiest way to go about
> debugging the issue?
Since you are the maintainer, the answer is ultimately your choice. But
your answers to the above questions will largely determine the ultimate
value of your port. :)
You needn't open a pr(1). [personally] I would wait to see if the
problem actually manifests itself in "real life".
poudriere is one option. But there is no good reason you can't create
a jail, use a VM, or use any other means to create a suitable
environment as a test bed, to isolate the problem/issue. Lastly; If you
truly believe the problem exists in the source, you should report it
upstream. Unless you want to fix it for them. :)
P.S. don't forget that you can always mark the port broken for
ARCH, or OSVERSION, or any combination of the two.

> 
> Last, if anyone has any idea why a Golang build would fail with these
> errors please share it with me:
> 
> /var/tmp/go-link-ejdAoV/go.o(.text+0x1cc44): In function
> 'runtime.mallocinit': /usr/local/go/src/runtime/malloc.c:219: relocation
> truncated to fit: R_386_32 runtime.end
> /var/tmp/go-link-ejdAoV/go.o(.debug_info+0x10f493): In function
> 'time.Time.IsZero':
> /usr/local/go/src/time/time.go:242: relocation truncated to fit:
> R_386_32 runtime.end
Purely a guess; maybe not 100% 32bit compatible? But I have no idea.

--Chris
> 
> 
> Thank you,
> Konstantinos
> 
> -- 
> |/ |/ Konstantinos <koukopoulos@gmail.com>
> |\ |\ Koukopoulos <http://kouk.surukle.me>;
> 
> VSRE messages are welcome*, Thanks!
> * for more information see: http://vsre.info
> <http://vsre.info/>;
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2f9b32561bce9916b208f3a6d3e5c200>