From Newsgroup: muc.lists.freebsd.ports

I just noticed that a poudriere build of dns/bind920 is compiling
things like ghostscript and cups.... Is that necessary? Can it be
prevented?

Thanks for reading,

bob prohaska



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Hi!

I just noticed that a poudriere build of dns/bind920 is compiling
things like ghostscript and cups.... Is that necessary? Can it be
prevented?

This might help, please test:

make config

DOCS=off
--
pi@FreeBSD.org +49 171 3101372 Now what ?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Thu, Mar 12, 2026 at 04:00:44PM +0100, Kurt Jaeger wrote:

Hi!

I just noticed that a poudriere build of dns/bind920 is compiling
things like ghostscript and cups.... Is that necessary? Can it be prevented?

This might help, please test:

make config

DOCS=off

Apologies for being obtuse, is this part of the poudriere command
or something done directly in /usr/ports? As an aside, I'd like to
have the man pages, it's the GUI-related material that seems a waste
since this is for a headless server. A setting in poudriere.conf
that looks like no-gui=yes or similar would be good.

As an aside, quite a few Linux programs seem to have no man page.
It would be sad if FreeBSD went that route.

Thanks for writing!

bob prohaska



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Hi!

I just noticed that a poudriere build of dns/bind920 is compiling
things like ghostscript and cups.... Is that necessary? Can it be prevented?

This might help, please test:

make config

DOCS=off

Apologies for being obtuse, is this part of the poudriere command
or something done directly in /usr/ports?

This probably can be done in /usr/ports/dns/bind920.

I have not tested all the details, but if poudriere is set up properly,
it should write some entries to:

/var/db/ports/dns_bind920/options

which can be copied to

/usr/local/etc/poudriere.d/options/dns_bind920

to be picked up in the next poudriere run.

As an aside, I'd like to
have the man pages, it's the GUI-related material that seems a waste
since this is for a headless server.

I have not analysed this in full detail, but I'm not sure man pages
and the rest can easily be seperatly build.

As an aside, quite a few Linux programs seem to have no man page.
It would be sad if FreeBSD went that route.

I agree, but this depends on the port and the nitty-gritty details
of the app itself.
--
pi@FreeBSD.org +49 171 3101372 Now what ?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports


--Apple-Mail=_B4E8C52F-73EF-49DA-B5E2-E65F0DA10CC0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii

On Mar 12, 2026, at 16:32, Kurt Jaeger <pi@freebsd.org> wrote:

Hi!

I just noticed that a poudriere build of dns/bind920 is compiling
things like ghostscript and cups.... Is that necessary? Can it be
prevented?

This might help, please test:

make config

DOCS=off

Apologies for being obtuse, is this part of the poudriere command
or something done directly in /usr/ports?

This probably can be done in /usr/ports/dns/bind920.

I have not tested all the details, but if poudriere is set up properly,
it should write some entries to:

/var/db/ports/dns_bind920/options

which can be copied to

/usr/local/etc/poudriere.d/options/dns_bind920

to be picked up in the next poudriere run.

As an aside, I'd like to
have the man pages, it's the GUI-related material that seems a waste
since this is for a headless server.

I have not analysed this in full detail, but I'm not sure man pages
and the rest can easily be seperatly build.

As an aside, quite a few Linux programs seem to have no man page.
It would be sad if FreeBSD went that route.

I agree, but this depends on the port and the nitty-gritty details
of the app itself.

--
pi@FreeBSD.org +49 171 3101372 Now what ?

Easiest would be:

% echo "dns_bind920_UNSET+=DOCS >> /usr/local/etc/poudriere.d/make.conf

Kind regards,
Moin

--Apple-Mail=_B4E8C52F-73EF-49DA-B5E2-E65F0DA10CC0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEETfdREoUGjQZKBS+fvbm1phfAvJEFAmmy5HhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRE Rjc1MTEyODUwNjhEMDY0QTA1MkY5RkJEQjlCNUE2MTdDMEJDOTEACgkQvbm1phfA vJGWlw//fUdJT+zjxx2OmMD3NMXLix4FGWmnpp8zy5H+9WbS+4zuVxxBCh3zSUjy wDedi+ah8o4TbDswVZ5pcZc6c3qlXIQ6vz3GPhgcy72jHqOqbE1kAb+WQEYzRZxO Cb+f89/HauQU4y+UyDN8AbpjNPoMVB/02XP9SUimrUEArpLG2peBFbi0XglD+bQl lQAu/O0U2H21SJKzbIs6/oFJFs0jEXC/edw6XA7XIQLiMiEjZwmNhX2dtOqtxJb3 tsF/83ZY+wwEZOkMeS2Z++tgcls4AjcTgL/p/gvkjwQ2Wlq++t4GmMEp3q1WpGmv oUTaUm/PlhinB5H/pHGLRbKDHySEqaNssWSlDpmq2d8Toeb2asWCwiCbLCDRs6Xy hTa4JeiWLDsZvaWpxFhNBUIjv0jxK3o1oiggepQiphPt9fIvv0jWQRl6MLjfjXT8 cJz24QUizZUaGyoy0FttSBmscKkMESl83DRW5AcGCZs7DcJ85/JP6SPx7pvR/Wqa SlIPbbMa3BZsixwfQjSZ/+WBgJf2qlMIBu74RE+A7un7hp/UYgQEjw+5VJ6fA68D xQmu/a2BHrHWZe9JeM16PgjigHVIL3VkcsEg8evr/62WSFqq3Jtya7n5OLKIaQhA lmm42tV6WQk4PSumLzlpYY5rNE6ubOeS+2oRgDwejZYnP15PvYs=
=EcnX
-----END PGP SIGNATURE-----

--Apple-Mail=_B4E8C52F-73EF-49DA-B5E2-E65F0DA10CC0--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Thu, Mar 12, 2026 at 05:06:16PM +0100, Moin Rahman wrote:

On Mar 12, 2026, at 16:32, Kurt Jaeger <pi@freebsd.org> wrote:

Hi!

I just noticed that a poudriere build of dns/bind920 is compiling
things like ghostscript and cups.... Is that necessary? Can it be
prevented?

This might help, please test:

make config

DOCS=off

Apologies for being obtuse, is this part of the poudriere command
or something done directly in /usr/ports?

This probably can be done in /usr/ports/dns/bind920.

I have not tested all the details, but if poudriere is set up properly,
it should write some entries to:

/var/db/ports/dns_bind920/options

which can be copied to

/usr/local/etc/poudriere.d/options/dns_bind920

to be picked up in the next poudriere run.

As an aside, I'd like to
have the man pages, it's the GUI-related material that seems a waste
since this is for a headless server.

I have not analysed this in full detail, but I'm not sure man pages
and the rest can easily be seperatly build.

As an aside, quite a few Linux programs seem to have no man page.
It would be sad if FreeBSD went that route.

I agree, but this depends on the port and the nitty-gritty details
of the app itself.

--
pi@FreeBSD.org +49 171 3101372 Now what ?

Easiest would be:

% echo "dns_bind920_UNSET+=DOCS >> /usr/local/etc/poudriere.d/make.conf

Hmm, could one substitute

echo "dns_UNSET+=DOCS" >> /usr/local/etc/poudriere.d/make.conf

to make the setting apply to everything in /usr/ports/dns ?

Thanks for writing!

bob prohaska




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 12 Mar 2026, at 16:17, bob prohaska <fbsd@www.zefox.net> wrote:

On Thu, Mar 12, 2026 at 04:00:44PM +0100, Kurt Jaeger wrote:

Hi!

I just noticed that a poudriere build of dns/bind920 is compiling
things like ghostscript and cups.... Is that necessary? Can it be
prevented?

This might help, please test:

make config

DOCS=off

Apologies for being obtuse, is this part of the poudriere command
or something done directly in /usr/ports? As an aside, I'd like to
have the man pages, it's the GUI-related material that seems a waste
since this is for a headless server. A setting in poudriere.conf
that looks like no-gui=yes or similar would be good.

The problem in this case is that the BIND documentation is formatted
using sphinx and Read the Docs, which pulls in a large part of the
python ecosystem, and various graphics rendering programs. These in turn
pull in ghostscript, cups and others.

That said, some ports come with separate DOCS and MANPAGES options, but
this is unfortunately not the case with dns/bind920.

-Dimitry



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports


--Apple-Mail=_C925FD2B-061E-4B87-A428-1C73C33D09BC
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii

On Mar 12, 2026, at 17:37, bob prohaska <fbsd@www.zefox.net> wrote:

On Thu, Mar 12, 2026 at 05:06:16PM +0100, Moin Rahman wrote:

On Mar 12, 2026, at 16:32, Kurt Jaeger <pi@freebsd.org> wrote:

Hi!

I just noticed that a poudriere build of dns/bind920 is compiling
things like ghostscript and cups.... Is that necessary? Can it be
prevented?

This might help, please test:

make config

DOCS=off

Apologies for being obtuse, is this part of the poudriere command
or something done directly in /usr/ports?

This probably can be done in /usr/ports/dns/bind920.

I have not tested all the details, but if poudriere is set up properly,
it should write some entries to:

/var/db/ports/dns_bind920/options

which can be copied to

/usr/local/etc/poudriere.d/options/dns_bind920

to be picked up in the next poudriere run.

As an aside, I'd like to
have the man pages, it's the GUI-related material that seems a waste
since this is for a headless server.

I have not analysed this in full detail, but I'm not sure man pages
and the rest can easily be seperatly build.

As an aside, quite a few Linux programs seem to have no man page.
It would be sad if FreeBSD went that route.

I agree, but this depends on the port and the nitty-gritty details
of the app itself.

--
pi@FreeBSD.org +49 171 3101372 Now what ?

Easiest would be:

% echo "dns_bind920_UNSET+=DOCS >> /usr/local/etc/poudriere.d/make.conf

