Re: FreeBSD Port: strongswan-5.9.2_1

[Franco Fichtner]

Hi,

Strongswan authors have no interest in supporting LibreSSL and patching it in 
the code #ifdef maze is really difficult since it checks OpenSSL version 
numbers which for LibreSSL looks like the most modern OpenSSL Release.


Cheers,
Franco

> On 25. Apr 2021, at 20:41, Gena Gulchin  wrote:
> 
> Good morning! 
> 
> I’m having problems building strongSwan 5.9.2 IPSec on FreeBSD 13 and 
> LibreSSL 3.2.5
> 
> Contents of my /etc/make.conf:
> OPENSSL_PORT=   security/libressl
> DEFAULT_VERSIONS+=ssl=libressl
> 
> 
> I have searched the internet for solution and tried applying various patches 
> but to no avail. 
> 
> Much appreciate your help on this matter! 
> 
> Below is the build log
> 
> 
> (apologies for the long paste):
> 
> 8<
> --- openssl_rng.lo ---
> openssl_rng.c:61:20: warning: passing 'char *' to parameter of type 'unsigned 
> char *' converts between pointers to integer types with different sign 
> [-Wpointer-sign]
>return RAND_bytes((char*)buffer, bytes) == 1;
>  ^
> /usr/local/include/openssl/rand.h:93:32: note: passing argument to parameter 
> 'buf' here
> int  RAND_bytes(unsigned char *buf, int num);
>   ^
> 1 warning generated.
> --- openssl_ed_private_key.lo ---
> openssl_ed_private_key.c:89:6: warning: implicit declaration of function 
> 'EVP_DigestSign' is invalid in C99 [-Wimplicit-function-declaration]
>if (EVP_DigestSign(ctx, NULL, >len, data.ptr, data.len) <= 
> 0)
>^
> openssl_ed_private_key.c:135:7: warning: implicit declaration of function 
> 'EVP_PKEY_get_raw_public_key' is invalid in C99 
> [-Wimplicit-function-declaration]
>if (!EVP_PKEY_get_raw_public_key(this->key, NULL, ))
> ^
> --- openssl_xof.lo ---
> openssl_xof.c:82:7: warning: implicit declaration of function 
> 'EVP_DigestFinalXOF' is invalid in C99 [-Wimplicit-function-declaration]
>if (EVP_DigestFinalXOF(this->ctx, data.ptr, data.len) == 1)
>^
> --- openssl_rsa_private_key.lo ---
> openssl_rsa_private_key.c:318:52: warning: passing 'char *' to parameter of 
> type 'unsigned char *' converts between pointers to integer types with 
> different sign [-Wpointer-sign]
>len = RSA_private_decrypt(crypto.len, crypto.ptr, decrypted,
>  ^
> /usr/local/include/openssl/rsa.h:339:20: note: passing argument to parameter 
> 'to' here
>unsigned char *to, RSA *rsa, int padding);
>   ^
> openssl_rsa_private_key.c:326:24: warning: passing 'char *' to parameter of 
> type 'u_char *' (aka 'unsigned char *') converts between pointers to integer 
> types with different sign [-Wpointer-sign]
>*plain = chunk_create(decrypted, len);
>  ^
> ../../../../src/libstrongswan/utils/chunk.h:57:44: note: passing argument to 
> parameter 'ptr' here
> static inline chunk_t chunk_create(u_char *ptr, size_t len)
>   ^
> --- openssl_xof.lo ---
> openssl_xof.c:140:9: warning: implicit declaration of function 'EVP_shake128' 
> is invalid in C99 [-Wimplicit-function-declaration]
>md = EVP_shake128();
> ^
> openssl_xof.c:140:7: warning: incompatible integer to pointer conversion 
> assigning to 'const EVP_MD *' (aka 'const struct env_md_st *') from 'int' 
> [-Wint-conversion]
>md = EVP_shake128();
>   ^ ~~
> openssl_xof.c:143:9: warning: implicit declaration of function 'EVP_shake256' 
> is invalid in C99 [-Wimplicit-function-declaration]
>md = EVP_shake256();
> ^
> openssl_xof.c:143:7: warning: incompatible integer to pointer conversion 
> assigning to 'const EVP_MD *' (aka 'const struct env_md_st *') from 'int' 
> [-Wint-conversion]
> --- openssl_ec_diffie_hellman.lo ---
> openssl_ec_diffie_hellman.c:216:3: warning: implicit declaration of function 
> 'EVP_PKEY_set1_tls_encodedpoint' is invalid in C99 
> [-Wimplicit-function-declaration]
> --- openssl_xof.lo ---
>md = EVP_shake256();
>   ^ ~~
> --- openssl_ec_diffie_hellman.lo ---
>EVP_PKEY_set1_tls_encodedpoint(pub, value.ptr, value.len) <= 0)
>^
> openssl_ec_diffie_hellman.c:245:12: warning: implicit declaration of function 
> 'EVP_PKEY_get1_tls_encodedpoint' is invalid in C99 
> [-Wimplicit-function-declaration]
>pub.len = EVP_PKEY_get1_tls_encodedpoint(this->key, );
>  ^
> --- openssl_aead.lo ---
> openssl_aead.c:289:21: warning: implicit declaration of function 
> 'EVP_chacha20_poly1305' is invalid in C99 [-Wimplicit-function-declaration]
>this->cipher = 

LibreSSL 3.1.5 quarterly update vs. vuxml entry

[Franco Fichtner]

Hello,

https://svnweb.freebsd.org/ports?view=revision=557712
https://svnweb.freebsd.org/ports?view=revision=557716

vuxml only sets 3.2.3 but
that still flags the fixed quarterly version 3.1.5
as vulnerable.

It would be nice to have this fixed.


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re:

[Franco Fichtner]

> On 7. Nov 2020, at 6:25 PM, Cy Schubert  wrote:
> 
> That's not needed. The proposal is to replace the syslog-ng port with the 
> contents of syslog-ng329 and deprecate the others. Those using 
> sysutils/syslog-ng will see no change. Those using older versions will need 
> to replace syslog-ngNN with simply syslog-ng.

Actually I was referring to this:

https://github.com/freebsd/freebsd-ports/blob/master/sysutils/syslog-ng329/files/syslog-ng.conf.sample#L1

Also a question for Peter.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Ready for commit PRs

[Franco Fichtner]

Hi,

ClamnAV build fix for latest version: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247792

Squid update to 4.12: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247397


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Portmaster failing

[Franco Fichtner]

Hi Adam,

> On 1. Jan 2020, at 10:18 PM, Adam Weinberger  wrote:
> 
> On Wed, Jan 1, 2020 at 1:51 PM @lbutlr  wrote:
>> 
>> On 01 Jan 2020, at 13:46, Franco Fichtner  wrote:
>>> 
>>> 
>>> 
>>>> On 1. Jan 2020, at 9:42 PM, @lbutlr  wrote:
>>>> 
>>>> On 01 Jan 2020, at 13:40, Franco Fichtner  wrote:
>>>>> security/openssl was removed before, now security/openssl111 has become 
>>>>> security/openssl.
>>>> 
>>>> Ugh.
>>>> 
>>>>> A bit too eager for my taste, but that's why we all have private trees, 
>>>>> don't we.  ;)
>>>> 
>>>> This is going to go poorly, if previous attempts to update to 1.1 are any 
>>>> indication.
>>> 
>>> With PHP 5.6 axed prematurely a while back I am interested to see OpenSSL 
>>> 1.0.2
>>> phased out now with a number of ports still not supporting 1.1.1 and seeing 
>>> them
>>> marked as broken sooner or later.
>> 
>> Well, at this point I cannot install openssl111 without deinstalling 
>> openssl, which I cannot deinstall since it is gone from ports.
>> 
>> Looks like I have to remove openssl, which … I mean, seriously, this seems 
>> pretty hostile.
>> 
>> Name   : openssl
>> Version: 1.0.2u,1
>> Installed on   : Sun Dec 22 08:13:27 2019 MST
>> 
>> There was nothing at all on the 22nd about “WARNING THIS WILL BREAK 
>> EVERYTHING IN A WEEK” which to mean seems like it should have been made 
>> super obvious.
> 
> This is why we practically beg people to use poudriere.

Let me stop you right here and say: ports Framework itself is
suffering from this wishful attitude and this has nothing to do
with readily available poudriere "replacements" which are not
as good as poudriere for sure.

If the ports framework isn't seen as a stand alone infrastructure
worth its own integrity the discussion is already dead and the
quality will keep to decline for every casual FreeBSD user who
doesn't really care for this or that tool, but wants to install
software from the ports tree manually.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Portmaster failing

[Franco Fichtner]

> On 1. Jan 2020, at 9:42 PM, @lbutlr  wrote:
> 
> On 01 Jan 2020, at 13:40, Franco Fichtner  wrote:
>> security/openssl was removed before, now security/openssl111 has become 
>> security/openssl.
> 
> Ugh.
> 
>> A bit too eager for my taste, but that's why we all have private trees, 
>> don't we.  ;)
> 
> This is going to go poorly, if previous attempts to update to 1.1 are any 
> indication.

With PHP 5.6 axed prematurely a while back I am interested to see OpenSSL 1.0.2
phased out now with a number of ports still not supporting 1.1.1 and seeing them
marked as broken sooner or later.

With all this in mind, I'm surprised Python did not suffer the same fate
and was deprecate-extended to the end of 2020 in the ports tree which is an
unusual 180 regarding previous arguments that having expired ports still
supported is "too much work".


Happy new year,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Portmaster failing

[Franco Fichtner]

security/openssl was removed before, now security/openssl111 has become 
security/openssl.

A bit too eager for my taste, but that's why we all have private trees, don't 
we.  ;)


Cheers,
Franco

> On 1. Jan 2020, at 9:37 PM, @lbutlr  wrote:
> 
> Portmaser -L errors out with
> 
> make: "/usr/ports/Mk/Uses/ssl.mk" line 97: You are using an unsupported SSL 
> provider openssl
> 
> Make.conf:
> DEFAULT_VERSIONS+=ssl=openssl apache=2.4 php=7.2 perl5=5.28 mysql=10.1m
> 
> Worked fine on Saturday, maybe Friday.
> 
> 
> 
> -- 
> i wasn't born a programmer. i became one because i was impatient. -
>   Dave Winer
> 
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: XXX needs Python 3.4 at least, but 2.7 was specified

[Franco Fichtner]

> On 25. Dec 2019, at 12:59 PM, D'Arcy Cain  wrote:
> 
> On 12/24/19 5:56 PM, w.schwarzenfeld wrote:
>> At least a workaround (maybe the sollutiion):
>> 
>> 
>> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=209881=diff
> 
> Another workaround if you don't want to modify files in the repo is to
> simply go into the problem folder, /usr/ports/graphics/graphene in the
> OP's case, and run "make install" before returning to the original
> build.  You may have to do it multiple times for different packages though.

