Version numbers not being compared correctly in ports?

2017-11-12 Thread bob prohaska 
Got a strange error message while trying to compile firefox on an
RPI2:

===>  Installing for gettext-tools-0.19.8.1
===>  Checking if gettext-tools already installed
===>   gettext-tools-0.19.8.1 is already installed
  You may wish to ``make deinstall'' and install this port again
  by ``make reinstall'' to upgrade it properly.
  If you really wish to overwrite the old port of gettext-tools
  without deleting it first, set the variable "FORCE_PKG_REGISTER"
  in your environment or the "make install" command line.
*** Error code 1

It seems as if make is finding the version of gettext-tools it wants, 
why is it reporting an error? 

Just for fun, I cd'd to /usr/ports/devel/gettext-tools and
did the make deinstall/reinstall. No errors, but it didn't help.

svnlite info reports
Path: .
Working Copy Root Path: /usr/ports
URL: svn://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 454091
Node Kind: directory
Schedule: normal
Last Changed Author: ed
Last Changed Rev: 454091
Last Changed Date: 2017-11-12 14:13:47 -0800 (Sun, 12 Nov 2017)

Thanks for reading and any suggestions.

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"

Cancelled: ECO BANK PLC,DEPT OF WESTERN UNION MONEY TRANSFER. @ Wednesday, 01 November 2017

2017-11-12 Thread nwa abig via freebsd-ports 

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

Invitation: ECO BANK PLC,DEPT OF WESTERN UNION MONEY TRANSFER. @ Wednesday, 01 November 2017

2017-11-12 Thread nwa abig via freebsd-ports 

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

Default option changes-lacking explanation

2017-11-12 Thread Dewayne Geraghty 
It would be very helpful if maintainers could add an explanation for the
changes to default options that they make. 

For example freeradius3 recently added heimdal and updfromto as default
options to the build without any reason in either the maintainer's (svn)
log nor in UPDATING.  As a suggestion:

  * Improved Kerberos support. Added MIT krb as an option. Heimdal base
now defaults to ON.
  * udp_fromto enables specification of source address, helpful on
multi-homed devices. Default is now ON

I'm sure there are a lot of administrators that would like to have
consistency in their builds/installs, even if they regularly have to
review the log files to find it.  This is not to take away the valuable
work that maintainers contribute to the project, only that a little more
communication of changes that do affect people will help them to prepare
pro-actively their builds.

Regards, Dewayne.

PS And Zi, thankyou for modernising the Makefile and adding MIT Krb.

___
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: Firefox doesn't build...

2017-11-12 Thread Walter Schwarzenfeld 

Yes, it is unset by default.
I changed it to reduce compile time.
(Maybe, some other do it for the same
reason).

___
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: Firefox doesn't build...

2017-11-12 Thread Matthias Apitz 
El día domingo, noviembre 12, 2017 a las 06:52:56p. m. +0100, Walter 
Schwarzenfeld escribió:

> Sprry. I puzzled the name of the option.
> I meant PORT_LLVM.

Ok, but this seems to be unset by default:

# This file is auto-generated by 'make config'.
# Options for rust-1.21.0_1
_OPTIONS_READ=rust-1.21.0_1
_FILE_COMPLETE_OPTIONS_LIST=DOCS GDB LLNEXTGEN PORT_LLVM SOURCES
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_UNSET+=GDB
OPTIONS_FILE_UNSET+=LLNEXTGEN
OPTIONS_FILE_UNSET+=PORT_LLVM<*
OPTIONS_FILE_UNSET+=SOURCES

or I'm wrong?

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub


signature.asc
Description: PGP signature

