Re: Dependencies satisfied, build stops anyway.

2017-11-26 Thread bob prohaska 
On Sat, Nov 25, 2017 at 11:38:41PM -0800, Kevin Oberman wrote:
> Bob,
> 
> BATCH is not deprecated, but it's "portmaster -mBATCH x11/xorg". You also
> don't need to cd to the port directory for portmaster.
> BATCH is a make variable. (See man portmaster). Ihave not used BATCH in a
> while. It is possible that you need "-mBATCH=yes".
> 
The command running is 
make -DBATCH
in /usr/ports/x11/xorg. Portmaster simply didn't run, whether in
/usr/ports or /usr/ports/x11/xorg.   
 
This morning, there was a dialog box asking if llvm4 should be built. Knowing
that the system already uses llvm5 I unselected all the boxes and hit ok.
The system reported downloading llvm4, but then promptly moved on to to other
software, so I am doubtful it actually did anything with the files.  

Altogether it seems that ports building has changed significantly. Whether
it's intrinsic to ports, or an artifact of my system, is unclear.
The change seems to have occurred around the armv6/v7 split, but that bears
no obvious connection. It also coincides with the use of /tmp directories
for compilation, which might be more relevant. If this isn't a local problem
it seemingly must be arm or possibly rpi2-related.  

Thanks again for reading!

bob prohaska

> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> 
> On Sat, Nov 25, 2017 at 11:18 PM, bob prohaska  wrote:
> 
> > On Sat, Nov 25, 2017 at 10:03:02PM -0800, Kevin Oberman wrote:
> > > On Sat, Nov 25, 2017 at 10:54 AM, bob prohaska 
> > wrote:
> > >
> > >
> > > > Perhaps it's time  to eliminate all record of installed ports,
> > > > given that the ports management tools don't seem to work correctly,
> > > > and start over. Is emptying /usr/local and /var/db/pkg sufficient?
> > > > There's no customization of value on the system.
> > > >
> > >
> > > Yes, I would expect that to work. It may leave some odds and ends
> > hanging,
> > > as it is not the way it is normally done.
> > >
> > There still seems to be something wrong. /usr/local and /var/db/pkg are
> > both empty. Make install worked finished successfully for both pkg and
> > portmaster, but running portmaster in /usr/ports/x11/xorg produced
> >
> > root@www:/usr/ports # cd x11/xorg
> > root@www:/usr/ports/x11/xorg # portmaster
> >
> > ===>>> Port directory: /usr/ports/x11/xorg
> >
> > ===>>> Gathering distinfo list for installed ports
> >
> > ===>  Creating some important subdirectories
> > ===>  Starting chrooted make in /...
> > ===>  Chrooted make in / succeeded
> > ===>  Cleaning up...
> > ===>>> Gathering dependency list for x11/xorg from ports
> >
> > ===>>> Cannot cd to /tmp/mountpoint.mcNbXH/graphics/mesa-dri
> > ===>>> Aborting update
> >
> > Thinking there might be a collision problem between old files in /tmp
> > I cleared all the mountpoint.xx files, to no avail.
> >
> > Subsequently using make -DBATCH in /usr/ports/x11/xorg seems to be
> > running a successful attempt, but for some reason configuration
> > dialogs are still showing up. Is the -DBATCH flag deprecated?
> >
> > > They do cooperate in most regards as both call pkg (or pkg-static) to do
> > > the pkg related work and portmaster executes "make" with appropriate
> > > arguments. The one real difference that you have seen is the portmaster
> > > keeps a copy of the distinfo file for all ports it installs so it can do
> > > the --clean-distfiles. That is something other tools can't do, but it is
> > > not critical. I generally use portmaster, but, when I am hiting problems,
> > > will use make(1) to build the port and then use "portmaster -C" to finish
> > > the installation.
> > >
> >
> > That seems like a good approach. If the xorg build completes I'll try it.
> >
> > Thanks for all your counsel!
> >
> > bob prohaska
> >
> >
___
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: RTTI support in devel/llvm40 (and maybe other llvm ports)