While Poudriere is nice and all and does this automagically it is a major
annoyance trending lately that you cannot build ports without these silly
build errors.  If USES= python: is used it doesn't mean ports should
just barf all over users with these non-errors when they don't build deps
with that particular version that one didn't even specify for the deps.

It seems like USES enforces this recursively but should not as witnessed
by this "workaround".  There's still a relevant DEFAULT_VERSIONS entry
but it is happily ignored.

If all users need to use Poudriere just to have a chance at building
ports we're at the point where Poudriere itself is becoming problematic
for port framework quality, something that always seemed to linger in
the background for the last couple of years and now it's finally here.

And yes, lang/rust was one recent example that has python:3.3+ now and
fails to build somewhere down the dependency chain.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Patches waiting for commits

[Franco Fichtner]

Hi,

Here are a few bug reports waiting for a kind committer:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233963
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239860
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241569
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242658 includes 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242629


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: PHP version retirement

[Franco Fichtner]

> On 12. Aug 2019, at 16:29, Adam Weinberger  wrote:
> 
> On Mon, Aug 12, 2019 at 1:04 AM Martin Waschbüsch  
> wrote:
>> Furthermore, the argument that it is more more work to maintain an 
>> abandoned version is silly because it’s more work to delete a port that 
>> to just keep it in the tree for a while longer.
> 
> That last part isn't correct. The work of deleting the ports is
> largely automated and simple, and it will always happen eventually.
> The work involved is in supporting unsupported versions. Our php team
> is spread very thin, and they simply cannot support php versions
> outside of upstream development. There are no resources to backport
> fixes that may or may not be designed to work with older versions
 
 I do not understand this. At all.
 And I sort of hope I misunderstood you, because it sounds like you think a 
 maintainer is or may be regarded as someone who can be expected to provide 
 product support of some kind?
 I find that notion worrying to say the least.
>>> 
>>> If you believe that handling updates, analyzing submitted and upstream
>>> patches and development, and answering a bevy of questions for every
>>> major update is effortless, then you drastically underestimate the
>>> amount of work that goes into the ports tree.
>> 
>> You completely misunderstand me.
>> I know there is a lot of effort going into this. I disagree only in that I 
>> do not believe there should be any expectations towards maintainers.
>> It is voluntary work. Spare time, etc. I am grateful for the effort people 
>> put into this, but I strongly believe no one should act towards volunteers 
>> with any expectations as to what they should do, how much time they spend, 
>> etc.
>> 
>> So, I find it wrong to say, as I understood you, to remove a package from 
>> the ports tree because otherwise others people, for instance users of 
>> FreeBSD, would have the *expectation* of receiving support for those 
>> packages.
>> That perception of any kind of entitlement towards volunteers is wrong, IMHO.
>> 
>> And that is why I answered that part of your message because it is not (for 
>> reasons stated above) a valid argument against having outdated software in 
>> the ports tree.
> 
> Ah! You're right, I did completely misunderstand you.
> 
> You're correct that we don't provide any semblance of support for the
> upstream software. Absolutely, and under no circumstances should
> anyone have to.
> 
> I'm referring to support of the port itself. Maintainership requires
> responding to private emails asking for help; evaluating, testing, and
> approving submitted patches; responding to PRs about changes or fixes
> or poor behaviour (90% of the time related to portmaster); responding
> to error reports; and so on.
> 
> We do expect those things from maintainers, because those are what are
> required to keep the ports tree running. And we actively drop
> maintainership from ports where maintainers routinely ignore those
> responsibilities, regardless of whether they have a commit bit.
> 
> As decke noted, maintainership of a small port with relatively low
> deployment is pretty smooth (and don't get me wrong, they're as or
> more important than the big packages). But a huge and complex
> framework like php is a massive undertaking, with a near-constant
> barrage of complex patches that require highly complex testing
> strategies, and thousands of dependent ports to worry about for every
> change.

Sure, if you feel like that is so there is no need to argue about it. I still 
feel the latent drift of “php is high profile and low profile is easy” like a 
sneaky way out of a fruitful discussion ignoring the request made by users: 
don’t kill software on tight schedules if there is no technical need for it.

Unless you want to state a valid technical reason. For PHP 5.6 removal 
especially one has to assume that general arguments are merely made up here to 
fit the general lack of disagreement on the grace period issue.

That’s fine and easier to say you don’t want to do it vs. it cannot be done. :)

> I suggested that it might be possible for stale languages to remain in
> the tree, as long as the above support wasn't required or expected.
> But, honestly, Franco's response mocking the offer made my desire to
> help him somewhere at or below zero, and has pretty much ensured that
> nobody else in portmgr is going to be eager to get skin in the game.

I‘m merely pointing out you‘re unwilling to do it and your offer was 
impractical for users running any PHP extension but you were not straight 
forward in your answer previously. This segment at least makes it clear so 
thank you for being frank about it. To sum it up there is no desire by 
maintainers to do what users requested here so yay for that conclusion at least.


Cheers,
Franco

___
freebsd-ports@freebsd.org mailing list

Re: PHP version retirement

[Franco Fichtner]

> On 12. Aug 2019, at 00:22, Adam Weinberger  wrote:
> 
>> On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner  wrote:
>> 
>> Quarterly is essentially useless if the decision is to immediately axe a 
>> deprecated release. 3 months are nothing in production environments, if you 
>> get 3 months (1,5 months mean) at all and also all other updates and 
>> security relevant bug fixes in the same quarterly that you desperately need.
>> 
>> Yeah, we know that won’t happen so please don’t suggest it.
>> 
>> That deprecation policy is nice and well all by itself except when it wreaks 
>> havoc over the ports infrastructure like in the case of PHP version support 
>> where numerous ports are immediately unavailable and incompatible with 
>> upgrades.
>> 
>> Furthermore, the argument that it is more more work to maintain an abandoned 
>> version is silly because it’s more work to delete a port that to just keep 
>> it in the tree for a while longer.
> 
> That last part isn't correct. The work of deleting the ports is
> largely automated and simple, and it will always happen eventually.
> The work involved is in supporting unsupported versions. Our php team
> is spread very thin, and they simply cannot support php versions
> outside of upstream development. There are no resources to backport
> fixes that may or may not be designed to work with older versions

I don’t believe this is anywhere near true for two reasons: FreeBSD ports does 
not add as much maintainers as it says it desperately needs so you are creating 
a scarce environment to base your „too much work“ argument on. The other part 
is having handled a ports fork myself since 2015 the work to keep a port where 
it is is low at its worst.

>> That „while“ is debatable, but it’s neither indefinitely nor immediately. 
>> The people responsible for FreeBSD ports and packages would be wise to 
>> enrich their policies with a more graceful way of dealing with legacy 
>> software, especially if it relates to more than a handful of ports in a 
>> single deprecation decision.
>> 
>> TL;DR: don’t remove PHP ports prematurely and you’ll have less work reading 
>> mails like these.
> 
> Part of the contract in providing packages includes providing support
> for them. Other OSes provide packages for software that they can never
> support, and there are definitely consequences for that paradigm. This
> is doubly true for PHP, which is extremely common and for which
> security fixes can be vitally important.

Well, you are arguing against a grace period for obsolete software which is 
quite pointless because the software is not bad per se. It will be eventually 
and it should be removed and nobody argued against that.

In the case of PHP 5.6 a clear error of judgement was made based on a 
reasonable decision at the time. It should give enough incentive to not let 
this happen again so quickly and try to learn from how it negatively impacts 
users.

I‘m going to reiterate because nobody acknowledges the obvious: 1,5 months mean 
of a grace period in quarterly is productions worst enemy, not to mention when 
you run HEAD.

> I've been thinking about this a lot lately (I used to be hardline
> against it), but at this point I am not fundamentally opposed to the
> idea of providing old versions of major languages and interpreters, as
> long as (a) they cannot be specified by DEFAULT_VERSIONS, (b) nothing
> can ever depend on them, and (c) it is clear that they are provided
> without support and at your own peril.

That makes no sense for PHP ports which are part of the picture here. But you 
probably know that. :)


Cheers,
Franco

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: PHP version retirement

[Franco Fichtner]

Quarterly is essentially useless if the decision is to immediately axe a 
deprecated release. 3 months are nothing in production environments, if you get 
3 months (1,5 months mean) at all and also all other updates and security 
relevant bug fixes in the same quarterly that you desperately need.

Yeah, we know that won’t happen so please don’t suggest it.

That deprecation policy is nice and well all by itself except when it wreaks 
havoc over the ports infrastructure like in the case of PHP version support 
where numerous ports are immediately unavailable and incompatible with upgrades.

Furthermore, the argument that it is more more work to maintain an abandoned 
version is silly because it’s more work to delete a port that to just keep it 
in the tree for a while longer.

That „while“ is debatable, but it’s neither indefinitely nor immediately. The 
people responsible for FreeBSD ports and packages would be wise to enrich their 
policies with a more graceful way of dealing with legacy software, especially 
if it relates to more than a handful of ports in a single deprecation decision.

TL;DR: don’t remove PHP ports prematurely and you’ll have less work reading 
mails like these.


Cheers,
Franco

> On 11. Aug 2019, at 21:41, Martin Waschbüsch  wrote:
> 
> Hi Wolfgang,
> 
>> Am 11.08.2019 um 01:12 schrieb Wolfgang Zenker :
>> 
>> * Martin Waschbüsch  [190811 00:47]:
 Am 10.08.2019 um 20:18 schrieb Patrick Powell :
 
 Umm this was just the kick in the pants that I needed to switch to PHP 7.
 See https://www.glaver.org/blog/?p=1109 for a desperation 'I need PHP5.6' 
 hack which I used during this update.
>> 
>>> Thank you, Patrick,
>>> that is a work-around I also came across. It helped me as well.
>> 
>> You could also have used the quarterly branch, which keeps software till
>> the end of the quarter. In the case of php 5.6 it would have given you
>> time until March 31st, and would have included version 5.6.40
>> 
>> Wolfgang
> 
> 
> 5.6.40 never made it into the main ports tree. Are you sure it was available 
> in the quarterly snapshot?
> 
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Bind914 conficts with bind-tools

[Franco Fichtner]

> On 1. May 2019, at 11:08 AM, Xavier  wrote:
> 
> Hello,
> 
> I wanted to portupgrad bind914, ran into a conflict :
> 
>> [root@numenor bind914]# make all
>> ===>  Staging for bind914-9.14.1
>> ===>   bind914-9.14.1 depends on package: bind-tools>0 - not found
>> ===>  Installing for bind-tools-9.14.1
>> ===>  Checking if bind-tools is already installed
>> ===>   Registering installation for bind-tools-9.14.1 as automatic
>> Installing bind-tools-9.14.1...
>> pkg-static: bind-tools-9.14.1 conflicts with bind914-9.14.0 (installs files 
>> into the same place).  Problematic file: /usr/local/bin/arpaname
> 
> I ran make clean before
> 
> Thanks for ideas,