Re: Firefox (Doesn't) Build

2017-11-12 Thread Jonathan Chen 
On 13 November 2017 at 07:33, Jonathan Chen  wrote:
> On 13 November 2017 at 00:03, Grzegorz Junka  wrote:
>> On 12/11/2017 07:14, Jonathan Chen wrote:
>>>
>>> On 12 November 2017 at 12:16, Patrick Dorion 
>>> wrote:

 What's the difference between using Poudriere or Synth, though?

 This is a clean system, I can't imagine a jail being cleaner... it was
 unpacked from the DVD the day before yesterday
>>>
>>> Both are clean room builds; ie where only minimal build dependancies
>>> are installed for each port build. The main difference is that:
>>>   * poudriere uses jails to achieve this
>>>   * synth uses unionfs+chroot to achieve this
>>
>>
>> Does it mean synth can't be used on ZFS? AFAIK unionfs isn't properly
>> supported on ZFS, i.e. a file that exists in the underlying fs can't be
>> marked as deleted in the overlying fs.
>
> synth uses unionfs for read-only access to the build-host's files; eg:
> ports-dir, system binaries. In normal operation, all build artifacts
> are generated onto on an isolated tmpfs filesystem. There are no
> additions/removals on the build-host's filesystem.

Sorry, this is not true. The build logs and generated packages *do*
affect the build-host's filesystem; but the build operations do not.

Cheers.
-- 
Jonathan Chen 
___
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: Firefox (Doesn't) Build

2017-11-12 Thread Jonathan Chen 
On 13 November 2017 at 00:03, Grzegorz Junka  wrote:
> On 12/11/2017 07:14, Jonathan Chen wrote:
>>
>> On 12 November 2017 at 12:16, Patrick Dorion 
>> wrote:
>>>
>>> What's the difference between using Poudriere or Synth, though?
>>>
>>> This is a clean system, I can't imagine a jail being cleaner... it was
>>> unpacked from the DVD the day before yesterday
>>
>> Both are clean room builds; ie where only minimal build dependancies
>> are installed for each port build. The main difference is that:
>>   * poudriere uses jails to achieve this
>>   * synth uses unionfs+chroot to achieve this
>
>
> Does it mean synth can't be used on ZFS? AFAIK unionfs isn't properly
> supported on ZFS, i.e. a file that exists in the underlying fs can't be
> marked as deleted in the overlying fs.

synth uses unionfs for read-only access to the build-host's files; eg:
ports-dir, system binaries. In normal operation, all build artifacts
are generated onto on an isolated tmpfs filesystem. There are no
additions/removals on the build-host's filesystem.

Cheers.
-- 
Jonathan Chen 
___
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: Firefox doesn't build...

2017-11-12 Thread Walter Schwarzenfeld 

Sprry. I puzzled the name of the option.
I meant PORT_LLVM.

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

sysutils/pcbsd-utils (HEAD) fails to compile in poudriere

2017-11-12 Thread Matthias Apitz 

The above port fails to compile with:
...
echo pc-ldapconf: 
/wrkdirs/usr/ports/sysutils/pcbsd-utils/work/stage/usr/local/bin/usr/lib/libc.a 
 >> .depend
--- pc-ldapconf.o ---
--- ldap-lexer.lex.c ---
--- ldap-parser.tab.c ---
--- pc-ldapconf.o ---
clang  -O2 -pipe  -fstack-protector -fno-strict-aliasing   -I. 
-I/wrkdirs/usr/ports/sysutils/pcbsd-utils/work/pcbsd-3c4d2b/src-sh/pcbsd-utils/pc-adctl/pc-ldapconf
 -MD  -MF.depend.pc-ldapconf.o -MTpc-ldapconf.o -std=gnu99 
-fstack-protector-strong-Qunused-arguments  -c pc-ldapconf.c -o 
pc-ldapconf.o
pc-ldapconf.c:8:10: fatal error: 'ldap-parser.tab.h' file not found
#include "ldap-parser.tab.h"
 ^~~
1 error generated.
*** [pc-ldapconf.o] Error code 1

The full log is attached.

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
>> Building sysutils/pcbsd-utils
build started at Sun Nov 12 17:24:25 CET 2017
port directory: /usr/ports/sysutils/pcbsd-utils
building for: FreeBSD freebsd-r318593-ports-2017-job-03 12.0-CURRENT 
FreeBSD 12.0-CURRENT r318593 amd64
make: Working in: /usr/ports/sysutils/pcbsd-utils
make: Working in: /usr/ports/sysutils/pcbsd-utils
maintained by: kmo...@freebsd.org
Makefile ident:  $FreeBSD: head/sysutils/pcbsd-utils/Makefile 430454 
2017-01-03 11:01:05Z mat $
Poudriere version: 3.2-pre
Host OSVERSION: 1200030
Jail OSVERSION: 1200030
Job Id: 03

---Begin Environment---
SHELL=/bin/csh
OSVERSION=1200030
UNAME_v=FreeBSD 12.0-CURRENT r318593
UNAME_r=12.0-CURRENT
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
SAVED_TERM=screen
MASTERMNT=/usr/local/poudriere/data/.m/freebsd-r318593-ports-2017/ref
UID=0
FORCE_PACKAGE=yes
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=pcbsd-utils-1440778617
OLDPWD=/
PWD=/usr/local/poudriere/data/.m/freebsd-r318593-ports-2017/ref/.p/pool
MASTERNAME=freebsd-r318593-ports-2017
SCRIPTPREFIX=/usr/local/share/poudriere
USER=root
HOME=/root
POUDRIERE_VERSION=3.2-pre
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
GID=0
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
---End Environment---

---Begin OPTIONS List---
---End OPTIONS List---

--CONFIGURE_ARGS--
--with-qt-includes=/usr/local/include/qt5  
--with-qt-libraries=/usr/local/lib/qt5  
--with-extra-includes=/usr/local/include  --with-extra-libs=/usr/local/lib
--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
QT_SELECT=qt5 PKG_CONFIG=pkgconf 
XDG_DATA_HOME=/wrkdirs/usr/ports/sysutils/pcbsd-utils/work  
XDG_CONFIG_HOME=/wrkdirs/usr/ports/sysutils/pcbsd-utils/work  
HOME=/wrkdirs/usr/ports/sysutils/pcbsd-utils/work TMPDIR="/tmp" 
PATH=/wrkdirs/usr/ports/sysutils/pcbsd-utils/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
 SHELL=/bin/sh CONFIG_SHELL=/bin/sh QTDIR="/usr/local/lib/qt5" 
QMAKE="/usr/local/lib/qt5/bin/qmake"  MOC="/usr/local/lib/qt5/bin/moc" 
RCC="/usr/local/lib/qt5/bin/rcc" UIC="/usr/local/lib/qt5/bin/uic"  
QMAKESPEC="/usr/local/lib/qt5/mkspecs/freebsd-$(ccver="$(clang++ --version)"; 
case "$ccver" in *clang*) echo clang ;; *) echo g++ ;; esac)"
--End CONFIGURE_ENV--

