Re: On 14-CURRENT: no ports options anymore?

[John Baldwin]

On 3/13/21 12:58 PM, Guido Falsi via freebsd-current wrote:

On 13/03/21 20:17, Hartmann, O. wrote:

Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to 
set
options via "make config" or via poudriere accordingly. I always get "===> 
Options
unchanged" (when options has been already set and I'd expect a dialog menu).
This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD
14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64).

I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG.

How to fix this? What happened?


I encountered something similar, some base shared library has changed,
guess this is related with the ncurses changes in base.

If I remember correctly force reinstalling dialog4ports package fixed
it. Make sure you reinstall a freshly rebuilt one.

Most probably anything using ncurses will require rebuild/reinstall.

The cause is dialog4ports failing to start and the system sees no option
changed.

If that's not enough try

# ldd -v /usr/local/bin/dialog4ports

And see if it reports some useful information.


There was an ABI breakage for ncurses that broke 12.x dialog4ports binaries.
The shared library versions for everything that depended on ncurses were bumped
for 13 and 14 after the branch of stable/13.0 (commit 6e1fe6d26ea2).  After
that commit, if you upgraded from 12 to 13 you should have been fine, but if
you had updated before that, the 12.x dialog4ports was still going to fail
as the 12.x version of those libraries were already broken.  I haven't checked
to see if the affected libraries have been added to misc/compat12x.

--
John Baldwin
___
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: On 14-CURRENT: no ports options anymore?

[Nuno Teixeira]

I have same problem days ago when dialog4ports crashed.

just reinstall/install ports-mgmt/dialog4ports/

Hartmann, O.  escreveu no dia sábado, 13/03/2021
à(s) 19:17:

> Since I moved on to 14-CURRENT, I face a very strange behaviour when
> trying to set
> options via "make config" or via poudriere accordingly. I always get "===>
> Options
> unchanged" (when options has been already set and I'd expect a dialog
> menu).
> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at
> FreeBSD
> 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021
> amd64).
>
> I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG.
>
> How to fix this? What happened?
>
> Thanks in advance,
>
> O. Hartmann
>
___
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: On 14-CURRENT: no ports options anymore?

[Dan Mahoney (Ports)]

You mention release notes.  Slightly off-topic, but I never understood why, if 
there was a beta or RC available, the release-notes of the time weren’t 
available on www.freebsd.org .

Wouldn’t that make sense to see if there were things you wanted to try out and 
test?

Anyway, more on topic, it seems that if one is on -CURRENT (or possibly 
-STABLE), you’re building from source, and should be expected to read UPDATING. 
 That much is on the site.  (But that would be /usr/src, not /usr/ports).

Did this happen mid-line in a stable?  That…shouldn’t.

-Dan

> On Mar 13, 2021, at 3:48 PM, Kevin Oberman  wrote:
> 
> On Sat, Mar 13, 2021 at 2:51 PM Dan Mahoney (Ports) 
> wrote:
> 
>> If this isn’t at least in /usr/ports/UPDATING it sure should be.
>> 
>> -Dan
>> 
> Ditto! While it did not take me long to discover that the ncurses shareable
> had bumped the version, I wasted a lot of time rebuilding ports one by one.
> At least a heads-up would have been nice. The way to do this is unclear,
> though, as it was a base library update. I assume that it only bit those
> running current or 13. Those running 13-STABLE, as I was, had no warning.
> I'm not sure a note in UPDATING would have been appropriate, but a post to
> stable@ and current@ would have been nice. Or, did I miss them?
> 
> This would also be made VERY clear in the 13.0 Release Notes. I suspect
> installing misc/compat12x would have worked.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> ___
> 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: On 14-CURRENT: no ports options anymore?

[Kevin Oberman]

On Sat, Mar 13, 2021 at 2:51 PM Dan Mahoney (Ports) 
wrote:

> If this isn’t at least in /usr/ports/UPDATING it sure should be.
>
> -Dan
>
Ditto! While it did not take me long to discover that the ncurses shareable
had bumped the version, I wasted a lot of time rebuilding ports one by one.
At least a heads-up would have been nice. The way to do this is unclear,
though, as it was a base library update. I assume that it only bit those
running current or 13. Those running 13-STABLE, as I was, had no warning.
I'm not sure a note in UPDATING would have been appropriate, but a post to
stable@ and current@ would have been nice. Or, did I miss them?

This would also be made VERY clear in the 13.0 Release Notes. I suspect
installing misc/compat12x would have worked.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: On 14-CURRENT: no ports options anymore?

[Dan Mahoney (Ports)]

If this isn’t at least in /usr/ports/UPDATING it sure should be.

-Dan

> On Mar 13, 2021, at 12:58 PM, Guido Falsi via freebsd-ports 
>  wrote:
> 
> On 13/03/21 20:17, Hartmann, O. wrote:
>> Since I moved on to 14-CURRENT, I face a very strange behaviour when trying 
>> to set
>> options via "make config" or via poudriere accordingly. I always get "===> 
>> Options
>> unchanged" (when options has been already set and I'd expect a dialog menu).
>> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at 
>> FreeBSD
>> 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 
>> amd64).
>> I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG.
>> How to fix this? What happened?
> 
> I encountered something similar, some base shared library has changed, guess 
> this is related with the ncurses changes in base.
> 
> If I remember correctly force reinstalling dialog4ports package fixed it. 
> Make sure you reinstall a freshly rebuilt one.
> 
> Most probably anything using ncurses will require rebuild/reinstall.
> 
> The cause is dialog4ports failing to start and the system sees no option 
> changed.
> 
> If that's not enough try
> 
> # ldd -v /usr/local/bin/dialog4ports
> 
> And see if it reports some useful information.
> 
> -- 
> Guido Falsi 
> ___
> 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: On 14-CURRENT: no ports options anymore?

[Guido Falsi via freebsd-ports]

On 13/03/21 20:17, Hartmann, O. wrote:

Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to 
set
options via "make config" or via poudriere accordingly. I always get "===> 
Options
unchanged" (when options has been already set and I'd expect a dialog menu).
This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD
14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64).

I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG.

How to fix this? What happened?


I encountered something similar, some base shared library has changed, 
guess this is related with the ncurses changes in base.


If I remember correctly force reinstalling dialog4ports package fixed 
it. Make sure you reinstall a freshly rebuilt one.


Most probably anything using ncurses will require rebuild/reinstall.

The cause is dialog4ports failing to start and the system sees no option 
changed.


If that's not enough try

# ldd -v /usr/local/bin/dialog4ports

And see if it reports some useful information.

--
Guido Falsi 
___
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: On 14-CURRENT: no ports options anymore?

[Stefan Esser]

Am 13.03.21 um 20:17 schrieb Hartmann, O.:

Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to 
set
options via "make config" or via poudriere accordingly. I always get "===> 
Options
unchanged" (when options has been already set and I'd expect a dialog menu).
This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD
14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64).

I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG.

How to fix this? What happened?


Hi Oliver,

please check your TERM setting and test with a trivial setting
if it is not one of xterm, vt100 or vt320 (for example).

I had this problem when my TERM variable was xterm-color, which
used to be supported but apparently no longer is.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

On 14-CURRENT: no ports options anymore?

[Hartmann, O.]

Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to 
set
options via "make config" or via poudriere accordingly. I always get "===> 
Options
unchanged" (when options has been already set and I'd expect a dialog menu).
This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD
14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64).

I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG.

How to fix this? What happened?

Thanks in advance,

O. Hartmann


pgprjjNYTd1wx.pgp
Description: OpenPGP digital signature

Re: MariaDB Options for Port.,MariaDB Options for Port.

[Janky Jay, III]

Hello Yasuhiro,

On 3/10/21 6:30 PM, Yasuhiro Kimura wrote:
> From: "Janky Jay, III" 
> Subject: MariaDB Options for Port.,MariaDB Options for Port.
> Date: Wed, 10 Mar 2021 17:59:35 -0700
>
>>     I've been trying to add a MariaDB option to a port I maintain but
>> everything I have tried has failed. There's is obviously something I'm
>> not understanding about the available options so I'm hoping someone can
>> point me the right direction.
>>
>>     The port currently has a MySQL option which works fine but I'd like
>> to add MariaDB in there as an alternative:
>>
>> .if ${PORT_OPTIONS:MMYSQLSERVER}
>> USES+=  mysql:server
>> .endif
>>
>>     Based on the information I found in the Porter's Handbook [1], it
>> appears there are options for MariaDB but they come from variants of
>> USES=mysql (such as "mysql:105m", for MariaDB.) However, setting this to
>> the version isn't working. Plus, I don't want to specify a required
>> version since there isn't one (I'd like users to be able to use whatever
>> version they prefer.) It also appears I cannot use multiple USES= lines
>> because aside from the version arg, it would just use those settings for
>> MySQL and ignore MariaDB like it's already doing.
>>
>>     Below is the line I last tested without any luck. Again, I don't
>> want to specify a version, though. I'd like it do the same thing that
>> USES+=mysql does where it will install the default version if MariaDB
>> doesn't exist but if it does, it'll find the correct libs and move
>> forward with the dependency:
>>
>> .if ${PORT_OPTIONS:MMARIADBSERVER}
>> USES+=  mysql:105m
>> .endif
>>
>>     Can someone please point me to more informative documentation or
>> maybe even provide an example port that is already doing this? I've
>> searched the ports tree but failed to find anything helpful.
>>
>> [1] - https://docs.freebsd.org/en/books/porters-handbook/#uses-mysql
>>
>> Regards,
>> Janky Jay, III
>>
> Your port works fine with both MySQL and MariaDB. Right? If so you
> should add `USES=mysql` without version arguments in the Makefile of
> your port. Then user can specify which version of MySQL or MariaDB to
> be used. For example, if he wants to use MariaDB 10.5 then he should
> add following line in make.conf
>
> --
> DEFAULT_VERSIONS+=10.5m
> --
    This makes much more sense. Thank you!

Regards,
Janky Jay, III




OpenPGP_signature
Description: OpenPGP digital signature

Re: MariaDB Options for Port.,MariaDB Options for Port.

[Yasuhiro Kimura]

From: "Janky Jay, III" 
Subject: MariaDB Options for Port.,MariaDB Options for Port.
Date: Wed, 10 Mar 2021 17:59:35 -0700

>     I've been trying to add a MariaDB option to a port I maintain but
> everything I have tried has failed. There's is obviously something I'm
> not understanding about the available options so I'm hoping someone can
> point me the right direction.
> 
>     The port currently has a MySQL option which works fine but I'd like
> to add MariaDB in there as an alternative:
> 
> .if ${PORT_OPTIONS:MMYSQLSERVER}
> USES+=  mysql:server
> .endif
> 
>     Based on the information I found in the Porter's Handbook [1], it
> appears there are options for MariaDB but they come from variants of
> USES=mysql (such as "mysql:105m", for MariaDB.) However, setting this to
> the version isn't working. Plus, I don't want to specify a required
> version since there isn't one (I'd like users to be able to use whatever
> version they prefer.) It also appears I cannot use multiple USES= lines
> because aside from the version arg, it would just use those settings for
> MySQL and ignore MariaDB like it's already doing.
> 
>     Below is the line I last tested without any luck. Again, I don't
> want to specify a version, though. I'd like it do the same thing that
> USES+=mysql does where it will install the default version if MariaDB
> doesn't exist but if it does, it'll find the correct libs and move
> forward with the dependency:
> 
> .if ${PORT_OPTIONS:MMARIADBSERVER}
> USES+=  mysql:105m
> .endif
> 
>     Can someone please point me to more informative documentation or
> maybe even provide an example port that is already doing this? I've
> searched the ports tree but failed to find anything helpful.
> 
> [1] - https://docs.freebsd.org/en/books/porters-handbook/#uses-mysql
> 
> Regards,
> Janky Jay, III
> 

Your port works fine with both MySQL and MariaDB. Right? If so you
should add `USES=mysql` without version arguments in the Makefile of
your port. Then user can specify which version of MySQL or MariaDB to
be used. For example, if he wants to use MariaDB 10.5 then he should
add following line in make.conf

--
DEFAULT_VERSIONS+=10.5m
--

---
Yasuhiro Kimura
___
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"

MariaDB Options for Port.

[Janky Jay, III]

Hello Everyone,

    I've been trying to add a MariaDB option to a port I maintain but
everything I have tried has failed. There's is obviously something I'm
not understanding about the available options so I'm hoping someone can
point me the right direction.

    The port currently has a MySQL option which works fine but I'd like
to add MariaDB in there as an alternative:

.if ${PORT_OPTIONS:MMYSQLSERVER}
USES+=  mysql:server
.endif

    Based on the information I found in the Porter's Handbook [1], it
appears there are options for MariaDB but they come from variants of
USES=mysql (such as "mysql:105m", for MariaDB.) However, setting this to
the version isn't working. Plus, I don't want to specify a required
version since there isn't one (I'd like users to be able to use whatever
version they prefer.) It also appears I cannot use multiple USES= lines
because aside from the version arg, it would just use those settings for
MySQL and ignore MariaDB like it's already doing.

    Below is the line I last tested without any luck. Again, I don't
want to specify a version, though. I'd like it do the same thing that
USES+=mysql does where it will install the default version if MariaDB
doesn't exist but if it does, it'll find the correct libs and move
forward with the dependency:

.if ${PORT_OPTIONS:MMARIADBSERVER}
USES+=  mysql:105m
.endif

    Can someone please point me to more informative documentation or
maybe even provide an example port that is already doing this? I've
searched the ports tree but failed to find anything helpful.

[1] - https://docs.freebsd.org/en/books/porters-handbook/#uses-mysql

Regards,
Janky Jay, III



OpenPGP_signature
Description: OpenPGP digital signature

Re: What are my options regarding deprecated PyPy port?

[Dewayne Geraghty]

On 26/08/2020 7:12 am, figosdev via freebsd-ports wrote:
>> the easiest way, if you build your own ports, is to svnlite update -r 
>> '{2020-03-29}' /usr/ports/security/w3af Note the date before removal from 
>> the ports tree.
> 
> Thanks, this is probably what I was looking for (a way to get a copy of the 
> existing work if ports deletes it).
> 
You're welcome :)

> Forgive my lack of experience here-- does this imply that when something is 
> "deleted" from ports-- it is like an edit in git or Wikipedia, where the old 
> version still (typically) exists in the tree somewhere? Because if a year 
> from now I can still get the old ports code from the older tree, that's good 
> enough for me.
> 

I can't speak to git or wikipedia, but I use this technique for ports
that go back to 2018-12-14.  So you should be ok for awhile, perhap a
ports infrastructure person can illuminate.  Though frankly, I keep
copies of all local tree changes against a pristine copy of the ports
tree ("diff -urN" is useful)