Update bind914 first and it'll work.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Open strongswan bugs

[Franco Fichtner]

Hi,

> On 9. Mar 2019, at 11:46 AM, Kurt Jaeger  wrote:
> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212149
> 
> I'm unsure about closing this one. Right now strongswan does not
> build with libressl, right ?

It's tricky.  LibreSSL is not supported and currently the only
way to make it build is modify the opensslv.h file in LibreSSL
to emit a "compatible" version number since StrongSwan only
uses version checks to figure out features.  So this is in
all likeliness a larger upstream issue.

https://wiki.strongswan.org/issues/2495
https://wiki.strongswan.org/issues/2165

> Either the FreeBSD port adds patches to allow build with libressl,
> or upstream does it, otherwise that PR is just unresolved, and
> has to stay open.

Ah, okay, then it should stay open indeed.

>> LibreSSL support in StrongSwan is nonexistent, a patch
>> set for interested parties can be found at:
>> 
>> https://github.com/opnsense/ports/blob/master/security/strongswan/Makefile#L126-L131
> 
> So, does the maintainer approve that patch ?

See above, requires fudging the OPENSSL_VERSION_NUMBER via
libressl port include file:

https://github.com/opnsense/ports/blob/master/security/libressl/files/patch-include_openssl_opensslv.h

It looks like too much trickery for useful FreeBSD inclusion
although the end result is a working StrongSwan port.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Open strongswan bugs

[Franco Fichtner]

Hi,

strongswan port has 4 open tickets with maintainer feedback
or approval, but no assignees.  Here's the digest.

Should be committed (maintainer approval +):

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234648
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236218

Should be closed (maintainer responded, upstream issues):

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224112
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212149

LibreSSL support in StrongSwan is nonexistent, a patch
set for interested parties can be found at:

https://github.com/opnsense/ports/blob/master/security/strongswan/Makefile#L126-L131


Thank you,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Add conflicts to port

[Franco Fichtner]

Hi Matthias,

Explicit CONFLICTS only exist within the ports tree
during builds.

pkg detects conflicts simply when files are attempted
to be installed in the same place -- i.e. a file already
belongs to another installed package.


Cheers,
Franco

> On 8. Jan 2019, at 3:52 PM, Matthias Fechner  wrote:
> 
> Dear all,
> 
> I just implement some changes in the gitlab-ce port which requires some
> conflicts.
> I tried to add:
> 
> CONFLICTS_INSTALL=  gitolite-* \
> gitolite2-* \
> gogs-* \
> ${PYTHON_PKGNAMEPREFIX}-gitosis-*
> 
> My test machine has gitolite and gitlab-ce installed.
> 
> If I know execute pkg upgrade it does not trigger the conflict.
> I had expected that pkg forces now a deinstallation of gitolite before
> it continues with upgrading gitlab-ce.
> But it just installs gitlab-ce and ignores the conflict definition.
> 
> Is this a bug in pkg or is something with the definition of the conflict
> not correct?
> 
> Thanks.
> 
> Gruß
> Matthias
> 
> -- 
> 
> "Programming today is a race between software engineers striving to
> build bigger and better idiot-proof programs, and the universe trying to
> produce bigger and better idiots. So far, the universe is winning." --
> Rich Cook
> 
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ssl=base

[Franco Fichtner]

> On 25. Nov 2018, at 12:51 PM, Eugene Grosbein  wrote:
> 
> Why can't you use LibreSSL port for some ports and base libssl for other 
> ports?
> That is, net/mpd5 links with base system libfetch that depends on base libssl,
> so it is example of port that cannot be built with LibreSSL.

FWIW, since 2015 we've had no build or operational issue with mpd5 for LibreSSL
from ports.

If the issue is mixed linkling between base and ports, it's not that LibreSSL
fails but rather any combination of base and ports, on FreeBSD 12 even between
1.1.1 and 1.0.2.  On 11 that wasn't really an issue because base OpenSSL and
ports OpenSSL were the same so I can understand where the the idea of "breakage"
for LibreSSL specifically comes from.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: sed dollar sign substitution in Makefile

[Franco Fichtner]

Hi,

> On 6. Nov 2018, at 9:12 PM, Oliver Mahmoudi  wrote:
> 
> Therefore, in Makefile I set: ${REINPLACE_CMD} 's|print $1|print $4|g' 
> file_to_be_changed

In make commands you need to escape $ as $$ to be able to pass it to the shell.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Concerns about external contribution handling, a case study

[Franco Fichtner]

To whom this may concern,

The following PR showed vividly what I've been seeing for
a long time on this list and while working with FreeBSD ports.

I'm attaching my last response here because it may be important
for some to see, even if it's being brushed off.

===> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231377

>From your lack of response I gather that you have realised your argument was 
>not as well laid out as it could have been or simply don't care. Let me also 
>tell you why this is the *worst experience* with a FreeBSD ports committer 
>that I've come across since 2014 and therefore can't let this slide. Here's 
>the full timeline for general reading pleasure.

You committed C-ICAP 0.5.3 in April 2018[1]. Nobody has given you much trouble 
or blame which is only fair considering the involvement of upstream in this 
issue, but doing so broke integration for OPNsense[2] and pfSense[3] for these 
newer versions. As you can see from [2] we have been at it since your commit. 
We brought this topic up with the C-ICAP mailing list[4]. Meanwhile, you had 
another open bug[5] first reported in April as well.

A silent couple of months followed until September. 0.5.4 and 0.5.5 came out 
which were tested and *both* submitted for you to review[6]. 15 days go by 
before you immediately committed a fix from another FreeBSD committer who added 
a very similar patch with a few cleanups on top. You failed to take into 
account that this patch may have included previous efforts, which were clearly 
laid out in the two weeks of existence of the ticket. They were committed as 
"Submitted by:  garga" and that was the end of it for you.

And you also never answered to [5] in the months June, July and August. Instead 
of looking into the issue, you've now opportunistically asked the user if the 
issue resolved itself?

In general, my concern is that we have a 3 months pause in urgency and then a 
generally sloppy approach to resolving the issues with no concern from you why 
we ended up here in the first place. And I don't care about bylines, but I care 
about process and a sense of urgency and professionalism to the task at hand so 
that no issue lays dormant for weeks and is then brushed over as if it was 
submitted yesterday and you have been all over it.

I understand that we are all busy and real lives get in the way, but it doesn't 
exempt or excuse you from not heeding the following things:

1. Talk to submitters as to what you are going to do given split choices 
against proposed changes or when conflicts arise, which have clearly arisen in 
[5] due to "more impovements". Renato himself called to his aid a rule 
previously that contributions that were opened earlier are the ones to be 
committed[7] which is in conflict with the action taken here. It makes no sense 
to me as an external contributor. And find the repeated involvement does not 
shed the best light on this.
2. Don't brush over submitter concerns after the fact. Admit your mistake. If 
you feel like it it doesn't hurt to say you're sorry this was handled in a 
suboptimal way.
3. Make sure an episode like this never repeats. The FreeBSD ports prosperity 
depends on it.

I would now like to add to your sentiment "Hope this glitch doesn't stop you 
from contributing in the future."

First of all, it's not a glitch. Your actions are raising multiple concerns 
over the fact that FreeBSD ports has many rules for external contributors, but 
some committers have no regard for process and correctness that is being forced 
upon externals in comparison.

Secondly, I'll continue pushing updates but have long lost faith in the 
"process" employed. In 2014 it would have been an honour to be a committer. In 
following years it would have been easier than wait for someone to help, to 
take burden off of other committers. Nowadays, I have to admit that my interest 
in this has completely faded so submissions are a mere courtesy to the user 
interests of the FreeBSD ports which cannot be left un- or underrepresented. I 
also feel the need to protect future contributions[8] in fear of doing them for 
no apparent reason if someone else submits them anyway, too.

More importantly Interactions like this alter the future forever. I would wish 
that this does not happen to others, especially newbies, contributing because 
it can just turn them away from FreeBSD to never return. It's up to you to make 
a difference here. I'm not seeing that at the moment so please prove me wrong.

Last but not least, this could have been avoided by showing at least a bit of 
empathy and maintainer spirit, but you decided to go the route of swiftly 
cherry-picking a submission that you can't even know wasn't based on the 
initial submission because you did not ask or talk or otherwise made an effort 
to separate the incoming submissions.

This is a singular incident in a rising battle for external contributors 
literally begging for committers to look at their patches in the port 

Re: net/ntopng: version jump by an order of magnitude

[Franco Fichtner]

Hi Guido,

> On 20. Sep 2018, at 9:02 AM, Guido Falsi  wrote:
> 
> Terribly sorry I did not catch the typo before committing!

No worries, was just wondering about it to point out that going
back to the proper date will not upgrade through package because
the version number is smaller again.

> BTW they are skipping odd numbers, so next version is likely to be 3.8.

Alright.  Thanks for the quick reply.  :)


Cheers,
Franco

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

net/ntopng: version jump by an order of magnitude

[Franco Fichtner]

Hi,

Small question:

https://github.com/freebsd/freebsd-ports/commit/0585180d

... has a typo in the version number which was an ISO date
originally.  Are we using this new date format now or is there
going to be a PORTEPOCH amendment?


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: LibreSSL CVE-2018-0732 correction

[Franco Fichtner]

> On 23. Jul 2018, at 9:29 PM, Mathieu Arnold  wrote:
> 
> On Mon, Jul 23, 2018 at 09:14:48PM +0200, Franco Fichtner wrote:
>> Hi,
>> 
>> What's the policy for picking these up?  Is there the same
>> kind of maintainer timeout at play here?  Feedback welcome.
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229037
> 
> security/vuxml is maintained by ports-secteam@, so it's their turf.  Or
> the maintainer of the offending port, or the person who did the first
> commit to vuln.xml file about this entry.
> In any way, the vuln.xml file is open to anyone to commit, so anyone can
> do it.

Great, so who will do it?


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

LibreSSL CVE-2018-0732 correction

[Franco Fichtner]

Hi,

What's the policy for picking these up?  Is there the same
kind of maintainer timeout at play here?  Feedback welcome.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229037


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Should a package restart on upgrade itself

[Franco Fichtner]

> On 26. Jun 2018, at 1:27 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> One example from today upgrade:
> 
> [87/96] Extracting open-vm-tools-nox11-10.2.5,2: .. done
> Stopping vmware_guestd.
> Waiting for PIDS: 516.
> Loading vmmemctl kernel module: already loaded.
> vmware_guestd not running? (check /var/run/vmware_guestd.pid).

Wasn't this added a year ago?  I remember because it broke a production
build system.  ;)