--MAKE_ENV--
QT_SELECT=qt5 XDG_DATA_HOME=/wrkdirs/usr/ports/sysutils/pcbsd-utils/work  
XDG_CONFIG_HOME=/wrkdirs/usr/ports/sysutils/pcbsd-utils/work  
HOME=/wrkdirs/usr/ports/sysutils/pcbsd-utils/work TMPDIR="/tmp" 
PATH=/wrkdirs/usr/ports/sysutils/pcbsd-utils/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
 NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES 
PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"  CC="clang" 
CFLAGS="-O2 -pipe  -fstack-protector -fno-strict-aliasing"  CPP="clang-cpp" 
CPPFLAGS=""  LDFLAGS=" -fstack-protector" LIBS=""  CXX="clang++" CXXFLAGS="-O2 
-pipe -fstack-protector -fno-strict-aliasing "  MANPREFIX="/usr/local" 
BSD_INSTALL_PROGRAM="install  -s -m 555"  BSD_INSTALL_LIB="install  -s -m 0644" 
 BSD_INSTALL_SCRIPT="install  -m 555"  BSD_INSTALL_DATA="install  -m 0644"  
BSD_INSTALL_MAN="install  -m 444"
--End MAKE_ENV--

--PLIST_SUB--
QT_BINDIR="lib/qt5/bin"
QT_INCDIR="include/qt5"
QT_LIBDIR="lib/qt5"
QT_ARCHDIR="lib/qt5"
QT_PLUGINDIR="lib/qt5/plugins"
QT_LIBEXECDIR="libexec/qt5"
QT_IMPORTDIR="lib/qt5/imports"
QT_QMLDIR="lib/qt5/qml"
QT_DATADIR="share/qt5"
QT_DOCDIR="share/doc/qt5"
QT_L10NDIR="share/qt5/translations"
QT_EXAMPLEDIR="share/examples/qt5"
QT_TESTDIR="share/qt5/tests"
QT_MKSPECDIR="lib/qt5/mkspecs"
QT_QTCHOOSERDIR="etc/xdg/qtchooser"
OSREL=12.0
PREFIX=%D
LOCALBASE=/usr/local
RESETPREFIX=/usr/local
PORTDOCS=""
PORTEXAMPLES=""
LIB32DIR=lib
DOCSDIR="share/doc/pcbsd-utils"
EXAMPLESDIR="share/examples/pcbsd-utils"
DATADIR="share/pcbsd-utils"
WWWDIR="www/pcbsd-utils"
ETCDIR="etc/pcbsd-utils"
--End PLIST_SUB--