You should be aware that the mailing list(s) has mentioned a move to
git, and there is an intention to retain the svn feed, so we should be
fine for the foreseeable.  Also mentioned was a transition guide...

> I also got the downloadable Linux ELF pre-compiled version from pypy.org to 
> run in Linuxulator-- this has me covered for most of the stuff I do with 
> Python, though for GUI stuff it doesn't seem to like the libc in /compat or 
> the one I copied (a point for another list, but for me this solves most of my 
> issue.)
> 

A bit unfortunate that you need to, though its a resilient workaround :)

> Same GUI stuff runs on the native PyPy. I'm hoping the PyPy devs find a way 
> to make this work, I intend to ask them if they can make a FreeBSD download 
> again. They did one for FreeBSD64 a long time ago.
> 
Yes, the best way is to try to get the upstream folks to modify their
code for python3.  Though if the dev doesn't want to, you (we) need to
make a calculated risk determination, as I've found with a few very
useful applications (ports).

And as a general rule, I'd suggest avoiding unmaintained ports that
enable inbound network access.
Cheerio.
___
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: What are my options regarding deprecated PyPy port?

[figosdev via freebsd-ports]

> the easiest way, if you build your own ports, is to svnlite update -r 
> '{2020-03-29}' /usr/ports/security/w3af Note the date before removal from the 
> ports tree.

Thanks, this is probably what I was looking for (a way to get a copy of the 
existing work if ports deletes it).

Forgive my lack of experience here-- does this imply that when something is 
"deleted" from ports-- it is like an edit in git or Wikipedia, where the old 
version still (typically) exists in the tree somewhere? Because if a year from 
now I can still get the old ports code from the older tree, that's good enough 
for me.

I also got the downloadable Linux ELF pre-compiled version from pypy.org to run 
in Linuxulator-- this has me covered for most of the stuff I do with Python, 
though for GUI stuff it doesn't seem to like the libc in /compat or the one I 
copied (a point for another list, but for me this solves most of my issue.)

Same GUI stuff runs on the native PyPy. I'm hoping the PyPy devs find a way to 
make this work, I intend to ask them if they can make a FreeBSD download again. 
They did one for FreeBSD64 a long time ago.

Thanks all.
___
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: What are my options regarding deprecated PyPy port?

[Dewayne Geraghty]

On 25/08/2020 11:49 am, figosdev via freebsd-ports wrote:
> Hi, I'm new to FreeBSD-- I installed it for the first time this week. 
> Honestly, so far it has exceeded expectations.
> 
> I installed X11, but the first thing I installed was PyPy2.
> 
> Unlike CPython2, which is EOL'd, PyPy2 does not to the best of my knowledge 
> depend on CPython. When I installed it with pkg, it said the port was 
> deprecated and will be removed from ports soon-- but it also said it was 
> based on Python 2.7 (which is EOLd).
> 
> I think there is a misunderstanding there. PyPy states the intention to 
> continue to maintain that version.
> 
> Removing this port is unnecessary. Aware of the politics around this (which 
> go way over FreeBSD anyway) I doubt I will convince someone to save this 
> port, sadly.
> 
> I've used both Python 2.x and 3.x for years now. If this problem can't be 
> fixed, can I at least be put in touch with the current port maintainer so 
> that I can learn how to maintain this as a 3rd party package for my own use?
> 
> I'm certain I'm not up to becoming an official port maintainer at this stage, 
> but I'd like to be able to at least compile and run PyPy2 on freebsd without 
> redoing the ports work that was already done on this.
> ___
> 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"
> 

Hi figodev, I've had a similar experience.  Though in my case
security/w3af was removed, per

/usr/ports/MOVED:security/w3af||2020-03-31|Has expired: Uses deprecated
version of Python

So in my case the easiest way, if you build your own ports, is to

svnlite update -r '{2020-03-29}' /usr/ports/security/w3af
Note the date before removal from the ports tree.

You might consider the same action.  Though over time you will need to
self-maintain...
___
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: What are my options regarding deprecated PyPy port?

[Kurt Jaeger]

Hi!

> I am not above getting the PyPy devs on this if necessary. I find
> it hard to believe that an implementation they say will be around
> hard-depends on an implementation that will not.

I've checked the port itself, and the build of the port depends on
python 2.7.

Do you think you can tinker around with the port build to see
if you can get it to build with python3 ?

It looks like a major task, from what I can see in the Makefile.

But I'm no python expert 8-}

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
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: What are my options regarding deprecated PyPy port?

[figosdev via freebsd-ports]

Thank you both. Per Kevin's advice I have contacted freebsd-python@ and wait to 
hear what they say about this.

I am not above getting the PyPy devs on this if necessary. I find it hard to 
believe that an implementation they say will be around hard-depends on an 
implementation that will not.

The port itself could be another story. PyPy implements Python 2, so they 
should be able at this point to use PyPy to build PyPy if they don't already.

If I could run the ELF version on FreeBSD I'd take that over nothing, but I've 
meant to try FreeBSD again for years (possibly migrating to it) and I've only 
read the FAQ and part of the handbook so far. Still learning.
___
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: What are my options regarding deprecated PyPy port?

[Pete Wright]

On 8/24/20 8:05 PM, Kevin Oberman wrote:

On Mon, Aug 24, 2020 at 6:50 PM figosdev via freebsd-ports <
freebsd-ports@freebsd.org> wrote:


Hi, I'm new to FreeBSD-- I installed it for the first time this week.
Honestly, so far it has exceeded expectations.

I installed X11, but the first thing I installed was PyPy2.

Unlike CPython2, which is EOL'd, PyPy2 does not to the best of my
knowledge depend on CPython. When I installed it with pkg, it said the port
was deprecated and will be removed from ports soon-- but it also said it
was based on Python 2.7 (which is EOLd).

I think there is a misunderstanding there. PyPy states the intention to
continue to maintain that version.

Removing this port is unnecessary. Aware of the politics around this
(which go way over FreeBSD anyway) I doubt I will convince someone to save
this port, sadly.

I've used both Python 2.x and 3.x for years now. If this problem can't be
fixed, can I at least be put in touch with the current port maintainer so
that I can learn how to maintain this as a 3rd party package for my own use?

I'm certain I'm not up to becoming an official port maintainer at this
stage, but I'd like to be able to at least compile and run PyPy2 on freebsd
without redoing the ports work that was already done on this.


Looks like the deprecation might have been in error. While I can't be sure,
it looks like it is in no way dependent on python27 and, if it is
maintained, it probably was deprecated in error. Probably someone in the
python group saw the 2.7 references and tagged it for deprecation.

You probably should start by contacting python@ and, if there is no
response, open a ticket on bugzilla pointing this out and requesting that
the deprecation be reversed.
i agree - it looks like someone needs to refactor lang/pypy which seems 
to build against python2.7. there is a pypy3 port/pkg as well, but that 
seems to be incorrectly flagged as being deprecated according to freshports.


i searched bugzilla too but only found an open cleanup ticket there:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245747

-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: What are my options regarding deprecated PyPy port?

[Kevin Oberman]

On Mon, Aug 24, 2020 at 6:50 PM figosdev via freebsd-ports <
freebsd-ports@freebsd.org> wrote:

> Hi, I'm new to FreeBSD-- I installed it for the first time this week.
> Honestly, so far it has exceeded expectations.
>
> I installed X11, but the first thing I installed was PyPy2.
>
> Unlike CPython2, which is EOL'd, PyPy2 does not to the best of my
> knowledge depend on CPython. When I installed it with pkg, it said the port
> was deprecated and will be removed from ports soon-- but it also said it
> was based on Python 2.7 (which is EOLd).
>
> I think there is a misunderstanding there. PyPy states the intention to
> continue to maintain that version.
>
> Removing this port is unnecessary. Aware of the politics around this
> (which go way over FreeBSD anyway) I doubt I will convince someone to save
> this port, sadly.
>
> I've used both Python 2.x and 3.x for years now. If this problem can't be
> fixed, can I at least be put in touch with the current port maintainer so
> that I can learn how to maintain this as a 3rd party package for my own use?
>
> I'm certain I'm not up to becoming an official port maintainer at this
> stage, but I'd like to be able to at least compile and run PyPy2 on freebsd
> without redoing the ports work that was already done on this.
>
Looks like the deprecation might have been in error. While I can't be sure,
it looks like it is in no way dependent on python27 and, if it is
maintained, it probably was deprecated in error. Probably someone in the
python group saw the 2.7 references and tagged it for deprecation.

You probably should start by contacting python@ and, if there is no
response, open a ticket on bugzilla pointing this out and requesting that
the deprecation be reversed.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"

What are my options regarding deprecated PyPy port?

[figosdev via freebsd-ports]

Hi, I'm new to FreeBSD-- I installed it for the first time this week. Honestly, 
so far it has exceeded expectations.

I installed X11, but the first thing I installed was PyPy2.

Unlike CPython2, which is EOL'd, PyPy2 does not to the best of my knowledge 
depend on CPython. When I installed it with pkg, it said the port was 
deprecated and will be removed from ports soon-- but it also said it was based 
on Python 2.7 (which is EOLd).

I think there is a misunderstanding there. PyPy states the intention to 
continue to maintain that version.

Removing this port is unnecessary. Aware of the politics around this (which go 
way over FreeBSD anyway) I doubt I will convince someone to save this port, 
sadly.

I've used both Python 2.x and 3.x for years now. If this problem can't be 
fixed, can I at least be put in touch with the current port maintainer so that 
I can learn how to maintain this as a 3rd party package for my own use?

I'm certain I'm not up to becoming an official port maintainer at this stage, 
but I'd like to be able to at least compile and run PyPy2 on freebsd without 
redoing the ports work that was already done on this.
___
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: Port OPTIONS advice

[Dave]

On Wednesday, 20 May 2020 18:25:00 BST SirDice wrote:
> Some time ago I took over maintainership of fs-uae.
 
And I'd like to thank you very much for that! :-)
 
I finally got around to installing it, what with have an unexpected
few spare months of time on my hands.  I managed to dump my
old A1200 HDD to a file and eventually got it to boot after a trip
down memory lane figuring out how to edit startup-sequence
and user-startup to remove things like the SCSI drivers.  
 
There was one issue when I upgraded FreeBSD 11.3 --> 11.4.
fs-uae would crash out immediately the main window opened.
Even after doing a pkg upgrade -f I still ended up having to
manually build some related graphics libraries before it would
work again (Sorry, I didn't keep notes, IIRC it was mesa stuff)
 
So now all I need to do is find a cheap gamepad that will work
with it on FreeBSD :-)
 
If anyone is interested, you can download the Assassin Games CDs
full of PD games from archive.org (and much other Amiga related
goodness.  They boot and play just fine on fs-uae assuming you
have the correct ROM file(s))
 
Sorry if that last bit came over as a bit of a commercial but it's
years since I even plugged my old A1200 in, let alone played
games on it.
___
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: Port OPTIONS advice

[Mathieu Arnold]

On Wed, May 20, 2020 at 07:25:00PM +0200, SirDice wrote:
> What's a good way to deal with this sort of architecture dependent option?

If the feature is architecture dependant but also needs to be disabled
on architectures where it does not work, a naive way that I can see to
do it is probably to do something like this:

OPTIONS_DEFINE= JIT
OPTIONS_EXCLUDE_aarch64=  JIT
OPTIONS_EXCLUDE_armv6=  JIT

But you have to do it for all architectures, so it may not be the best
way, a way that would be a bit more convoluted, but still readable would
be:

OPTIONS_DEFINE= JIT
OPTIONS_EXCLUDE=  ${ARCH:Ni386:Namd64:C/.+/JIT/}

What it does is take ARCH, remove i386 and amd64 from it, and there is
still something, replace it with JIT.

-- 
Mathieu Arnold


signature.asc
Description: PGP signature

Re: Port OPTIONS advice

[Martin Neubauer]

On 20/05/2020 20:07, SirDice wrote:
> On Wed, May 20, 2020 at 7:45 PM Martin Neubauer  wrote:
> 
>> How about something like:
>>
>> 
>> OPTIONS_DEFINE_amd64=   JIT
>> OPTIONS_DEFINE_i386=JIT
>>
>> JIT_CONFIGURE_ENABLE=   jit
>> 
>>
>> That's what I had originally. The problem is that JIT_CONFIGURE_ENABLE is
> only parsed on amd64/i386. So it never passes --without-jit to  ./configure
> on other architectures.
> 
>> JIT_CONFIGURE_OFF=  --without-jit
> 
> Haven't tried that yet. But won't that  suffer from the same  effect, only
> getting parsed if on amd64/i386?

Honestly, I haven't tried it myself either, but judging from the usage
of this method (eg. in /usr/ports/biology/mrbayes/Makefile) it at least
seems to do just what you need.

-- 
Shipwrecked by the laughter of the gods.



signature.asc
Description: OpenPGP digital signature

Re: Port OPTIONS advice

[Martin Neubauer]

On 20/05/2020 19:45, Martin Neubauer wrote:
> JIT_CONFIGURE_ENABLE= jit

Sorry,

JIT_CONFIGURE_OFF=  --without-jit



-- 
Mrs. Peacock in the study with a knife.



signature.asc
Description: OpenPGP digital signature

Re: Port OPTIONS advice

[Martin Neubauer]

How about something like:


OPTIONS_DEFINE_amd64=   JIT
OPTIONS_DEFINE_i386=JIT

JIT_CONFIGURE_ENABLE=   jit