https://github.com/opnsense/tools/commit/6ee7188ebef 


CC jpaetzel


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Removing git dependencies on perl5 and python27

[Franco Fichtner]

> On 15. Jun 2018, at 10:10 AM, Mahmoud Al-Qudsi  wrote:
> 
> On Fri, Jun 15, 2018 at 2:57 AM, Michael Gmelin  wrote:
>> Last time I checked, building git without Perl broke submodules (which is a 
>> core feature that should work with a default installation).
> 
> I fully agree. Fortunately, (at least at a first glance) that does not
> seem to be the case.

The bottom line is that excluding Perl and Python support from git
will make it only usable for automated shell scripting.

Interactive parts require Perl or Python so there is nothing to be
gained from breaking POLA for existing users of the git FreeBSD
package or git software in general as any random tutorial out there
may not work for FreeBSD anymore.

For emphasis, this is suboptimal at best...


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Fwd: www/phalcon PHP flavoring

[Franco Fichtner]

Hi,

Maybe someone else will take this.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226552 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226552>


Thanks,
Franco

> Begin forwarded message:
> 
> From: Franco Fichtner <fra...@opnsense.org>
> Subject: www/phalcon PHP flavoring
> Date: 19. March 2018 at 9:56:18 AM CET
> To: Mathieu Arnold <m...@freebsd.org>
> Cc: lin...@gmail.com
> 
> Hi Mathieu,
> 
> Since you committed the previous change please consider following up using:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226552
> 
> The maintainer is impartial on the matter, but it seems like the proposal
> fits your intentions better than what was previously committed.
> 
> 
> Thanks,
> Franco

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: *** Error code 70

[Franco Fichtner]

> On 5. Mar 2018, at 3:28 AM, Paul Beard  wrote:
> 
> This was supposedly fixed almost 2 years ago in r412608. Seeing it now and 
> just updated to revision 463615.

Pkg 1.10.x "fixed" this and introduced this ports framework regression.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224244

Nobody works on it.

To update a port safely instead of

# make reinstall

one needs to type

# make && make deinstall && make install

;)

> 
> 
> /usr/ports/lang/php70-extensions]# make reinstall
> ===>  Installing for php70-extensions-1.1
> ===>   Registering installation for php70-extensions-1.1
> *** Error code 70
> 
> Stop.
> make[2]: stopped in /usr/ports/lang/php70-extensions
> *** Error code 1
> 
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-pkg
> To unsubscribe, send any mail to "freebsd-pkg-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

committer for snuffleupagus update

[Franco Fichtner]

Hi all,

See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225593


Thank you,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: RESTRICTED in net/frr

[Franco Fichtner]

Hi all,

No response from the committer or portmgr.  This is *bad*.

So we all agree it's ok to use the FreeBSD ports tree to
block open source projects for petty fights and favours?

But we are offended by strong language?

Can somebody with authority please clear this up beyond
a reasonable doubt or revert like it should have been
over a week ago.


Thank you,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: RESTRICTED in net/frr

[Franco Fichtner]

Hi Kurt,

> On 12. Jan 2018, at 9:57 AM, Kurt Jaeger  wrote:
> 
> As far as I understand it (and I'm by no means authoritative on this)!
> 
> [...]

Thank you for this.  Though I don't see a GPL violation reason here.

GPLv2 is still the license, the code is in the open.

In a nutshell, with the current info from the commit and yours:

Quagga did not allow FRR to fork.

I'm not sure it works that way.

> If anyone has more links to more details, please provide them!

Yes, please.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

RESTRICTED in net/frr

[Franco Fichtner]

Hi,

Can somebody please explain:

> Mark net/frr as RESTRICTED, it contains a possible GPL violation of some
> of the Quagga software that it includes.
> 
> Submitted by: Paul Jakma (author of Quagga)
> With hat: portmgr
> MFH:  2018Q1


If there is an open reason it should certainly be cited in the commit.

If not that must be backed right out because backstage drama is silly.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Option vs. flavor?

[Franco Fichtner]

Why not use a separate data package as optional dependency? Solves the 
conditional fetch.

> On 16. Dec 2017, at 22:02, Yuri  wrote:
> 
>> On 12/16/17 12:42, Ben Woods wrote:
>> Is there any reason why you want to avoid the download with the port “make
>> fetch”?
> 
> To not clog the package builder with huge unnecessary data? Or maybe this 
> shouldn't be a concern.
> 
>> This should not impact you if it uses subpackages and you just install the
>> program with pkg.
> 
> 
> But are subpackages already available?
> 
> 
> Yuri
> 
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Patches for a slave port

[Franco Fichtner]

Hi Kevin,

> On 15. Dec 2017, at 5:53 AM, Kevin Oberman  wrote:
> 
> Why does "svn diff" not see the new files? How do I get the diffs? Or am I
> going to have to manually generate the diff the old fashioned way.

Use "svn add" on these files beforehand.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make reinstall does not work

[Franco Fichtner]

> On 11. Dec 2017, at 7:34 AM, Kurt Jaeger  wrote:
> 
> Hi!
> 
>> On Sunday, 10 December 2017 at 20:32:38 +0100, Walter Schwarzenfeld wrote:
>>> Look at the link in Shawn Webb's post:
>>> 
>>> bapt (Baptisse Daroussin) wrote
>>> 
>>>  *bapt  * replied Nov 16, 2017
>>>  
>>> 
>> 
>> You should have quoted that in your reply.  And are we really now
>> using github as the primary repository?
> 
> pkg is developed on github, because as a tool it is supposed
> to be portable to other unix-like OS variants.
> 
> So the link to github is the link to upstream.

Now that that is sorted, can somebody please fix Mk/bsd.port.mk,
because it says, and probably has said for years...

# reinstall - Install the results of a build, ignoring "already 
installed" flag.

And the whole premise of "reinstall" being used as "deinstall reinstall"
in the face of "deinstall install" is just silly, either by deleting
the reinstall target or making it a composite target of deinstall + install
to not break existing tools / workflows.

It's worrisome that such latent fixes are not considered bugs, more so that
the inner workings of bsd.port.mk do not reflect that shift in "expected
behaviour" in any way; and even more so that long discussions are ongoing
where non-committers bring up issues and nobody with a commit bit cares to
even ask what could be wrong.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make reinstall does not work

[Franco Fichtner]

> On 10. Dec 2017, at 6:59 PM, Kevin Oberman  wrote:
> 
> On Sat, Dec 9, 2017 at 11:19 PM, Greg 'groggy' Lehey 
> wrote:
> 
>> On Saturday,  9 December 2017 at 12:04:02 +0100, Walter Schwarzenfeld
>> wrote:
>>> Thanks, this explains and solved the problem.
>> 
>> What?  And how?
>> 
>> Greg
>> 
> 
> Good question. "make reinstall" is, indeed, broken. I have been looking at
> bsd.ports.mk and reinstall simply deletes the .install_done and
> .package_done files from the work directory and than attempts to do a "make
> -DFORCE_PKG_REGISTER install" and that used to work.

>From what I saw, it "still works" on pkg 1.10.1, so 1.10.2 or 1.10.3
changed this, which--for stability reasons--it should probably not
have done.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make reinstall does not work

[Franco Fichtner]

> On 9. Dec 2017, at 12:29 AM, Shawn Webb  wrote:
> 
> This is due to this commit:
> https://github.com/freebsd/pkg/commit/7991c49665419916210ad589d4a85fd2a7f58b37
> 
> The standard procedure for reinstall is to do a deinstall first. I
> guess it's pretty common just to issue `make reinstall` (which is what
> I used to do as well). However, that's not the originally intended
> behavior as designed in the Ports build framework.
> 
> So: just do a `make deinstall reinstall`. It'll work that way.

That's not how the framework wants you to use it...  :)

https://github.com/freebsd/freebsd-ports/blob/9b94ce76dcc0e7b4875d6160e0b9cb4894a8ecbe/Mk/bsd.port.mk#L3483-L3487

I have the same reinstall error 70 with security/suricata with
pkg 1.10.3_1, but at least pkg 1.10.1 works fine, I just double-
checked.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [HEADSUP] Flavors, and specifically, Python flavors landing today

[Franco Fichtner]

> On 1. Dec 2017, at 9:28 AM, Mathieu Arnold <m...@freebsd.org> wrote:
> 
> Le 01/12/2017 à 07:20, Franco Fichtner a écrit :
>> Hi,
>> 
>>> On 30. Nov 2017, at 4:32 PM, Mathieu Arnold <m...@freebsd.org> wrote:
>>> 
>>> |  See Ports now have flavors enabled|
>>> |  Tool developers, see https://wiki.freebsd.org/Ports/FlavorsTools|
>>> |  All Python dependencies must have @${PY_FLAVOR} appended to them|
>> Very nice work, a thank you to all the people who worked on this!  :)
>> 
>> Preliminary build tests from here look as fine as ever, although the
>> full batch is still running.
>> 
>> FWIW, I found that fetch-recursive stopped working with FLAVOR set:
> 
> You will find that not setting FLAVOR will make it work just fine.
> (There are no ports that will fetch differently wrt flavors, so do not
> set it.)

Indeed, that's what I did.

Is this working as intended?  You do not see this as an incompatibility
within the framework WRT FLAVOR and -recursive targets?

If yes, will this be documented as such before it is reported again?


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [HEADSUP] Flavors, and specifically, Python flavors landing today

[Franco Fichtner]

Hi,

> On 30. Nov 2017, at 4:32 PM, Mathieu Arnold  wrote:
> 
> |  See Ports now have flavors enabled|
> |  Tool developers, see https://wiki.freebsd.org/Ports/FlavorsTools|
> |  All Python dependencies must have @${PY_FLAVOR} appended to them|

Very nice work, a thank you to all the people who worked on this!  :)

Preliminary build tests from here look as fine as ever, although the
full batch is still running.

FWIW, I found that fetch-recursive stopped working with FLAVOR set:

# cd /usr/ports/databases/py-sqlite3
# make fetch-recursive FLAVOR=py27
===> Fetching all distfiles for py27-sqlite3-2.7.14_7 and dependencies
===>  License PSFL accepted by the user
===>   py27-sqlite3-2.7.14_7 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by py27-sqlite3-2.7.14_7 for building
===>  pkg-1.10.2 FLAVOR is defined (to py27) while this port does not have
FLAVORS..
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/ports-mgmt/pkg
*** Error code 1

Stop.
make: stopped in /usr/ports/databases/py-sqlite3


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: committer wanted for maintainer timeouts

[Franco Fichtner]

Hi Kurt,

> On 22. Nov 2017, at 3:49 PM, Kurt Jaeger  wrote:
> 
> Done.

Many thanks!  :)


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

committer wanted for maintainer timeouts

[Franco Fichtner]

Hi,

Looking for a kind committer for these two issues:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218487
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222988


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Franco Fichtner]