--SUB_LIST--
PREFIX=/usr/local
LOCALBASE=/usr/local
DATADIR=/usr/local/share/pcbsd-utils

problems installing ImageMagick-nox11 from ports (resolved)

2017-11-12 Thread tech-lists 


Hello list,

I was having an odd problem updating imagemagick-nox11. It wasn't
readily apparent as I normally use MAKE_JOBS_NUMBER=10 on this machine,
so ran the make with MAKE_JOBS_UNSAFE=YES and found this problem:

/usr/bin/ld: cannot find -lstdc++

so commented out WITH_CCACHE_BUILD in /etc/make.conf

ran make distclean clean rmconfig and it built successfully. Everything
else builds fine, so I was at a loss initially; thought I'd mention it
here in case it can help others.
--
J.
___
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: Firefox doesn't build...

2017-11-12 Thread Matthias Apitz 
El día sábado, noviembre 11, 2017 a las 01:25:38a. m. +0100, Jan Beich escribió:

> Dimitry Andric  writes:
> 
> > On 10 Nov 2017, at 22:43, Patrick Dorion  wrote:
> >
> >> 
> >> ... on amd-64.
> >> 
> >> simd doesn't build: sse2 not found in x86.  i tried a bunch of options, 
> >> didn't work.
> >
> > See https://bugs.freebsd.org/223415.  For now, rebuild lang/rust without 
> > the LLVM_PORT option.
> 
> That's wrong one. https://bugs.freebsd.org/223342 is the one about PORT_LLVM 
> regression
> which affects www/firefox build (as opposed to runtime).

Hello,

I've read this mail thread and the PR, but I'm now unsure what to set or
unset;

Someone (Walter Schwarzenfeld) said here:

Set LLVM_PORT in lang/rust to off and
recompile rust.
This solved the problem with firefox.

If I run 'make config' in lang/rust, there is no LLVM_PORT option,
only PORT_LLVM and the generated options file is:

# This file is auto-generated by 'make config'.
# Options for rust-1.21.0_1
_OPTIONS_READ=rust-1.21.0_1
_FILE_COMPLETE_OPTIONS_LIST=DOCS GDB LLNEXTGEN PORT_LLVM SOURCES
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_UNSET+=GDB
OPTIONS_FILE_UNSET+=LLNEXTGEN
OPTIONS_FILE_UNSET+=PORT_LLVM
OPTIONS_FILE_UNSET+=SOURCES


What should I set or unset exactly?