On 20/05/2020 19:25, SirDice wrote:
> Hi,
> 
> Some time ago I took over maintainership of fs-uae. Port itself is doing
> great but I wanted to enable the JIT option to experiment with (it builds
> but crashes the application; that's an entirely different issue though). To
> enable it I had added this:
> 
> OPTIONS_DEFINE_i386=JIT
> OPTIONS_DEFINE_amd64=   JIT
> 
> Because the option is only available for i386/amd64 I wanted the port
> option to only show up on x86. Unfortunately the brain-dead ./configure
> script simply assumes --with-jit on all architectures. As these OPTIONS
> were only available on x86, any other ARCH never passes --without-jit to
> ./configure and thus it fails to build.
> 
> The quick solution was to use OPTIONS_DEFINE= JIT and make the port option
> available everywhere.  However, if you try to enable it you will run into
> build failures on Powerpc or ARM for example.
> 
> I could do this:
> -
> OPTIONS_DEFINE_i386=JIT
> OPTIONS_DEFINE_amd64=   JIT
> 
> .include 
> 
> # JIT is not supported on non-x86
> .if ${ARCH} != amd64 && ${ARCH} != i386
> CONFIGURE_ARGS+= --without-jit
> .endif
> 
> 
> Or do something like this:
> 
> OPTIONS_DEFINE= JIT
> 
> .include 
> 
> .if ${PORT_OPTIONS:MJIT}
> ONLY_FOR_ARCHS= i386 amd64
> .endif
> 
> 
> 
> The JIT OPTION is off by default in all cases. But I would  like to only
> have it appear on supported architectures or have some sort of sanity check
> so it doesn't get enabled on unsupported architectures. As I need to update
> the port (new version came out) I would like to fix this OPTION issue too.
> 
> What's a good way to deal with this sort of architecture dependent option?
> 
> Thanks for your time,
> 
> Remko C.
> ___
> 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"
> 
-- 
Any environmental problem can be solved by a good Ice Age.



signature.asc
Description: OpenPGP digital signature

Port OPTIONS advice

[SirDice]

Hi,

Some time ago I took over maintainership of fs-uae. Port itself is doing
great but I wanted to enable the JIT option to experiment with (it builds
but crashes the application; that's an entirely different issue though). To
enable it I had added this:

OPTIONS_DEFINE_i386=JIT
OPTIONS_DEFINE_amd64=   JIT

Because the option is only available for i386/amd64 I wanted the port
option to only show up on x86. Unfortunately the brain-dead ./configure
script simply assumes --with-jit on all architectures. As these OPTIONS
were only available on x86, any other ARCH never passes --without-jit to
./configure and thus it fails to build.

The quick solution was to use OPTIONS_DEFINE= JIT and make the port option
available everywhere.  However, if you try to enable it you will run into
build failures on Powerpc or ARM for example.

I could do this:
-
OPTIONS_DEFINE_i386=JIT
OPTIONS_DEFINE_amd64=   JIT

.include 

# JIT is not supported on non-x86
.if ${ARCH} != amd64 && ${ARCH} != i386
CONFIGURE_ARGS+= --without-jit
.endif


Or do something like this:

OPTIONS_DEFINE= JIT

.include 

.if ${PORT_OPTIONS:MJIT}
ONLY_FOR_ARCHS= i386 amd64
.endif



The JIT OPTION is off by default in all cases. But I would  like to only
have it appear on supported architectures or have some sort of sanity check
so it doesn't get enabled on unsupported architectures. As I need to update
the port (new version came out) I would like to fix this OPTION issue too.

What's a good way to deal with this sort of architecture dependent option?

Thanks for your time,

Remko C.
___
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-mgmt/poudriere-devel does not follow options

[Martin Neubauer]

On 01/03/2020 10:06, Miroslav Lachman wrote:
> I migrated from "poudriere" to "poudriere-devel" about week ago that's
> when I noticed this problem. That's why I suspect poudriere-devel.
> Everything worked for me for years with poudriere.
> 
> I search my command history and I never called poudriere options with -j
> 
> It was like
> poudriere options -z php71m103 -p default -c mail/dovecot
> graphics/py-pillow www/nginx
> poudriere options -z php71m103 -p default -c ports-mgmt/poudriere-devel
> poudriere options -z php71m103 -p default -f
> /usr/local/etc/poudriere.d/pkglists/php71m103
> poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f
> /usr/local/etc/poudriere.d/pkglists/php71m103
> 
> I don't know when / what command exactly created
> 11_3_amd64-default-php71m103-options in disk.
I admit that's looking odd, but even if the exact command that led to
the presence of that directory can't be reconstructed, it should at
least be possible to gather some information regarding the time that
happened. "ls -lU" should give at least some starting point.



signature.asc
Description: OpenPGP digital signature

Re: ports-mgmt/poudriere-devel does not follow options

[Miroslav Lachman]

Martin Neubauer wrote on 2020/03/01 02:00:



On 01/03/2020 00:29, Miroslav Lachman wrote:

Martin Neubauer wrote on 2020/02/29 23:44:


[...]


But I am talking about "poudriere options" taking different saved
options than "poudriere bulk".
The "poudriere options" does not show me any dialog because they are all
set in "default-php71m103-options" and then "poudriere bulk" ignore
settings in "default-php71m103-options".
That is a bug from my point of view. Both commands should work with the
same set of stored options. Otherwise if "poudriere bulk" wants options
from "11_3_amd64-default-php71m103-options" I am not able to set those
options by calling "poudriere options".

If the issued command lines were in fact those from your earlier mail,
then you did in fact request two different option sets. If you also add
"-j 11_3_amd64" to the "poudriere options" call, you should access the
same option set the "poudriere bulk" run did.


I migrated from "poudriere" to "poudriere-devel" about week ago that's 
when I noticed this problem. That's why I suspect poudriere-devel. 
Everything worked for me for years with poudriere.


I search my command history and I never called poudriere options with -j

It was like
poudriere options -z php71m103 -p default -c mail/dovecot 
graphics/py-pillow www/nginx

poudriere options -z php71m103 -p default -c ports-mgmt/poudriere-devel
poudriere options -z php71m103 -p default -f 
/usr/local/etc/poudriere.d/pkglists/php71m103
poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f 
/usr/local/etc/poudriere.d/pkglists/php71m103


I don't know when / what command exactly created 
11_3_amd64-default-php71m103-options in disk.


You are right that anything after that is "expected behaviour", a bit 
unexpected to me.


Kind regards
Miroslav Lachman
___
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-mgmt/poudriere-devel does not follow options

[Martin Neubauer]

On 01/03/2020 00:29, Miroslav Lachman wrote:
> Martin Neubauer wrote on 2020/02/29 23:44:
>>
>>
>> On 28/02/2020 17:20, Miroslav Lachman wrote:
>>> I am using Poudriere for a long time. I switched to poudriere-devel few
>>> days ago because I want to test ports overlay.
>>> I run
>>>     poudriere options -z php71m103 -p default -f
>>> /usr/local/etc/poudriere.d/pkglists/php71m103
>>> just to be sure everything is set. No options dialog appeared because
>>> all options was set few week ago on regular update.
>>>
>>> Now I am running
>>>     poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f
>>> /usr/local/etc/poudriere.d/pkglists/php71m103
>>
>> [snip]
>>
>>> I tried to find what is going on and I found that all ports are built
>>> with default options instead of what I have stored in
>>> /usr/local/etc/poudriere.d/default-php71m103-options
>>>
>>> Just a wild guess... "poudriere options" read options from
>>> default-php71m103-options but "poudriere bulk" are trying to read
>>> 11_3_amd64-default-php71m103-options.
>>> Is it possible?
>> It isn't such a wild guess at all, considering that documentation does
>> state that the most specific set of options gets used with higher
>> priority. More details at:
> 
> But I am talking about "poudriere options" taking different saved
> options than "poudriere bulk".
> The "poudriere options" does not show me any dialog because they are all
> set in "default-php71m103-options" and then "poudriere bulk" ignore
> settings in "default-php71m103-options".
> That is a bug from my point of view. Both commands should work with the
> same set of stored options. Otherwise if "poudriere bulk" wants options
> from "11_3_amd64-default-php71m103-options" I am not able to set those
> options by calling "poudriere options".
If the issued command lines were in fact those from your earlier mail,
then you did in fact request two different option sets. If you also add
"-j 11_3_amd64" to the "poudriere options" call, you should access the
same option set the "poudriere bulk" run did.

Good luck,
Martin



signature.asc
Description: OpenPGP digital signature

Re: ports-mgmt/poudriere-devel does not follow options

[Miroslav Lachman]

Martin Neubauer wrote on 2020/02/29 23:44:



On 28/02/2020 17:20, Miroslav Lachman wrote:

I am using Poudriere for a long time. I switched to poudriere-devel few
days ago because I want to test ports overlay.
I run
    poudriere options -z php71m103 -p default -f
/usr/local/etc/poudriere.d/pkglists/php71m103
just to be sure everything is set. No options dialog appeared because
all options was set few week ago on regular update.

Now I am running
    poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f
/usr/local/etc/poudriere.d/pkglists/php71m103


[snip]


I tried to find what is going on and I found that all ports are built
with default options instead of what I have stored in
/usr/local/etc/poudriere.d/default-php71m103-options

Just a wild guess... "poudriere options" read options from
default-php71m103-options but "poudriere bulk" are trying to read
11_3_amd64-default-php71m103-options.
Is it possible?

It isn't such a wild guess at all, considering that documentation does
state that the most specific set of options gets used with higher
priority. More details at:


But I am talking about "poudriere options" taking different saved 
options than "poudriere bulk".
The "poudriere options" does not show me any dialog because they are all 
set in "default-php71m103-options" and then "poudriere bulk" ignore 
settings in "default-php71m103-options".
That is a bug from my point of view. Both commands should work with the 
same set of stored options. Otherwise if "poudriere bulk" wants options 
from "11_3_amd64-default-php71m103-options" I am not able to set those 
options by calling "poudriere options".


Kind regards
Miroslav Lachman
___
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-mgmt/poudriere-devel does not follow options

[Martin Neubauer]

On 28/02/2020 17:20, Miroslav Lachman wrote:
> I am using Poudriere for a long time. I switched to poudriere-devel few
> days ago because I want to test ports overlay.
> I run
>    poudriere options -z php71m103 -p default -f
> /usr/local/etc/poudriere.d/pkglists/php71m103
> just to be sure everything is set. No options dialog appeared because
> all options was set few week ago on regular update.
> 
> Now I am running
>    poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f
> /usr/local/etc/poudriere.d/pkglists/php71m103

[snip]

> I tried to find what is going on and I found that all ports are built
> with default options instead of what I have stored in
> /usr/local/etc/poudriere.d/default-php71m103-options
> 
> Just a wild guess... "poudriere options" read options from
> default-php71m103-options but "poudriere bulk" are trying to read
> 11_3_amd64-default-php71m103-options.
> Is it possible?
It isn't such a wild guess at all, considering that documentation does
state that the most specific set of options gets used with higher
priority. More details at:
https://github.com/freebsd/poudriere/wiki/poudriere.8-devel#custom--build-options





signature.asc
Description: OpenPGP digital signature

ports-mgmt/poudriere-devel does not follow options

[Miroslav Lachman]

I am using Poudriere for a long time. I switched to poudriere-devel few 
days ago because I want to test ports overlay.

I run
   poudriere options -z php71m103 -p default -f 
/usr/local/etc/poudriere.d/pkglists/php71m103
just to be sure everything is set. No options dialog appeared because 
all options was set few week ago on regular update.


Now I am running
   poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f 
/usr/local/etc/poudriere.d/pkglists/php71m103


There were some error on ports like "You are using OpenSSL from ports 
and have selected GSSAPI from base, please select another GSSAPI value"
It is strange because all ports have GSSAPI set to NONE from the 
beginning. No changes done.


I tried to find what is going on and I found that all ports are built 
with default options instead of what I have stored in 
/usr/local/etc/poudriere.d/default-php71m103-options


Just a wild guess... "poudriere options" read options from 
default-php71m103-options but "poudriere bulk" are trying to read 
11_3_amd64-default-php71m103-options.

Is it possible?

For example
From the log of cyrus-sasl built few weeks ago:

---Begin OPTIONS List---
===> The following configuration options are available for 
cyrus-sasl-2.1.27:

 ALWAYSTRUE=off: Alwaystrue password verifier (discouraged)
 AUTHDAEMOND=on: Use of authdaemon
 DOCS=off: Build and/or install documentation
 KEEP_DB_OPEN=off: Keep handle to Berkeley DB open
 OBSOLETE_CRAM_ATTR=off: cmusaslsecretCRAM-MD5 auxprop property
 OBSOLETE_DIGEST_ATTR=on: cmusaslsecretDIGEST-MD5 auxprop property
> Options available for the group PLUGIN
 ANONYMOUS=off: ANONYMOUS authentication
 CRAM=off: CRAM-MD5 authentication
 DIGEST=off: DIGEST-MD5 authentication
 LOGIN=on: LOGIN authentication
 NTLM=off: NTLM authentication
 OTP=off: OTP authentication
 PLAIN=on: PLAIN authentication
 SCRAM=off: SCRAM authentication
> SASLdb auxprop plugin: you can only select none or one of them
 BDB1=on: Berkeley DB 1.85 support
 BDB=off: Berkeley DB support
 GDBM=off: GNU dbm library support
 LMDB=off: OpenLDAP Lightning Memory-Mapped Database support
===> Use 'make config' to modify these settings
---End OPTIONS List---


From the log of cyrus-sasl built today

---Begin OPTIONS List---
===> The following configuration options are available for 
cyrus-sasl-2.1.27:

 ALWAYSTRUE=off: Alwaystrue password verifier (discouraged)
 AUTHDAEMOND=on: Use of authdaemon
 DOCS=off: Build and/or install documentation
 KEEP_DB_OPEN=off: Keep handle to Berkeley DB open
 OBSOLETE_CRAM_ATTR=on: cmusaslsecretCRAM-MD5 auxprop property
 OBSOLETE_DIGEST_ATTR=on: cmusaslsecretDIGEST-MD5 auxprop property
> Options available for the group PLUGIN
 ANONYMOUS=on: ANONYMOUS authentication
 CRAM=on: CRAM-MD5 authentication
 DIGEST=on: DIGEST-MD5 authentication
 LOGIN=on: LOGIN authentication
 NTLM=on: NTLM authentication
 OTP=on: OTP authentication
 PLAIN=on: PLAIN authentication
 SCRAM=on: SCRAM authentication
> SASLdb auxprop plugin: you can only select none or one of them
 BDB1=on: Berkeley DB 1.85 support
 BDB=off: Berkeley DB support
 GDBM=off: GNU dbm library support
 LMDB=off: OpenLDAP Lightning Memory-Mapped Database support
===> Use 'make config' to modify these settings
---End OPTIONS List---


Both built with the same commands (the same poudriere options & 
poudriere bulk)


Kind regards
Miroslav Lachman

___
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: Tool to check for non-default options for installed ports

[Tatsuki Makino]

I forgot some tr before grep. orz
___
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: Tool to check for non-default options for installed ports

[Tatsuki Makino]

1.
pkg query %Ov=%Ok ports-mgmt/pkg | sed -e 's/on=/+/; s/off=/-/'
Options for installed packages.

2.
make -C /usr/ports/ports-mgmt/pkg\
  ALL_OPTIONS=\$\{OPTIONS_DEFINE:O:u\} pretty-print-config |
  grep '^[-+]'
Options after pressing OK in dialog4ports. Sorted for comparison.

3.
make -C /usr/ports/ports-mgmt/pkg\
  OPTIONS_FILE=/dev/null\
  ALL_OPTIONS=\$\{OPTIONS_DEFINE:O:u\} pretty-print-config |
  grep '^[-+]'
Options before pressing OK in dialog4ports. Sorted for comparison.

4.1
OPTIONS_NAME='ports-mgmt_pkg'
make -C /usr/ports/ports-mgmt/pkg\
  OPTIONS_SET= OPTIONS_UNSET=\
  "${OPTIONS_NAME}_SET=" "${OPTIONS_NAME}_UNSET="\
  OPTIONS_SET_FORCE= OPTIONS_UNSET_FORCE=\
  "${OPTIONS_NAME}_SET_FORCE=" "${OPTIONS_NAME}_UNSET_FORCE="\
  WITH= WITHOUT= OPTIONS_FILE=/dev/null\
  ALL_OPTIONS=\$\{OPTIONS_DEFINE:O:u\} pretty-print-config |
  tr ' ' '\n' | grep '^[-+]'
Pure options not including those defined in make.conf.

4.2
make -C /usr/ports/ports-mgmt/pkg\
  __MAKE_CONF=/dev/null OPTIONS_FILE=/dev/null\
  ALL_OPTIONS=\$\{OPTIONS_DEFINE:O:u\} pretty-print-config |
  tr ' ' '\n' | grep '^[-+]'
Simpler than 4.1 by not including make.conf.

It would be better to compare these. (I read poudriere a little :) )
Would someone make a tool? :)