> On 5. Oct 2017, at 9:47 AM, Eugene Grosbein  wrote:
> 
> On 05.10.2017 08:14, Adam Weinberger wrote:
> 
>> Poudriere wants to be everything to everybody
> 
> First poudriere will have to learn how to run without noticeable overhead
> compared to "just build from ports" before it could became "everything to 
> everybody"
> and it needs to became part of base system for that purpose.

For OPNsense we broke down the poudriere approach into a simple
equivalent that is capable of building inside a jail, resume
after a faulty build and wrap everything into a ready to use
(pkg-repo creation and signing) archive that can be moved to
a remote location and unpacked to be used as an online package
repo, but it would also work on a singular system.

https://github.com/opnsense/tools/blob/master/build/ports.sh

In case someone feels the need to know this before starting from
scratch trying to build something simple.  It does not support
clever multi-threading, but then again it would work as anyone
would use the ports tree manually and runs well in a headless
mode setting via cron for nightly rebuild fun.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: pkg issue after FreeBSD 11 upgrade

[Franco Fichtner]

Hi Baptiste,

> On 30. Aug 2017, at 3:05 PM, Baptiste Daroussin  wrote:
> 
>> No.  At OPNsense we use a patch to revert the behaviour.
>> 
>> https://github.com/opnsense/ports/blob/master/ports-mgmt/pkg/files/patch-libpkg_scripts.c
> 
> Why and what is your use case, there is a reason why this code has been added,
> and I would like to hear more about use cases so we can try to address them.

There's to things in this patch.

(1) The hard fail for scripts leaves a GUI-driven environment without
its package, so post-install fails become fatal and appliances are
completely stranded, possibly left without means of recovery.

This is where FreeBSD base and the "appliance" GUI packages are completely
separated.  This is somewhat mitigated by marking said GUI package
vital, but vital won't help if the package was deinstalled during an
upgrade and then the upgrade script itself fails.

Every now and then, I see "user disappeared" during package installs
on stock FreeBSD systems so the install fails.  I am guessing that's
the same issue.

(2) The reaper kills a package-based watchdog / backend service.  Maybe
HANDLE_RC_SCRIPTS can cope with this, but it would be beneficial to be
able to enable this per package / rc service / metadata as generally the
reaper is a fine and sane addition.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: pkg issue after FreeBSD 11 upgrade

[Franco Fichtner]

Hi Cassiano,

> On 30. Aug 2017, at 2:55 PM, Cassiano Peixoto  
> wrote:
> 
> Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only.

It was a later 10.x change as far as I know.

> Is there some flag to disable it? Or some hack that I could do?

No.  At OPNsense we use a patch to revert the behaviour.

https://github.com/opnsense/ports/blob/master/ports-mgmt/pkg/files/patch-libpkg_scripts.c


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: security/libressl: Add the possibility to build only libtls

[Franco Fichtner]

> On 21. Aug 2017, at 4:55 PM, Mathieu Arnold  wrote:
> 
>> Unless you build your own packages with OpenSSL from ports
>> you can just install LibreSSL and use it in your programs...
>> 
>> # pkg install libressl
>> 
>> OpenSSL lives in the base system, LibreSSL will be an optional
>> install under /usr/local.
> 
> 
> That is not quite true. As soon as you install openssl, openssl-devel,
> or libressl or libressl-devel, the ports framework will use it whenever
> you build something that needs SSL from the ports tree.

Maybe that wasn't clear.  I said "unless you build your own packages"
meaning "use prebuilt binary packages only".


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: security/libressl: Add the possibility to build only libtls

[Franco Fichtner]

> On 21. Aug 2017, at 11:59 AM, David Wahlund  wrote:
> 
> I'd like to use the libtls library of LibreSSL on FreeBSD. Or the python 
> bindings to libtls specifically. I do NOT however want to replace openssl or 
> use the libssl library.
> 
> From what I understand it would be possible in practice as I assume it's only 
> libssl that overwrites files used by openssl.
> 
> Would it be possible to create an option in LibreSSL, or preferably make a 
> separate port, for libtls only? That way future ports can depend on libtls 
> only. For example a future python-libtls port could depend on that.


Unless you build your own packages with OpenSSL from ports
you can just install LibreSSL and use it in your programs...

# pkg install libressl

OpenSSL lives in the base system, LibreSSL will be an optional
install under /usr/local.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Pkg does not upgrade if more than one repository is defined

[Franco Fichtner]

> On 28. Jul 2017, at 1:13 PM, Matt Smith  wrote:
> 
> This might also be related to the CONSERVATIVE_UPGRADE setting of pkg.conf. 
> According to the man page:
> 
> CONSERVATIVE_UPGRADE: boolean
> Ensure in multi repository mode that the priority is
> given as much as possible to the repository where a
> package was first installed from.  Default: YES.

Is it still blindly updating from other repositories when a newer
version was found there?  In that case COSERVATIVE_UPGRADE still
doesn't work in most scenarios.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

StrongSwan CVE-2017-9023 vuln.xml entry correction

[Franco Fichtner]

Hi,

An OPNsense user writes that the vuln.xml entry for CVE-2017-9023
has the wrong bound, it is less or equal to 5.5.2, not 5.5.3, see:

https://www.strongswan.org/blog/2017/05/30/strongswan-vulnerability-(cve-2017-9023).html

Can somebody correct this please?


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How to get pkg to recognize local repository?

[Franco Fichtner]

> On 17. Jul 2017, at 8:44 AM, Thomas Mueller  wrote:
> 
> What meta files?  There is a metamail-2.7_11.txz, but I don't think that's 
> what you meant.

The files digests.txz, meta.txz and packagesite.txz, like this...

https://pkg.opnsense.org/FreeBSD:11:amd64/17.1/latest/

> 
> On the drive I was trying to install from, 
> ls -l /mnt/usr/packages shows
> 
> total 12
> drwxr-xr-x  2 root  wheel  7680 Jun 12 07:34 All
> drwxr-xr-x  2 root  wheel   512 Jun 12 04:41 Latest

# pkg repo /mnt/usr/packages


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How to get pkg to recognize local repository?

[Franco Fichtner]

> On 17. Jul 2017, at 7:10 AM, Thomas Mueller  wrote:
> 
> pkg-static: Ignoring bad configuration entry in 
> /usr/local/etc/pkg/repos/mytemprepo.conf: "file:///mnt/usr/packages/All"
> pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static 
> install -f pkg" recommended
> No active remote repositories configured.

You want to point to file:///mnt/usr/packages instead, it should work given
the repository meta files are in there.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Should a package restart on upgrade itself

[Franco Fichtner]

Hi Matthias,

As far as I know, pkg package scripts' runaway processes are
reaped since a few versions, so you can't restart from there
anymore.

Maybe there is a way to detach correctly, I don't know.


Cheers,
Franco

> On 27. Jun 2017, at 6:29 PM, Matthias Fechner  wrote:
> 
> Dear all,
> 
> it is always a pain if pkg upgrade a lot of packages to restart all
> services to make sure update/security fixes are applied to all running
> services.
> 
> Is there an option in pkg that it restart services automatically or is
> it OK if I would add a post-install script to the packages (I maintain)
> that will include a "service foo restart"?
> 
> What is best practice here?
> 
> 
> Thanks
> Matthias
> 
> -- 
> 
> "Programming today is a race between software engineers striving to
> build bigger and better idiot-proof programs, and the universe trying to
> produce bigger and better idiots. So far, the universe is winning." --
> Rich Cook
> 
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Franco Fichtner]

> On 26. Jun 2017, at 9:43 AM, Kurt Jaeger  wrote:
> 
>> Thus, in some cases, people demand or insist because they want something 
>> they either cannot accomplish themselves, or cannot accomplish in the 
>> limited time they have. As far as I have observed, you can't even -pay- 
>> the ports experts to do something you might want.
> 
> You can discuss the general idea with the foundation. Then give them
> the money they estimate for the feature. They'll easily find folks doing it.
> It just won't be cheap.

How about this: add more volunteers to begin with, more free resources for
any useful work.  With the right project leadership it'll do great.  :)


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: lang/php71-extensions - missing php71-mssql

[Franco Fichtner]

> On 15. May 2017, at 3:01 PM, Torsten Zuehlsdorff  wrote:
> 
>>> We are using php56-mssql for connecting to some MSSQL servers and we are 
>>> planning to upgrade to PHP 7.1 now but unfortunately I cannot find 
>>> php71-mssql port.
>>> Why is it missing? Are there any problems to build this extension for PHP 
>>> 7.1?
>> PHP 7 does not have mysql anymore, only mysqli.
> 
> He asked for mSsql not mYsql. ;)

True, sorry for the noise.  :)


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: lang/php71-extensions - missing php71-mssql

[Franco Fichtner]

> On 15. May 2017, at 2:53 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> We are using php56-mssql for connecting to some MSSQL servers and we are 
> planning to upgrade to PHP 7.1 now but unfortunately I cannot find 
> php71-mssql port.
> Why is it missing? Are there any problems to build this extension for PHP 7.1?

PHP 7 does not have mysql anymore, only mysqli.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: diff and submissions

[Franco Fichtner]

> On 4. May 2017, at 10:20 AM, Mathieu Arnold  wrote:
> 
> If you went as far as being able to create a pull request, you can do a
> git show HEAD or git diff origin/trunk...HEAD and submit that in the
> FreeBSD PR as well.

It's pretty easy to extract the diff from a PR on GitHub, just append
".diff", and ".patch" works too, but gives the full git commit history:

https://github.com/freebsd/freebsd-ports/pull/62.diff


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

zabbix server LibreSSL BROKEN improvement

[Franco Fichtner]

Hi,

I know this didn't fully time out yet, but it is a blanket?
change that allows to build Zabbix Server higher than version
3 "with" LibreSSL by selecting a different crypto option
(GnuTLS/PolarSSL) instead of failing the hard way all the time:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218238


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Suricata / Hyperscan ports timeouts

[Franco Fichtner]

Hi ports,

I would like to kindly ask for assistance on these port
updates.  Suricata has been lagging behind for quite some
time now and for quality reasons FreeBSD must be quicker
in adapting these patches.

Yes, they work fine.  Suricata developers take good care
of FreeBSD compatibility including netmap support and the
newer versions are already incorporated in FreeBSD in a
release setting.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217116
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217143


Thank you,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 6:03 PM, Steve Wills  wrote:
> 
> Just because you don't use any features of the newer version doesn't
> mean it's safe to run binaries built for the newer version on the older
> version, as far as I understand it.

True.  :)

Yet the reports are for missing symbols in pkg and how to fix.  It
beats pulling a ports tree and rebuilding pkg which may or may not
end up being replaced by a newer repo version on the next pkg upgrade.

Plus you still get to garbage-collect compatibility features during
major upgrade jumps.