Hmm, could one substitute

echo "dns_UNSET+=DOCS" >> /usr/local/etc/poudriere.d/make.conf

to make the setting apply to everything in /usr/ports/dns ?

Thanks for writing!

bob prohaska

No. What you are looking for is:

.if ${.CURDIR:M*/dns}
OPTIONS_UNSET+=DOCS
.endif

Kind regards,
Moin

--Apple-Mail=_C925FD2B-061E-4B87-A428-1C73C33D09BC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEETfdREoUGjQZKBS+fvbm1phfAvJEFAmmy7AlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRE Rjc1MTEyODUwNjhEMDY0QTA1MkY5RkJEQjlCNUE2MTdDMEJDOTEACgkQvbm1phfA vJElHQ/8CjtgohRbSuzmPyU12D+voMzwDuT3rbdlpXTM1Dp5HQRZ4w5ggX8YRTy2 +ksdvpAgyZ9+8OxFUPgvZAMDDUh/W3H//olnPNMynP1ibgqqCYDjSEHXR8JCPeXh OsvDFxgJFxVDRpNWZp/3Q7I3bEdF2FjS71pHUbLQXTKImKHvotQWE0H1WokrLca2 dcRQOB8/8einHXuLw/kymY2pVnf8egqVw7f+xJ7qk7TBulLmTXeB+thbEs/lbBZ2 8pv6DnTuxu3htV88fMroEpsuXGW1c4J2ofmEb/gcpb9yY7d1AuGKt1rwFHs2zY5e CTz1PXY/NmGn1vh/YixC2XQxEWWqp7tTwyBr5P/b8p79gPvgXQ8+xnig1StIfSOi jMEjCIvRLd74jDcUa4ZIia2GoPvPo38RYA4cwYmNwiCLHTxYrv8vkkNNyrs3Y+8G WHp2n0yImdFPVzZeKpWwVMjUFo8dCl1BB4OEuGFaXVK9mXj8fZXjd8PpFwbBkon9 O7HTWp/VPpHrtg4e0lzn50R4ve0bt+CVeF0zBY36txLnyyWEkMRe/h9ZhlDvnQR8 agUkD1hGLKk2tFUenrWOkhkgmfctpzRy+B6DxaYPZQu7fERwP/gjAeqIAnCfLWAi 5lsisFXqXIo/hTgGuxEjo/wIBekBIYj8tD5F3Q10UJULQSPAmaE=
=yPl5
-----END PGP SIGNATURE-----

--Apple-Mail=_C925FD2B-061E-4B87-A428-1C73C33D09BC--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Thu, Mar 12, 2026 at 05:38:33PM +0100, Moin Rahman wrote:

On Mar 12, 2026, at 17:37, bob prohaska <fbsd@www.zefox.net> wrote:

On Thu, Mar 12, 2026 at 05:06:16PM +0100, Moin Rahman wrote:

On Mar 12, 2026, at 16:32, Kurt Jaeger <pi@freebsd.org> wrote:

Hi!

I just noticed that a poudriere build of dns/bind920 is compiling >>>>>> things like ghostscript and cups.... Is that necessary? Can it be >>>>>> prevented?

This might help, please test:

make config

DOCS=off

Apologies for being obtuse, is this part of the poudriere command
or something done directly in /usr/ports?

This probably can be done in /usr/ports/dns/bind920.

I have not tested all the details, but if poudriere is set up properly, >>> it should write some entries to:

/var/db/ports/dns_bind920/options

which can be copied to

/usr/local/etc/poudriere.d/options/dns_bind920

to be picked up in the next poudriere run.

As an aside, I'd like to
have the man pages, it's the GUI-related material that seems a waste >>>> since this is for a headless server.

I have not analysed this in full detail, but I'm not sure man pages
and the rest can easily be seperatly build.

As an aside, quite a few Linux programs seem to have no man page.
It would be sad if FreeBSD went that route.

I agree, but this depends on the port and the nitty-gritty details
of the app itself.

--
pi@FreeBSD.org +49 171 3101372 Now what ?

Easiest would be:

% echo "dns_bind920_UNSET+=DOCS >> /usr/local/etc/poudriere.d/make.conf

Hmm, could one substitute

echo "dns_UNSET+=DOCS" >> /usr/local/etc/poudriere.d/make.conf

to make the setting apply to everything in /usr/ports/dns ?

Thanks for writing!

bob prohaska

No. What you are looking for is:

.if ${.CURDIR:M*/dns}
OPTIONS_UNSET+=DOCS
.endif

Something's wrong.
I have
# more /usr/local/etc/poudriere.d/make.conf
.if ${.CURDIR:M*/dns}
OPTIONS_UNSET+=DOCS
.endif

but

# tail bind.log
[00:16:53] [03] [00:00:00] Builder starting
[00:16:53] [04] [00:00:00] Builder starting
[00:20:49] [01] [00:03:57] Builder started
[00:20:49] [04] [00:03:56] Builder started
[00:20:49] [02] [00:03:56] Builder started
[00:20:49] [03] [00:03:56] Builder started
[00:20:49] [02] [00:00:00] Building graphics/poppler | poppler-25.10.0_1 [00:20:49] [01] [00:00:00] Building print/harfbuzz-icu | harfbuzz-icu-12.3.2 [00:20:49] [04] [00:00:00] Building print/texlive-texmf | texlive-texmf-20250308_1
[00:20:49] [03] [00:00:00] Building x11-toolkits/pango | pango-1.56.4_1

after restarting the poudriere bulk session.

Need I go back and clean up in some fashion to extirpate existing DOCS-dependent packages?

Actually, DOCS aren't what to suppress: The need is to suppress GUI-dependency, which imposes huge overhead and compatibility penalties.

Might there be a no-GUI switch somewhere in poudriere?

Interestingly, a second identical host running the same command:
poudriere bulk -j main dns/bind920 dns/bind-tools > bind.log
eventually built both ports but failed to complete all the
GUI-related ports. That seems a bit odd.

Thanks for writing,

bob prohsk


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports


--Apple-Mail=_5C467853-0B49-4736-A0FD-40D0664E2DE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii

On Mar 12, 2026, at 19:22, bob prohaska <fbsd@www.zefox.net> wrote:
=20
On Thu, Mar 12, 2026 at 05:38:33PM +0100, Moin Rahman wrote:

=20
=20

On Mar 12, 2026, at 17:37, bob prohaska <fbsd@www.zefox.net> wrote:
=20
On Thu, Mar 12, 2026 at 05:06:16PM +0100, Moin Rahman wrote:

=20
=20

On Mar 12, 2026, at 16:32, Kurt Jaeger <pi@freebsd.org> wrote:
=20
Hi!
=20

I just noticed that a poudriere build of dns/bind920 is =

compiling

things like ghostscript and cups.... Is that necessary? Can it =

be

prevented?

=20
This might help, please test:
=20
make config
=20
DOCS=3Doff

=20
Apologies for being obtuse, is this part of the poudriere command
or something done directly in /usr/ports?

=20
This probably can be done in /usr/ports/dns/bind920.
=20
I have not tested all the details, but if poudriere is set up =

properly,

it should write some entries to:
=20
/var/db/ports/dns_bind920/options
=20
which can be copied to
=20
/usr/local/etc/poudriere.d/options/dns_bind920
=20
to be picked up in the next poudriere run.
=20

As an aside, I'd like to
have the man pages, it's the GUI-related material that seems a =

waste

since this is for a headless server.

=20
I have not analysed this in full detail, but I'm not sure man =

pages

and the rest can easily be seperatly build.
=20

As an aside, quite a few Linux programs seem to have no man page.
It would be sad if FreeBSD went that route.

=20
I agree, but this depends on the port and the nitty-gritty details
of the app itself.
=20
--=20
pi@FreeBSD.org +49 171 3101372 Now what ? >>>>>=20

=20
Easiest would be:
=20
% echo "dns_bind920_UNSET+=3DDOCS >> = /usr/local/etc/poudriere.d/make.conf
=20

=20
Hmm, could one substitute
=20
echo "dns_UNSET+=3DDOCS" >> /usr/local/etc/poudriere.d/make.conf
=20
to make the setting apply to everything in /usr/ports/dns ?
=20
Thanks for writing!
=20
bob prohaska

=20
No. What you are looking for is:
=20
.if ${.CURDIR:M*/dns}
OPTIONS_UNSET+=3DDOCS
.endif
=20

=20
Something's wrong.=20
I have
# more /usr/local/etc/poudriere.d/make.conf
.if ${.CURDIR:M*/dns}
OPTIONS_UNSET+=3DDOCS
.endif
=20
but
=20
# tail bind.log
[00:16:53] [03] [00:00:00] Builder starting
[00:16:53] [04] [00:00:00] Builder starting
[00:20:49] [01] [00:03:57] Builder started
[00:20:49] [04] [00:03:56] Builder started
[00:20:49] [02] [00:03:56] Builder started
[00:20:49] [03] [00:03:56] Builder started
[00:20:49] [02] [00:00:00] Building graphics/poppler | =

poppler-25.10.0_1

[00:20:49] [01] [00:00:00] Building print/harfbuzz-icu | =

harfbuzz-icu-12.3.2

[00:20:49] [04] [00:00:00] Building print/texlive-texmf | =

texlive-texmf-20250308_1

[00:20:49] [03] [00:00:00] Building x11-toolkits/pango | =

pango-1.56.4_1

=20
after restarting the poudriere bulk session.=20
=20
Need I go back and clean up in some fashion to extirpate existing DOCS-dependent packages?
=20
Actually, DOCS aren't what to suppress: The need is to suppress GUI-dependency, which imposes huge overhead and compatibility =

penalties.