Regards.
___
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"

Tool to check for non-default options for installed ports

[Kevin Oberman]

I should just write this as it looks very straight-forward but I'm lazy and
hate reinventing wheels.

On my development system I build from ports. An on-going issue is that
ports frequently change options from non-default to default and I never see
the change. The result is that every now and then a port won't build due to
a change or a port runs with reduced capabilities or performance when a new
option becomes the standard.

Looking at the DEFAULT_OPTIONS in the port Makefile and comparing them with
saved config is trivial and I suspect a tool for this has probably been
written several times.

Thanks!
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: Speeding-up poudriere options

[Walter Schwarzenfeld]

A simple bash script?

#!/usr/local/bin/bash
for i in `cat list.txt`
do
poudriere options -cn $i
done

---

Shows only the port, not the recursive dependencies.

list.txt should contain the ports in the form category/port (e.g. 
www/firefox).


___
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"

Speeding-up poudriere options

[Grzegorz Junka]

I have a file with a list of packages to compile with poudriere. Every 
time I update ports I execute "poudriere options -j ... -f some_file" in 
order to update options of new packages or whenever something changed.


The issue is that it takes about an hour for poudriere to go through the 
list and try to configure options for each package. If the package was 
renamed or removed poudriere throws an error and stops. Then I need to 
update the list and restart the command.


Is there any better way of updating options than "poudriere options..."?

Can I speed it up by having the ports tree in ram (tmpfs)? If yes, what 
would be the easiest way for setting that up?


GrzegorzJ

___
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: BIND default options: dnstap

[Kubilay Kocak]

On 12/05/2019 5:09 am, Greg Rivers wrote:

I'd like to suggest that dnstap should be enabled by default going forward, 
starting with bind914. Doing so would be a no-op for people who don't use it, 
since it has to be specifically enabled in the configuration. I suspect there 
may be quite a few people like me who would appreciate the ability to use 
dnstap without building our own packages and maintaining our own repos. 
Thoughts?



Hi Greg,

I encourage you to open a Bugzilla issue with the suggestion.

Make sure to include the value it provides you, the 'noop' element, and 
describe the dependency changes (if any), as this tends to be the 
primary reason why OPTIONS aren't enabled by default. Though most 
maintainers are already aware of this, it doesn't hurt to mention it.


./koobs


___
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"

BIND default options: dnstap

[Greg Rivers]

I'd like to suggest that dnstap should be enabled by default going forward, 
starting with bind914. Doing so would be a no-op for people who don't use it, 
since it has to be specifically enabled in the configuration. I suspect there 
may be quite a few people like me who would appreciate the ability to use 
dnstap without building our own packages and maintaining our own repos. 
Thoughts?

-- 
Greg


___
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: options DOCS + EXAMPLES

[Bob Eager]

On Fri, 2 Nov 2018 11:33:11 +0100
Harry Schmalzbauer  wrote:

> Am 02.11.2018 um 11:24 schrieb Mathieu Arnold:
> > On Fri, Nov 02, 2018 at 10:49:52AM +0100, Harry Schmalzbauer
> > wrote:  
> >> Hello,
> >>
> >> found out that the need to define DOCS and EXAMPLES in
> >> OPTIONS_DEFINE was made mandatory some time ago, which
> >> ports-mgmt/portlint isn't aware about yet (found
> >> https://reviews.freebsd.org/D13036).
> >>
> >> I intentionally haven't defined it, because I want to make use of
> >> the bsd.ports.mk handling of PORTDOCS and PORTEXAMPLES, but don't
> >> want to spam the UI.  EXAMPLES and DOCS shall stay mandatory for
> >> my port, as long as the user changes the corresponding defaults.
> >>
> >> How do I hide the user selection for EXAMPLES and DOCS after the
> >> change (which I wasn't able to find by reading commit logs)?  
> > 
> > I am not sure what you are asking.
> > 
> > To be able to use PORTDOCS or PORTEXAMPLES, you must define a DOCS
> > or an EXAMPLES option.
> > 
> > The users must be allowed to choose if they want documentation or
> > examples to be installed.  If you personnaly do not want the options
> > dialog to show up when you build ports, you can set BATCH in your
> > environment.  
> 
> Thank you for your answer.
> In my case, I have additional options, so I can't use BATCH.
> Please see my opinion about the DOCS/EXAMPLES selection in the reply
> to myself, where I reference the commit introducing this change and
> where I explain why in many/most cases, I consider these
> DOCS/EXAMPLES/NLS options as spam.

Yes, but it's possible to turn off DOCS and EXAMPLES (and indeed
any other named option) globally (for all ports). That can be useful
when building for certain targets.
___
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: options DOCS + EXAMPLES

[Harry Schmalzbauer]

Am 02.11.2018 um 11:41 schrieb Mathieu Arnold:

On Fri, Nov 02, 2018 at 11:33:11AM +0100, Harry Schmalzbauer wrote:

Am 02.11.2018 um 11:24 schrieb Mathieu Arnold:

On Fri, Nov 02, 2018 at 10:49:52AM +0100, Harry Schmalzbauer wrote:

Hello,