Fixing this issue in 25k at the same times ends up delaying a workable
solution, whatever it may be.

pkg first, then the rest, no?


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 5:53 PM, Steve Wills  wrote:
> 
> What would enforcement look like? Something like "Sorry, you can't pkg
> update because this system isn't supported any more."? But how would
> that be possible without also breaking things for those who build/ship
> their own OS and packages?

Let me try another way:

Since pkg has feature macros for building correctly on different
FreeBSD versions, namely 10.0, 10.1, 10.2 and 10.3, the way to
provide binaries without missing symbols is to build pkg with a
fixed set of feature macros for 10.0.

I've done this for projects to retain upgrade paths.  It's not
hard.  It doesn't violate a policy or promise FreeBSD makes, does
it?


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 5:53 PM, Steve Wills  wrote:
> 
> What would enforcement look like? Something like "Sorry, you can't pkg
> update because this system isn't supported any more."? But how would
> that be possible without also breaking things for those who build/ship
> their own OS and packages?

Let me try another way:

Since pkg has feature macros for building correctly on different
FreeBSD versions, namely 10.0, 10.1, 10.2 and 10.3, the way to
provide binaries without missing symbols is to build pkg with a
fixed set of feature macros for 10.0.

I've done this for projects to retain upgrade paths.  It's not
hard.  It doesn't violate a policy or promise FreeBSD makes, does
it?


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 5:21 PM, Steve Wills  wrote:
> 
> We provide backwards compatibility, not forwards compatibility.

But don't you see that users won't know this?

This is a good theory, yet it is difficult in practice because it is
not being enforced.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 5:21 PM, Steve Wills  wrote:
> 
> We provide backwards compatibility, not forwards compatibility.

But don't you see that users won't know this?

This is a good theory, yet it is difficult in practice because it is
not being enforced.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 5:12 PM, Konstantin Belousov <kostik...@gmail.com> wrote:
> 
> On Thu, Feb 09, 2017 at 04:30:20PM +0100, Franco Fichtner wrote:
>> FreeBSD package management makes an ABI promise in the form of
>> "FreeBSD:10:amd64", but not even pkg code itself adheres to this,
>> and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.
> Stop spreading FUD. There is no ABI breakage on stable/10 branch,
> nor there is a breakage in the package sets. We only promise
> backward-compatibility, and this works as advertized. A binary compiled
> on later system, is not guaranteed to work on the early system even on
> the same branch.
> 
> The current package set for stable/10 is built on 10.3 and is only
> guaranteed to work on 10.3 and later. Trying to make arbitrary
> combinations of binaries and base systems outside of the scope of the
> project.

You're contradicting yourself here.  Either it's compatible or it isn't?


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 4:47 PM, Steve Wills  wrote:
> 
> They're supposed to upgrade to a supported version of FreeBSD.

pkg won't refuse the upgrade.  And at least if it upgraded, it
should not break itself.

Imagine a GUI-driven appliance being bricked.  There is nobody
who can tell it "fetch ports and build pkg to keep using it".

Don't get me wrong.  Automation around pkg is really good, though
that doesn't warrant it's perfect (yet).


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

Hi Steve,

> On 9 Feb 2017, at 4:09 PM, Steve Wills  wrote:
> 
> Ports and packages are maintained on the assumption that the user is
> using a supported version of the OS. We didn't decide when to end
> support for 10.1 or 10.2. How long after the end of life for 10.1 would
> you have ports maintain support?

The issue is quite simple and cause of multiple issues:

FreeBSD package management makes an ABI promise in the form of
"FreeBSD:10:amd64", but not even pkg code itself adheres to this,
and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.

And since pkg acts according to the imposed paradigm of a unified
ABI, this will continue to be a source of problems for users who
cannot know what's going on, lest even know how to fix it.

They simply run:

# pkg upgrade

And then their systems are unusable *and* not fixable with pkg.

What are they supposed to do?  They come here.  They want to make
everyone aware that this is a serious issue that shouldn't repeat
in FreeBSD 11.  It's not to late to do that by pinning the pkg ABI
to 11.0 by forcing the proper feature macros.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 10:03 AM, Kirill Ponomarev <k...@krion.cc> wrote:
> 
> On 02/09, Franco Fichtner wrote:
>> 
>>> On 9 Feb 2017, at 9:49 AM, Kirill Ponomarev <k...@krion.cc> wrote:
>>> 
>>> I don't understand all critics I see in this thread and in your mail,
>>> the fate of this project is all in your hands - try to contribute more,
>> 
>> I'm going to stop you right there.
>> 
>> That's not entirely true.  Too few committers, substantial lack of
>> maintainer feedback, apparently no mentors to pick up newcomers, and
>> worst of all no newcomers.
>> 
>> Decide for yourself which of these are true and which are self-made
>> due to project management policies.
> 
> I think I've dejavu, as I've been reading these statements since 15
> years, and they've the same meaning and context, with the same
> argumentations and facts.  The truth is - the dogs bark, but the
> caravan moves on.

The lack of an open reply is exactly what I was arguing for, so I'm not
sure how much this stance helps your case.  ;)


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 9:49 AM, Kirill Ponomarev  wrote:
> 
> I don't understand all critics I see in this thread and in your mail,
> the fate of this project is all in your hands - try to contribute more,

I'm going to stop you right there.

That's not entirely true.  Too few committers, substantial lack of
maintainer feedback, apparently no mentors to pick up newcomers, and
worst of all no newcomers.

Decide for yourself which of these are true and which are self-made
due to project management policies.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 8 Feb 2017, at 12:29 PM,   
> wrote:
> 
> I just tried to install the fuse-nfts pkg under 10.2 on my
> server-of-all-work.  But after requiring me to "upgrade" pkg, the
> fuse-ntfs install failed, apparently because there's an undefined
> symbol ("utimenstat") in pkg itself!
> 
> How do I extricate myself?

The latest supported release is FreeBSD 10.3 and packages are therefore
build against it.  It creates this soft breakage inside the fixed ABI,
which quite a few people run into.

There are two solutions:

(a) Build the packages yourself on a FreeBSD 10.2.

(b) Upgrade to FreeBSD 10.3 and do a "pkg upgrade -f" run.

And for the wicked:

(c) Let's please address this issue within FreeBSD so users don't run into it.

;)


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

pending PRs

[Franco Fichtner]

Hi,

Please have a look at either one of:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215313
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215900


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Ports options in make.conf vs. GSSIAPI

[Franco Fichtner]

> On 13 Jan 2017, at 1:40 PM, Stefan Bethke <s...@lassitu.de> wrote:
> 
>> 
>> Am 13.01.2017 um 13:36 schrieb Franco Fichtner <fra...@lastsummer.de>:
>> 
>> Hi Stefan,
>> 
>>> On 13 Jan 2017, at 1:30 PM, Stefan Bethke <s...@lassitu.de> wrote:
>>> 
>>> For example, with dns/bind99, without options for that port in make.conf, I 
>>> can run make showconfig and other build commands without issue.  As soon as 
>>> I add either of these:
>>> #OPTIONS_UNSET+=  GSSAPI_BASE
>>> #OPTIONS_SET+=GSSAPI_MIT
>>> dns_bind99_UNSET+=  GSSAPI_BASE
>>> dns_bind99_SET+=GSSAPI_MIT
>>> 
>>> running make showconfig produces:
>>> # make showconfig
>>> > You must select one and only one option from the GSSAPI single
>>> *** Error code 1
>> 
>> Try to use "=" instead of "+=" for SET/UNSET.
>> 
>> Here's an example we use in production:
>> 
>> https://raw.githubusercontent.com/opnsense/tools/master/config/17.1/make.conf
> 
> Tried that, doesn’t make a difference.

BATCH=yes is specifically for avoiding interaction.  If the config
is stuck "rmconfig" may help, too.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Ports options in make.conf vs. GSSIAPI

[Franco Fichtner]

Hi Stefan,

> On 13 Jan 2017, at 1:30 PM, Stefan Bethke  wrote:
> 
> For example, with dns/bind99, without options for that port in make.conf, I 
> can run make showconfig and other build commands without issue.  As soon as I 
> add either of these:
> #OPTIONS_UNSET+=  GSSAPI_BASE
> #OPTIONS_SET+=GSSAPI_MIT
> dns_bind99_UNSET+=  GSSAPI_BASE
> dns_bind99_SET+=GSSAPI_MIT
> 
> running make showconfig produces:
> # make showconfig
> > You must select one and only one option from the GSSAPI single
> *** Error code 1

Try to use "=" instead of "+=" for SET/UNSET.

Here's an example we use in production:

https://raw.githubusercontent.com/opnsense/tools/master/config/17.1/make.conf


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: openldap-client vs openldap-sasl-client

[Franco Fichtner]

> On 9 Jan 2017, at 11:54 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> I don't need SASL for LDAP client, but somebody messed up ports tree with 
> WANT_OPENLDAP_SASL which is for users and not maintainers:
> 
> # WANT_OPENLDAP_SASL
> #   - User-defined variable to depend upon 
> SASL-enabled OpenLDAP
> # client. Must NOT be set in a port Makefile.

This note was added two days ago and it's simply not correct,
and/or overcome by events as it is against the common practice
in the tree *and* adhering to it would break currently working
ports.

OpenLDAP needs framework improvements of the sort that gssapi
or ssl received, but we have yet to hear from the maintainer of
OpenLDAP on the matter.

So far, there was a single answer on the suggestion to unify
SASL into OpenLDAP as a default option, to be taken out by avid
self-made port builders when they are sure they don't need it
and don't break their ports.  The plus would be no more
package name changes of the sort openldap-{sasl-,}client and
the dependency tracking issues associated with having two
ports clash with each other, because they are "same same but
different".


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: openldap-client vs openldap-sasl-client

[Franco Fichtner]

> On 5 Jan 2017, at 11:44 AM, Julian Elischer  wrote:
> 
> On 5/01/2017 6:30 PM, Jan Bramkamp wrote:
>> On 04/01/2017 18:32, Andriy Gapon wrote:
>>> 
>>> Do you I understand correctly that it is impossible now to install both 
>>> samba44
>>> and libreoffice using the official FreeBSD package repository?
>>> Or samba44 and KDE?
>>> 
>>> If yes, then that sucks...
> 
> similar happened recently with the two jpeg libraries.
> They can't be installed at the same time but some packages wanted one and 
> some the other.

The OpenLDAP package state is a bit behind more modern ports framework
approaches.  Fixing the offending packages away from OpenLDAP is nice,
but eventually the issues will reappear port for port, time after time.

If we strive for default ports options that are sane for most users,
globally setting WANT_OPENLDAP_SASL=yes is the way to prevent that
from happening again.

There is probably a very valid historic reason for not having done so,
but people can still build their own ports without SASL if they want and
incompatibility issues are unlikely when the support is built in.  At
least we haven't seen anything in the past 6 months in OPNsense since we
switched to avoid this in our build runs.