=20
Might there be a no-GUI switch somewhere in poudriere?=20
=20
Interestingly, a second identical host running the same command:
poudriere bulk -j main dns/bind920 dns/bind-tools > bind.log
eventually built both ports but failed to complete all the
GUI-related ports. That seems a bit odd.=20
=20
Thanks for writing,
=20
bob prohsk

I think I mistyped something:

.if ${.CURDIR:M*/dns/*}
OPTIONS_UNSET+=3DDOCS
.endif

This should work.

Kind regards,
Moin


--Apple-Mail=_5C467853-0B49-4736-A0FD-40D0664E2DE0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEETfdREoUGjQZKBS+fvbm1phfAvJEFAmmzDT1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRE Rjc1MTEyODUwNjhEMDY0QTA1MkY5RkJEQjlCNUE2MTdDMEJDOTEACgkQvbm1phfA vJFf6A//TYjn6DmAUu6pRuN3hhY6zVMq4l+6d2mmkE9gn25To9qR/JYVSFN3v/Vk kX1I0osenY92UP7Tisz3PsuEytfd9HKRYpHMiFDlFOLDQpjAKxiy10ree1UzfXjS d6WvaT9E2wbnAbrUKgJPGuThIZ8JzHgiP4gsn5ECJ3d/y4FwPnXoBJyihNaxYhbY IAE/ZueAUGILFdJNld8MQtDt+3Xn2rPL9TtsixG92YWsUom/GG+KEYHMnpdv9s19 GOYgypk4Gk4GoTrlZlBPu0EJyTPaTk4Ea1r53CWtjmuq8M6Swrzg6GnBn8tgHkL1 tde/C/CqdYEinqr56Aepr6xjsPq2AVWehPAbK0sBnqIXeie6JaGvVtbeM5Y++bLB 8TSukXjQYvq5M5qWUaNG85X6vm9lIkYYBX5YWN6ngsAZ1GpJQUSlx9vf3TcyZwWX jn/7COMjteRjLoE32wedD4D+zi2V11GbfRMYFjaD3SkNfJwFPOLnRpg5xd9/okLq QKKepEfXWJrpO8l9pGVMjV7G9dE6n5XLrK9S1NaPqBPWt/p/xbBe6YSTXVh4HP4d NRfm7UqjF5S7MWtWLFgLd/tfbdgGPt0Sy6dj/LrIbQh6bjl2HIC/JkpFis1uW4uI c6NWxvodfH0c2EQ5gVCJ5xcbC/NFl7vN/3oyq9BNSjtb48lRsec=
=wKvk
-----END PGP SIGNATURE-----

--Apple-Mail=_5C467853-0B49-4736-A0FD-40D0664E2DE0--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Thu, Mar 12, 2026 at 08:00:13PM +0100, Moin Rahman wrote:

[long conversation about building bind920 without huge graphics
dependencies omitted]

I think I mistyped something:

.if ${.CURDIR:M*/dns/*}
OPTIONS_UNSET+=DOCS
.endif

This should work.

Seems not, to my eye:
[main-default] [2026-03-12_16h03m32s] [balancing_pool] Queued: 14 Built: 0 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 14 Time: 00:14:23
[00:16:44] Recording filesystem state for prepkg... done
[00:16:48] Building 14 packages using up to 4 builders
[00:16:48] Hit CTRL+t at any time to see build progress and stats
[00:16:48] [01] [00:00:00] Builder starting
[00:16:49] [02] [00:00:00] Builder starting
[00:16:49] [03] [00:00:00] Builder starting
[00:16:49] [04] [00:00:00] Builder starting
[00:20:52] [03] [00:04:03] Builder started
[00:20:52] [04] [00:04:03] Builder started
[00:20:52] [01] [00:04:04] Builder started
[00:20:52] [04] [00:00:00] Building print/texlive-texmf | texlive-texmf-20250308_1
[00:20:52] [01] [00:00:00] Building dns/libidn | libidn-1.43
[00:20:52] [03] [00:00:00] Building graphics/poppler | poppler-25.10.0_1 [00:20:52] [02] [00:04:03] Builder started
[00:20:52] [02] [00:00:00] Building print/harfbuzz-icu | harfbuzz-icu-12.3.2

Maybe I edited the wrong file or added a typo of my own?

bob@pelorus:/usr/local/etc/poudriere.d % more /usr/local/etc/poudriere.d/make.conf

.if ${.CURDIR:M*/dns/*}
OPTIONS_UNSET+=DOCS
.endif

Meanwhile ghostscript just started compiling....

I'll let it run, if I get a usable bind920 that's still useful.

It seems to me that the important distinction is between cli and gui
ports, not whether docs are included in the build..

Might there be a switch for curses compatibility?

Thanks for writing!

bob prohaska



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 3/12/26 11:22, bob prohaska wrote:

On Thu, Mar 12, 2026 at 05:38:33PM +0100, Moin Rahman wrote:

On Mar 12, 2026, at 17:37, bob prohaska <fbsd@www.zefox.net> wrote:

On Thu, Mar 12, 2026 at 05:06:16PM +0100, Moin Rahman wrote:

On Mar 12, 2026, at 16:32, Kurt Jaeger <pi@freebsd.org> wrote:

Hi!

I just noticed that a poudriere build of dns/bind920 is compiling >>>>>>>> things like ghostscript and cups.... Is that necessary? Can it be >>>>>>>> prevented?

This might help, please test:

make config

DOCS=off

Apologies for being obtuse, is this part of the poudriere command
or something done directly in /usr/ports?

This probably can be done in /usr/ports/dns/bind920.

I have not tested all the details, but if poudriere is set up properly, >>>>> it should write some entries to:

/var/db/ports/dns_bind920/options

which can be copied to

/usr/local/etc/poudriere.d/options/dns_bind920

to be picked up in the next poudriere run.

As an aside, I'd like to
have the man pages, it's the GUI-related material that seems a waste >>>>>> since this is for a headless server.

I have not analysed this in full detail, but I'm not sure man pages
and the rest can easily be seperatly build.

As an aside, quite a few Linux programs seem to have no man page.
It would be sad if FreeBSD went that route.

I agree, but this depends on the port and the nitty-gritty details
of the app itself.

--
pi@FreeBSD.org +49 171 3101372 Now what ?

Easiest would be:

% echo "dns_bind920_UNSET+=DOCS >> /usr/local/etc/poudriere.d/make.conf >>>>

Hmm, could one substitute

echo "dns_UNSET+=DOCS" >> /usr/local/etc/poudriere.d/make.conf

to make the setting apply to everything in /usr/ports/dns ?

Thanks for writing!

bob prohaska

No. What you are looking for is:

.if ${.CURDIR:M*/dns}
OPTIONS_UNSET+=DOCS
.endif

Something's wrong.
I have
# more /usr/local/etc/poudriere.d/make.conf
.if ${.CURDIR:M*/dns}
OPTIONS_UNSET+=DOCS
.endif

but

# tail bind.log
[00:16:53] [03] [00:00:00] Builder starting
[00:16:53] [04] [00:00:00] Builder starting
[00:20:49] [01] [00:03:57] Builder started
[00:20:49] [04] [00:03:56] Builder started
[00:20:49] [02] [00:03:56] Builder started
[00:20:49] [03] [00:03:56] Builder started
[00:20:49] [02] [00:00:00] Building graphics/poppler | poppler-25.10.0_1 [00:20:49] [01] [00:00:00] Building print/harfbuzz-icu | harfbuzz-icu-12.3.2 [00:20:49] [04] [00:00:00] Building print/texlive-texmf | texlive-texmf-20250308_1
[00:20:49] [03] [00:00:00] Building x11-toolkits/pango | pango-1.56.4_1

after restarting the poudriere bulk session.

Need I go back and clean up in some fashion to extirpate existing DOCS-dependent packages?

Actually, DOCS aren't what to suppress: The need is to suppress GUI-dependency, which imposes huge overhead and compatibility penalties.

Might there be a no-GUI switch somewhere in poudriere?

Interestingly, a second identical host running the same command:
poudriere bulk -j main dns/bind920 dns/bind-tools > bind.log
eventually built both ports but failed to complete all the
GUI-related ports. That seems a bit odd.

Thanks for writing,

bob prohsk

My old memory (possibly/likely incorrect?) is that the Mk/bsd.options.mk
code:

# Some options are always enabled by default.
. for _opt in DOCS NLS EXAMPLES IPV6
. if ${COMPLETE_OPTIONS_LIST:M${_opt}}
PORT_OPTIONS+= ${_opt}
. endif
. endfor

lead to there being both the explicit OPTIONS_UNSET and an (implicit) OPTIONS_SET for DOCS (when it is defined) and that the explicit
OPTIONS_UNSET did not necessarily work when both were present. My memory
is that it was something like OPTIONS_EXCLUDE that prevented the default enabling by preventing the DOCS option from even being defined.

I also seem to remember running into examples of dependencies sometimes
also having DOCS defined of themselves, leading to tracing down more
than just the thing of direct interest in order for DOCS to not be
enabled to build the thing of direct interest.

In this context, dependencies need not also be under dns/ .

You might try:

.if ${.CURDIR:M*/dns}
OPTIONS_EXCLUDE+=DOCS
.endif

But, even if necessary, it might well prove not sufficient. It might not
be necessary. I just do not remember the full detail or how to find old notes/materials related to when I ran into this area a few times in the
past.

Similar points go for the others: NLS EXAMPLES IPV6

An example might have been my trying to avoid DOCS or one or more of
those for devel/llvm* builds back when otherwise a lang/rust (?) build
ended up as a prerequisite for a while during a major update of some
area before everything got back to normal and rust ended up no longer
involved.
--
===
Mark Millard
marklmi at yahoo.com


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports


--Apple-Mail=_4778A8B3-FD32-454E-8C06-E8BF685AE3EF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii

On Mar 13, 2026, at 01:16, bob prohaska <fbsd@www.zefox.net> wrote:
=20
On Thu, Mar 12, 2026 at 08:00:13PM +0100, Moin Rahman wrote:
=20
[long conversation about building bind920 without huge graphics
dependencies omitted]
=20

I think I mistyped something:
=20
.if ${.CURDIR:M*/dns/*}
OPTIONS_UNSET+=3DDOCS
.endif
=20
This should work.

=20
Seems not, to my eye:
[main-default] [2026-03-12_16h03m32s] [balancing_pool] Queued: 14 =

Built: 0 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 14 =
Time: 00:14:23

[00:16:44] Recording filesystem state for prepkg... done
[00:16:48] Building 14 packages using up to 4 builders
[00:16:48] Hit CTRL+t at any time to see build progress and stats
[00:16:48] [01] [00:00:00] Builder starting
[00:16:49] [02] [00:00:00] Builder starting
[00:16:49] [03] [00:00:00] Builder starting
[00:16:49] [04] [00:00:00] Builder starting
[00:20:52] [03] [00:04:03] Builder started
[00:20:52] [04] [00:04:03] Builder started
[00:20:52] [01] [00:04:04] Builder started
[00:20:52] [04] [00:00:00] Building print/texlive-texmf | =

texlive-texmf-20250308_1

[00:20:52] [01] [00:00:00] Building dns/libidn | libidn-1.43
[00:20:52] [03] [00:00:00] Building graphics/poppler | =

poppler-25.10.0_1

[00:20:52] [02] [00:04:03] Builder started
[00:20:52] [02] [00:00:00] Building print/harfbuzz-icu | =

harfbuzz-icu-12.3.2

=20
Maybe I edited the wrong file or added a typo of my own?=20
=20
bob@pelorus:/usr/local/etc/poudriere.d % more =

/usr/local/etc/poudriere.d/make.conf

=20
.if ${.CURDIR:M*/dns/*}
OPTIONS_UNSET+=3DDOCS
.endif
=20
Meanwhile ghostscript just started compiling....
=20
I'll let it run, if I get a usable bind920 that's still useful.
=20
It seems to me that the important distinction is between cli and gui
ports, not whether docs are included in the build..=20
=20
Might there be a switch for curses compatibility?
=20
Thanks for writing!
=20
bob prohaska
=20
=20

So what you are missing is it turns off DOCS only in dns but there
are other dependencies and I can see that those are actually called
in from devel/protobuf-c rather than anything in dns. If you will
see the buildlog of dns/bind920 you will see that DOCS is turned
off. So maybe try
devel_protobuf-c_UNSET+=3DDOCS

Check if other ports are calling in those one by one.

These are my production server setup:
OPTIONS_SET+=3DBE_NATIVE INSULTS LSOF OPTIMIZED_CFLAGS
OPTIONS_UNSET+=3DALSA BE_FREEBSD BE_STANDARD CUPS DEBUG DOCS DOXYGEN \
DTRACE EXAMPLES GTK2 HTMLDOCS IDN IDN2 INFO \
LADSPA LANG_AF LANG_AK LANG_AM LANG_AR LANG_AST LANG_BB \
LANG_BE LANG_BG LANG_BN LANG_BR LANG_BS LANG_CA LANG_CS \
LANG_CY LANG_DA LANG_DE LANG_EL LANG_EO LANG_ES LANG_ET \
LANG_EU LANG_FA LANG_FI LANG_FR LANG_FY LANG_GA LANG_GB \
LANG_GD LANG_GL LANG_GU LANG_HE LANG_HI LANG_HR LANG_HU \
LANG_ID LANG_IS LANG_IT LANG_JA LANG_JP LANG_KK LANG_KN \
LANG_KO LANG_KU LANG_LG LANG_LK LANG_LT LANG_LV LANG_MAI \
LANG_MK LANG_ML LANG_MN LANG_MR LANG_NB LANG_NL LANG_NN \
LANG_NSO LANG_OR LANG_PA LANG_PBR LANG_PL LANG_PT LANG_RM \
LANG_RO LANG_RU LANG_SA LANG_SC LANG_SE LANG_SI LANG_SK \
LANG_SL LANG_SM LANG_SON LANG_SQ LANG_SR LANG_SV LANG_TA \
LANG_TE LANG_TH LANG_TR LANG_UA LANG_UK LANG_VI LANG_ZA \
LANG_ZU LANG_TW \
NLS OPENMP PDF PDFDOCS PERFSCHM PULSEAUDIO TEST WAYLAND X11

Kind regards,
Moin=

--Apple-Mail=_4778A8B3-FD32-454E-8C06-E8BF685AE3EF
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEETfdREoUGjQZKBS+fvbm1phfAvJEFAmmzu4VfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRE Rjc1MTEyODUwNjhEMDY0QTA1MkY5RkJEQjlCNUE2MTdDMEJDOTEACgkQvbm1phfA vJH2IQ//YULLqRnAI/Vxxhr4Gq65HPMt54jSpxASxELGoZm5lKbxk8uHKj7mGuIA SKpmnp4axMXhrNrcmfLS/nppvDH1bSwUFpY1EVXKpxdml4lDA+gHKrUePkVGrtmj Q1fAWuwGQNFJtC7cS47I41p2n6/jlcn17tOcZ4PYbPstpzhVi5nfJX0i5jida96W E49V8vmQ+fs9spGC7LB0n9sHfthslRKdgu4a/IKwyarhrtXrGXXyPMZRHfNToCrw h7USn5wvIy0kXLpS9fzZlh4X44sCkc7oc5swAkUIlLL3QaoMuNq6C0ShgS40Xa5Z 3E7q/t56d8dfWWTa3adr5XlVCrO83IOx3vNRLF7TafHoQZxdaqgFGZRlYYs4o0Ya VUQjelUB5j2qgeJEvze+oTq3W6nmg+5XBkIn22h0nfN65yMqYtaCSl3fQkHZhKtF j2+9Eyrz+N9FgO1aHFbNQXPCPnE5HQinQxl8RbnzbYZVmYtGf+URLwsvY0tV4MQy IAmcu0s3x7O5yzNzJcRzrAbgbhNTF4+Rw8sCf3RCScS5aVZ8jrNmZ8CFJjSkMArS RvvSAx1T2FRPi5KzkqGJGF4Ctt8+WwH1zJZW7SS1CQQqbQ8Garh2D8Y4gXTj37RF Vjxv8ThEx2FnF8J3pD8/Hw6SHlkwCJjxmci10LJsDcbqYU+UlRE=
=pDG/
-----END PGP SIGNATURE-----

--Apple-Mail=_4778A8B3-FD32-454E-8C06-E8BF685AE3EF--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 13/03/2026 01:16, bob prohaska wrote:

On Thu, Mar 12, 2026 at 08:00:13PM +0100, Moin Rahman wrote:

[...]

bob@pelorus:/usr/local/etc/poudriere.d % more /usr/local/etc/poudriere.d/make.conf

.if ${.CURDIR:M*/dns/*}
OPTIONS_UNSET+=DOCS
.endif

Meanwhile ghostscript just started compiling....

I'll let it run, if I get a usable bind920 that's still useful.

It seems to me that the important distinction is between cli and gui
ports, not whether docs are included in the build..

Might there be a switch for curses compatibility?

Years ago, a similar problem (the long time needed to build dependencies
for documentation) led to the definition of this in our Poudriere setup:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

The resulting packages are for headless machines, build is faster, the resulting packages are smaller, dependency chain is shorter, install and upgrade times are shorter. The disadvantage is that many build
dependencies have different options than in the official repository, so
they cannot be pre-fetched and must also be built.

Kind regards
Miroslav Lachman




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Fri, Mar 13, 2026 at 10:54:02AM +0100, Miroslav Lachman wrote:

Years ago, a similar problem (the long time needed to build dependencies for documentation) led to the definition of this in our Poudriere setup:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

The resulting packages are for headless machines, build is faster, the resulting packages are smaller, dependency chain is shorter, install and upgrade times are shorter.

That's what I'm seeking.

The disadvantage is that many build dependencies
have different options than in the official repository, so they cannot be pre-fetched and must also be built.

Is that another way of saying "Use ports _or_ pkg, not both"?

Thanks for writing!

bob prohaska



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 13/03/2026 18:36, bob prohaska wrote:

On Fri, Mar 13, 2026 at 10:54:02AM +0100, Miroslav Lachman wrote:

Years ago, a similar problem (the long time needed to build dependencies for >> documentation) led to the definition of this in our Poudriere setup:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or
<setname>-make.conf or <tree>-make.conf or...

The resulting packages are for headless machines, build is faster, the
resulting packages are smaller, dependency chain is shorter, install and
upgrade times are shorter.

That's what I'm seeking.

The disadvantage is that many build dependencies
have different options than in the official repository, so they cannot be
pre-fetched and must also be built.

Is that another way of saying "Use ports _or_ pkg, not both"?

You can control it from poudriere.conf, there are variables that will
affect it:

PACKAGE_FETCH_BRANCH=latest PACKAGE_FETCH_URL=pkg+http://pkg.FreeBSD.org/\${ABI}
PACKAGE_FETCH_BLACKLIST=""
PACKAGE_FETCH_WHITELIST="gcc* rust llvm*"

Kind regards
Miroslav Lachman



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Fri, 13 Mar 2026 19:33:46 +0100
Miroslav Lachman <000.fbsd@quip.cz> wrote:

On 13/03/2026 18:36, bob prohaska wrote:

On Fri, Mar 13, 2026 at 10:54:02AM +0100, Miroslav Lachman wrote:

Years ago, a similar problem (the long time needed to build dependencies for
documentation) led to the definition of this in our Poudriere setup:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or
<setname>-make.conf or <tree>-make.conf or...

Just a FYI:
To share default ports tree, configured options and saved distfiles
between bare-metal and poudriere, I have

null mounted ports tree configured with below
poudriere ports -c -f none -M /usr/ports -m null

make /usr/local/etc/poudriere.d/options to be a symlink to
/var/db/ports

make sure "DISTFILES_CACHE=/usr/ports/distfiles" in
/usr/local/etc/poudriere.conf


And if you're using any overlays to be used both for
bare-metal and poudriere, you'll need something like below
in your /etc/make.conf per-overlay. Example below has
2 overlays.

.ifndef POUDRIERE_BUILD_TYPE
OVERLAYS= /usr/local/overlays/kdeguchi/mozc-ports \
/usr/local/overlays/kdeguchi/compiz-reloaded-ports
.endif


I've written up about my poudriere use-case at the time I was on
stable/14 here (now I'm on stable/15, though).

https://brew.bsd.cafe/TomAoki/Tips-and-Tricks/src/branch/main/poudriere/README.md

Not documented there, but I have /usr/local/etc/poudriere.d/make.conf
and /usr/local/etc/poudriere.d/src.conf to be symlinks to each files
in /etc/. This is because my poudriere jail is deditated for local
host only.

The resulting packages are for headless machines, build is faster, the
resulting packages are smaller, dependency chain is shorter, install and >> upgrade times are shorter.

That's what I'm seeking.

The disadvantage is that many build dependencies
have different options than in the official repository, so they cannot be >> pre-fetched and must also be built.

Is that another way of saying "Use ports _or_ pkg, not both"?

You can control it from poudriere.conf, there are variables that will
affect it:

PACKAGE_FETCH_BRANCH=latest PACKAGE_FETCH_URL=pkg+http://pkg.FreeBSD.org/\${ABI} PACKAGE_FETCH_BLACKLIST=""
PACKAGE_FETCH_WHITELIST="gcc* rust llvm*"

Kind regards
Miroslav Lachman

--
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Fri, Mar 13, 2026 at 07:33:46PM +0100, Miroslav Lachman wrote:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or <setname>-make.conf or <tree>-make.conf or...

At the moment I have
# cat /usr/local/etc/poudriere.d/make.conf

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

but poudriere is reporting
# tail *.log
[10:11:33] [04] [00:00:00] Building x11/libXrender | libXrender-0.9.12 [10:26:37] [04] [00:15:04] Finished x11/libXrender | libXrender-0.9.12: Success [10:27:41] [01] [00:16:08] Finished x11/libXext | libXext-1.3.6,1: Success [10:38:32] [03] [00:26:59] Finished x11-toolkits/libXt | libXt-1.3.0,1: Success [10:38:36] [01] [00:00:00] Building x11-toolkits/libXmu | libXmu-1.1.4,1 [10:38:36] [03] [00:00:00] Building x11/libXpm | libXpm-3.5.17_1
[10:54:08] [03] [00:15:32] Finished x11/libXpm | libXpm-3.5.17_1: Success [10:54:53] [01] [00:16:17] Finished x11-toolkits/libXmu | libXmu-1.1.4,1: Success
[10:54:56] [01] [00:00:00] Building x11-toolkits/libXaw | libXaw-1.0.16,2 [11:22:54] [01] [00:27:58] Finished x11-toolkits/libXaw | libXaw-1.0.16,2: Success

Could the leading blank be causing poudriere to ignore the directive?
Did I manage to slip in another typo?

Thanks for your help!

bob prohaska



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 3/15/26 10:11, bob prohaska wrote:

On Fri, Mar 13, 2026 at 07:33:46PM +0100, Miroslav Lachman wrote:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or <setname>-make.conf >> or <tree>-make.conf or...

At the moment I have
# cat /usr/local/etc/poudriere.d/make.conf

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Have you tried either of:

OPTIONS_EXCLUDE+= X11 GUI CUPS DOCS EXAMPLES NLS
or:
OPTIONS_EXCLUDE= X11 GUI CUPS DOCS EXAMPLES NLS

instead in your:

/usr/local/etc/poudriere.d/make.conf

?

but poudriere is reporting
# tail *.log
[10:11:33] [04] [00:00:00] Building x11/libXrender | libXrender-0.9.12 [10:26:37] [04] [00:15:04] Finished x11/libXrender | libXrender-0.9.12: Success
[10:27:41] [01] [00:16:08] Finished x11/libXext | libXext-1.3.6,1: Success [10:38:32] [03] [00:26:59] Finished x11-toolkits/libXt | libXt-1.3.0,1: Success
[10:38:36] [01] [00:00:00] Building x11-toolkits/libXmu | libXmu-1.1.4,1 [10:38:36] [03] [00:00:00] Building x11/libXpm | libXpm-3.5.17_1
[10:54:08] [03] [00:15:32] Finished x11/libXpm | libXpm-3.5.17_1: Success [10:54:53] [01] [00:16:17] Finished x11-toolkits/libXmu | libXmu-1.1.4,1: Success
[10:54:56] [01] [00:00:00] Building x11-toolkits/libXaw | libXaw-1.0.16,2 [11:22:54] [01] [00:27:58] Finished x11-toolkits/libXaw | libXaw-1.0.16,2: Success

Could the leading blank be causing poudriere to ignore the directive?
Did I manage to slip in another typo?

Thanks for your help!

bob prohaska

--
===
Mark Millard
marklmi at yahoo.com


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 15/03/2026 18:11, bob prohaska wrote:

On Fri, Mar 13, 2026 at 07:33:46PM +0100, Miroslav Lachman wrote:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or <setname>-make.conf >> or <tree>-make.conf or...

At the moment I have
# cat /usr/local/etc/poudriere.d/make.conf

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

but poudriere is reporting
# tail *.log
[10:11:33] [04] [00:00:00] Building x11/libXrender | libXrender-0.9.12 [10:26:37] [04] [00:15:04] Finished x11/libXrender | libXrender-0.9.12: Success
[10:27:41] [01] [00:16:08] Finished x11/libXext | libXext-1.3.6,1: Success [10:38:32] [03] [00:26:59] Finished x11-toolkits/libXt | libXt-1.3.0,1: Success
[10:38:36] [01] [00:00:00] Building x11-toolkits/libXmu | libXmu-1.1.4,1 [10:38:36] [03] [00:00:00] Building x11/libXpm | libXpm-3.5.17_1
[10:54:08] [03] [00:15:32] Finished x11/libXpm | libXpm-3.5.17_1: Success [10:54:53] [01] [00:16:17] Finished x11-toolkits/libXmu | libXmu-1.1.4,1: Success
[10:54:56] [01] [00:00:00] Building x11-toolkits/libXaw | libXaw-1.0.16,2 [11:22:54] [01] [00:27:58] Finished x11-toolkits/libXaw | libXaw-1.0.16,2: Success

Could the leading blank be causing poudriere to ignore the directive?
Did I manage to slip in another typo?

The blank should be OK. You can take a look in build log of some package
what options it has detected.

Are you building only bind920 or is it some larger package set? I know
there are some packages pulling X11 libraries unconditionally because
the are needed / are not optional. And some packages have X11 as a user selectable option, but must be set to ON because consumer of this
dependency expect support of X11 from it.

Even with the OPTIONS_UNSET = X11 GUI CUPS DOCS EXAMPLES NLS I still see
these libraries being built.

libX11-1.8.12,1.pkg
libXau-1.0.12.pkg
libXdmcp-1.1.5.pkg
libXext-1.3.6,1.pkg
libXrandr-1.5.4.pkg
libXrender-0.9.12.pkg

Most of the packages are built really without dependency on X11, but I
know there is something pulling it unconditionally. I don't remember now
what it was. Maybe something around Cairo, Poppler (for headless work
with PDF) or something like this.

I tried to track it down now on one of our machines, there is a huge
chain of library dependencies to work with some multimedia content from
the webapp, and something around x265 / libheif needs vulkan-loader
which has the following options set:

Options :
WAYLAND : off
XCB : on
XLIB : on

So it does not uses X11 option, it has XCB and XLIB which pulls libX?? libraries. And I know there are some others on different machines.

The "funny" thing is, all these X libraries are used to fulfill the
needs of ... "ImageMagick7-nox11-7.1.2.11". ImageMagick itself is built
as nox11 because of the OPTIONS_UNSET shown above, but as ImageMagick
has HEIF SET, then there is the chain of libX as I wrote above.

Can't speak about bind920, we don't build it in our Poudriere.

WAYLAND is the next candidate to be added to our OPTIONS_UNSET as more
and more packages have it as an option.

Best regards
Miroslav Lachman



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sun, Mar 15, 2026 at 11:48:56AM -0700, Mark Millard wrote:

On 3/15/26 10:11, bob prohaska wrote:

On Fri, Mar 13, 2026 at 07:33:46PM +0100, Miroslav Lachman wrote:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or <setname>-make.conf
or <tree>-make.conf or...

At the moment I have
# cat /usr/local/etc/poudriere.d/make.conf

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Have you tried either of:

OPTIONS_EXCLUDE+= X11 GUI CUPS DOCS EXAMPLES NLS
or:

OPTIONS_EXCLUDE= X11 GUI CUPS DOCS EXAMPLES NLS

instead in your:

/usr/local/etc/poudriere.d/make.conf

?

I've placed the += form there presently. Poudriere
is still making progress, so I've let it keep going.
Presumably I'll have to update ports to test the change.

Thanks for writing!

bob prohaska

but poudriere is reporting
# tail *.log
[10:11:33] [04] [00:00:00] Building x11/libXrender | libXrender-0.9.12 [10:26:37] [04] [00:15:04] Finished x11/libXrender | libXrender-0.9.12: Success
[10:27:41] [01] [00:16:08] Finished x11/libXext | libXext-1.3.6,1: Success [10:38:32] [03] [00:26:59] Finished x11-toolkits/libXt | libXt-1.3.0,1: Success
[10:38:36] [01] [00:00:00] Building x11-toolkits/libXmu | libXmu-1.1.4,1 [10:38:36] [03] [00:00:00] Building x11/libXpm | libXpm-3.5.17_1
[10:54:08] [03] [00:15:32] Finished x11/libXpm | libXpm-3.5.17_1: Success [10:54:53] [01] [00:16:17] Finished x11-toolkits/libXmu | libXmu-1.1.4,1: Success
[10:54:56] [01] [00:00:00] Building x11-toolkits/libXaw | libXaw-1.0.16,2 [11:22:54] [01] [00:27:58] Finished x11-toolkits/libXaw | libXaw-1.0.16,2: Success

Could the leading blank be causing poudriere to ignore the directive?
Did I manage to slip in another typo?

Thanks for your help!

bob prohaska

--
===
Mark Millard
marklmi at yahoo.com

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sun, Mar 15, 2026 at 09:29:21PM +0100, Miroslav Lachman wrote:

On 15/03/2026 18:11, bob prohaska wrote:

On Fri, Mar 13, 2026 at 07:33:46PM +0100, Miroslav Lachman wrote:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or <setname>-make.conf
or <tree>-make.conf or...

At the moment I have
# cat /usr/local/etc/poudriere.d/make.conf

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

but poudriere is reporting
# tail *.log
[10:11:33] [04] [00:00:00] Building x11/libXrender | libXrender-0.9.12 [10:26:37] [04] [00:15:04] Finished x11/libXrender | libXrender-0.9.12: Success
[10:27:41] [01] [00:16:08] Finished x11/libXext | libXext-1.3.6,1: Success [10:38:32] [03] [00:26:59] Finished x11-toolkits/libXt | libXt-1.3.0,1: Success
[10:38:36] [01] [00:00:00] Building x11-toolkits/libXmu | libXmu-1.1.4,1 [10:38:36] [03] [00:00:00] Building x11/libXpm | libXpm-3.5.17_1
[10:54:08] [03] [00:15:32] Finished x11/libXpm | libXpm-3.5.17_1: Success [10:54:53] [01] [00:16:17] Finished x11-toolkits/libXmu | libXmu-1.1.4,1: Success
[10:54:56] [01] [00:00:00] Building x11-toolkits/libXaw | libXaw-1.0.16,2 [11:22:54] [01] [00:27:58] Finished x11-toolkits/libXaw | libXaw-1.0.16,2: Success

Could the leading blank be causing poudriere to ignore the directive?
Did I manage to slip in another typo?

The blank should be OK. You can take a look in build log of some package
what options it has detected.

Are you building only bind920 or is it some larger package set? I know there are some packages pulling X11 libraries unconditionally because the are needed / are not optional. And some packages have X11 as a user selectable option, but must be set to ON because consumer of this dependency expect support of X11 from it.

I'm building bind-tools and bind920, which far as I know are all
command line only.

Even with the OPTIONS_UNSET = X11 GUI CUPS DOCS EXAMPLES NLS I still see these libraries being built.

libX11-1.8.12,1.pkg
libXau-1.0.12.pkg
libXdmcp-1.1.5.pkg
libXext-1.3.6,1.pkg
libXrandr-1.5.4.pkg
libXrender-0.9.12.pkg

Trying to look for the above packages served up a surprise. If I do
# tail bind.log
[1D:06:09:30] [03] [00:56:39] Finished graphics/jpeg-turbo | jpeg-turbo-3.1.3: Success
[1D:06:09:37] [03] [00:00:00] Building graphics/tiff | tiff-4.7.1
[1D:06:13:18] [02] [00:26:01] Finished x11-fonts/fontconfig | fontconfig-2.17.1,1: Success
[1D:06:36:09] [03] [00:26:32] Finished graphics/tiff | tiff-4.7.1: Success [1D:06:36:13] [02] [00:00:00] Building graphics/webp | webp-1.6.0
[1D:06:42:57] [01] [01:30:06] Finished devel/pcre2 | pcre2-10.47_1: Success [1D:06:43:03] [01] [00:00:01] Building devel/glib20@bootstrap | glib-bootstrap-2.84.4,2
[1D:07:22:17] [02] [00:46:04] Finished graphics/webp | webp-1.6.0: Success [1D:07:22:23] [02] [00:00:01] Building graphics/gd | libgd-2.3.3_13,1 [1D:07:46:52] [02] [00:24:30] Finished graphics/gd | libgd-2.3.3_13,1: Success #
the output makes sense. But if I do

#more bind.log ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
the file looks like it's binary, which I'm reasonably sure it isn't.
Using less explicitly states the file is binary. Maybe this is a bug
in -current that I hadn't noticed until now.....

Most of the packages are built really without dependency on X11, but I know there is something pulling it unconditionally. I don't remember now what it was. Maybe something around Cairo, Poppler (for headless work with PDF) or something like this.

I tried to track it down now on one of our machines, there is a huge chain
of library dependencies to work with some multimedia content from the
webapp, and something around x265 / libheif needs vulkan-loader which has
the following options set:

Options :
WAYLAND : off
XCB : on
XLIB : on

So it does not uses X11 option, it has XCB and XLIB which pulls libX?? libraries. And I know there are some others on different machines.

The "funny" thing is, all these X libraries are used to fulfill the needs of ... "ImageMagick7-nox11-7.1.2.11". ImageMagick itself is built as nox11 because of the OPTIONS_UNSET shown above, but as ImageMagick has HEIF SET, then there is the chain of libX as I wrote above.

Can't speak about bind920, we don't build it in our Poudriere.

Bind920 built using make -DBATCH in /usr/ports/dns seems to run
very quickly, a couple of hours at most. Could poudriere be made
to honor those dependencies?

Thanks for writing!

bob prohaska



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 3/15/26 19:18, bob prohaska wrote:

On Sun, Mar 15, 2026 at 09:29:21PM +0100, Miroslav Lachman wrote:

On 15/03/2026 18:11, bob prohaska wrote:

On Fri, Mar 13, 2026 at 07:33:46PM +0100, Miroslav Lachman wrote:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or <setname>-make.conf
or <tree>-make.conf or...

At the moment I have
# cat /usr/local/etc/poudriere.d/make.conf

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

but poudriere is reporting
# tail *.log
[10:11:33] [04] [00:00:00] Building x11/libXrender | libXrender-0.9.12
[10:26:37] [04] [00:15:04] Finished x11/libXrender | libXrender-0.9.12: Success
[10:27:41] [01] [00:16:08] Finished x11/libXext | libXext-1.3.6,1: Success >>> [10:38:32] [03] [00:26:59] Finished x11-toolkits/libXt | libXt-1.3.0,1: Success
[10:38:36] [01] [00:00:00] Building x11-toolkits/libXmu | libXmu-1.1.4,1 >>> [10:38:36] [03] [00:00:00] Building x11/libXpm | libXpm-3.5.17_1
[10:54:08] [03] [00:15:32] Finished x11/libXpm | libXpm-3.5.17_1: Success >>> [10:54:53] [01] [00:16:17] Finished x11-toolkits/libXmu | libXmu-1.1.4,1: Success
[10:54:56] [01] [00:00:00] Building x11-toolkits/libXaw | libXaw-1.0.16,2 >>> [11:22:54] [01] [00:27:58] Finished x11-toolkits/libXaw | libXaw-1.0.16,2: Success

Could the leading blank be causing poudriere to ignore the directive?
Did I manage to slip in another typo?

The blank should be OK. You can take a look in build log of some package
what options it has detected.

Are you building only bind920 or is it some larger package set? I know there >> are some packages pulling X11 libraries unconditionally because the are
needed / are not optional. And some packages have X11 as a user selectable >> option, but must be set to ON because consumer of this dependency expect
support of X11 from it.

I'm building bind-tools and bind920, which far as I know are all
command line only.

Even with the OPTIONS_UNSET = X11 GUI CUPS DOCS EXAMPLES NLS I still see
these libraries being built.

libX11-1.8.12,1.pkg
libXau-1.0.12.pkg
libXdmcp-1.1.5.pkg
libXext-1.3.6,1.pkg
libXrandr-1.5.4.pkg
libXrender-0.9.12.pkg

Trying to look for the above packages served up a surprise. If I do
# tail bind.log
[1D:06:09:30] [03] [00:56:39] Finished graphics/jpeg-turbo | jpeg-turbo-3.1.3: Success
[1D:06:09:37] [03] [00:00:00] Building graphics/tiff | tiff-4.7.1 [1D:06:13:18] [02] [00:26:01] Finished x11-fonts/fontconfig | fontconfig-2.17.1,1: Success
[1D:06:36:09] [03] [00:26:32] Finished graphics/tiff | tiff-4.7.1: Success [1D:06:36:13] [02] [00:00:00] Building graphics/webp | webp-1.6.0 [1D:06:42:57] [01] [01:30:06] Finished devel/pcre2 | pcre2-10.47_1: Success [1D:06:43:03] [01] [00:00:01] Building devel/glib20@bootstrap | glib-bootstrap-2.84.4,2
[1D:07:22:17] [02] [00:46:04] Finished graphics/webp | webp-1.6.0: Success [1D:07:22:23] [02] [00:00:01] Building graphics/gd | libgd-2.3.3_13,1 [1D:07:46:52] [02] [00:24:30] Finished graphics/gd | libgd-2.3.3_13,1: Success
#
the output makes sense. But if I do

#more bind.log ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
the file looks like it's binary, which I'm reasonably sure it isn't.

Try?:

# file bind.log

# head bind.log

(There are other programs for looking at files that have arbitrary byte
values. I'll note try to list them here.)

tail could be simply skipping past the null characters before finding
the last lines (the ones to be displayed).

A null character in a file is enough to make it be classified as binary
as I remember.

Finding how null characters got into what should have been a text file
could lead to FreeBSD OS problems or to program problems (or both).

Using less explicitly states the file is binary. Maybe this is a bug
in -current that I hadn't noticed until now.....

Most of the packages are built really without dependency on X11, but I know >> there is something pulling it unconditionally. I don't remember now what it >> was. Maybe something around Cairo, Poppler (for headless work with PDF) or >> something like this.

I tried to track it down now on one of our machines, there is a huge chain >> of library dependencies to work with some multimedia content from the
webapp, and something around x265 / libheif needs vulkan-loader which has
the following options set:

Options :
WAYLAND : off
XCB : on
XLIB : on

So it does not uses X11 option, it has XCB and XLIB which pulls libX??
libraries. And I know there are some others on different machines.

The "funny" thing is, all these X libraries are used to fulfill the needs of >> ... "ImageMagick7-nox11-7.1.2.11". ImageMagick itself is built as nox11
because of the OPTIONS_UNSET shown above, but as ImageMagick has HEIF SET, >> then there is the chain of libX as I wrote above.

Can't speak about bind920, we don't build it in our Poudriere.

Bind920 built using make -DBATCH in /usr/ports/dns seems to run
very quickly, a couple of hours at most. Could poudriere be made
to honor those dependencies?

Thanks for writing!

bob prohaska

--
===
Mark Millard
marklmi at yahoo.com


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 3/15/26 20:10, Mark Millard wrote:

On 3/15/26 19:18, bob prohaska wrote:

On Sun, Mar 15, 2026 at 09:29:21PM +0100, Miroslav Lachman wrote:

On 15/03/2026 18:11, bob prohaska wrote:

On Fri, Mar 13, 2026 at 07:33:46PM +0100, Miroslav Lachman wrote:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or <setname>-make.conf
or <tree>-make.conf or...

At the moment I have
# cat /usr/local/etc/poudriere.d/make.conf

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

but poudriere is reporting
# tail *.log
[10:11:33] [04] [00:00:00] Building x11/libXrender | libXrender-0.9.12 >>>> [10:26:37] [04] [00:15:04] Finished x11/libXrender | libXrender-0.9.12: Success
[10:27:41] [01] [00:16:08] Finished x11/libXext | libXext-1.3.6,1: Success >>>> [10:38:32] [03] [00:26:59] Finished x11-toolkits/libXt | libXt-1.3.0,1: Success
[10:38:36] [01] [00:00:00] Building x11-toolkits/libXmu | libXmu-1.1.4,1 >>>> [10:38:36] [03] [00:00:00] Building x11/libXpm | libXpm-3.5.17_1
[10:54:08] [03] [00:15:32] Finished x11/libXpm | libXpm-3.5.17_1: Success >>>> [10:54:53] [01] [00:16:17] Finished x11-toolkits/libXmu | libXmu-1.1.4,1: Success
[10:54:56] [01] [00:00:00] Building x11-toolkits/libXaw | libXaw-1.0.16,2 >>>> [11:22:54] [01] [00:27:58] Finished x11-toolkits/libXaw | libXaw-1.0.16,2: Success

Could the leading blank be causing poudriere to ignore the directive?
Did I manage to slip in another typo?

The blank should be OK. You can take a look in build log of some package >>> what options it has detected.

Are you building only bind920 or is it some larger package set? I know there
are some packages pulling X11 libraries unconditionally because the are
needed / are not optional. And some packages have X11 as a user selectable >>> option, but must be set to ON because consumer of this dependency expect >>> support of X11 from it.

I'm building bind-tools and bind920, which far as I know are all
command line only.

Even with the OPTIONS_UNSET = X11 GUI CUPS DOCS EXAMPLES NLS I still see >>> these libraries being built.

libX11-1.8.12,1.pkg
libXau-1.0.12.pkg
libXdmcp-1.1.5.pkg
libXext-1.3.6,1.pkg
libXrandr-1.5.4.pkg
libXrender-0.9.12.pkg

Trying to look for the above packages served up a surprise. If I do
# tail bind.log
[1D:06:09:30] [03] [00:56:39] Finished graphics/jpeg-turbo | jpeg-turbo-3.1.3: Success
[1D:06:09:37] [03] [00:00:00] Building graphics/tiff | tiff-4.7.1
[1D:06:13:18] [02] [00:26:01] Finished x11-fonts/fontconfig | fontconfig-2.17.1,1: Success
[1D:06:36:09] [03] [00:26:32] Finished graphics/tiff | tiff-4.7.1: Success >> [1D:06:36:13] [02] [00:00:00] Building graphics/webp | webp-1.6.0
[1D:06:42:57] [01] [01:30:06] Finished devel/pcre2 | pcre2-10.47_1: Success >> [1D:06:43:03] [01] [00:00:01] Building devel/glib20@bootstrap | glib-bootstrap-2.84.4,2
[1D:07:22:17] [02] [00:46:04] Finished graphics/webp | webp-1.6.0: Success >> [1D:07:22:23] [02] [00:00:01] Building graphics/gd | libgd-2.3.3_13,1
[1D:07:46:52] [02] [00:24:30] Finished graphics/gd | libgd-2.3.3_13,1: Success
#
the output makes sense. But if I do

#more bind.log
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
the file looks like it's binary, which I'm reasonably sure it isn't.

Try?:

# file bind.log

# head bind.log

(There are other programs for looking at files that have arbitrary byte values. I'll note try to list them here.)

tail could be simply skipping past the null characters before finding
the last lines (the ones to be displayed).

A null character in a file is enough to make it be classified as binary
as I remember.

Finding how null characters got into what should have been a text file
could lead to FreeBSD OS problems or to program problems (or both).

I left out media failures as another possibility. System crashes or
power loss while writing to the media was active might be another.

There might be no evidence to use to figure which specific sort of
failure it was.

Using less explicitly states the file is binary. Maybe this is a bug
in -current that I hadn't noticed until now.....

Most of the packages are built really without dependency on X11, but I know >>> there is something pulling it unconditionally. I don't remember now what it >>> was. Maybe something around Cairo, Poppler (for headless work with PDF) or >>> something like this.

I tried to track it down now on one of our machines, there is a huge chain >>> of library dependencies to work with some multimedia content from the
webapp, and something around x265 / libheif needs vulkan-loader which has >>> the following options set:

Options :
WAYLAND : off
XCB : on
XLIB : on

So it does not uses X11 option, it has XCB and XLIB which pulls libX??
libraries. And I know there are some others on different machines.

The "funny" thing is, all these X libraries are used to fulfill the needs of
... "ImageMagick7-nox11-7.1.2.11". ImageMagick itself is built as nox11
because of the OPTIONS_UNSET shown above, but as ImageMagick has HEIF SET, >>> then there is the chain of libX as I wrote above.

Can't speak about bind920, we don't build it in our Poudriere.

Bind920 built using make -DBATCH in /usr/ports/dns seems to run
very quickly, a couple of hours at most. Could poudriere be made
to honor those dependencies?

Thanks for writing!

bob prohaska

--
===
Mark Millard
marklmi at yahoo.com


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sun, Mar 15, 2026 at 08:10:11PM -0700, Mark Millard wrote:

On 3/15/26 19:18, bob prohaska wrote:

On Sun, Mar 15, 2026 at 09:29:21PM +0100, Miroslav Lachman wrote:

On 15/03/2026 18:11, bob prohaska wrote:

On Fri, Mar 13, 2026 at 07:33:46PM +0100, Miroslav Lachman wrote:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or <setname>-make.conf
or <tree>-make.conf or...

At the moment I have
# cat /usr/local/etc/poudriere.d/make.conf

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

but poudriere is reporting
# tail *.log
[10:11:33] [04] [00:00:00] Building x11/libXrender | libXrender-0.9.12 >>> [10:26:37] [04] [00:15:04] Finished x11/libXrender | libXrender-0.9.12: Success
[10:27:41] [01] [00:16:08] Finished x11/libXext | libXext-1.3.6,1: Success
[10:38:32] [03] [00:26:59] Finished x11-toolkits/libXt | libXt-1.3.0,1: Success
[10:38:36] [01] [00:00:00] Building x11-toolkits/libXmu | libXmu-1.1.4,1 >>> [10:38:36] [03] [00:00:00] Building x11/libXpm | libXpm-3.5.17_1
[10:54:08] [03] [00:15:32] Finished x11/libXpm | libXpm-3.5.17_1: Success >>> [10:54:53] [01] [00:16:17] Finished x11-toolkits/libXmu | libXmu-1.1.4,1: Success
[10:54:56] [01] [00:00:00] Building x11-toolkits/libXaw | libXaw-1.0.16,2 >>> [11:22:54] [01] [00:27:58] Finished x11-toolkits/libXaw | libXaw-1.0.16,2: Success

Could the leading blank be causing poudriere to ignore the directive?
Did I manage to slip in another typo?

The blank should be OK. You can take a look in build log of some package >> what options it has detected.

Are you building only bind920 or is it some larger package set? I know there
are some packages pulling X11 libraries unconditionally because the are
needed / are not optional. And some packages have X11 as a user selectable >> option, but must be set to ON because consumer of this dependency expect >> support of X11 from it.

I'm building bind-tools and bind920, which far as I know are all
command line only.

Even with the OPTIONS_UNSET = X11 GUI CUPS DOCS EXAMPLES NLS I still see >> these libraries being built.

libX11-1.8.12,1.pkg
libXau-1.0.12.pkg
libXdmcp-1.1.5.pkg
libXext-1.3.6,1.pkg
libXrandr-1.5.4.pkg
libXrender-0.9.12.pkg

Trying to look for the above packages served up a surprise. If I do
# tail bind.log
[1D:06:09:30] [03] [00:56:39] Finished graphics/jpeg-turbo | jpeg-turbo-3.1.3: Success
[1D:06:09:37] [03] [00:00:00] Building graphics/tiff | tiff-4.7.1 [1D:06:13:18] [02] [00:26:01] Finished x11-fonts/fontconfig | fontconfig-2.17.1,1: Success
[1D:06:36:09] [03] [00:26:32] Finished graphics/tiff | tiff-4.7.1: Success [1D:06:36:13] [02] [00:00:00] Building graphics/webp | webp-1.6.0 [1D:06:42:57] [01] [01:30:06] Finished devel/pcre2 | pcre2-10.47_1: Success [1D:06:43:03] [01] [00:00:01] Building devel/glib20@bootstrap | glib-bootstrap-2.84.4,2
[1D:07:22:17] [02] [00:46:04] Finished graphics/webp | webp-1.6.0: Success [1D:07:22:23] [02] [00:00:01] Building graphics/gd | libgd-2.3.3_13,1 [1D:07:46:52] [02] [00:24:30] Finished graphics/gd | libgd-2.3.3_13,1: Success
#
the output makes sense. But if I do

#more bind.log ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
the file looks like it's binary, which I'm reasonably sure it isn't.

Try?:

# file bind.log

bob@pelorus:/usr/local/poudriere % file bind.log
bind.log: data

# head bind.log

bob@pelorus:/usr/local/poudriere % head bind.log
[06:43:28] [02] [00:08:20] Finished misc/help2man | help2man-1.49.3_1: Success ^^^^^^^^^^
it looks like the beginning of the file was simply skipped by head

It was my fault; I inadvertently started a duplicate poudriere build
command that overwrote the beginning of the log file, subsequently
killing the separate session after reallizing what I'd done. The
first session meanwhile kept running. The result is still a bit odd:

The command to poudriere was
poudriere bulk -j main dns/bind920 dns/bind-tools > bind.log

So, two different PIDs writing to the same file. Isn't there some
mechanism to keep that from happening?

(There are other programs for looking at files that have arbitrary byte values. I'll note try to list them here.)

tail could be simply skipping past the null characters before finding
the last lines (the ones to be displayed).

That seems to be exactly what happened.

A null character in a file is enough to make it be classified as binary
as I remember.

Finding how null characters got into what should have been a text file
could lead to FreeBSD OS problems or to program problems (or both).

Primarily this was my error. Whether the system should have reported
it as an error is less clear to me.

Using less explicitly states the file is binary. Maybe this is a bug
in -current that I hadn't noticed until now.....

The greater bug is the bum on the seat, but there might be a lesser
weevil in the second PID not noticing it's writing to a file owned
by another, older process.


Thanks for writing!

bob prohaska


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports


--ydGXIYe37wJalhw/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 16, 2026 at 06:59:54AM -0700, bob prohaska wrote:

On Sun, Mar 15, 2026 at 08:10:11PM -0700, Mark Millard wrote:

On 3/15/26 19:18, bob prohaska wrote:

On Sun, Mar 15, 2026 at 09:29:21PM +0100, Miroslav Lachman wrote:

On 15/03/2026 18:11, bob prohaska wrote:

On Fri, Mar 13, 2026 at 07:33:46PM +0100, Miroslav Lachman wrote: >>>>>>

OPTIONS_UNSET=3D X11 GUI CUPS DOCS EXAMPLES NLS

Placed in /usr/local/etc/poudriere.conf ?

It should be in /usr/local/etc/poudriere.d/make.conf or <setname>-=

make.conf

or <tree>-make.conf or...

At the moment I have
# cat /usr/local/etc/poudriere.d/make.conf

OPTIONS_UNSET=3D X11 GUI CUPS DOCS EXAMPLES NLS

but poudriere is reporting
# tail *.log
[10:11:33] [04] [00:00:00] Building x11/libXrender | libXrender-0.9=

=2E12

[10:26:37] [04] [00:15:04] Finished x11/libXrender | libXrender-0.9=

=2E12: Success

[10:27:41] [01] [00:16:08] Finished x11/libXext | libXext-1.3.6,1: =

Success

[10:38:32] [03] [00:26:59] Finished x11-toolkits/libXt | libXt-1.3.=

0,1: Success

[10:38:36] [01] [00:00:00] Building x11-toolkits/libXmu | libXmu-1.=

1.4,1

[10:38:36] [03] [00:00:00] Building x11/libXpm | libXpm-3.5.17_1
[10:54:08] [03] [00:15:32] Finished x11/libXpm | libXpm-3.5.17_1: S=

uccess

[10:54:53] [01] [00:16:17] Finished x11-toolkits/libXmu | libXmu-1.=

1.4,1: Success

[10:54:56] [01] [00:00:00] Building x11-toolkits/libXaw | libXaw-1.=

0.16,2

[11:22:54] [01] [00:27:58] Finished x11-toolkits/libXaw | libXaw-1.=

0.16,2: Success

Could the leading blank be causing poudriere to ignore the directiv=

e?

Did I manage to slip in another typo?

The blank should be OK. You can take a look in build log of some pac=

kage

what options it has detected.

Are you building only bind920 or is it some larger package set? I kn=

ow there

are some packages pulling X11 libraries unconditionally because the =

are

needed / are not optional. And some packages have X11 as a user sele=

ctable

option, but must be set to ON because consumer of this dependency ex=

pect

support of X11 from it.

I'm building bind-tools and bind920, which far as I know are all=20 command line only.=20
=20

Even with the OPTIONS_UNSET =3D X11 GUI CUPS DOCS EXAMPLES NLS I sti=

ll see

these libraries being built.

libX11-1.8.12,1.pkg
libXau-1.0.12.pkg
libXdmcp-1.1.5.pkg
libXext-1.3.6,1.pkg
libXrandr-1.5.4.pkg
libXrender-0.9.12.pkg

=20
Trying to look for the above packages served up a surprise. If I do
# tail bind.log
[1D:06:09:30] [03] [00:56:39] Finished graphics/jpeg-turbo | jpeg-tur=

bo-3.1.3: Success

[1D:06:09:37] [03] [00:00:00] Building graphics/tiff | tiff-4.7.1 [1D:06:13:18] [02] [00:26:01] Finished x11-fonts/fontconfig | fontcon=

fig-2.17.1,1: Success

[1D:06:36:09] [03] [00:26:32] Finished graphics/tiff | tiff-4.7.1: Su=

ccess

[1D:06:36:13] [02] [00:00:00] Building graphics/webp | webp-1.6.0 [1D:06:42:57] [01] [01:30:06] Finished devel/pcre2 | pcre2-10.47_1: S=

uccess

[1D:06:43:03] [01] [00:00:01] Building devel/glib20@bootstrap | glib-=

bootstrap-2.84.4,2

[1D:07:22:17] [02] [00:46:04] Finished graphics/webp | webp-1.6.0: Su=

ccess

[1D:07:22:23] [02] [00:00:01] Building graphics/gd | libgd-2.3.3_13,1 [1D:07:46:52] [02] [00:24:30] Finished graphics/gd | libgd-2.3.3_13,1=

: Success

#=20
the output makes sense. But if I do
=20
#more bind.log ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^=

@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@= ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^= @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@= ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

the file looks like it's binary, which I'm reasonably sure it isn't.

=20
Try?:
=20
# file bind.log

=20
bob@pelorus:/usr/local/poudriere % file bind.log
bind.log: data
=20
=20
=20
=20

# head bind.log

=20
bob@pelorus:/usr/local/poudriere % head bind.log
[06:43:28] [02] [00:08:20] Finished misc/help2man | help2man-1.49.3_1: Su=

ccess

^^^^^^^^^^
it looks like the beginning of the file was simply skipped by head

Not really; I think head displayed all the null bytes, they simply do not
show in a pseudo-terminal. Try this:

dd if=3D/dev/zero bs=3D512 count=3D1 > zeroes.bin
cat zeroes.bin
head zeroes.bin

If you pipe the output of head to e.g. od or hexdump or something, you will probably see all the null bytes.

G'luck,
Peter

--=20
Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com
PGP key: https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

--ydGXIYe37wJalhw/
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmm5hSkACgkQZR7vsCUn 3xM+kg//ckTjOg0YYEm74in/Cwg4ttkUe64kn1Wb8/5PFBFiw62Yalg1SoQOhmjt xeTY6Qg3D4kp3cRfHKZN3hyjMiq5zJ7B+Dt+Kl+29RMjO2ov/32gVn0RyPtKWvWK XzJEbE+FfMs/kXUeRot2uIiD31qZYulqNsYS9LuwYl/H/5npmqa7oUwVhDzah1dh 9TDPw8TztoL+ZbsXsjFTXt39CvqMYVLPkOMunSKhVJd43U2ucbEMWqk4k+rNwa7f I4+hx9pyeFVW0IkuF4z9ijxOAj+fF1X+3Mu5yhjfabD4vyj66+5YUzJ+1ZYxY5E+ 2gUEcoD3UpbDTcbwjlSEzYrJh9HE9zMj+o48BFbKQH8P3Stx//toAEVUvAdxle6p 7hIqt6JYL87j7PN4sL6maZYu2iJlVQ2gDqejApVZlk5tbrrRYweDXn4/KQZpU2Ki lpavgSmBiv6R5tOe5+VoT3GlRmgfRDq9ysD6UQz5k7ehdSx3u4r4QjqCP40BwYdb PMEK3kOtjewhu5oe6xVsMr8VVb9DOx8ALalym8kfBqqDY534ZMSFww48pkXS7gAQ D09mbF+5EnWb4X2jtsV5jW6RWRXM+AvA2rlE2JmfKQ3bT0EBXO2M3LWFV5cGBmmV qP5lhgerGczXuHdfolpYcRoP6nXIAcSzMPSzzFpi8cGBGZ1EaIw=
=f+Ov
-----END PGP SIGNATURE-----

--ydGXIYe37wJalhw/--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21d-Linux NewsLink 1.2