found out that the need to define DOCS and EXAMPLES in OPTIONS_DEFINE was
made mandatory some time ago, which ports-mgmt/portlint isn't aware about
yet (found https://reviews.freebsd.org/D13036).

…


If you want to hide them, you can always set in your make.conf:

OPTIONS_SLAVE=  DOCS EXAMPLES

(or OPTIONS_EXCLUDE to disable the options.)


Great, thanks a lot!
No idea why/how (meaning I haven't searched for it in the makefiles), 
but this exactly restores previous behaviour and is what I wanted for my 
port.
So I'm _not_ forced to "spam" my options dialog, which was my bigest 
concern.


I'd love to see OPTIONS_SLAVE mentioned in the porters handbook!

Thanks,

-harry


___
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: options DOCS + EXAMPLES

[Mathieu Arnold]

On Fri, Nov 02, 2018 at 11:33:11AM +0100, Harry Schmalzbauer wrote:
> Am 02.11.2018 um 11:24 schrieb Mathieu Arnold:
> > On Fri, Nov 02, 2018 at 10:49:52AM +0100, Harry Schmalzbauer wrote:
> > > Hello,
> > > 
> > > found out that the need to define DOCS and EXAMPLES in OPTIONS_DEFINE was
> > > made mandatory some time ago, which ports-mgmt/portlint isn't aware about
> > > yet (found https://reviews.freebsd.org/D13036).
> > > 
> > > I intentionally haven't defined it, because I want to make use of the
> > > bsd.ports.mk handling of PORTDOCS and PORTEXAMPLES, but don't want to spam
> > > the UI.  EXAMPLES and DOCS shall stay mandatory for my port, as long as 
> > > the
> > > user changes the corresponding defaults.
> > > 
> > > How do I hide the user selection for EXAMPLES and DOCS after the change
> > > (which I wasn't able to find by reading commit logs)?
> > 
> > I am not sure what you are asking.
> > 
> > To be able to use PORTDOCS or PORTEXAMPLES, you must define a DOCS or an
> > EXAMPLES option.
> > 
> > The users must be allowed to choose if they want documentation or
> > examples to be installed.  If you personnaly do not want the options
> > dialog to show up when you build ports, you can set BATCH in your
> > environment.
> 
> Thank you for your answer.
> In my case, I have additional options, so I can't use BATCH.
> Please see my opinion about the DOCS/EXAMPLES selection in the reply to
> myself, where I reference the commit introducing this change and where I

If you want to hide them, you can always set in your make.conf:

OPTIONS_SLAVE=  DOCS EXAMPLES

(or OPTIONS_EXCLUDE to disable the options.)

> explain why in many/most cases, I consider these DOCS/EXAMPLES/NLS options
> as spam.

Thank you for your input.

-- 
Mathieu Arnold


signature.asc
Description: PGP signature

Re: options DOCS + EXAMPLES

[Harry Schmalzbauer]

Am 02.11.2018 um 11:24 schrieb Mathieu Arnold:

On Fri, Nov 02, 2018 at 10:49:52AM +0100, Harry Schmalzbauer wrote:

Hello,

found out that the need to define DOCS and EXAMPLES in OPTIONS_DEFINE was
made mandatory some time ago, which ports-mgmt/portlint isn't aware about
yet (found https://reviews.freebsd.org/D13036).

I intentionally haven't defined it, because I want to make use of the
bsd.ports.mk handling of PORTDOCS and PORTEXAMPLES, but don't want to spam
the UI.  EXAMPLES and DOCS shall stay mandatory for my port, as long as the
user changes the corresponding defaults.

How do I hide the user selection for EXAMPLES and DOCS after the change
(which I wasn't able to find by reading commit logs)?


I am not sure what you are asking.

To be able to use PORTDOCS or PORTEXAMPLES, you must define a DOCS or an
EXAMPLES option.

The users must be allowed to choose if they want documentation or
examples to be installed.  If you personnaly do not want the options
dialog to show up when you build ports, you can set BATCH in your
environment.


Thank you for your answer.
In my case, I have additional options, so I can't use BATCH.
Please see my opinion about the DOCS/EXAMPLES selection in the reply to 
myself, where I reference the commit introducing this change and where I 
explain why in many/most cases, I consider these DOCS/EXAMPLES/NLS 
options as spam.


Thanks,

-harry

___
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: options DOCS + EXAMPLES

[Harry Schmalzbauer]

Am 02.11.2018 um 10:49 schrieb Harry Schmalzbauer:

Hello,

found out that the need to define DOCS and EXAMPLES in OPTIONS_DEFINE 
was made mandatory some time ago, which ports-mgmt/portlint isn't 
aware about yet (found https://reviews.freebsd.org/D13036).


I intentionally haven't defined it, because I want to make use of the 
bsd.ports.mk handling of PORTDOCS and PORTEXAMPLES, but don't want to 
spam the UI.  EXAMPLES and DOCS shall stay mandatory for my port, as 
long as the user changes the corresponding defaults.


How do I hide the user selection for EXAMPLES and DOCS after the 
change (which I wasn't able to find by reading commit logs)?


Confused bsd.port.options.mk with bsd.options.mk, so I found the 
corresponding commit 
(https://svnweb.freebsd.org/ports?view=revision=479410).


If a port has only a view DOCS and/or EXAMPLES files, consuming very 
little space, the user shouldn't get naged about installing it or not.


The OPTIONS dialog is already real pain, where the user get's overloaded 
with hardly usable descriptions and without hints about consequences 
about changing different options – they all look the same while having 
enourmous different impact on change.


Adding two completely meaningless choices (at least for my and many 
other ports I know) makes the dialog notably worse in my opinion.
It does make absolutely no difference if myreadme.txt is in placed into 
a standards directory or not; even not on systems with very very limited 
inodes/space since pkg requires many orders of magnitudes more resources 
anyways, so the for sub½GB-setups, the public ports/pkg distribution 
isn't usable, hence the N indoes / N kb more ore less can't justify two 
more choices for _all_ ports which want to utilize %%PORTDOCS%% and 
%%PORTEXAMPLES%%.


Of course there are ports where EXAMPLES or especially DOCS make a big 
difference, especially if DOCS require additional build dependencies.
But these should be handled separatly instead of forcing all others to 
show never changing options.


-harry
___
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"

options DOCS + EXAMPLES

[Harry Schmalzbauer]

Hello,

found out that the need to define DOCS and EXAMPLES in OPTIONS_DEFINE 
was made mandatory some time ago, which ports-mgmt/portlint isn't aware 
about yet (found https://reviews.freebsd.org/D13036).


I intentionally haven't defined it, because I want to make use of the 
bsd.ports.mk handling of PORTDOCS and PORTEXAMPLES, but don't want to 
spam the UI.  EXAMPLES and DOCS shall stay mandatory for my port, as 
long as the user changes the corresponding defaults.


How do I hide the user selection for EXAMPLES and DOCS after the change 
(which I wasn't able to find by reading commit logs)?


Thanks,

-harry



___
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/openssl111 TLSv1.3 port options

[Dan Mahoney (Gushi)]

On Wed, 12 Sep 2018, Koichiro Iwao wrote:


Hi,

OpenSSL 1.1.1 has been added to ports tree. AFAIK OpenSSL 1.1.1 supports 
TLSv1.3

but no port options for TLSv1.3. There're only TLS1, TLS1_1, TLS1_2.

I assume TLSv1.3 will be enabled by default unless disabled explicitly so
security/openssl111 will always be built with TLSv1.3 enabled, am I correct?
And why not add port options to enable/disable TLSv1.3 as well as older TLS 
versions?


Moreover -- is OpenSSL 1.1.1 going to be the default in FreeBSD 12? 
Probably not as it's already in the RE phase.


If that's the case, people who want tls13 are going to be building 
ports/packages against the non-base version until at least FreeBSD 13.


At least tls13 and freebsd13 would coincide nicely, linguistally speaking.

-Dan


--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.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"

security/openssl111 TLSv1.3 port options

[Koichiro Iwao]

Hi,

OpenSSL 1.1.1 has been added to ports tree. AFAIK OpenSSL 1.1.1 supports 
TLSv1.3

but no port options for TLSv1.3. There're only TLS1, TLS1_1, TLS1_2.

I assume TLSv1.3 will be enabled by default unless disabled explicitly 
so
security/openssl111 will always be built with TLSv1.3 enabled, am I 
correct?
And why not add port options to enable/disable TLSv1.3 as well as older 
TLS versions?


--
meta 
___
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: setting port options for multiple ports

[blubee blubeeme]

On 7/31/18, Guido Falsi  wrote:
> On 7/30/18 8:48 PM, Jan Beich wrote:
>> Guido Falsi  writes:
>>
>>> On 7/30/18 1:02 PM, blubee blubeeme wrote:
>>>
>>>> I am working on a port that requires many other ports to be built with
>>>> specific options selected.
>>>>
>>>> Is there any way to have a port enables options in it's dependencies?
>>>>
>>>
>>> There is no way to do exactly what you are asking for, but the
>>> "traditional" solution is to create a slave port forcing the options you
>>> require and naming it accordingly.
>>>
>>> This could also be done with flavors today, but keep in mind that adding
>>> flavors would require approval from both the maintainer and portmgr.
>>
>> Except anything else that depends on unslaved/unflavored port is likely
>> to cause a conflict... until variable dependencies come into play.
>
> Oh yes, I forgot to mention that.
>
> Thanks for filling my omission!
>
> --
> Guido Falsi 
> ___
> 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"
>
After thinking about this, implementing something like this will
explode in complexity pretty rapidly.

The slave ports idea does create install conflicts or bloats a system
with prefixed install locations.
The port option matrix would be insanely large and require insane
amounts of testing to possible get correct.

Might as well try to touch the Sun; not saying it's impossible but
it's not a task that I want to embark on right now.

I'll have to figure out a better way to handle this.

Best,
Owen
___
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: setting port options for multiple ports

[Guido Falsi]

On 7/30/18 8:48 PM, Jan Beich wrote:
> Guido Falsi  writes:
> 
>> On 7/30/18 1:02 PM, blubee blubeeme wrote:
>>
>>> I am working on a port that requires many other ports to be built with
>>> specific options selected.
>>>
>>> Is there any way to have a port enables options in it's dependencies?
>>>
>>
>> There is no way to do exactly what you are asking for, but the
>> "traditional" solution is to create a slave port forcing the options you
>> require and naming it accordingly.
>>
>> This could also be done with flavors today, but keep in mind that adding
>> flavors would require approval from both the maintainer and portmgr.
> 
> Except anything else that depends on unslaved/unflavored port is likely
> to cause a conflict... until variable dependencies come into play.

Oh yes, I forgot to mention that.

Thanks for filling my omission!

-- 
Guido Falsi 
___
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: setting port options for multiple ports

[Jan Beich]

Guido Falsi  writes:

> On 7/30/18 1:02 PM, blubee blubeeme wrote:
>
>> I am working on a port that requires many other ports to be built with
>> specific options selected.
>> 
>> Is there any way to have a port enables options in it's dependencies?
>> 
>
> There is no way to do exactly what you are asking for, but the
> "traditional" solution is to create a slave port forcing the options you
> require and naming it accordingly.
>
> This could also be done with flavors today, but keep in mind that adding
> flavors would require approval from both the maintainer and portmgr.

Except anything else that depends on unslaved/unflavored port is likely
to cause a conflict... until variable dependencies come into play.

https://lists.freebsd.org/pipermail/freebsd-ports/2017-September/110332.html
___
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: setting port options for multiple ports

[Guido Falsi]

On 7/30/18 1:02 PM, blubee blubeeme wrote:
> I am working on a port that requires many other ports to be built with
> specific options selected.
> 
> Is there any way to have a port enables options in it's dependencies?
> 

There is no way to do exactly what you are asking for, but the
"traditional" solution is to create a slave port forcing the options you
require and naming it accordingly.

This could also be done with flavors today, but keep in mind that adding
flavors would require approval from both the maintainer and portmgr.

-- 
Guido Falsi 
___
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: setting port options for multiple ports

[Mark Millard via freebsd-ports]

blubee blubeeme gurenchan at gmail.com write on
Mon Jul 30 11:03:07 UTC 2018 :

> I am working on a port that requires many other ports to be built with
> specific options selected.
> 
> Is there any way to have a port enables options in it's dependencies?

If the port is to be built on the FreeBSD package builders there are
likely large implications to forcing specific options of other ports.

Is this a "personal/local" port or otherwise not to be built by the
package builders ( or anyone doing poudriere bulk -a )?

There are ports that have local copies and internal builds of other
things needed in order to avoid such ties. As I remember pkg itself
is an example. (This has an environment-bootstrap sequence issue
involved in why as well.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: setting port options for multiple ports

[Gökşin Akdeniz]

Mon, 30 Jul 2018 19:02:54 +0800 tarihinde
blubee blubeeme  yazmış:

> 
> Is there any way to have a port enables options in it's dependencies?
> 

A port can only gonfigure it options not others. 

On the otherhand you can type "make config-recursive" at top level
port. "Top level port" is he port you want to install. This command
will configure all other ports, if any configuration options are
available for which top-level port is depending upon. I did not run
this command on "flavoured ports" so be careful.

-- 
Gökşin Akdeniz 


pgpPDbzYJq2i8.pgp
Description: PGP signature

Re: setting port options for multiple ports

[George Mitchell]

On 07/30/18 07:02, blubee blubeeme wrote:
> I am working on a port that requires many other ports to be built with
> specific options selected.
> 
> Is there any way to have a port enables options in it's dependencies?
> 
> Best,
> Owen
> [...]

If the port you need offers the option as a flavor, then I think you
can specify that flavor of the port (though it would probably conflict
with a different flavor of that port if it is installed).-- George



signature.asc
Description: OpenPGP digital signature

Re: setting port options for multiple ports

[Kurt Jaeger]

Hi!

> I am working on a port that requires many other ports to be built with
> specific options selected.

How many other ports ?

> Is there any way to have a port enables options in it's dependencies?

As far as I know, there is no mechanism for this.

Maybe it's time to design one.

-- 
p...@freebsd.org +49 171 3101372  2 years to go !
___
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"

setting port options for multiple ports

[blubee blubeeme]

I am working on a port that requires many other ports to be built with
specific options selected.

Is there any way to have a port enables options in it's dependencies?

Best,
Owen
___
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: poudriere options: -c flag explanation

[abi]

On 04.03.2018 02:26, Le Baron d’Merde wrote:

On Sat, Mar 03, 2018 at 01:02:23PM +0300, abi wrote:

Hello,

Assuming that -n flag suggests that options run recursivly for deps chain,
isn't  -c flag should always invoke dialog4ports for every port with options ?

For example, poudriere options -c editors/libreoffice asks for options
through all dep chain if runs the first time, on subsequent run it asks for
options only for original port or if it find no cached options.

This looks confusing, is it intended?

The default behavior of ports-mgmt/poudriere is to open the dialog to set 
OPTIONS
for each selected port (targets) and all its dependencies, unless they were
already set.

Issuing 'poudriere options -n' will just open the dialog to the target(s) and 
not its
dependencies. Again, but for those which already have OPTIONS set.

The -c flag in 'poudriere options' delete the previous selected options to the
specified target(s) and open the dialog to set them again - what may include
dependencies without OPTINOS set already.

Isn't this behaviour incorrect? If -c skips dependencies with OPTIONS, 
it is impossible to revisit them? For example, if I want to re-think all 
dependencies of java and check their options, how can I do this? Man 
suggests that -c behaviour is recursive (if -n is not provided).

___
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: poudriere options: -c flag explanation

[Le Baron d’Merde]

On Sat, Mar 03, 2018 at 01:02:23PM +0300, abi wrote:
> Hello,
> 
> Assuming that -n flag suggests that options run recursivly for deps chain,
> isn't  -c flag should always invoke dialog4ports for every port with options ?
> 
> For example, poudriere options -c editors/libreoffice asks for options
> through all dep chain if runs the first time, on subsequent run it asks for
> options only for original port or if it find no cached options.
> 
> This looks confusing, is it intended?

The default behavior of ports-mgmt/poudriere is to open the dialog to set 
OPTIONS
for each selected port (targets) and all its dependencies, unless they were 
already set.

Issuing 'poudriere options -n' will just open the dialog to the target(s) and 
not its 
dependencies. Again, but for those which already have OPTIONS set.

The -c flag in 'poudriere options' delete the previous selected options to the
specified target(s) and open the dialog to set them again - what may include
dependencies without OPTINOS set already.

-C will delete the target OPTIONS and all its dependencies.


> ___
> 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"

-- 
Best Regards.
LBdM.
___
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"

poudriere options: -c flag explanation

[abi]

Hello,

Assuming that -n flag suggests that options run recursivly for deps 
chain, isn't  -c flag should always invoke dialog4ports for every port 
with options ?


For example, poudriere options -c editors/libreoffice asks for options 
through all dep chain if runs the first time, on subsequent run it asks 
for options only for original port or if it find no cached options.


This looks confusing, is it intended?

___
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"

how to make upstream acknowledge MPI port options?

[Anton Shterenlikht]

I'm the maintainer of lang/opencoarrays.
I offer users a choice of 3 MPI libraries.
It seems upstream cmake doesn't know of my options:

# make showconfig
===> The following configuration options are available for opencoarrays-1.9.3_1:
> MPI (Message Passing Interface) support: you have to select exactly one 
of them
 MPICH=off: Parallel processing support via MPICH
 OPENMPI=on: Parallel processing support via Open MPI
 OPENMPI2=off: Parallel processing support via Open MPI v2
===> Use 'make config' to modify these settings
#

-- Found MPI_C: /usr/local/lib/libmpi.so (found version "3.1")
-- Found MPI_Fortran: /usr/local/lib/libmpifort.so (found version "3.1")

(which are for mpich)

Obviously upstream doesn't know or care about
FreeBSD ports options.
So how is this supposed to work?

How can I affect upstream build process based
on port options?

Thanks

Anton
___
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"

If the port is designed to have a Motif version, a GTK version, and a NOGUI version, can these be made into flavors, instead of options?

[Yuri]

The port can be built to have the exact same UI but alternatively based 
on Motif, GTK, or no GUI at all. In each case, the plist is exactly the 
same.



Can these be made into flavors: FLAVORS=nogui motif gtk ?

My opinion: this is a good idea. The package is originally designed to 
have 2 UI incarnations, and flavors beautifully match this polymorphism.


Is there any reason that flavors shouldn't be used in this case?


Thanks,

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"

Re: Again, flavors or options?

[Mathieu Arnold]

Le 21/12/2017 à 09:55, Yuri a écrit :
> On 12/21/17 00:17, Mathieu Arnold wrote:
>> Flavors is for when a port needs to be built differently multiple times.
>>  From what you are saying, this can be built once and splitted up later,
>> this is subpackages. For now, you should use options, with what most
>> people need as the default options. You could do slave ports, but I
>> don't see the point.
>
>
> Is there an ETA for sub-packages?

When it is done.

-- 
Mathieu Arnold

___
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: Again, flavors or options?

[Yuri]

On 12/21/17 00:17, Mathieu Arnold wrote:

Flavors is for when a port needs to be built differently multiple times.
 From what you are saying, this can be built once and splitted up later,
this is subpackages. For now, you should use options, with what most
people need as the default options. You could do slave ports, but I
don't see the point.



Is there an ETA for sub-packages?


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"

Re: Again, flavors or options?

[Mathieu Arnold]

Le 21/12/2017 à 03:16, Yuri a écrit :
> Do you think flavors are a good fit for this task?

Flavors is for when a port needs to be built differently multiple times.
From what you are saying, this can be built once and splitted up later,
this is subpackages. For now, you should use options, with what most
people need as the default options. You could do slave ports, but I
don't see the point.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: Again, flavors or options?

[Shane Ambler]

On 21/12/2017 16:35, Freddie Cash wrote:
> On Dec 20, 2017 6:16 PM, "Yuri" <y...@rawbw.com> wrote:
> 
> I have the port for the digital currency. It has 3 parts that install
> non-intersecting file sets: daemon, cli, qt-ui. The commonality: same
> repository, same build options, same license, mostly same port options.
> 
> I am attracted to the idea to use flavors to let users choose which part do
> they want: FLAVORS=default daemon qt cli

As I said in my first answer, flavours changes the dependencies not the
options of the port, eg a flavour using py27 another using py36

I don't think there is a way to have different options enabled for
different flavours, each flavour will use the same options.

Until we have the ability to break a single port into multiple packages
that can be installed separately, you either have options for each item
or a different port for each. So you could make the daemon and cli
enabled as default, which will be available in the standard repos, then
the qt-gui as an option the user needs to enable and build themselves.

To simplify maintaining multiple related ports, you can use the same
Makefile for each by setting up the others as slave ports, see 5.10 of
the porters handbook. By setting a variable in the slave, you can use
logic tests to control what varies for each port in the one Makefile.

> "default" will install all of them, others will install individual parts.
> Option list will be slightly different for each flavor.
> 
> One alternative: only have port options. Then some options can't be
> conditional on which parts are built.

You have several options to logically control what options are enabled.
You can find several possibilities in 5.13 of the porters handbook.

from 5.13.3.7 -
OPT1_IMPLIES= OPT2
# this means when you enable OPT1, OPT2 will automatically be turned on

from 5.13.3.8 -
OPT1_PREVENTS= OPT2
# this prevents enabling OPT1 and OPT2 at the same time

You can use the standard logic available in any Makefile -

.if ${PORT_OPTIONS:MOPT1} && ${PORT_OPTIONS:MOPT2}
# make adjustments for both options being on
.endif

You also get custom build targets based on options (5.13.3.12) -
post-patch-OPT1-on:
${REINPLACE_CMD} -e 's|opt2=True|opt2=False|' ${WRKSRC}/configure


-- 
FreeBSD - the place to B...Software Developing

Shane Ambler

___
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: Again, flavors or options?

[Freddie Cash]

On Dec 20, 2017 6:16 PM, "Yuri" <y...@rawbw.com> wrote:

I have the port for the digital currency. It has 3 parts that install
non-intersecting file sets: daemon, cli, qt-ui. The commonality: same
repository, same build options, same license, mostly same port options.

I am attracted to the idea to use flavors to let users choose which part do
they want: FLAVORS=default daemon qt cli

"default" will install all of them, others will install individual parts.
Option list will be slightly different for each flavor.

One alternative: only have port options. Then some options can't be
conditional on which parts are built.

Another alternative: 3 slave ports. I don't like this idea at all.

Do you think flavors are a good fit for this task?


Sounds like a textbook example of sub-packages.

Until then, slave ports would be the next-best thing as that provides
separate packages that can be installed.

Cheers,
Freddie
___
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"

Again, flavors or options?

[Yuri]

I have the port for the digital currency. It has 3 parts that install 
non-intersecting file sets: daemon, cli, qt-ui. The commonality: same 
repository, same build options, same license, mostly same port options.


I am attracted to the idea to use flavors to let users choose which part 
do they want: FLAVORS=default daemon qt cli


"default" will install all of them, others will install individual 
parts. Option list will be slightly different for each flavor.



One alternative: only have port options. Then some options can't be 
conditional on which parts are built.


Another alternative: 3 slave ports. I don't like this idea at all.


Do you think flavors are a good fit for this task?


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"

Re: Heads up: Poudriere changed default options dir

[Serpent7776]

On Tue, 14 Nov 2017 18:41:53 +0100
"Vlad K." <vlad-f...@acheronmedia.com> wrote:

> List,
> 
> before 3.2.0 Poudriere defined PORT_DBDIR with only 
> --options, which was apparently a bug. Now (in 3.2.0) 
> it honors -p option in the options command and includes ports tree name 
> (given to -p) in PORT_DBDIR.
> 
> In other words, if -p is given, it will be included in PORT_DBDIR. If 
> it's not, then nothing's changed.
> 
> The result of that is that it will mkdir 
> ---options, which has higher priority than 
> --options, so if you have the options dir created 
> from before, named only -options (or 
> --options), it will now be overriden by the new 
> (correct) scheme.
> 
> This is important in my case, because when I first ran poudriere options 
> many lunar orbits ago, it created -options, and 
> --options, and it remained like that as I don't have 
> more than one tree (but do have several jails and sets). So now it 
> "broke" my set up (which I suppose should be said it fixed a bug and my 
> setup was broken from before).
> 
> The fix was simply to rename the old -options dir I had to 
> -default-options (as "default" is my ports tree name), and 
> likewise for each set I use.
> 
> Sorry if this was mentioned before, though I found no public 
> announcement of this change. Thought it was important enough to mention 
> it, so here.
> 

Thanks for mentioning this. I wondered why poudriere is asking me to configure
each port after updating.
I think it should me mentioned in UPDATING.

-- 
/*
 * Serpent7776
 */
___
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: Heads up: Poudriere changed default options dir

[Bryan Drewery]

On 11/14/2017 9:45 AM, Vlad K. wrote:
> On 2017-11-14 18:41, Vlad K. wrote:
>> List,
>>
>> before 3.2.0 Poudriere defined PORT_DBDIR with only
>> --options, which was apparently a bug. Now (in
>> 3.2.0) it honors -p option in the options command and includes ports
>> tree name (given to -p) in PORT_DBDIR.
>>
> 
> I forgot to mention, this is the relevant commit, if I'm not mistaken:
> 
> https://github.com/freebsd/poudriere/commit/9082679feba8c12290bbd719df5d4512aa736167
> 

It was in the release notes but subtle...
https://github.com/freebsd/poudriere/wiki/release_notes_32
"options: -p flag support fixed."

I am going to tweak 'poudriere options' for 3.2.1 by checking if an
existing non-ports-tree dir already exists and having it ask if it
should use that one instead and suggest to not use -p, all before the
'mkdir -p' it does which causes bulk to get an empty option set on the
next run.

It's bitten quite a few people already, probably 6+ that I know of.  I
am tempted to just revert it but I think it is useful for some which is
why I'll go the interactive route (when in a TTY).


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Heads up: Poudriere changed default options dir

[Vlad K.]

On 2017-11-14 18:41, Vlad K. wrote:

List,

before 3.2.0 Poudriere defined PORT_DBDIR with only
--options, which was apparently a bug. Now (in
3.2.0) it honors -p option in the options command and includes ports
tree name (given to -p) in PORT_DBDIR.



I forgot to mention, this is the relevant commit, if I'm not mistaken:

https://github.com/freebsd/poudriere/commit/9082679feba8c12290bbd719df5d4512aa736167



--
Vlad K.
___
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"

Heads up: Poudriere changed default options dir

[Vlad K.]

List,

before 3.2.0 Poudriere defined PORT_DBDIR with only 
--options, which was apparently a bug. Now (in 3.2.0) 
it honors -p option in the options command and includes ports tree name 
(given to -p) in PORT_DBDIR.


In other words, if -p is given, it will be included in PORT_DBDIR. If 
it's not, then nothing's changed.


The result of that is that it will mkdir 
---options, which has higher priority than 
--options, so if you have the options dir created 
from before, named only -options (or 
--options), it will now be overriden by the new 
(correct) scheme.


This is important in my case, because when I first ran poudriere options 
many lunar orbits ago, it created -options, and 
--options, and it remained like that as I don't have 
more than one tree (but do have several jails and sets). So now it 
"broke" my set up (which I suppose should be said it fixed a bug and my 
setup was broken from before).


The fix was simply to rename the old -options dir I had to 
-default-options (as "default" is my ports tree name), and 
likewise for each set I use.


Sorry if this was mentioned before, though I found no public 
announcement of this change. Thought it was important enough to mention 
it, so here.




--
Vlad K.
___
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"

SIGSEGV due to different options for amanda-server and amanda-client

[G. Paul Ziemba]

Summary
---
For a given installation, make sure amanda-server and amanda-client ports
are built with the same port/build options, or memory access errors could
occur.

A Longer Summary

These two ports are built from the same source tree, and binaries from
both ports reference data in libamanda.so. However, only the instance
of libamanda.so from amanda-clients is actually installed. The build options
are captured in the version_info[] string pointer array in libamanda.so,
and the size of the array can vary if the build options are different.

I don't know the details of the dynamic linker, but it seems that the
arrangement of data in libamanda.so at build time of a dynamically-linked
application leaves state in the application binary that influences the
memory layout of the library data at run time.

A binary that references version_info[] (in libamanda.so) contains some
information (maybe segment boundaries?) that depends on the size of
version_info[] that the binary was built against.

Using a binary with a libamanda.so that has a larger version_info[]
than what the binary was built with can result in some sort of truncation
of the array, with ensuing gnashing of teeth.

What to do?
---
I think it's FreeBSD's issue (i.e., not upstream) because the potential
for mismatch arises from splitting into two ports. However, it might
be possible for upstream to fix it by hiding version_info[] in libamanda.so
and providing some access function(s).

I don't think there is a way to detect inconsistent flags/options
between ports.

Maybe the best FreeBSD can do is add a warning in pkg-message about the
potential for problems if options are different.

Or other ideas?

Details
---

Versions:

% uname -m -r -s -v
FreeBSD 11.1-STABLE FreeBSD 11.1-STABLE #0 r321349: Fri Jul 21 16:31:37 PDT 
2017 root@hairball:/usr/obj/usr/src/sys/GENERIC  amd64
% pkg info -x amanda
amanda-client-3.3.9,1
amanda-perl-wrapper-1.01
amanda-server-3.3.9,1

amdump failed with:

driver: FATAL Did not get DATE line from planner

I ran planner by itself with:

% cd ~/tmp/amanda/amanda-3.3.9/server-src
% sudo gdb /usr/local/libexec/amanda/planner
(gdb) run Weekly --starttime 201709081213 -otapedev= -otpchanger=

and found a bad string address (0x100) deep in printf and friends 
from the g_fprintf here (planner.c):

267 for (i = 0; version_info[i] != NULL; i++)
268 g_fprintf(stderr, _("%s: %s"), get_pname(), version_info[i]);

Program received signal SIGSEGV, Segmentation fault.
strlen (str=0x100 )
at /usr/src/lib/libc/string/strlen.c:100
100 va = (*lp - mask01);
(gdb) where
#0  strlen (str=0x100 )
at /usr/src/lib/libc/string/strlen.c:100
#1  0x000802c1721a in __vfprintf (fp=, 
locale=0x802ec1578 <__xlocale_global_locale>, fmt0=, 
ap=) at /usr/src/lib/libc/stdio/vfprintf.c:845
#2  0x000802c15344 in vfprintf_l (fp=0x802ec2ab0, 
locale=0x802ec1578 <__xlocale_global_locale>, fmt0=0x411fae "%s: %s", 
ap=0x7fffd370) at /usr/src/lib/libc/stdio/vfprintf.c:283
#3  0x000802467030 in g_vfprintf (file=0x802ec2ab0, 
format=0x411fae "%s: %s", args=0x7fffd370) at gprintf.c:213
#4  0x000802466fb9 in g_fprintf (file=0x802ec2ab0, 
format=0x411fae "%s: %s") at gprintf.c:82
#5  0x004041fe in main (argc=4, argv=0x7fffea10) at planner.c:268

Further investigation with code modifications per:

for (i = 0; version_info[i] != NULL; i++) {
char *vinfo;
vinfo = version_info[i];
g_fprintf(stderr, _("%s: %s"), get_pname(), vinfo);
}

showed that with i=25, after the assignment to vinfo but before the call
to g_printf, version_info[i] was a valid string pointer but vinfo contained
0x100.

Here is some output of "nm -n /usr/local/libexec/amanda/planner" (the binary):

00614730 A __bss_start
00614730 B __stdoutp@@FBSD_1.0
00614730 A _edata
00614740 B version_info
00614808 B __mb_sb_limit@@FBSD_1.0
00614810 B _DefaultRuneLocale@@FBSD_1.0

Note that 0x614808 - 0x614740 = 200 decimal.

Here is some output of
"objdump -a -t -s /usr/local/lib/amanda/libamanda-3.3.9.so" (the library):

00295020 g O .data.rel.ro   00d8  
version_info

 295020 b3990800  d2990800   
 295030 119a0800  469a0800   F...
 295040 809a0800  af9a0800   
 295050 e09a0800  1c9b0800   
 295060 409b0800  7e9b0800   @...~...
 295070 ac9b0800  e79b0800   
 295080 2b9c0800  559c0800   +...U...
 295090 989c0800  dc9c0800   
 2950a0 199d0800  5

Re: Configuring options/knobs without `make config`

[Jonathan Chen]

On 1 August 2017 at 08:16, Morse, Richard E.,MGH
<remo...@mgh.harvard.edu> wrote:
> On Jul 31, 2017, at 4:06 PM, Jonathan Chen <j...@chen.org.nz> wrote:
>>
>> Here's a quick run down on the change:
>>  https://forums.freebsd.org/threads/52871/
>>
>> The portconf features have been baked into the ports system, and you
>> can set/unset options within /etc/make.conf, eg:
>>
>> graphics_atril_SET=DVI T1LIB
>> mail_thunderbird_UNSET= PULSEAUDIO
>
> Out of curiosity, is there a global way to disable X11 (say) in this? Is that 
> documented anywhere?
>
> In portconf, I was able to add a line:
>
> *: WITHOUT_X11=“YES”
>
> and it would (hopefully) suppress X11. Do I need to add
>
>     port_UNSET= X11
>
> for every port that will get installed?

Try:
OPTIONS_UNSET= X11

Multiple options can also be set, eg:
OPTIONS_UNSET= X11 NLS DOCS

Cheers.
-- 
Jonathan Chen <j...@chen.org.nz>
___
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: Configuring options/knobs without `make config`

[Morse, Richard E.,MGH]

On Jul 31, 2017, at 4:06 PM, Jonathan Chen <j...@chen.org.nz> wrote:
> 
> Here's a quick run down on the change:
>  https://forums.freebsd.org/threads/52871/
> 
> The portconf features have been baked into the ports system, and you
> can set/unset options within /etc/make.conf, eg:
> 
> graphics_atril_SET=DVI T1LIB
> mail_thunderbird_UNSET= PULSEAUDIO

Out of curiosity, is there a global way to disable X11 (say) in this? Is that 
documented anywhere?

In portconf, I was able to add a line:

*: WITHOUT_X11=“YES”

and it would (hopefully) suppress X11. Do I need to add

port_UNSET= X11

for every port that will get installed?

Ricky


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
___
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: Configuring options/knobs without `make config`

[Jonathan Chen]

On 1 August 2017 at 07:50, Morse, Richard E.,MGH
<remo...@mgh.harvard.edu> wrote:
> Hi! I used to use portconf on the machine this is going to be replacing, but 
> it seemed like there were changes to the way the port system worked between 
> 8.4 and 11, and I couldn’t find anything that documented how to properly set 
> up portconf for the new “options” stuff, in place of the old “WITH/WITHOUT” 
> stuff. Can you recommend somewhere I can find that out?
>

Here's a quick run down on the change:
  https://forums.freebsd.org/threads/52871/

The portconf features have been baked into the ports system, and you
can set/unset options within /etc/make.conf, eg:

graphics_atril_SET=DVI T1LIB
mail_thunderbird_UNSET= PULSEAUDIO

Cheers.
-- 
Jonathan Chen <j...@chen.org.nz>
___
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: Configuring options/knobs without `make config`

[Morse, Richard E.,MGH]

Hi! I used to use portconf on the machine this is going to be replacing, but it 
seemed like there were changes to the way the port system worked between 8.4 
and 11, and I couldn’t find anything that documented how to properly set up 
portconf for the new “options” stuff, in place of the old “WITH/WITHOUT” stuff. 
Can you recommend somewhere I can find that out?

Thanks,
Ricky

> On Jul 27, 2017, at 8:18 PM, Dewayne Geraghty 
> <dewayne.gerag...@heuristicsystems.com.au> wrote:
> 
> Richard,
> I'm unsure of how you're planning on using the information, perhaps
> these suggestions may help:
> 
> To examine what options are available, chosen or rejected (note: the
> value of CATEGORY and PORT must be in lowercase):
> make -C /usr/ports/$CATEGORY/$PORT -VPORT_OPTIONS -VSELECTED_OPTIONS
> -VDESELECTED_OPTIONS
> 
> If you're after consistency, then I would suggest that you use
> /etc/make.conf to ascribe the options that you want for each of the ports.
> 
> For example, using mail/dovecot2:
> mail_dovecot2_SET=LZ4 KQUEUE SSL
> mail_dovecot2_UNSET=BDB PGSQL
> 
> I'll reiterate that I don't interactively set port options on anything,
> so no "make config".  I use a tool called ports-mgmt/portconf to manage
> my ports. I can't recommend the tool as I do some preprocessing to align
> with port devs requirements, currently
> $CATEGORY_$PORT_[SET|UNSET]=
> if in /etc/make.conf or on the command line by
> [WITH|WITHOUT]=
> 
> Enjoy.
> Dewayne



The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
___
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: Configuring options/knobs without `make config`

[Chris Rees]

___
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: Configuring options/knobs without `make config`

[Dewayne Geraghty]

Oops.  I forgot to mention that you would use portmaster this way
/usr/local/sbin/portmaster -m "commands to pass" $CATEGORY/$PORT
which I use for other tasks, as explained earlier.
For example
portmaster -m 'WITH="SQLITE LDAP" WITHOUT="DIGEST IPV6"' $CAT/$PORT

Note: -m "" can not be issued multiple times on the command line.

___
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: Configuring options/knobs without `make config`

[Dewayne Geraghty]

Richard,
I'm unsure of how you're planning on using the information, perhaps
these suggestions may help:

To examine what options are available, chosen or rejected (note: the
value of CATEGORY and PORT must be in lowercase):
make -C /usr/ports/$CATEGORY/$PORT -VPORT_OPTIONS -VSELECTED_OPTIONS
-VDESELECTED_OPTIONS

If you're after consistency, then I would suggest that you use
/etc/make.conf to ascribe the options that you want for each of the ports.

For example, using mail/dovecot2:
mail_dovecot2_SET=LZ4 KQUEUE SSL
mail_dovecot2_UNSET=BDB PGSQL

I'll reiterate that I don't interactively set port options on anything,
so no "make config".  I use a tool called ports-mgmt/portconf to manage
my ports. I can't recommend the tool as I do some preprocessing to align
with port devs requirements, currently
$CATEGORY_$PORT_[SET|UNSET]=
if in /etc/make.conf or on the command line by
[WITH|WITHOUT]=

Enjoy.
Dewayne
___
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: Configuring options/knobs without `make config`

[Kevin Oberman]

On Thu, Jul 27, 2017 at 7:36 AM, Morse, Richard E.,MGH <
remo...@mgh.harvard.edu> wrote:

> Hi! I’m trying to document the setup of a new system, and I’m finding it
> really complicated to document exactly which options I choose for various
> ports.
>
> I was wondering if there is some magic command-line syntax, (ideally to
> postmaster) that would let me document the options selected in the form of
> a command — something like:
>
> postmaster editors/vim -o NOLUA,NOPYTHON,NORUBY,CONSOLE,NOGNOME
>
> (to indicate the changes from the default settings; I would be fine if I
> had to specify every option, I suppose, but ideally only ones that changed…)
>
> Thanks,
> Ricky
>
>
Short answer is "no". because the ports system always remembers teh chosen
configuration for any port and that is stored in the pkg database, I am not
aware of any tool that allows setting of options from the command line.
That said, it is certainly possible and does not look difficult to
implement. It would probably be both easiest and more supportable to set
the options in the command line into the DB. Of course, '-o' is already in
use, so that would net be available.

More difficult to deal with is the issue of default options. Frankly, that
is not an issue that is really handled at all well with any of the current
tools and periodically bites my in the ass. Clearly, requiring all options
to e listed on the command line is not workable. (Just look at the list of
options on some multimedia ports.) So the assumption is that the command
line only specifies variations from defaults, but that does not address how
to deal with changes in defaults or with deleted options. I don't have
obvious answers on this. Do you? It's certainly not trivial.

As a non-answer to your question, maybe a dump of the current options. That
could easily be added to most any tool ad it is a one-line command.
make -C PORT_PATH showconfig
where "PORT_PATH" is the path to the port, e.g.
/usr/ports/multimedia/ffmpeg. It could easily in a simple wrapper around
some other command such as portmaster.

Maybe someone else has a better idea, but it does not look at all simple to
me.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"

Configuring options/knobs without `make config`

[Morse, Richard E.,MGH]

Hi! I’m trying to document the setup of a new system, and I’m finding it really 
complicated to document exactly which options I choose for various ports.

I was wondering if there is some magic command-line syntax, (ideally to 
postmaster) that would let me document the options selected in the form of a 
command — something like:

postmaster editors/vim -o NOLUA,NOPYTHON,NORUBY,CONSOLE,NOGNOME

(to indicate the changes from the default settings; I would be fine if I had to 
specify every option, I suppose, but ideally only ones that changed…)

Thanks,
Ricky


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
___
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: Pass options to dependency

[Adam Weinberger]

> On 5 Jun, 2017, at 7:10, Eugene Grosbein <eu...@grosbein.net> wrote:
> 
> 05.06.2017 18:51, Matthew Seaman пишет:
>> On 05/06/2017 10:56, Eugene Grosbein wrote:
>>> How can a port (its Makefile) pass a build option to BUILD_DEPENDS?
>>> For example, devel/ragel has:
>>> 
>>> DOCS_USE=   TEX=latex:build
>>> DOCS_BUILD_DEPENDS= fig2dev:print/transfig
>>> 
>>> And "make -C /usr/ports/devel/ragel all-depends-list" shows HUGE
>>> list of its dependencies completely unneded for a port that just
>>> needs to use BUILD_DEPENDS=ragel:devel/ragel
>>> 
>>> The reason is that bsd.options.mk includes PORT_OPTIONS+=  DOCS
>>> unless user option NOPORTDOCS is set.
>>> 
>>> Is it possible to specify something like OPTIONS_EXCLUDE=DOCS
>>> for BUILD_DEPENDS entity?
>>> 
>> 
>> Generally what you would do is create a slave port of the dependency
>> with the options settings you require.  Doing this to turn off the DOCS
>> option would be unprecedented though.
>> 
>> I believe the consensus nowadays is that DOCS should control installing
>> documentation that takes little or no effort to generate.  If you need
>> to install a huge dependency tree in order to generate documentation,
>> then that should be controlled using a different option.  Whether to
>> have that option default to either ON or OFF is at the discretion of the
>> maintainer.
>> 
>> So my advice here is open a PR to get devel/ragel modified, and in the
>> mean time try and ignore all those unwanted dependencies while you work
>> on your own port.
> 
> It would be more useful to have general way to build a dependency
> with needed set of options or at least introduce NODEPDOCS
> similar to NOPORTDOCS, wouldn't it?

Standard policy is that DOCS is always enabled by default, and if heavy 
dependencies are required, they have a new option name. TEXDOCS, for instance, 
for ragel's example.

NODEPDOCS is a little too grey because the interpretation is arbitrary; what 
about ports that need pandoc to produce manpages... we'd need a NODEPMANPAGES 
variable, and a NODEPHELPFILESBUTNOTDOCS, NODEPEXAMPLES, etc.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.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: Pass options to dependency

[Eugene Grosbein]

05.06.2017 18:51, Matthew Seaman пишет:
> On 05/06/2017 10:56, Eugene Grosbein wrote:
>> How can a port (its Makefile) pass a build option to BUILD_DEPENDS?
>> For example, devel/ragel has:
>>
>> DOCS_USE=   TEX=latex:build
>> DOCS_BUILD_DEPENDS= fig2dev:print/transfig
>>
>> And "make -C /usr/ports/devel/ragel all-depends-list" shows HUGE
>> list of its dependencies completely unneded for a port that just
>> needs to use BUILD_DEPENDS=ragel:devel/ragel
>>
>> The reason is that bsd.options.mk includes PORT_OPTIONS+=  DOCS
>> unless user option NOPORTDOCS is set.
>>
>> Is it possible to specify something like OPTIONS_EXCLUDE=DOCS
>> for BUILD_DEPENDS entity?
>>
> 
> Generally what you would do is create a slave port of the dependency
> with the options settings you require.  Doing this to turn off the DOCS
> option would be unprecedented though.
> 
> I believe the consensus nowadays is that DOCS should control installing
> documentation that takes little or no effort to generate.  If you need
> to install a huge dependency tree in order to generate documentation,
> then that should be controlled using a different option.  Whether to
> have that option default to either ON or OFF is at the discretion of the
> maintainer.
> 
> So my advice here is open a PR to get devel/ragel modified, and in the
> mean time try and ignore all those unwanted dependencies while you work
> on your own port.

It would be more useful to have general way to build a dependency
with needed set of options or at least introduce NODEPDOCS
similar to NOPORTDOCS, wouldn't it?

Eugene Grosbein





signature.asc
Description: OpenPGP digital signature

Re: Pass options to dependency

[Matthew Seaman]

On 05/06/2017 10:56, Eugene Grosbein wrote:
> How can a port (its Makefile) pass a build option to BUILD_DEPENDS?
> For example, devel/ragel has:
> 
> DOCS_USE=   TEX=latex:build
> DOCS_BUILD_DEPENDS= fig2dev:print/transfig
> 
> And "make -C /usr/ports/devel/ragel all-depends-list" shows HUGE
> list of its dependencies completely unneded for a port that just
> needs to use BUILD_DEPENDS=ragel:devel/ragel
> 
> The reason is that bsd.options.mk includes PORT_OPTIONS+=  DOCS
> unless user option NOPORTDOCS is set.
> 
> Is it possible to specify something like OPTIONS_EXCLUDE=DOCS
> for BUILD_DEPENDS entity?
> 

Generally what you would do is create a slave port of the dependency
with the options settings you require.  Doing this to turn off the DOCS
option would be unprecedented though.

I believe the consensus nowadays is that DOCS should control installing
documentation that takes little or no effort to generate.  If you need
to install a huge dependency tree in order to generate documentation,
then that should be controlled using a different option.  Whether to
have that option default to either ON or OFF is at the discretion of the
maintainer.

So my advice here is open a PR to get devel/ragel modified, and in the
mean time try and ignore all those unwanted dependencies while you work
on your own port.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Pass options to dependency

[Eugene Grosbein]

Hi!

How can a port (its Makefile) pass a build option to BUILD_DEPENDS?
For example, devel/ragel has:

DOCS_USE=   TEX=latex:build
DOCS_BUILD_DEPENDS= fig2dev:print/transfig

And "make -C /usr/ports/devel/ragel all-depends-list" shows HUGE
list of its dependencies completely unneded for a port that just
needs to use BUILD_DEPENDS=ragel:devel/ragel

The reason is that bsd.options.mk includes PORT_OPTIONS+=  DOCS
unless user option NOPORTDOCS is set.

Is it possible to specify something like OPTIONS_EXCLUDE=DOCS
for BUILD_DEPENDS entity?

Eugene Grosbein

___
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: Document for OPTIONS syntax in /etc/make.conf, where to find?

[Thomas Mueller]

> On 25 May 2017 at 19:47, Thomas Mueller <mueller6...@twc.com> wrote:
[...]
> > The new synth has no mechanism for configuring options; I guess that would 
> > have to be done by
> > make config-recursive ,
> > possibly several times until there is nothing more left to configure, as I 
> > did when using portupgrade and later portmaster.

> >From synth(1) man page:
 -make.conf
   This is an optional, user-provided file. If it exists,
   the builder's /etc/make.conf will be appended with the
   contents of this file. For the default profile, the
   file would normally be located at
   /usr/local/etc/synth/LiveSystem-make.conf

> Cheers.

> Jonathan Chen <j...@chen.org.nz>

Thanks for the tip.

I already have read the man page because I git-cloned synth tree from github 
repository.

I want to keep the Ada code for viewing, among other things.

My first attempt to build synth was on FreeBSD-current amd64 and failed when 
the system rebooted itself when I was sleeping.  Apparently no filesystem 
damage.

System came up in System Rescue CD 5.0.0 USB-stick installation.

I attribute this to FreeBSD-current instability rather than synth or ports, 
meaning I must first rebuild FreeBSD 11.0-STABLE amd64 installation, and then 
from there, FreeBSD-current amd64.

Tom

___
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: Document for OPTIONS syntax in /etc/make.conf, where to find?

[Jonathan Chen]

On 25 May 2017 at 19:47, Thomas Mueller <mueller6...@twc.com> wrote:
[...]
> The new synth has no mechanism for configuring options; I guess that would 
> have to be done by
> make config-recursive ,
> possibly several times until there is nothing more left to configure, as I 
> did when using portupgrade and later portmaster.

>From synth(1) man page:
 -make.conf
   This is an optional, user-provided file. If it exists,
   the builder's /etc/make.conf will be appended with the
   contents of this file. For the default profile, the
   file would normally be located at
   /usr/local/etc/synth/LiveSystem-make.conf

Cheers.
-- 
Jonathan Chen <j...@chen.org.nz>
___
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: Document for OPTIONS syntax in /etc/make.conf, where to find?

[Thomas Mueller]

> > On 24 May, 2017, at 21:52, Thomas Mueller <mueller6...@twc.com> wrote:

> > Where do I find documentation so I get the correct syntax for setting ports 
> > options in /etc/make.conf ?

> > I tried "man ports", "man make", "man make.conf", and the online Porters' 
> > Handbook but have been unable to find the needle in the haystack.

> > NetBSD pkgsrc and Gentoo (Linux) portage document this much better.


> Tom

> You'll find some info in the instructions at the top of 
> /usr/ports/Mk/bsd.options.mk; there's not a lot of info because it's not 
> generally the preferred place to specify options.

> To turn something off by default on all ports (which can always be overridden 
> by make config),
OPTIONS_UNSET=  NLS

> To turn something off which overrides make config,
OPTIONS_UNSET_FORCE=NLS

> You can set options for individual ports in make.conf too, though it's almost 
> always a better idea to run 'make config' or 'poudriere options':
> /usr/ports/editors/vim$ make -V OPTIONS_NAME
> editors_vim

> make.conf:
> editors_vim_UNSET=  NLS
 
# Adam


> Adam Weinberger

While the newer dialog4ports is a big improvement over the previous dialog, it 
is still difficult to go back in case of finger error.

Previous dialog tended to make a mess of the screen, especially when I teed to 
a log file.

Now I have a better idea what to do to set options.

I still have in /etc/make.conf from some time ago,

OPTIONS_SET.mpop=GNUTLS NLS

I guess that would need to be revised to

mail_mpop_set=GNUTLS NLS

if I stay with the same options.

The new synth has no mechanism for configuring options; I guess that would have 
to be done by
make config-recursive ,
possibly several times until there is nothing more left to configure, as I did 
when using portupgrade and later portmaster.

Thanks for the tips!

Other options-configuring systems don't have the dialog: I am thinking of 
NetBSD pkgsrc and Gentoo portage (not all-inclusive).

Tom

___
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: Document for OPTIONS syntax in /etc/make.conf, where to find?

[Adam Weinberger]

> On 24 May, 2017, at 21:52, Thomas Mueller <mueller6...@twc.com> wrote:
> 
> Where do I find documentation so I get the correct syntax for setting ports 
> options in /etc/make.conf ?
> 
> I tried "man ports", "man make", "man make.conf", and the online Porters' 
> Handbook but have been unable to find the needle in the haystack.
> 
> NetBSD pkgsrc and Gentoo (Linux) portage document this much better.
> 
> 
> Tom

You'll find some info in the instructions at the top of 
/usr/ports/Mk/bsd.options.mk; there's not a lot of info because it's not 
generally the preferred place to specify options.

To turn something off by default on all ports (which can always be overridden 
by make config),
OPTIONS_UNSET=  NLS

To turn something off which overrides make config,
OPTIONS_UNSET_FORCE=NLS

You can set options for individual ports in make.conf too, though it's almost 
always a better idea to run 'make config' or 'poudriere options':
/usr/ports/editors/vim$ make -V OPTIONS_NAME
editors_vim

make.conf:
editors_vim_UNSET=  NLS

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.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"

Document for OPTIONS syntax in /etc/make.conf, where to find?

[Thomas Mueller]

Where do I find documentation so I get the correct syntax for setting ports 
options in /etc/make.conf ?

I tried "man ports", "man make", "man make.conf", and the online Porters' 
Handbook but have been unable to find the needle in the haystack.

NetBSD pkgsrc and Gentoo (Linux) portage document this much better.


Tom

___
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"

poudriere parallel options

[Russell L. Carter]

Greetings,

So recently LibreOffice has been piling up with
various gcc/thunderbird/firefox/chromium/llvm/
openjdk/virtualbox/etc rebuild jobs and the total
time is exceeding 12 hours.

This is on an 8 core AMD box with 32GB of memory
and ample ccache on a fast SSD.  Neither ram nor
swap capacity seem to be a factor.  This behavior
seems like it is somewhat new.  That's ok!

Supposing those packages noted above were the only
items in a ports list file, what would be the best
practice poudriere parallel configuration options?

Or more specifically, is there a way to limit a
particular package's internally managed parallel jobs
to, say, 2?

Thanks,
Russell
___
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"

Bug 215153: sysutils/apcupsd, change default options to enable SNMP driver

[Simon Wright]

Hi all,

I requested this change to sysutils/apcupsd so that it will be 
possible to access/control/monitor UPS's across the network out of 
the box. At present due to the SNMP driver not being enabled in the 
default settings this is not possible.


The maintainer has not responded to the bug or follow-up mails. 
Would any committer be able to look at this suggestion and the 
included patch?


Any feedback appreciated.

Thanks,

Simon.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Ports options in make.conf vs. GSSIAPI

[Stefan Bethke]

> Am 13.01.2017 um 14:12 schrieb Stefan Bethke <s...@lassitu.de>:
> 
> 
>> Am 13.01.2017 um 13:30 schrieb Stefan Bethke <s...@lassitu.de>:
>> 
>> 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
>> 
>> Stop.
>> make: stopped in /freebsd/checkout/ports/dns/bind99
> 
> I swear I’ve looked at this for I don’t know how long, but it’s really 
> trivial:
> 
> Some ports have GSSAPI_BASE as their OPTIONS_DEFAULTS, some have GSSAPI_NONE.
> 
> $ find . -name Makefile | xargs grep 'OPTIONS_DEFAULT=.*GSSAPI_' | sort
> ./databases/mariadb101-server/Makefile:OPTIONS_DEFAULT=   GSSAPI_BASE
> ./dns/bind9-devel/Makefile:OPTIONS_DEFAULT=   SSL THREADS SIGCHASE IDN 
> GSSAPI_NONE JSON
> ./dns/bind910/Makefile:OPTIONS_DEFAULT=   SSL THREADS SIGCHASE IDN 
> GSSAPI_NONE JSON \
> ./dns/bind911/Makefile:OPTIONS_DEFAULT=   SSL THREADS SIGCHASE IDN 
> GSSAPI_NONE JSON
> ./dns/bind99/Makefile:OPTIONS_DEFAULT=SSL THREADS SIGCHASE IDN 
> GSSAPI_NONE RRL DLZ_FILESYSTEM \
> ./mail/dovecot2-pigeonhole/Makefile:OPTIONS_DEFAULT=MANAGESIEVE GSSAPI_NONE
> ./mail/dovecot2/Makefile:OPTIONS_DEFAULT=KQUEUE GSSAPI_NONE
> ./mail/fetchmail/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE
> ./net-mgmt/adcli/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE
> ./security/cyrus-sasl2-gssapi/Makefile:OPTIONS_DEFAULT=   
> GSSAPI_BASE
> ./security/p5-Authen-Krb5-Simple/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE
> ./security/p5-Authen-Krb5/Makefile:OPTIONS_DEFAULT=   GSSAPI_BASE
> ./security/p5-GSSAPI/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE
> ./security/p5-Heimdal-Kadm5/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE
> ./security/py-kerberos/Makefile:OPTIONS_DEFAULT=  GSSAPI_BASE
> ./sysutils/msktutil/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE
> ./www/mod_auth_kerb2/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE
> 
> In order to have only a single GSSAPI option selected, OPTIONS_UNSET must 
> include both:
> OPTIONS_UNSET+=  GSSAPI_BASE GSSAPI_NONE

Here’s a small improvement to bsd.port.mk to print out all the active options 
for OPTION_SINGLEs and OPTION_RADIOs:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216150


Stefan

-- 
Stefan Bethke <s...@lassitu.de>   Fon +49 151 14070811




___
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

[Stefan Bethke]

> Am 13.01.2017 um 13:30 schrieb Stefan Bethke <s...@lassitu.de>:
> 
> 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
> 
> Stop.
> make: stopped in /freebsd/checkout/ports/dns/bind99

I swear I’ve looked at this for I don’t know how long, but it’s really trivial:

Some ports have GSSAPI_BASE as their OPTIONS_DEFAULTS, some have GSSAPI_NONE.

$ find . -name Makefile | xargs grep 'OPTIONS_DEFAULT=.*GSSAPI_' | sort
./databases/mariadb101-server/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE
./dns/bind9-devel/Makefile:OPTIONS_DEFAULT= SSL THREADS SIGCHASE IDN 
GSSAPI_NONE JSON
./dns/bind910/Makefile:OPTIONS_DEFAULT= SSL THREADS SIGCHASE IDN GSSAPI_NONE 
JSON \
./dns/bind911/Makefile:OPTIONS_DEFAULT= SSL THREADS SIGCHASE IDN GSSAPI_NONE 
JSON
./dns/bind99/Makefile:OPTIONS_DEFAULT=  SSL THREADS SIGCHASE IDN GSSAPI_NONE 
RRL DLZ_FILESYSTEM \
./mail/dovecot2-pigeonhole/Makefile:OPTIONS_DEFAULT=MANAGESIEVE GSSAPI_NONE
./mail/dovecot2/Makefile:OPTIONS_DEFAULT=KQUEUE GSSAPI_NONE
./mail/fetchmail/Makefile:OPTIONS_DEFAULT=  GSSAPI_BASE
./net-mgmt/adcli/Makefile:OPTIONS_DEFAULT=  GSSAPI_BASE
./security/cyrus-sasl2-gssapi/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE
./security/p5-Authen-Krb5-Simple/Makefile:OPTIONS_DEFAULT=  GSSAPI_BASE
./security/p5-Authen-Krb5/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE
./security/p5-GSSAPI/Makefile:OPTIONS_DEFAULT=  GSSAPI_BASE
./security/p5-Heimdal-Kadm5/Makefile:OPTIONS_DEFAULT=   GSSAPI_BASE
./security/py-kerberos/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE
./sysutils/msktutil/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE
./www/mod_auth_kerb2/Makefile:OPTIONS_DEFAULT=  GSSAPI_BASE

In order to have only a single GSSAPI option selected, OPTIONS_UNSET must 
include both:
OPTIONS_UNSET+=  GSSAPI_BASE GSSAPI_NONE


Stefan

-- 
Stefan Bethke <s...@lassitu.de>   Fon +49 151 14070811




___
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

[Stefan Bethke]

> 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.

-- 
Stefan Bethke <s...@lassitu.de>   Fon +49 151 14070811

___
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 <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


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"

Ports options in make.conf vs. GSSIAPI

[Stefan Bethke]

I’m having trouble selecting options for ports through make.conf.

For most ports, this works fine.  I have set NO_DIALOG=yes so I can run ports 
commands from scripts and cron without being stuck in a dialog; for those few 
ports where I do need custom options, I set appropriate _SET and _UNSET options 
in make.conf, for example:
graphics_ImageMagick_SET+=  PANGO
graphics_ImageMagick_UNSET+=X11
graphics_ImageMagick7_UNSET+=   X11

However, if I try to do the same with GSSAPI, ports won’t build unless I do 
create a config file for that port.

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

Stop.
make: stopped in /freebsd/checkout/ports/dns/bind99

If I then run make do-config and simply save the config presented, the port 
starts working again as expected.

This appears to affect any port that uses GSSAPI.

I would very much like to be able to build ports without any interaction, and 
since I’m setting config options through make.conf, I’d also prefer not having 
to create ports options files, ever.

Is there some option I’m missing for GSSAPI?  I find the user documentation for 
GSSAPI not very helpful in this regard.  I’ve tried to understand what 
Mk/Uses/gssapi.mk does, but failed.


Stefan

p.s. here’s a slightly condensed version of make.conf that I’m using:

DISTDIR?=   /var/ports/distfiles
WRKDIRPREFIX?=  /var/ports/work
INDEXDIR=   /var/ports
DISABLE_VULNERABILITIES?=   true
NO_DIALOG=  yes
WITH_OPENSSL_PORT=  YES
DEFAULT_VERSIONS+=  bdb=48
DEFAULT_VERSIONS+=  perl5=5.20
DEFAULT_VERSIONS+=  ssl=openssl
OPTIONS_UNSET+=  GSSAPI_BASE
OPTIONS_SET+=GSSAPI_MIT
editors_emacs_UNSET+=   MAGICK
# … more ports options

-- 
Stefan Bethke <s...@lassitu.de>   Fon +49 151 14070811




___
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: poudriere ignores stored options after r429298

[Baptiste Daroussin]

On Sun, Dec 25, 2016 at 05:54:20PM +0100, Stefan Ehmann wrote:
> On 25.12.2016 07:08, Jan Beich wrote:
> > René Ladan <r...@freebsd.org> writes:
> > 
> > > On 24-12-2016 10:09, Stefan Ehmann wrote:
> > > 
> > > > After today's ports update, poudriere ignores all options that were
> > > > previously stored.
> > > > 
> > > > Everything works as before after reverting r429298 "Make the ports
> > > > infrastructure accept at least 3 level ports"
> > > > 
> > > > Previously, poudriere stored its options for python27 in
> > > > /usr/local/etc/poudriere.d/options/lang_python27
> > > > 
> > > > Now options are stored in
> > > > /usr/local/etc/poudriere.d/options/_usr_ports_lang_python27
> > > 
> > > Hmm, it should still store options in the old directory, or did we
> > > overlook something?
> ...
> 
> > > > root@e17:/usr/local/etc/poudriere.d/options/lang_python27 # ls -l
> > > > total 5
> > > > -rw-r--r--  1 root  wheel  406 24 dec. 15:32 options
> > > 
> > > What do 'make -V PKGORIGIN' and 'make -V OPTIONS_NAME' tell?
> > 
> > Perhaps, poudriere invoked |make config| outside of jail where PORTSDIR
> > has a different value.
> 
> Seems like a good guess:
> 
> poudriere sets (at least on my setup) PORTSDIR=/usr/ports/) when invoking
> make config
> 
> Old behavior:
> $ make PORTSDIR=/usr/ports/ -V PKGORIGIN
> lang/python27
> $ make PORTSDIR=/usr/ports/ -V OPTIONS_NAME
> lang_python27
> 
> With D8889.diff applied:
> $ make PORTSDIR=/usr/ports/ -V PKGORIGIN
> /usr/ports/lang/python27
> $ make PORTSDIR=/usr/ports/ -V OPTIONS_NAME
> _usr_ports_lang_python27

The change has been reverted


signature.asc
Description: PGP signature

Re: poudriere ignores stored options after r429298

[Stefan Ehmann]

On 25.12.2016 07:08, Jan Beich wrote:

René Ladan <r...@freebsd.org> writes:


On 24-12-2016 10:09, Stefan Ehmann wrote:


After today's ports update, poudriere ignores all options that were
previously stored.

Everything works as before after reverting r429298 "Make the ports
infrastructure accept at least 3 level ports"

Previously, poudriere stored its options for python27 in
/usr/local/etc/poudriere.d/options/lang_python27

Now options are stored in
/usr/local/etc/poudriere.d/options/_usr_ports_lang_python27


Hmm, it should still store options in the old directory, or did we
overlook something?

...


root@e17:/usr/local/etc/poudriere.d/options/lang_python27 # ls -l
total 5
-rw-r--r--  1 root  wheel  406 24 dec. 15:32 options


What do 'make -V PKGORIGIN' and 'make -V OPTIONS_NAME' tell?


Perhaps, poudriere invoked |make config| outside of jail where PORTSDIR
has a different value.


Seems like a good guess:

poudriere sets (at least on my setup) PORTSDIR=/usr/ports/) when 
invoking make config


Old behavior:
$ make PORTSDIR=/usr/ports/ -V PKGORIGIN
lang/python27
$ make PORTSDIR=/usr/ports/ -V OPTIONS_NAME
lang_python27

With D8889.diff applied:
$ make PORTSDIR=/usr/ports/ -V PKGORIGIN
/usr/ports/lang/python27
$ make PORTSDIR=/usr/ports/ -V OPTIONS_NAME
_usr_ports_lang_python27
___
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: poudriere ignores stored options after r429298

[Jan Beich]

René Ladan <r...@freebsd.org> writes:

> On 24-12-2016 10:09, Stefan Ehmann wrote:
>
>> After today's ports update, poudriere ignores all options that were
>> previously stored.
>> 
>> Everything works as before after reverting r429298 "Make the ports
>> infrastructure accept at least 3 level ports"
>> 
>> Previously, poudriere stored its options for python27 in
>> /usr/local/etc/poudriere.d/options/lang_python27
>> 
>> Now options are stored in
>> /usr/local/etc/poudriere.d/options/_usr_ports_lang_python27
>
> Hmm, it should still store options in the old directory, or did we
> overlook something?

Hmm, I don't like risky infra changes landing just before a new quaterly.
Can you back it out on 2017Q1?

>
> From
> https://reviews.freebsd.org/file/data/aq3dh3bgietiaksqg764/PHID-FILE-abonf7wbxelwjoqv2aiq/D8889.diff
> :
>
> Old:
> -_PORTDIRNAME=${.CURDIR:T}
> -PORTDIRNAME?=${_PORTDIRNAME}
> -PKGORIGIN?=  ${PKGCATEGORY}/${PORTDIRNAME}
> -OPTIONS_NAME?=   ${PKGORIGIN:S/\//_/}
>  OPTIONS_FILE?=   ${PORT_DBDIR}/${OPTIONS_NAME}/options
>
> New:
> +PKGORIGIN?=  ${.CURDIR:C/${PORTSDIR}\///}

Assuming .CURDIR is under PORTSDIR or using absolute pathname violates POLA.
For one, I'm working with multiple forks of the ports tree without adjusting
PORTSDIR value as Mk/* bits are same or compatible. While such a workflow
isn't recommended it guarantees the same options apply to every tree.

> +OPTIONS_NAME?=   ${PKGORIGIN:S/\//_/g}
>  OPTIONS_FILE?=   ${PORT_DBDIR}/${OPTIONS_NAME}/options


>> root@e17:/usr/local/etc/poudriere.d/options/lang_python27 # ls -l
>> total 5
>> -rw-r--r--  1 root  wheel  406 24 dec. 15:32 options
>
> What do 'make -V PKGORIGIN' and 'make -V OPTIONS_NAME' tell?

Perhaps, poudriere invoked |make config| outside of jail where PORTSDIR
has a different value.
___
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"