Thanks

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
___
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: Firefox (Doesn't) Build

2017-11-12 Thread Baho Utot 



On 11/12/17 06:03, Grzegorz Junka wrote:

On 12/11/2017 07:14, Jonathan Chen wrote:
On 12 November 2017 at 12:16, Patrick Dorion 
 wrote:

What's the difference between using Poudriere or Synth, though?

This is a clean system, I can't imagine a jail being cleaner... it 
was unpacked from the DVD the day before yesterday

Both are clean room builds; ie where only minimal build dependancies
are installed for each port build. The main difference is that:
  * poudriere uses jails to achieve this
  * synth uses unionfs+chroot to achieve this


Does it mean synth can't be used on ZFS? AFAIK unionfs isn't properly 
supported on ZFS, i.e. a file that exists in the underlying fs can't be 
marked as deleted in the overlying fs.


GrzegorzJ



I use synth on a ZFS raid systemworks fine
___
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-12 Thread Alexey Dokuchaev 
On Sun, Nov 12, 2017 at 02:01:39PM +1030, Shane Ambler wrote:
> On 10/11/2017 17:37, 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.
> [...]
> 
> While I know appleseed fails when rtti is disabled directly in CXXFLAGS,
> maybe cmake can detect the use of rtti in llvm (or offer an option) and
> adjust to suit, or just add -fno-rtti only for the osl files.

According to Esteban (one of appleseed's devs), they do use RTTI, so
disabling it is not an option (see discussion in that issue #1625).

Also, from the point of feature-completeness of infrastructure-important
port(s) such as LLVM, having RTTI enabled by default looks good to me.

./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: RTTI support in devel/llvm40 (and maybe other llvm ports)

2017-11-12 Thread Alexey Dokuchaev 
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.
> > 
> > The patch is very simple (apart port revision bump):
> > 
> > @@ -39,7 +41,7 @@
> >  SUB_LIST=  LLVM_PREFIX="${LLVM_PREFIX}" LLVM_SUFFIX="${LLVM_SUFFIX}"
> >  CMAKE_INSTALL_PREFIX=  ${LLVM_PREFIX}
> > -CMAKE_ARGS=-DLLVM_BUILD_LLVM_DYLIB=ON
> > +CMAKE_ARGS=-DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_ENABLE_RTTI=ON
> > 
> > Could you review/commit it, and check if other LLVM ports could
> > also benefit from it?  Thanks,
> 
> 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.

./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: Firefox (Doesn't) Build

2017-11-12 Thread Grzegorz Junka 

On 12/11/2017 07:14, Jonathan Chen wrote:

On 12 November 2017 at 12:16, Patrick Dorion  wrote:

What's the difference between using Poudriere or Synth, though?

This is a clean system, I can't imagine a jail being cleaner... it was unpacked 
from the DVD the day before yesterday

Both are clean room builds; ie where only minimal build dependancies
are installed for each port build. The main difference is that:
  * poudriere uses jails to achieve this
  * synth uses unionfs+chroot to achieve this


Does it mean synth can't be used on ZFS? AFAIK unionfs isn't properly 
supported on ZFS, i.e. a file that exists in the underlying fs can't be 
marked as deleted in the overlying fs.


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"

FreeBSD ports you maintain which are out of date

2017-11-12 Thread portscout 
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
multimedia/motion   | 4.0.1   | release-4.1
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
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: writing drivers based on hardware manuals

2017-11-12 Thread Kurt Jaeger 
Hi!

> This is a request on where can I get more information and talk to other
> FreeBSD developers about writing software to control hardware based on
> dmidecode and a device manual.
> 
> I found this manual page that not only describe the fan controllers and lid
> switch but also the keyboard LED controller as well.
> 
> https://www.manualslib.com/manual/1269646/Clevo-P650hs.html?page=114#manual
> 
> I should be able to write code to interface with this hardware directly
> from FreeBSD.
> 
> Where can I go to get help with this?

Try this book:

https://www.nostarch.com/bsddrivers.htm

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

writing drivers based on hardware manuals

2017-11-12 Thread blubee blubeeme 
This is a request on where can I get more information and talk to other
FreeBSD developers about writing software to control hardware based on
dmidecode and a device manual.

I found this manual page that not only describe the fan controllers and lid
switch but also the keyboard LED controller as well.

https://www.manualslib.com/manual/1269646/Clevo-P650hs.html?page=114#manual

I should be able to write code to interface with this hardware directly
from FreeBSD.

Where can I go to get help with 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: [Bug 223383] pathconf querying for posix_falloc not supported on freebsd [devel/llvm*'s lld's are also broken by this for zfs and need updating]

2017-11-12 Thread Brooks Davis 
I'll work on this.

-- Brooks

On Thu, Nov 09, 2017 at 07:09:00PM -0800, Mark Millard wrote:
> [ devel/llvm* also have the issue in their
> lld 's.]
> 
> On 2017-Nov-7, at 4:43 PM, bugzilla-noreply at freebsd.org wrote:
> 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223383
> > 
> > --- Comment #7 from commit-h...@freebsd.org ---
> > A commit references this bug:
> > 
> > Author: emaste
> > Date: Wed Nov  8 00:39:04 UTC 2017
> > New revision: 325523
> > URL: https://svnweb.freebsd.org/changeset/base/325523
> > 
> > Log:
> >  MFC r325420: lld: accept EINVAL to indicate posix_fallocate is unsupported
> > 
> >  As of r325320 posix_fallocate on a ZFS filesystem returns EINVAL to
> >  indicate that the operation is not supported. (I think this is a strange
> >  choice of errno on the part of POSIX.)
> > 
> >  PR:   223383, 223440
> >  Reported by:  Mark Millard
> >  Sponsored by: The FreeBSD Foundation
> > 
> > Changes:
> > _U  stable/11/
> >  stable/11/contrib/llvm/lib/Support/Unix/Path.inc
> > 
> > -- 
> > You are receiving this mail because:
> > You are on the CC list for the bug.
> 
> [Context a zfs file system.]
> 
> From /usr/src/UPDATING:
> 
> 20171106:
> The naive and non-compliant support of posix_fallocate(2) in ZFS
> has been removed as of r325320.  The system call now returns EINVAL
> when used on a ZFS file.  Although the new behavior complies with the
> standard, some consumers are not prepared to cope with it.
> One known victim is lld prior to r325420.
> 
> 
> The issue is not limited to the system clang's
> associated lld. 
> 
> Here is an attempt to use clang++50, implicitly using
> its associated lld:
> 
> # clang++50 -v exception_test.cc
> clang version 5.0.0 (tags/RELEASE_500/final)
> Target: x86_64-portbld-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/local/llvm50/bin
>  "/usr/local/llvm50/bin/clang-5.0" -cc1 -triple x86_64-portbld-freebsd12.0 
> -emit-obj -mrelax-all -disable-free -main-file-name exception_test.cc 
> -mrelocation-model static -mthread-model posix -mdisable-fp-elim 
> -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v 
> -dwarf-column-info -debugger-tuning=gdb -resource-dir 
> /usr/local/llvm50/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 
> -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit 19 
> -fmessage-length 200 -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions 
> -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/exception_test-baadc9.o 
> -x c++ exception_test.cc
> clang -cc1 version 5.0.0 based upon LLVM 5.0.0 default target 
> x86_64-portbld-freebsd12.0
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/include/c++/v1
>  /usr/local/llvm50/lib/clang/5.0.0/include
>  /usr/include
> End of search list.
>  "/usr/local/llvm50/bin/ld" --eh-frame-hdr -dynamic-linker 
> /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out 
> /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib 
> /tmp/exception_test-baadc9.o -lc++ -lm -lgcc --as-needed -lgcc_s 
> --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o 
> /usr/lib/crtn.o
> /usr/local/llvm50/bin/ld: error: cannot open output file a.out: Invalid 
> argument
> clang-5.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> 
> https://svnweb.freebsd.org/ports/head/devel/?dir_pagestart=1000
> 
> does not yet suggest updates to devel/llvm* 's for
> the issue.
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 


signature.asc
Description: PGP signature

Re: RTTI support in devel/llvm40 (and maybe other llvm ports)

2017-11-12 Thread Brooks Davis 
On Fri, Nov 10, 2017 at 02:07:48PM +0700, Alexey Dokuchaev wrote:
> Hi Brooks,
> 
> 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.
> 
> The patch is very simple (apart port revision bump):
> 
> @@ -39,7 +41,7 @@
>  SUB_LIST=LLVM_PREFIX="${LLVM_PREFIX}" LLVM_SUFFIX="${LLVM_SUFFIX}"
>  CMAKE_INSTALL_PREFIX=  ${LLVM_PREFIX}
> -CMAKE_ARGS=  -DLLVM_BUILD_LLVM_DYLIB=ON
> +CMAKE_ARGS=  -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_ENABLE_RTTI=ON
> 
> Could you review/commit it, and check if other LLVM ports could
> also benefit from it?  Thanks,

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

-- Brooks


signature.asc
Description: PGP signature