Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Feb 2015 11:50:47 +1100
From:      Kubilay Kocak <koobs@FreeBSD.org>
To:        marino@freebsd.org, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org
Cc:        tijl Coosemans <tijl@FreeBSD.org>
Subject:   Re: svn commit: r378316 - head/devel/libhtp
Message-ID:  <54D01B67.4010406@FreeBSD.org>
In-Reply-To: <54D015B7.2080408@marino.st>
References:  <201502021841.t12IfvP1021156@svn.freebsd.org> <54D01223.7020703@FreeBSD.org> <54D015B7.2080408@marino.st>

next in thread | previous in thread | raw e-mail | index | archive | help
On 3/02/2015 11:26 AM, John Marino wrote:
> On 2/3/2015 01:11, Kubilay Kocak wrote:
>> On 3/02/2015 5:41 AM, John Marino wrote:

>> Apart from the lack of an Approved by: line for this commit, even in the
>> case of blanket, isn't LIBS= better here?
> 
> It was a blanket - when ports that were building on dfly suddenly break
> and the fix is simple and not invasive (e.g. missing LDFLAG) then I've
> been given a blanket to just fix it.

It would be appreciated if you could add the Approved by: line in future
for these. Apart from not requiring anyone to ask (publicly or
otherwise), it also helps other people in the project see and understand
what is and isn't part of any policy-based decision making. That
benefits everyone.

Is the blanket for DFly and/or simple "non-invasive" *FLAGS changes
documented anywhere or does it only apply to individuals?

> I don't know if "LIBS" is standardized but it's a flag that's missing,
> not a library.

I'll pull tijl@ in the explain this one if needed and I'll leave this
commit reference here as well:

https://svnweb.freebsd.org/ports?view=revision&revision=357486

And just to note, there was this related and "simple" change that broke
Python completely:

https://lists.freebsd.org/pipermail/freebsd-python/2014-July/007129.html

>>
>> Further, if it is indeed the case that iconv:translit adds -liconv to
>> LDFLAGS, wouldn't adding -L${LOCALBASE}/lib to LDFLAGS be better solved
>> in Uses/iconv.mk when that case is true?
> 
> I would think so.
> Most of the time this doesn't pop up because another dependency brings
> in -L/usr/local/lib so it works by accident very often.
> 
> At the very least it should have an ${LDFLAGS_ICONV} option that could
> be added to LDFLAGS.  It would be a more correct solution.
> 

If you can sort out a proper fix in the right place that would be great.
You have approval from me to revert/change devel/libhtp as necessary.

>> Give me a holler on IRC or email in future if you notice anything up
>> with ports I maintain. I'm almost always happy to oblige.
> 
> 
> I not on IRC ATM and I didn't see the downside of unbreaking the port
> with a single flag.  I would have opened a bugzilla ticket if the fix
> was not obvious or invasive; I do that all the time.
> 
> John

I appreciate not everyone is online or working at the same time.

Consideration is the key here, even if it resulted in the same outcome
(a commit not *requiring* approval). Mindfulness and collaboration can
sometimes take a little more effort, definitely.

Having said all of the above, thank you for putting in the effort to
improve a port I maintain.

./koobs



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