And besides, having a package name flip-flop using arcane toggles should
be removed as it breaks POLA.

Long story short: make SASL an OPTION, add it to defaults, don't mess
with the package name anymore?


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OpenVPN 2.3.13+ and the subnet fix on FreeBSD 10.x

[Franco Fichtner]

Hi,

Turns out the issue could not be reproduced by the reporter anymore.  Thanks
to both mandree@ and OpenVPN for helping out so swiftly.  The current 2.3.14
work as expected.


Cheers,
Franco

> On 21 Dec 2016, at 11:47 AM, Franco Fichtner <fra...@lastsummer.de> wrote:
> 
> Hi,
> 
> Looks like subnet fix has unfortunate consequences[1] in FreeBSD 10.x.
> 
> Can we get this fixed before it hits quarterly?
> 
> 
> Cheers,
> Franco
> 
> --
> [1] https://github.com/opnsense/core/issues/1314
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

[Franco Fichtner]

> On 23 Dec 2016, at 10:34 AM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> But we don't have that now. For example dns/py-dnspython can create 
> py27-dnspython, py33-dnspython, py34-dnspython, py35-dnspython - four 
> different packages from one origin, one Makefile.

Noticed that too.  This could be easily solved with slave ports that set
this for e.g. py27-dnspython:

USES= python:2.7

and in the master port

USES?= python
USES+= other-uses-stuff

In fact, py-dnspython master port already does it this way.  But most
Python ports do not.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

OpenVPN 2.3.13+ and the subnet fix on FreeBSD 10.x

[Franco Fichtner]

Hi,

Looks like subnet fix has unfortunate consequences[1] in FreeBSD 10.x.

Can we get this fixed before it hits quarterly?


Cheers,
Franco

--
[1] https://github.com/opnsense/core/issues/1314
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

[Franco Fichtner]

> On 20 Dec 2016, at 9:42 AM, Franco Fichtner <fra...@lastsummer.de> wrote:
> 
> To emphasise on this:

And lastly... if we have the automatic "default" flavour that is
defined by the OPTIONS_DEFAULT knobs, we could finally avoid pkg
upgrading custom builds by knowing that somebody built a "custom"
version of their port and that there is no equivalent to upgrade
to.

This is exciting!


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

[Franco Fichtner]

> On 20 Dec 2016, at 9:27 AM, Franco Fichtner <fra...@lastsummer.de> wrote:
> 
> We shouldn't use "-" or "/" anyway, should we?  Please no fancy things
> like "~" or so.  No arbitrary package names...

To emphasise on this:

A flavour should act as a full replacement of its unflavoured package, that
means the package name must be kept.  Only one flavour (or unflavoured)
package can be installed at all times.  As an example:

A weird package "foo" requires "vim", but the user doesn't want to deal with
X11, the user should be able to:

# pkg install vim:lite foo

This should not try to change "vim:lite" to "vim".

# pkg install vim

This should be perfectly fine afterwards, too.

Every "vim" should act as "vim", not revoking the integrity of the package
dependency on vim during e.g. pkg upgrade.  No forced install should be
needed to do this as long as the shared libraries and dependencies are still
satisfied.  And maybe the moral of the story is that flavours should not
be depended on by default, although it could be a possibility for special
cases.

This is something that is really really needed.  An very good example would
be Suricata package with Hyperscan right now, where Hyperscan does not work
on all amd64 architectures, so we need to have a replacement package.  But
if that replacement package without Hyperscan needs to be a separate port,
any package depending on Suricata (e.g. a distribution or GUI package) will
complain about the missing dependency and try to undo a Suricata-No-Hyperscan
package[1] as it conflicts and changes back to the defunct package on upgrade.


Cheers,
Franco

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210490
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

[Franco Fichtner]

Hi,

> On 19 Dec 2016, at 1:31 AM, Baptiste Daroussin  wrote:
> 
> For flavors I would like to propose a simple approach first which is more 
> like a
> rework of the slave ports for now:

This progression sure is nice to see!  I like "category/portname/flavour"
origin a lot, but how is it handled in terms of packages names?

Are we going to see something like:

# pkg install myport:flavour

We shouldn't use "-" or "/" anyway, should we?  Please no fancy things
like "~" or so.  No arbitrary package names...

In OpenBSD, installing flavoured packages has been hard to script in the
past, offering a prompt whenever the main package is going to be installed.
The thing to think about here is that

# pkg install myport

Should *only* install the default port, especially with -y option.

# pkg install myport:

This *could* prompt for flavours, then.  The nice thing should be the
user doesn't have to care about flavours if that is so.

Flavours as you showed can be very simple.  Why not go the extra mile
here:

FLAVOURS=   sub1 sub2

OPTIONS_sub1=   EXPLICIT LIST OF OPTIONS
OPTIONS_sub2=   ANOTHER LIST OF OPTIONS

And keep everything as is.  No need for sub-packages?  No implied
OPTIONS_DEFAULT, no nothing.  A single line to grep and change.  :)

>From this perspective, nothing changes for users of the ports tree, options
are defined by the main port and all of its flavours are neatly stored in
the Makefile.  People can still use all options during rebuild, even the
ones only used in flavours.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: net/haproxy 1.7.0 : libressl support

[Franco Fichtner]

> On 9 Dec 2016, at 11:51 AM, Dmitry Sivachenko  wrote:
> 
> If they reject it and refuse to support libressl for some reason, we will not 
> add your patches too, because this is not something FreeBSD-specific.

Strongswan developers said similar things.  Unfortunately,
we have very good support of LibreSSL in the FreeBSD ports
tree since 2015.  No reason to flush this down the toilet,
not yet anyway if the patches work.

We used to have this patch, it still fixes strongswan,
likely fixes haproxy 1.7:

https://github.com/opnsense/ports/commit/7e8ea59cabc

I brought this up with LibreSSL developers, some other
users from different BSD projects noted this needs fixing
too.  We're not there yet, but we can find a solution if
everyone does their part in embracing choice for users.  :)


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: security/heimdal timeout, committer wanted

[Franco Fichtner]

> On 31 Oct 2016, at 6:04 PM, Mathieu Arnold <m...@freebsd.org> wrote:
> 
> Le 31/10/2016 à 13:25, Franco Fichtner a écrit :
>> Hi,
>> 
>> A simple packaging fix for security/heimdal port is required to
>> include two header files which are provided in base and security/krb5
>> and currently make sysutils/msktutil fail with option gssapi:heimdal.
> 
> PR ?

Oh, of course, apologies:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213470


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

security/heimdal timeout, committer wanted

[Franco Fichtner]

Hi,

A simple packaging fix for security/heimdal port is required to
include two header files which are provided in base and security/krb5
and currently make sysutils/msktutil fail with option gssapi:heimdal.


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: www/subsonic-standalone license

[Franco Fichtner]

> On 28 Oct 2016, at 6:30 PM, Joshua Ruehlig  wrote:
> 
> I don't believe the maintainer dropped the project.

I was talking about www/subsonic, sorry for the confusion:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213298

> If a user wants to use a previous version they are free to modify the 
> PORTVERSION, update the 'distinfo', and build the port. Also the 
> 'www/subsonic' port is still on version 5.3 so people can use that as well.

That's impractical for users who use packages.  :)


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: www/subsonic-standalone license

[Franco Fichtner]

> On 28 Oct 2016, at 5:53 PM, Joshua Ruehlig  wrote:
> 
> Franco, what do you mean a maintainer drop?
> Also Madsonic, which is supposedly GPL based on their website is available.

The maintainer resigned, but updated to 6.0 because there were no distfiles,
and the code seemed to be gone for 5.3 is now on GitHub:

https://github.com/sindremehus/subsonic

I don't know whether 6.0 is quintessential, but from a pure license perspective
it seems odd that everyone now has to use a proprietary license with no options
given even though we still have the original 5.3 *and* a fork which could very
well gain traction of a port was added as an alternative.

Just for the record, I know this takes work.  Not asking for it to be done,
simply wondering why this happened the way it did.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: www/subsonic-standalone license

[Franco Fichtner]

> On 28 Oct 2016, at 4:41 PM, Joshua Ruehlig  wrote:
> 
> sure I'll take a look. I assume all I need to do is find and set the
> current license?

I would like to take this opportunity to ask why we have a maintainer
drop whilst doing the upgrade of a free 5.3 to a proprietary 6.0.

What's the logic in that?  Wouldn't it be better to have keep 5.3 until
it dies in dignity?

Also, there is https://github.com/Libresonic/libresonic


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lighttpd does not pull OpenSSL dependency

[Franco Fichtner]

> On 27 Oct 2016, at 11:00 AM, Mathieu Arnold  wrote:
> 
> Le 26/10/2016 à 15:44, David Demelier a écrit :
>> 2016-10-26 10:46 GMT+02:00 Mathieu Arnold :
>>> Le 26/10/2016 à 00:14, Don Lewis a écrit :
 Then the question is, if DEFAULT_VERSIONS+=ssl=openssl is not in
 make.conf, then why is OpeSSL from ports installed?  Nothing should
 be depending on it.
>>> Well, the problem is that many ports have WITH_OPENSSL_PORT defined, so,
>>> something could have brought it along. I have a git branch changing it
>>> to WANT_OPENSSL_PORT that will mark the port IGNOREd if using base
>>> OpenSSL, I should commit it one day.
>>> 
>>> Also, I'll change the default for ports from base to openssl, one day.
>> I can help if needed.
> 
> But I don't use all of that, so I need help figuring out which should be
> the default afterwards (it can't be base, because you can't mix base
> heimdal with non base openssl)

Having stripped Kerberos from base for our 11.0 builds makes for a
nice test bed in places where GSSAPI is not yet in a port, but actually
required, leading to quick build errors.

gssapi:heimdal is the closes thing to base as far as we could see, and
we've rolled out several OPNsense releases with both OpenSSL and Heimdal
from ports that work nicely with external AD servers.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make makepatch

[Franco Fichtner]

> On 27 Oct 2016, at 8:28 AM, Jochen Neumeister  wrote:
> 
> Is this now right, that i can only use the new patch in /files? With
> "make clean" i delete the work folder and the old patches.

If all the previous patches patch a single file, makepatch will generate the
patch for the file, because it doesn't care about the ptch context, just the
file.

If you want, you can deconstruct the new patch file and push the individual
chunks into their old files to silence portlint, but that only works if the
patches do not depend on each other.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make makepatch

[Franco Fichtner]

> On 27 Oct 2016, at 7:53 AM, Jochen Neumeister  wrote:
> 
> No, make makepatch delete the patches into /files and:

If there are no patches in files/ maybe you have no patches applied
in the work/ dir?  Does running "make patch" before makepatch help?


Cheers,
Franco

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make makepatch