2017-11-26 Thread Alexey Dokuchaev 
On Sun, Nov 12, 2017 at 07:41:04PM +0700, Alexey Dokuchaev wrote:
> On Sun, Nov 12, 2017 at 08:03:19AM +, Brooks Davis wrote:
> > On Fri, Nov 10, 2017 at 02:07:48PM +0700, Alexey Dokuchaev wrote:
> > > I've just found out that our `devel/llvm40' port comes without
> > > -DLLVM_ENABLE_RTTI=ON on the CMAKE_ARGS.  This is a regression
> > > from e.g. 3.4 times when it was enabled by default.
> > > 
> > > The problem is that RTTI support is required by some consumers,
> > > e.g. `graphics/openshadinglanguage' and `graphics/appleseed'
> > > (cf. https://github.com/appleseedhq/appleseed/issues/1625),
> > > but I cannot enable RTTI in those ports unless I enable it in
> > > LLVM port(s) first.
> > 
> > It's been a few years since we disabled it so I don't remember the
> > details of the decision.  I'll look into it, but am not in a position
> > to test for breakage to other ports.
> 
> Well it's probably OK to expect users or maintainers of those ports
> would speak up if enabling RTTI breaks their software. :-)
> 
> > IIRC there were once ports that failed to build both with and
> > without so it may be that we need to wait for flavors to make this
> > change.
> 
> Hmm, that's weird: I'd expect it is easier to *not* use RTTI when
> one does not need it than try to find the way around when it is not
> available (which might not be possible).  I also don't see why we
> should wait for FLAVORS: if needed, we can always make it optional
> (cf. existing EXTRAS LIT LLD LLDB options) but enabled by default.

Did you have a chance to make up your mind on this?  (If you worry
that enabling RTTI might break some ports we can always ask portmgr@
for an exp-run).

./danfe
___
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: Time for a firefox-56 port?

2017-11-26 Thread Kurt Jaeger 
Hi!

> I'm sure I'm not the only person who relies on old addons.  How about
> a firefox-56 port until the current problems die down?
> 
> 
> Here is a port for the Palemoon browser:
> 
>   https://www.freshports.org/www/palemoon/

And thank you for that! It works much better than firefox in most cases.

-- 
p...@opsec.eu+49 171 3101372 3 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"

Re: Procmail Vulnerabilities check

2017-11-26 Thread Adam Weinberger 
> On 26 Nov, 2017, at 6:25, andrew clarke  wrote:
> 
> On Sat 2017-11-25 22:20:13 UTC-0500, Kevin P. Neal (k...@neutralgood.org) 
> wrote:
> 
>> Is that the consensus to replace use of procmail with maildrop?
>> 
>> A little googling makes it look like maildrop has the easy integration
>> with sendmail just like procmail. But is maildrop going to be around for
>> the next, oh, 20 years like procmail was?
> 
> maildrop began circa 1999 and is part of the Courier Mail Server
> software. procmail began circa 1990. Arguably both are due for a
> modern replacement, although at least maildrop does not suffer from
> vulnerabilities, afaik.

Sieve (ex. dovecot-pigeonhole) is the modern replacement.

# 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: Procmail Vulnerabilities check

2017-11-26 Thread andrew clarke 
On Sat 2017-11-25 22:20:13 UTC-0500, Kevin P. Neal (k...@neutralgood.org) wrote:

> Is that the consensus to replace use of procmail with maildrop?
> 
> A little googling makes it look like maildrop has the easy integration
> with sendmail just like procmail. But is maildrop going to be around for
> the next, oh, 20 years like procmail was?

maildrop began circa 1999 and is part of the Courier Mail Server
software. procmail began circa 1990. Arguably both are due for a
modern replacement, although at least maildrop does not suffer from
vulnerabilities, afaik.

I migrated from procmail to maildrop a few years ago. My only real
gripe with it is that it doesn't create Maildir subdirectories
automatically, so you have to call 'maildirmake' from within each
filter rule (but only if the subdirectory doesn't already exist!)
making each maildroprc filter more complicated than necessary.
___
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: Time for a firefox-56 port?

2017-11-26 Thread andrew clarke 
On Fri 2017-11-24 12:11:04 UTC+1100, Greg 'groggy' Lehey (g...@freebsd.org) 
wrote:

> I'm sure I'm not the only person who relies on old addons.  How about
> a firefox-56 port until the current problems die down?

Is using www/firefox-esr an option?
___
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: PORTDOCS=*, but check-plist still complains about the doxygen directory

2017-11-26 Thread Yuri 

I think, this is a bug in PORTDOCS.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223878

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"