[Franco Fichtner]

Hi Jochen,

> On 27 Oct 2016, at 7:47 AM, Jochen Neumeister  wrote:
> 
> what am i doing wrong?

Doesn't makepatch already place the new patches in files/?


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Alternatives to rsync

[Franco Fichtner]

> On 14 Oct 2016, at 7:54 AM, Eduardo Morras via freebsd-ports 
>  wrote:
> 
> 
> Sorry for commenting on this reply to Greg to answer Shane Ambler, I
> joined maillist today.
> 
> On Fri, 14 Oct 2016 09:26:03 +1100
> Greg 'groggy' Lehey  wrote:
> 
>> On Thursday, 13 October 2016 at 18:13:39 +1030, Shane Ambler wrote:
>>> On 13/10/2016 15:09, reko.turja--- via freebsd-ports wrote:
 One of my users is needing rsync like functionality to transfer
 changed contents of some directories between couple of machines.
 As rsync 3 isn't open source, but GPL3 it's out of question in
 order to keep the system untainted.
 
 The software should be relatively lightweight - no fullblown
 mirroring/backup is needed. Also hints how to achieve similar ends
 using maybe tar/ssh might do.
>>> 
>>> sysutils/cpdup provides similar functionality to rsync and is bsd
>>> licensed.
> 
> cpdup in ports comes from old matt dillon pages and is version1.18.
> DragonflyBSD has version 1.32 at [1][2] and compiles with low effort on
> FreeBSD.

If there is interest in updating the port we should do it.  I can talk
to Matt, see if he is willing to release an updated portable version
with required build fixes (if any).


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Alternatives to rsync

[Franco Fichtner]

> On 13 Oct 2016, at 6:39 AM, reko.turja--- via freebsd-ports 
>  wrote:
> 
> The software should be relatively lightweight - no fullblown mirroring/backup 
> is needed. Also hints how to achieve similar ends using maybe tar/ssh might 
> do.

Try cpdup(1).


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

pending security/suricata updates

[Franco Fichtner]

Hi list,

There are two pending updates for Suricata in bugzilla,
would anybody willing to take these?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210490
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212815


Thank you,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Pkg doesn't care about conflict

[Franco Fichtner]

> On 27 Sep 2016, at 5:05 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Margaret wrote on 09/27/2016 14:55:
> 
> [...]
> 
>>> Did you stop pkg in the middle or did you let it go? I think it will
>>> show you conflict message and ask you if you would like to deinstall PHP
>>> 7.0 and install 5.6 instead.
>>> 
>>> Miroslav Lachman
>> 
>> I stopped it immediately.
>> 
>> If you're right about it showing a conflct message (my memory
>> says you are), I'd think it would be friendlier to print the
>> message first, before anything is downloaded.  It routinely
>> checks versions, so putting out the conflict message immediately,
>> even before showing the proposed downloads, shouldn't be hard.
> 
> I think that conflicts are defined in package metadata so pkg don't know 
> about conflict until package is downloaded. Maybe I am wrong. I didn't 
> examine pkg internals too deep.

There is no concept of conflicts in package metadata.  The resolver
will figure out if packages conflict at runtime and it may run into
conflicts later due to replacing or installing packages that use the
same files, different shared libraries and maybe more (IDK).

It has occasionally stripped innocent top packages in systems for
me.  It looks like it doesn't virtually resolve through the whole
process but goes ahead with some operations that it later can't
roll back and just goes on taking a previous "y" as a base line.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

net/samplicator: fix fetch and bump to 1.3.8rc1

[Franco Fichtner]

Hi there,

This moves port fetch to GitHub and (unfortunately)
bumps to a newer version since there is no tag for
the former version.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212811

The new version was already tested in a production
environment and works as expected.  Can provide a
build log if requested.


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

sysutils/msktutil: fix fetch

[Franco Fichtner]

Hi there,

The msktutil home moved to SF.  There is also a new version
1.0 that came out two days ago so it's active... but first
things first.  :)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212810


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: devel/libsysinfo

[Franco Fichtner]

Hi Kurt,

> On 22 Sep 2016, at 1:37 PM, Kurt Jaeger  wrote:
> 
> Only if you provide one -- and a patch for the port.

Within this Google Code fallout, is there a policy for how the
submitted patches are committed?  E.g. do they require maintainer
approval?  Are they priority items?


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Checking port option descriptions

[Franco Fichtner]

> On 19 Sep 2016, at 12:59 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> In the end of this story - we are no longer using ports versions for any PHP 
> web applications. We are using them directly because ports were more 
> problematic.

We use various PHP packages from ports for a larger project
without any issues or having to deal with custom options.
It has also gotten a lot better in the last two years from
a ports framework perspective.

Yes, some things get messy when you go against the framework,
but that only leaves the option to make the framework more
flexible or deal with the custom build by building another
framework.  If there is an incompatibility between the two
approaches I don't see how e.g. your issues will be resolved
by changing the ports framework.

If there aren't any incompatibilities it's just work to get
it done.  :)

> pkg is too interactive anyway (compared to any older method) so I don't think 
> this will be a problem. I think it will be useful to do this on install phase 
> instead of package building phase.

pkg scripts really well compared to e.g. OpenBSD's pkg_add,
which at least for 5.9 cannot non-interactively select ambiguous
flavors.  You can see the latter was designed and nurtured from
a user's point of view, but deploying jails or custom images
with packages is way easier with FreeBSD's pkg.  It's not perfect
either, but it's in better shape than you might believe.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OpenSSL port ASM removal

[Franco Fichtner]

> On 19 Sep 2016, at 11:35 AM, Franco Fichtner <fra...@lastsummer.de> wrote:
> 
> 3. Is AESNI support considered a must-have feature for the
> OpenSSL port in FreeBSD or not?  How about base OpenSSL?  And
> how does this affect the plans to switch to OpenSSL from ports
> by default that would potentially strip AESNI support from all
> ports relying on it at the moment?

Some data off a FreeBSD 10.3 with base and ports OpenSSL/LibreSSL.
Base OpenSSL and ports LibreSSL are both four times faster than
ports OpenSSL in the default configuration for the particular
envelope mode.  The only fix here was the ASM option.

Segfaults in non-OpenSSL code that is OpenSSL-related hints to
improper linking/building between OpenSSL from ports and base.
I've done parallel builds for OpenSSL and LibreSSL from ports for
over a year and this doesn't happen unless there is something
stuck in the build system.

Please bring it back for the FreeBSD users that rely on AESNI and
do not have these problems.


Cheers,
Franco
--

+ uname -a
FreeBSD sensey64 10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 
18:38:15 UTC 2016 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
+ /usr/bin/openssl version
OpenSSL 1.0.1s-freebsd  1 Mar 2016
+ /usr/bin/openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 130910375 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 64 size blocks: 35016412 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 8989961 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 2255832 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 281046 aes-128-cbc's in 3.00s
OpenSSL 1.0.1s-freebsd  1 Mar 2016
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) 
blowfish(idx) 
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
aes-128-cbc 696375.19k   747016.79k   767143.34k   769990.66k   767442.94k

+ pkg query %n-%v openssl
openssl-1.0.2_15,1
+ /usr/local/bin/openssl version
WARNING: can't open config file: /usr/local/openssl/openssl.cnf
OpenSSL 1.0.2h  3 May 2016
+ /usr/local/bin/openssl speed -evp aes-128-cbc
WARNING: can't open config file: /usr/local/openssl/openssl.cnf
Doing aes-128-cbc for 3s on 16 size blocks: 31667033 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 64 size blocks: 8481827 aes-128-cbc's in 3.04s
Doing aes-128-cbc for 3s on 256 size blocks: 2177621 aes-128-cbc's in 3.09s
Doing aes-128-cbc for 3s on 1024 size blocks: 535092 aes-128-cbc's in 3.03s
Doing aes-128-cbc for 3s on 8192 size blocks: 66121 aes-128-cbc's in 3.02s
OpenSSL 1.0.2h  3 May 2016
built on: reproducible build, date unspecified
options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) 
idea(int) blowfish(idx) 
compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS 
-pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 
-Wall -O2 -pipe  -fstack-protector -fno-strict-aliasing
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
aes-128-cbc 168452.17k   178619.86k   180192.64k   180761.80k   179618.90k

+ pkg query %n-%v libressl
libressl-2.4.2
+ /usr/local/bin/openssl version
LibreSSL 2.4.2
+ /usr/local/bin/openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 131903200 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 35044060 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 256 size blocks: 8969315 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 1024 size blocks: 2291514 aes-128-cbc's in 3.09s
Doing aes-128-cbc for 3s on 8192 size blocks: 281113 aes-128-cbc's in 3.01s
LibreSSL 2.4.2
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) 
blowfish(idx) 
compiler: information not available
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
aes-128-cbc 703483.73k   749558.59k   759448.36k   760388.16k   765632.07k
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OpenSSL port ASM removal

[Franco Fichtner]

Hi Dirk,

> On 19 Sep 2016, at 11:22 AM, Dirk Meyer  wrote:
> 
>> ASM support for OpenSSL is missing from the port now,
>> which is kind of unfortunate for two reasons:
>> (a) FreeBSD base (at least for i386 and amd64) has it.
>> (b) ASM is required for AESNI to work last time I checked.
>> Why was it removed? It's not clear from the commit message.
> 
> Users with asm option enabled on amd64 have reported
> random segfaults in many ssl applications.
> 
> They confirmed that disabling asm option fixed their problems.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210859

This leads to even more questions:

1. Why is a non-default option removed that breaks for "some"
users?  We have thousands of OPNsense users that successfully
run it since October 2015.  Not one single segfault report.

https://github.com/opnsense/tools/commit/e344cfc35e6

2. What is the upstream-supported trigger for enabling AESNI
code in OpenSSL?  Or is AESNI support unaffected?

3. Is AESNI support considered a must-have feature for the
OpenSSL port in FreeBSD or not?  How about base OpenSSL?  And
how does this affect the plans to switch to OpenSSL from ports
by default that would potentially strip AESNI support from all
ports relying on it at the moment?


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

OpenSSL port ASM removal

[Franco Fichtner]

Hi all,

ASM support for OpenSSL is missing from the port now,
which is kind of unfortunate for two reasons:

(a) FreeBSD base (at least for i386 and amd64) has it.

(b) ASM is required for AESNI to work last time I checked.

Why was it removed? It's not clear from the commit message.

LibreSSL port has had the assembler bits turned on a
while back by default, too.


Thanks,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Maintainership Status for PHP 5.6

[Franco Fichtner]

Hi Kurt,

> On 26 Aug 2016, at 9:08 PM, Kurt Jaeger  wrote:
> 
> I'm testbuilding 5.6.25 right now.

Please please make sure to reset all the php56-* module's
port revisions to zero if you do commit.  This was missed
in the php70 bump.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"