Re: poudriere: net/openldap24-server: stage/runaway , building forever

[O. Hartmann]

On Fri, 9 Apr 2021 12:59:59 +0200
Gary Jennejohn  wrote:

> On Fri, 9 Apr 2021 12:12:45 +0200
> Guido Falsi via freebsd-current  wrote:
>
> > On 09/04/21 11:56, O. Hartmann wrote:
> > > On Fri, 9 Apr 2021 10:16:27 +0200 (CEST)
> > > Ronald Klop  wrote:
> > >
> > >> Hi,
> > >>
> > >> The official pkg builders are also stuck for 14-CURRENT. Although at a
> > >> different port sysutils/msktutil.
> > >>
> > >> See main-amd64 at https://pkg-status.freebsd.org/builds?type=package
> > >>
> > >> It is stuck in "stage/runaway" for 61 hours now.
> > >> http://beefy18.nyi.freebsd.org/build.html?mastername=main-amd64-default=p569609_s5b3b19db73
> > >> (ipv6 only)
> > >>
> > >> NB: I'm not involved in the pkg building cluster.
> > >>
> > >> Regards,
> > >> Ronald.
> > >>
> > >>
> > >> Van: "O. Hartmann" 
> > >> Datum: vrijdag, 9 april 2021 07:27
> > >> Aan: FreeBSD Ports 
> > >> Onderwerp: Re: poudriere: net/openldap24-server: stage/runaway , building
> > >> forever
> > >>>
> > >>> On Fri, 9 Apr 2021 06:17:03 +0200
> > >>> "Hartmann, O."  wrote:
> > >>>
> > >>>> Recent CURRENT host (FreeBSD 14.0-CURRENT #26 main-n245806-4d221f59b85:
> > >>>> Sat Apr  3 06:43:44 CEST 2021 amd64), poudriere CURRENT jail at
> > >>>> 14.0-CURRENT 147 amd64 from 2021-04-08 05:25:38. It seems that the
> > >>>> recent CURRENT does have a serious problem when building
> > >>>> net/openldap24-server. The build process gets stuck with staging and is
> > >>>> marked "runaway":
> > >>>>
> > >>>> [head-amd64-head-default] [2021-04-08_13h56m41s] [parallel_build:]
> > >>>> Queued: 1847 Built: 63 Failed: 17   Skipped: 1759 Ignored: 8
> > >>>> Tobuild: 0 Time: 13:26:35 [01]: net/openldap24-server |
> > >>>> openldap-sasl-server-2.4.58 stage/runaway (06:28:32 / 08:41:16)
> > >>>>
> > >>>> Also, on jails (recent CURRENT) serving as OpenLDAP server (also recent
> > >>>> taken from git /usr/ports, branch main), run into a serious problem
> > >>>> starting slapd, when starting slapd and the process is reporting
> > >>>> checking configuration, it freezes forever. Putting slapd into debug
> > >>>> mode doesn't help, since the freeze is quite early.
> > >>>>
> > >>>> Does anybody know what the reason for this strange behaviour is on
> > >>>> CURRENT? All CURRENT servers are affected (almost all the same revision
> > >>>> as shown above)?
> > >>>>
> > >>>> Thanks in advance,
> > >>>>
> > >>>> O. Hartmann
> > >>>
> > >>> Short update, another host is stuck at the very same point, host's
> > >>> CURRENT is at FreeBSD 14.0-CURRENT #2 main-n245870-86a52e262a6: Wed Apr
> > >>>  7 13:57:20 CEST 2021 amd64, it's jails is taken from the same source.
> > >>>
> > >>> The process is stuck at staging and took 34 hours ... never seen before:
> > >>>
> > >>>
> > >>> [...]
> > >>> [09:05:25] [03] [02:13:44] Finished net/openldap24-server |
> > >>> openldap-sasl-server-2.4.58: Failed: stage/runaway load: 10.39  cmd: awk
> > >>> 24374 [running] 0.06r 0.00u 0.00s 0% 3420k [headamd64-head-default]
> > >>> [2021-04-07_12h26m18s] [parallel_build:] Queued: 3298 Built: 2123
> > >>> Failed: 7 Skipped: 1161 Ignored: 7Tobuild: 0 Time: 40:52:34
> > >>> [03]: net/openldap24-server | openldap-sasl-server-2.4.58
> > >>> stage/runaway (31:48:30 / 34:01:11) [40:52:52] Logs:
> > >>> /pool/poudriere/data/logs/bulk/headamd64-head-default/2021-04-07_12h26m18s
> > >>> ___
> > >
> > > [...]
> > >
> > > It seems, that jails on 14-CURRENT do have a strange and malfunctional
> > > behaviour now.
> >
> > Most probably related to commit d36d68161517 check the thread at [1].
> >
> > A solution is being discussed in D29623 at [2].
> >
> >
> > [1]
> > https://lists.freebsd.org/pipermail/dev-commits-src-all/2021-April/005159.html
> >
> > [2] https://reviews.freebsd.org/D29623
> >
>
> Just FYI I was also was seeing strange hangs with dbus (polkitd was
> timing out) and firefox was hung waiting for urwlck.  I also saw
> timeouts waiting for Xorg to shutdown (startx ended up kiliing it).
>
> I applied the patch which kib posted and everything returned to normal.
>

I also applied the patch mentioned bz Guido Falsi above and services like
openLDAP and Apche start now as expected. It seems the patch works on amd64, at
least for some boxes (those I've already pacthed right now).

Thank you very much.

Kind regards,

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

Re: poudriere: net/openldap24-server: stage/runaway , building forever

[O. Hartmann]

On Fri, 9 Apr 2021 10:16:27 +0200 (CEST)
Ronald Klop  wrote:

> Hi,
>
> The official pkg builders are also stuck for 14-CURRENT. Although at a
> different port sysutils/msktutil.
>
> See main-amd64 at https://pkg-status.freebsd.org/builds?type=package
>
> It is stuck in "stage/runaway" for 61 hours now.
> http://beefy18.nyi.freebsd.org/build.html?mastername=main-amd64-default=p569609_s5b3b19db73
> (ipv6 only)
>
> NB: I'm not involved in the pkg building cluster.
>
> Regards,
> Ronald.
>
>
> Van: "O. Hartmann" 
> Datum: vrijdag, 9 april 2021 07:27
> Aan: FreeBSD Ports 
> Onderwerp: Re: poudriere: net/openldap24-server: stage/runaway , building
> forever
> >
> > On Fri, 9 Apr 2021 06:17:03 +0200
> > "Hartmann, O."  wrote:
> >
> > > Recent CURRENT host (FreeBSD 14.0-CURRENT #26 main-n245806-4d221f59b85:
> > > Sat Apr  3 06:43:44 CEST 2021 amd64), poudriere CURRENT jail at
> > > 14.0-CURRENT 147 amd64 from 2021-04-08 05:25:38. It seems that the
> > > recent CURRENT does have a serious problem when building
> > > net/openldap24-server. The build process gets stuck with staging and is
> > > marked "runaway":
> > >
> > > [head-amd64-head-default] [2021-04-08_13h56m41s] [parallel_build:] Queued:
> > > 1847 Built: 63 Failed: 17   Skipped: 1759 Ignored: 8Tobuild: 0
> > > Time: 13:26:35 [01]: net/openldap24-server |
> > > openldap-sasl-server-2.4.58 stage/runaway (06:28:32 / 08:41:16)
> > >
> > > Also, on jails (recent CURRENT) serving as OpenLDAP server (also recent
> > > taken from git /usr/ports, branch main), run into a serious problem
> > > starting slapd, when starting slapd and the process is reporting checking
> > > configuration, it freezes forever. Putting slapd into debug mode doesn't
> > > help, since the freeze is quite early.
> > >
> > > Does anybody know what the reason for this strange behaviour is on
> > > CURRENT? All CURRENT servers are affected (almost all the same revision
> > > as shown above)?
> > >
> > > Thanks in advance,
> > >
> > > O. Hartmann
> >
> > Short update, another host is stuck at the very same point, host's CURRENT
> > is at FreeBSD 14.0-CURRENT #2 main-n245870-86a52e262a6: Wed Apr  7 13:57:20
> > CEST 2021 amd64, it's jails is taken from the same source.
> >
> > The process is stuck at staging and took 34 hours ... never seen before:
> >
> >
> > [...]
> > [09:05:25] [03] [02:13:44] Finished net/openldap24-server |
> > openldap-sasl-server-2.4.58: Failed: stage/runaway load: 10.39  cmd: awk
> > 24374 [running] 0.06r 0.00u 0.00s 0% 3420k [headamd64-head-default]
> > [2021-04-07_12h26m18s] [parallel_build:] Queued: 3298 Built: 2123 Failed: 7
> > Skipped: 1161 Ignored: 7Tobuild: 0 Time: 40:52:34 [03]:
> > net/openldap24-server | openldap-sasl-server-2.4.58 stage/runaway
> > (31:48:30 / 34:01:11) [40:52:52] Logs:
> > /pool/poudriere/data/logs/bulk/headamd64-head-default/2021-04-07_12h26m18s
> > ___

[...]

It seems, that jails on 14-CURRENT do have a strange and malfunctional
behaviour now.

net/openldap24-server is failing to start on 14-CURRENT (FreeBSD 14.0-CURRENT
#4 main-n245909-3ce579325e4: Fri Apr  9 10:09:02 CEST 2021 amd64) host. The
jail is providing OpenLDAP functionality.

Trying to start slapd with debug mode -d7 and above does never give any
information (Ctrl-T on jail's console):

[...]
root@ldap-master:~ # service slapd start
grep: /usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={1}mdb: Is a
directory
grep: /usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={2}mdb: Is a
directory
Performing sanity check on slap configuration:

load: 0.37  cmd: slapd 61766 [uwrlck] 3.17r 0.04u 0.01s 0% 11232k
mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_wait_sig+0x9 _sleep+0x1ad
umtxq_sleep+0x230 do_rw_wrlock+0x5dc __umtx_op_rw_wrlock+0x45 sys__umtx_op+0x7a
amd64_syscall+0x10c fast_syscall_common+0xf8
load: 0.37  cmd: slapd 61766 [uwrlck] 3.36r 0.04u 0.01s 0% 11232k
mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_wait_sig+0x9 _sleep+0x1ad
umtxq_sleep+0x230 do_rw_wrlock+0x5dc __umtx_op_rw_wrlock+0x45 sys__umtx_op+0x7a
amd64_syscall+0x10c fast_syscall_common+0xf8
[...]


Today, I realised that Apache 2.4 (www/apach24) also fails to start - last time
I realised the failiure of OpenLDAP, Apache 2.4 did start, now, as of today, it
doesn't.

This is a subversion providing jail on that host (another webserver on the same
host does start the Apache 2.4 service flawless):

[...]
root@svn:~ # service apache24 restart
Performing sanity check on apache24 confi

Re: poudriere: net/openldap24-server: stage/runaway , building forever

[O. Hartmann]

On Fri, 9 Apr 2021 06:17:03 +0200
"Hartmann, O."  wrote:

> Recent CURRENT host (FreeBSD 14.0-CURRENT #26 main-n245806-4d221f59b85: Sat
> Apr  3 06:43:44 CEST 2021 amd64), poudriere CURRENT jail at 14.0-CURRENT
> 147 amd64 from 2021-04-08 05:25:38. It seems that the recent CURRENT does
> have a serious problem when building net/openldap24-server. The build process
> gets stuck with staging and is marked "runaway":
>
> [head-amd64-head-default] [2021-04-08_13h56m41s] [parallel_build:] Queued:
> 1847 Built: 63 Failed: 17   Skipped: 1759 Ignored: 8Tobuild: 0 Time:
> 13:26:35 [01]: net/openldap24-server | openldap-sasl-server-2.4.58
> stage/runaway (06:28:32 / 08:41:16)
>
> Also, on jails (recent CURRENT) serving as OpenLDAP server (also recent taken
> from git /usr/ports, branch main), run into a serious problem starting slapd,
> when starting slapd and the process is reporting checking configuration, it
> freezes forever. Putting slapd into debug mode doesn't help, since the freeze
> is quite early.
>
> Does anybody know what the reason for this strange behaviour is on CURRENT?
> All CURRENT servers are affected (almost all the same revision as shown
> above)?
>
> Thanks in advance,
>
> O. Hartmann

Short update, another host is stuck at the very same point, host's CURRENT is at
 FreeBSD 14.0-CURRENT #2 main-n245870-86a52e262a6: Wed Apr  7 13:57:20 CEST
 2021 amd64, it's jails is taken from the same source.

The process is stuck at staging and took 34 hours ... never seen before:


[...]
[09:05:25] [03] [02:13:44] Finished net/openldap24-server |
openldap-sasl-server-2.4.58: Failed: stage/runaway load: 10.39  cmd: awk 24374
[running] 0.06r 0.00u 0.00s 0% 3420k [headamd64-head-default]
[2021-04-07_12h26m18s] [parallel_build:] Queued: 3298 Built: 2123 Failed: 7
Skipped: 1161 Ignored: 7Tobuild: 0 Time: 40:52:34 [03]:
net/openldap24-server | openldap-sasl-server-2.4.58 stage/runaway
(31:48:30 / 34:01:11) [40:52:52] Logs:
/pool/poudriere/data/logs/bulk/headamd64-head-default/2021-04-07_12h26m18s
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

ports do not build anymore due to python version issues issues

[O. Hartmann]

Just updatet the ports tree to r455280.

No python depending port is building anymore.

According to
/usr/ports/UPDATING, tag 20171130, some has to do "make FLAVOUR=pyXX" for a 
certain port.
This weird text also states, that poudriere >3.2.X users also do not have to 
worry.

First: running recent poudriere 3.2.2 gives me simply  
[00:01:18] Calculating ports order and dependencies
[00:01:19] Error: compute_deps_pkg failed to lookup pkgname for 
devel/py-iso8601@
processing package samba46-4.6.11 from net/samba46 -- Does devel/py-iso8601 
provide the
'' FLAVOR?

among several other errors, poudriere dies.

Updating the hosts ports via portmaster also fails, as stated.

According to the information-rich UPDATING entry, I have to put "make 
FLAVOUR=xxx
install" to EACH port? Or is it only for those ports where the user has a 
choice? Or is
this general? What?

Just in case it can be selected globally (where is the explanation/info whether 
it can or
not?), does it imply ancient py27 is now out and a more modern python3 is the 
standard?

I'm confused.

Kind regards,

Oliver
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpSA9wwnWfB9.pgp
Description: OpenPGP digital signature

Re: ports: pkg-static: "x86_64-unknown-freebsd" versus "x86_64-portbld-freebsd"

[O. Hartmann]

On Sun, 15 Oct 2017 23:38:54 -0700
Mark Millard <mar...@dsl-only.net> wrote:

> O. Hartmann ohartmann at walstatt.org wrote on
> Sun Oct 15 16:37:58 UTC 2017 :
> 
> > . . .
> > file 
> > /usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-avx.bc:No
> > such file or directory pkg-static: Unable to access
> > . . .
> > find ./ -name "*freebsd12.0-avx.bc" -print
> > ./work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.0-avx.bc
> > ./work/pocl-0.14/lib/kernel/host/kernel-x86_64-portbld-freebsd12.0-avx.bc
> > . . .
> > so it seems to me as "unknown" gets replaced by "portbld".
> > . . .  
> 
> I do not know if this will help or not. Using a powerpc64
> context as an example:
> 
> In "modern times" devel/powerpc64-gcc generates -unknown- in names
> and lang/gcc* on that environment generates -portbld- in names. This
> helps allows for both devel/powerpc64-gcc and lang/gcc being installed
> in a powerpc64 context: it avoids file name conflicts.
> 
> So, for example:
> (I do not have lang/gcc around but do have lang/gcc7 .)
> 
> # ls -lTd /usr/local/bin/*portb*
> -r-xr-xr-x  4 root  wheel  3617405 Sep 30 23:33:03
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-c++7 -r-xr-xr-x  4 root
> wheel  3617405 Sep 30 23:33:03
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-g++7 -r-xr-xr-x  3 root
> wheel  3610452 Sep 30 23:33:06
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-7.2.0 -r-xr-xr-x  2
> root  wheel   121242 Sep 30 23:33:06
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-ar7 -r-xr-xr-x  2 root
> wheel   121146 Sep 30 23:33:07
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-nm7 -r-xr-xr-x  2 root
> wheel   121166 Sep 30 23:33:07
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-ranlib7 -r-xr-xr-x  3
> root  wheel  3610452 Sep 30 23:33:06
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc7 -r-xr-xr-x  2 root
> wheel  3620002 Sep 30 23:33:03
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gfortran7
> 
> # ls -lTd /usr/local/bin/*unknow*
> -r-xr-xr-x  2 root  wheel  3237168 Oct  1 01:17:24
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-c++ -rwxr-xr-x  1 root
> wheel  3235584 Oct  1 01:17:30
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-cpp -r-xr-xr-x  2 root
> wheel  3237168 Oct  1 01:17:24
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-g++ -r-xr-xr-x  2 root
> wheel  3234328 Oct  1 01:17:34
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -r-xr-xr-x  2 root
> wheel  3234328 Oct  1 01:17:34
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-6.3.0 -r-xr-xr-x  1
> root  wheel   121176 Oct  1 01:17:35
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ar -r-xr-xr-x  1 root
> wheel   120808 Oct  1 01:17:35
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-nm -r-xr-xr-x  1 root
> wheel   120824 Oct  1 01:17:35
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ranlib -r-xr-xr-x  1
> root  wheel  2347112 Oct  1 01:17:26
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcov -r-xr-xr-x  1 root
> wheel  2091280 Oct  1 01:17:26
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcov-tool
> 
> Something like this might be involved in your context?
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 

Hello Mark.

Port lang/pocl, 0.14, built flawless in the past, as it is usually compiled
with LLVM/CLANG. Something changed in the past weeks and I got noticed that
poudriere failed installing the port. I do not use gcc of any kind and I have
already proposed for a patch, but your statement/email make me rethink this
approach; the difference might be by intention, but if so, I do not understand
the logic of port's Mk infrastructure, simply because I'm not into it. The
changes to the port's system must have been recently made, lang/pocl built a
couple of weeks ago on 12-CURRENT without any problems. After I got the
poudriere failure notice, I tried on my installations and it failed to install
there, too.

So, the big question for me to answer is: is it a bug or is it a new feature
reflecting the need to sketched above ...

Thanks for answering,

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

Re: [ports]: GH_TAGNAME: how to figure out this tagname on downloadable archives?

[O. Hartmann]

On Mon, 16 Oct 2017 04:19:24 +
blubee blubeeme <gurenc...@gmail.com> wrote:

> I just ran into this issue yesterday myself.
> 
> To find the tagname I went to the project in githib, looked at their
> committed files and found the one with the latest date.
> 
> Click on that file, then you'll see three buttons in the upper right hand
> side;
> raw, blame, history.
> 
> Click on history and you'll see the tagnames on the right have column.
> 
> Copy that to your GH_TAGNAME in the makefile and you should be fine.
> 
> There are ways to get the tagname from git but that's if you've cloned the
> repo locally which I didn't want to bother doing.
> 
> Best

All right, thanks a lot for the hint,

but it doesn't solve the problem for me. I think I was in a kind of panic mode
yesterday when I realised that some ports I'm named as the maintainer has been
outdated.

Port devel/opencl is "tagged" as PORTVERSION=2.1 and HEADER_TAG=2d06e09.

If looking at github
(https://github.com/KhronosGroup/OpenCL-Headers/tree/2d4cc6184094fd6c70f114e381bdd51299b81fff/opencl22/CL),
you'll realise, that with 16th of May 2017, OpenCL 2.2 and the precedesors has
been altered to have the header files in a new subfolder, CL, beneath its
main folder. this is the very same for the older header files of OpenCL.

If proceeding as described, I find that the latest commit on opencl.h in
OpenCL22/CL/ has the tag number 2d4cc61 - as Yuri mentioned before, a 7
digit/alphanum number. I copied that into the Makefile (following the simple
logic stupidly now knowing how the tarball is created at all ...). Altering the
port's version to 2.2 - also simply following a simple logic, results then in
the following (PORTVERSION=2.2; HEADER_TAG=2d4cc61):

[...]
# make distclean makesum
=> KhronosGroup-OpenCL-Headers-2.2-2d4cc61_GH0.tar.gz doesn't seem to exist
in /usr/ports/distfiles/.
=> Attempting to fetch
https://codeload.github.com/KhronosGroup/OpenCL-Headers/tar.gz/2d4cc61?dummy=/KhronosGroup-OpenCL-Headers-2.2-2d4cc61_GH0.tar.gz
Certificate verification failed for /C=US/O=DigiCert
Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
34374640024:error:14090086:SSL routines:ssl3_get_server_certificate:certificate
verify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
fetch:
https://codeload.github.com/KhronosGroup/OpenCL-Headers/tar.gz/2d4cc61?dummy=/KhronosGroup-OpenCL-Headers-2.2-2d4cc61_GH0.tar.gz:
Authentication error
=> Attempting to fetch
http://distcache.FreeBSD.org/ports-distfiles/KhronosGroup-OpenCL-Headers-2.2-2d4cc61_GH0.tar.gz
fetch:
http://distcache.FreeBSD.org/ports-distfiles/KhronosGroup-OpenCL-Headers-2.2-2d4cc61_GH0.tar.gz:
Not Found
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/ports/distfiles/ and try again.
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/opencl

This attempt is from  12-CURRENT system at the bureau, another box, at the
lab's, proceeds successfully and I can retrieve the *_GH0.tar.gz tarball. I
found this out this morning. What is that creepy authentication error?

My confusion has its roots in the fact that with the old scheme the retrieved
files expand in ./work/ in a different way prior to 16th May 2017 - I guess.

Now I have to check why the same alerations to the Makefile of port
devel/opencl work from one 12-CURRENT box (attached to a network from another
provider, FreeBSD 12.0-CURRENT #356 r324638: Sun Oct 15 21:46:03 CEST 2017
amd64) and on the other one not (12-CURRENT also, but last compiled on Friday,
FreeBSD 12.0-CURRENT #59 r324593: Fri Oct 13 14:25:15 CEST 2017 amd64) :-(

Thank you all very much, kind regards

Oliver



> 
> On Mon, Oct 16, 2017, 04:58 Yuri <y...@rawbw.com> wrote:
> 
> > On 10/15/17 12:47, O. Hartmann wrote:  
> > > all right, that is what I picked up from the porter's handbook, but I  
> > must have  
> > > overlooked the note (if there is anything like that) regarding the  
> > sufficient first 7  
> > > digits.  
> >
> > If you look at other ports, most use 7 digits.
> >  
> > > I tried this earlier (yes, and I do also a make makesum ;-))), but I get  
> > a complete  
> > > different "structure" right now - no tarball which contains exactly  
> > OpenCL 2.1 or OpenCL  
> > > 2.2 (the one I'd like to download), but a complete hierarchie of the CL  
> > sources, starting  
> > > from OpenCL 1.0 to OpenCL 2.2. Either, there has been a change in the  
> > way OpenCL headers  
> > > are provided, or there is a magic trick to download, depending on the  
> > GH_TAGNAME, a  
> > > tarball ending in "*_GH0.tar.xz"  
> >
> >
> > The version downloaded using GH_TAGNAME should have the same structure
> > as releases, unless the project structure itsel

Re: [ports]: GH_TAGNAME: how to figure out this tagname on downloadable archives?

[O. Hartmann]

Am Sun, 15 Oct 2017 12:35:49 -0700
Yuri <y...@rawbw.com> schrieb:

> On 10/15/17 12:19, O. Hartmann wrote:
> > Out of the blue there is a so called GH_TAGNAME. It reflects some late 
> > commit/revision
> > number on an archive. Now I try to figure out how to find such a 
> > GH_TAGNAME. Since I
> > do not push stuff to github, it is some new playfield and there might be an 
> > easy way
> > to figure out, but this way is obscured to me right now.  
> 
> 
> GH_TAGNAME is the git commit hash, a hexadecimal number. github shows them 
> for every
> commit. Usually, 7 first characters suffice. GH_TAGNAME overrides the port 
> version when
> tarball is fetched. Just copy and paste it. :-)
> 
> 
> Yuri
> 

Hello, thanks for your response,

all right, that is what I picked up from the porter's handbook, but I must have
overlooked the note (if there is anything like that) regarding the sufficient 
first 7
digits.

I tried this earlier (yes, and I do also a make makesum ;-))), but I get a 
complete
different "structure" right now - no tarball which contains exactly OpenCL 2.1 
or OpenCL
2.2 (the one I'd like to download), but a complete hierarchie of the CL 
sources, starting
from OpenCL 1.0 to OpenCL 2.2. Either, there has been a change in the way 
OpenCL headers
are provided, or there is a magic trick to download, depending on the 
GH_TAGNAME, a
tarball ending in "*_GH0.tar.xz"

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpJxfOH5o8zj.pgp
Description: OpenPGP digital signature

[ports]: GH_TAGNAME: how to figure out this tagname on downloadable archives?

[O. Hartmann]

I'm officially maintaining a small port, devele/opencl. These are header files 
hosted at
Khronos and can be downloaded easily. Now I'm growing gray hair because OpenCL 
headers
have been pushed to version 2.2 and I need to update the port.

Out of the blue there is a so called GH_TAGNAME. It reflects some late 
commit/revision
number on an archive. Now I try to figure out how to find such a GH_TAGNAME. 
Since I do
not push stuff to github, it is some new playfield and there might be an easy 
way to
figure out, but this way is obscured to me right now.

Can somehow please help me in this matter and point me into the right 
direction? I think
the solution is near and easy.

Many thanks in advance,

Oliver

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpQjL3oZmhDB.pgp
Description: OpenPGP digital signature

ports: pkg-static: "x86_64-unknown-freebsd" versus "x86_64-portbld-freebsd"

[O. Hartmann]

A port (lang/pocl), of which I am the official maintainer, fails to build with 
recent
12-CURRENT and recent 11-STABLE:

[...]
===>   Registering installation for pocl-0.14
pkg-static: Unable to access
file 
/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-avx.bc:No
such file or directory pkg-static: Unable to access
file 
/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-avx2.bc:No
such file or directory pkg-static: Unable to access
file 
/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-avx512.bc:No
such file or directory pkg-static: Unable to access
file 
/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-avx_fma4.bc:No
such file or directory pkg-static: Unable to access
file 
/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-sse2.bc:No
such file or directory pkg-static: Unable to access
file 
/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-sse41.bc:No
such file or directory pkg-static: Unable to access
file 
/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-ssse3.bc:No
such file or directory *** Error code 74

The reason seems that on recent systems, in the staging folders, the files in 
question
have been build as 

[...]
find ./ -name "*freebsd12.0-avx.bc" -print
./work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.0-avx.bc
./work/pocl-0.14/lib/kernel/host/kernel-x86_64-portbld-freebsd12.0-avx.bc

so it seems to me as "unknown" gets replaced by "portbld". Performing a

make makeplist

indicates also, that recent build system is taking the "portbld" instead of the
"unknown" (/usr/ports is at revision 452155, CURRENT is at FreeBSD 12.0-CURRENT 
#276
r324621 amd64 and so is the jail I test building lang/pocl within).

Can someone shed some light on this? It would be simple to patch via diff the 
new
pkg-plist file, but I fear the problem indicates something more deeper in some 
changes
for the Mk files.

Thanks in advance,
Oliver
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpH9gLzfFwy_.pgp
Description: OpenPGP digital signature

Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

[O. Hartmann]

Am Tue, 3 Oct 2017 13:08:53 +0200
Kurt Jaeger <li...@opsec.eu> schrieb:

> Hi!
> 
> > When using "poudriere", it seems ABI is freebsd:12:x86:64.  

As I wrote: poudriere repo.

> 
> Where do you get that value from ? If I access a repo,
> I access e.g.
> 
> https://repo.opsec.eu/${ABI}
> 
> and ABI maps to
> 
> FreeBSD:12:amd64
> 



-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpQhS4dABbPJ.pgp
Description: OpenPGP digital signature

ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

[O. Hartmann]

When using "poudriere", it seems ABI is freebsd:12:x86:64. When using FreeBSD 
base, it
seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD world 
uses x86:64,
FreeBSD is using amd64, but why is this used inconsistently all over the places?

I run into trouble setting up some package- and base-servers and ran into the 
problem
when deleting - not thinking of this discovered inconsistency - some links on 
the servers
regarding FreeBSD:12:x86:64 (the same is for 11-STABLE).

Can someone shed some light onto this? 

What am I supposed to use now? The handbook referes to amd64, so I thought 
poudriere
would, too. 

Thanks in advance,

oh
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpY8GiKbV9ge.pgp
Description: OpenPGP digital signature

[poudriere] poudriere non-responsive, zombie sh

[O. Hartmann]

Running FreeBSD 12.0-CURRENT #87 r322472: Sun Aug 13 21:59:36 CEST 2017 amd64
with jail of the same revision, lately the poudriere build system started to
get inresponsive when hitting Ctrl-C or, very often, starts to stop when
showing up which package is deleted or has to be rebuild due to changed
dependencies. usually, the list of deleted/to-be-rebuild packages show up and
then the output flows as packages are build. This stops somehow in the middle
of the output.

Checking the box then via ps/top, I see the a "sh" eating up a tremendous
portion of the CPU time. I have a 4 core/8 threads XEON (IvyBridge based) with
16 GB of RAM using ZFS on a RAIDZ for the poudriere stuff (which induced never
problems in the past). 

When havin hit the Ctrl-C key, there are only two jails left not dying, I have
to use "poudriere jail -k" to kill the jail. But then, the zombie-shell (sh)
remains eating CPU time - no idea wht the shell is doing so far.

This strange behaviour occured within the last two weeks on several poudriere
hosts the same time with unchanged configurations working prior to this
observation.

Waiting long enough - in some cases hours! - the shell will finally die (after
Ctrl-C). I haven't checked whether the poudriere jobs work to the end in the
back when not showing progress on the terminal, I got impatient after a couple
of hours and stopped them.

Seems therer is an issue lately introduced.

Can someone shed some light on it? The problem is erratic - I can not easily
reproduce it, and I also can not say whether it is a ZFS or shell or kernel
issue.


kind regards,

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

devel/glib20: Undefined symbol "environ"

[O. Hartmann]

On recent CURRENT, FreeBSD 12.0-CURRENT #93 r318480: Thu May 18 20:48:25 CEST 
2017 amd64,
with WITH_LLD_IS_LD=yes set, mplayer rejects to work and
fails to start and quits immediately with:

 /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

I already tried to recompile mplayer with "portmaster -df" to hit all ports 
required or
especially recompiled libglib-2.0, but without success. Its strange ...

Is there any hint?

Kind regards and thanks in advance,

O. Hartmann


p.s.: Please CC me, I'm not a subscriber of this list.


pgpxrBuF3BRNb.pgp
Description: OpenPGP digital signature

texinfo/texinfo.tex: size mismatch

[O. Hartmann]

For two days, at least, now, updating ports fail at this point:

fetch: http://ftpmirror.gnu.org/texinfo/texinfo.tex: size mismatch: expected
380351, actual 380556

It seems the size has changed and the distinfo file does not reflect this.

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

/usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

[O. Hartmann]

On recent CURRENT (12.0-CURRENT #38 r317592: Sat Apr 29 17:35:38 CEST 2017  
amd64), with
up to date ports tree, multimedia/mplayer doesn't work any more and quits 
service with

/usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" on console,

and 

/usr/local/lib/libglib-2.0.so.0: Undefined symbol
"environ"write(2,"/usr/local/lib/libglib-2.0.so.0:"...,59) = 59 (0x3b)

write(2,"\n",1)  = 1 (0x1)
exit(0x1)   
process exit, rval = 1

running truss. Any ideas what is up here?

I have WITH_LLD_IS_LD=yes set!

Kind regards,

Oliver

p.s. Pleas CC me! I'm not a subscriber of this channel.

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpT2eCVn7onK.pgp
Description: OpenPGP digital signature

poudriere: security/clamav fails due to deleted devel/llvm36

[O. Hartmann]

Someone/something messed up the ports tree:

[00:00:22] >> Error: security/clamav depends on nonexistent origin
'devel/llvm36'; Please contact maintainer of the port to fix this. [00:00:22]
>> Error: security/clamav-milter depends on nonexistent origin
'devel/llvm36'; Please contact maintainer of the port to fix this.

It seems some dependencies to deleted port devel/llvm36 are still active.

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

Re: poudriere: crossbuilding for arm64 fails: pkg-static: No package files have been found

[O. Hartmann]

Am Thu, 20 Apr 2017 03:29:56 +0200
Jan Beich <jbe...@freebsd.org> schrieb:

> "O. Hartmann" <ohartm...@walstatt.org> writes:
> 
> > Trying to build a repository via poudriere fails on recent 12-CURRENT 
> > (FreeBSD
> > 12.0-CURRENT #2 r317090: Tue Apr 18 15:32:23 CEST 2017 amd64) initially with
> > failing to build ports-mgmt/pkg.
> >
> > poudriere's log reports:
> >
> > [...]
> > configure: error: in `/wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.10.1':
> > configure: error: C compiler cannot create executables  
> 
> Probably https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217189

Maybe, yes. It is a pity.

When starting poudriere to build on 12-CURRENT/arm64, I see a long time nothing 
before
the error pops up. qemu_user_static is running on several instances on a 4-core 
XEON
E3-1245 V2 @ 3.40GHz and ~ 3 to 4 minutes, nothing obviously happens in 
contrary to
amd64's immediate response. The error pops up then very soon.

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpfpy1kBHDea.pgp
Description: OpenPGP digital signature

poudriere: crossbuilding for arm64 fails: pkg-static: No package files have been found

[O. Hartmann]

Trying to build a repository via poudriere fails on recent 12-CURRENT (FreeBSD
12.0-CURRENT #2 r317090: Tue Apr 18 15:32:23 CEST 2017 amd64) initially with
failing to build ports-mgmt/pkg.

poudriere's log reports:

[...]
configure: error: in `/wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.10.1':
configure: error: C compiler cannot create executables

Well, I'm running "home brewn jail" which means that I successfully cross
compiled the 12-CURRENT sources as "TARGET=arm64" and having the obj tree
resulting from this build installed as jail. While installing the jail, I also
included the knob "-x" to "poudriere jail -c -a arm64.aarch64".

The port emulators/qemu-user-static is installed and the kernel module is
loaded successfully.

Ports tree and /usr/src are up to date as of today, additinally, I rebuilt the
qemu emulator and reloaded the kernel module to ensure nothing goes wrong there.

When starting the poudriere build, QEMU reports no issues, but after starting
to build ports-mgmt/pkg, I receive the error shown above.

By the way, CROSS_BINUTILS_PREFIX is not set anywhere in poudriere's config
files, nor do I set this variable in the environment as I think this is set via
the .mk scripts according to settings of "TARGET=" for ARM/ARM64 cross
compiling.

So, what is going wrong here?

Does anyone have an idea?

Thanks in advance,

Oliver

p.s.

Please CC me!
___
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"

www/firefox and poudriere: NotImplementedError: system provides too few semaphores

[O. Hartmann]

On a box running CURENT (FreeBSD 12.0-CURRENT #133 r316717: Tue Apr 11 22:53:06
CEST 2017 amd64), 16 GB RAM, 4-core XEON IvyBridge and jail:

Jail name: head-amd64
Jail version:  12.0-CURRENT
Jail arch: amd64
Jail method:   src=/usr/src
Jail updated:  2017-04-10 07:40:48

building/compiling www/firefox fails with the error shown below:

[...]
Creating config.status
Traceback (most recent call last):
  File "/wrkdirs/usr/ports/www/firefox/work/firefox-53.0/configure.py", line
124, in  sys.exit(main(sys.argv))
  File "/wrkdirs/usr/ports/www/firefox/work/firefox-53.0/configure.py", line
34, in main return config_status(config)
  File "/wrkdirs/usr/ports/www/firefox/work/firefox-53.0/configure.py", line
119, in config_status return config_status(args=[], **encode(sanitized_config,
encoding)) File
"/wrkdirs/usr/ports/www/firefox/work/firefox-53.0/python/mozbuild/mozbuild/config_status.py",
line 136, in config_status reader = BuildReader(env) File
"/wrkdirs/usr/ports/www/firefox/work/firefox-53.0/python/mozbuild/mozbuild/frontend/reader.py",
line 886, in __init__ self._gyp_worker_pool =
ProcessPoolExecutor(max_workers=max_workers) File
"/wrkdirs/usr/ports/www/firefox/work/firefox-53.0/python/futures/concurrent/futures/process.py",
line 274, in __init__ _check_system_limits() File
"/wrkdirs/usr/ports/www/firefox/work/firefox-53.0/python/futures/concurrent/futures/process.py",
line 263, in _check_system_limits raise NotImplementedError(_system_limited)
NotImplementedError: system provides too few semaphores (30 available, 256
necessary)
[...]

I run some other boxes in the lab, larger memeory (32 GB and 64GB), they do now
show this error. What causes it and how can I fix it?

Please CC me, I'm not a subscriber of the ports list.

Thanks in advance,

Oliver
___
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: Cannot build x11/libX11 in poudriere addendum: x11/xcb-util, too

[O. Hartmann]

Am Wed, 29 Mar 2017 19:13:13 +0200
Miroslav Lachman <000.f...@quip.cz> schrieb:

> I am trying to upgrade my package repository which was working fine for 
> a long time. I didn't change any options. Run just usual commands
> 
> # poudriere ports -u -p default
> 
> # poudriere options -z global -p default -f 
> /usr/local/etc/poudriere.d/pkglists/global
> 
> # poudriere bulk -v -j 10_3_amd64 -z global -p default -f 
> /usr/local/etc/poudriere.d/pkglists/global
> 
> but it failed with the following error:
> 
> [00:00:14] >> [01][00:00:00] Starting build of x11/libX11
> [00:00:14] >> [01][00:00:00] Status for build x11/libX11: check-sanity
> [00:00:14] >> [01][00:00:00] Status for build x11/libX11: pkg-depends
> [00:00:15] >> [01][00:00:01] Status for build x11/libX11: fetch-depends
> [00:00:15] >> [01][00:00:01] Status for build x11/libX11: fetch
> [00:00:15] >> [01][00:00:01] Status for build x11/libX11: distfiles 
> /vol0/poudriere/distfiles -> 
> /vol0/poudriere/data/.m/10_3_amd64-default-global/01/portdistfiles
> [00:00:15] >> [01][00:00:01] Status for build x11/libX11: checksum
> [00:00:15] >> [01][00:00:01] Status for build x11/libX11: distfiles 
> /vol0/poudriere/data/.m/10_3_amd64-default-global/01/portdistfiles -> 
> /vol0/poudriere/distfiles
> [00:00:15] >> [01][00:00:01] Status for build x11/libX11: 
> extract-depends
> [00:00:15] >> [01][00:00:01] Status for build x11/libX11: extract
> [00:00:15] >> [01][00:00:01] Status for build x11/libX11: patch-depends
> [00:00:15] >> [01][00:00:01] Status for build x11/libX11: patch
> [00:00:15] >> [01][00:00:01] Status for build x11/libX11: build-depends
> [00:00:17] >> [01][00:00:03] Status for build x11/libX11: lib-depends
> [00:00:17] >> [01][00:00:03] Status for build x11/libX11: configure
> [00:00:19] >> [01][00:00:05] Finished build of x11/libX11: Failed: 
> configure
> [00:00:19] >> [01][00:00:05] Skipping build of devel/apache-ant: 
> Dependent port x11/libX11 failed
> [00:00:19] >> [01][00:00:05] Skipping build of 
> textproc/elasticsearch: Dependent port x11/libX11 failed
> [00:00:19] >> [01][00:00:05] Skipping build of textproc/fop: 
> Dependent port x11/libX11 failed
> [00:00:19] >> [01][00:00:05] Skipping build of java/sigar: Dependent 
> port x11/libX11 failed
> [00:00:19] >> [01][00:00:05] Skipping build of x11/libXext: 
> Dependent port x11/libX11 failed
> [00:00:19] >> [01][00:00:05] Skipping build of x11/libXrender: 
> Dependent port x11/libX11 failed
> [00:00:19] >> [01][00:00:05] Skipping build of x11-toolkits/libXt: 
> Dependent port x11/libX11 failed
> [00:00:19] >> [01][00:00:05] Skipping build of java/openjdk7: 
> Dependent port x11/libX11 failed
> [00:00:19] >> [01][00:00:05] Skipping build of java/openjdk8: 
> Dependent port x11/libX11 failed
> [00:00:19] >> [01][00:00:05] Skipping build of 
> converters/wkhtmltopdf: Dependent port x11/libX11 failed
> [00:00:19] >> Stopping 8 builders
> 
> 
> Poudriere log + work/libX11-1.6.5/config.log are attached.
> 
> Miroslav Lachman
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"

On several building machines (3) the same failure after updating just right now 
the ports
tree and trying rebuilding everything (see below). Every X11 related ports 
fails to
build :-(

[...]
checking for XCB... no
configure: error: Package requirements (xcb >= 1.4) were not met:

Package pthread-stubs was not found in the pkg-config search path.
Perhaps you should add the directory containing `pthread-stubs.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pthread-stubs', required by 'xcb', not found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables XCB_CFLAGS
and XCB_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
===>  Script "configure" failed unexpectedly.
Please report the problem to ga...@freebsd.org [maintainer] and attach the
"/wrkdirs/usr/ports/x11/xcb-util/work/xcb-util-0.4.0/config.log" including
the output of the failure of your make command. Also, it might be a good idea
to provide an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make: stopped in /usr/ports/x11/xcb-util
>> Clean

Re: ELF binary type "3" not known.

[O. Hartmann]

On Mon, 20 Mar 2017 21:11:44 -0700
"Chris H"  wrote:

> On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H"  wrote
> 
> > I'm not sure which of the two lists I'm directing
> > this to is the best/correct one. So I picked both.
> > 
> > To the point; I received this message during a big
> > build session. I was only able to catch the one from
> > x11/nvidia-driver in such a way as to actually get
> > the entire message:
> > 
> > Installing nvidia-driver-375.26_1...
> > ELF binary type "3" not known.
> > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error
> > 
> > I built && installed emulators/linux_base-c7 *prior*
> > to installing this. This is on a:
> > 
> > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
> > Sun Mar 5 09:01:30 PST 2017 amd64  
> Sorry. Forgot to add the ports revision.
> 
> revision 435383
> 
> > 
> > Should I anticipate any problems? All and all, it seems
> > to work. But are there going to be some subtle repercussions?
> > 
> > Is this a 32bit-v-64bit problem with linux_base || the nvidia
> > blob?
> > 
> > Thanks.
> > 
> > --Chris
[...]

I see this in poudriere builds, too. I haven't seen with which builds this
occurs, but it occurs quite often.

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

Re: FreeBSD Port: xf86-video-intel-2.99.917.20170228

[O. Hartmann]

Am Tue, 07 Mar 2017 13:42:02 +0900 (JST)
Masachika ISHIZUKA <i...@amail.plala.or.jp> schrieb:

>   My Dell XPS12 (9Q33, Corei7-4500U, haswell) is working well with
> xf86-video-intel-2.99.917.20170228 (sna) without kld_list="i915kms".
> 
>   Issue for both r435512(2.99.917.20170228) and r433863(2.99.917.20170103)
> is not showing any windows after resuming blanking screen.
> Workaround is that the switching console (ctl-alt-F1) and
> reswitching x11 (clt-alt-F9). It's shown windows again.

Same here with a Lenovo E540 notebook with a Haswell HD4200 graphics.. 
Sometimes the
black screen goes away by itself and the xdm login/X11 graphics screen pops up, 
sometimes
not and I have to switch first to console and then to the tty with the graphics 
output
back to get the GUI.

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgp_uH19PRPbg.pgp
Description: OpenPGP digital signature

net-mgmt/nagvis: Uncaught Error: (0) require(CoreAuthModIcingaweb2.php): failed ...

[O. Hartmann]

First of all: please CC me, I'm not a subscriber to this specific list. Thank
you.

I have a problem with net-mgmt/nagvis and it seems to be a problem with some
php issues.

I'm running 12-CURRENT (most recent) with a ports collection also up to date, I
have a jail running net-mgmt/icingaweb2 (icingaweb2-2.4.1) in addition to the
module which can be found here:
https://github.com/Icinga/icingaweb2-module-nagvis
as well as ist requisite net-mgmt/nagvis.

With the basic config of nagvis and icingaweb2-nagvis, there is a "Maps" tag
lefthand on the icingaweb2 dashboard, but by clicking it, the error below pops
up. This is without any further patching.

[...]
Warning: Uncaught Error: (0) require(CoreAuthModIcingaweb2.php): failed to open
stream: No such file or directory
(/usr/local/www/nagvis/share/server/core/functions/autoload.php:40)

#0 /usr/local/www/nagvis/share/server/core/functions/autoload.php(40):
nagvisExceptionErrorHandler(2, 'require(CoreAut...', '/usr/local/www/...', 40,
Array) #1 /usr/local/www/nagvis/share/server/core/functions/autoload.php(40):
NagVisAutoload() #2 [internal function]: NagVisAutoload('CoreAuthModIcin...')
#3 /usr/local/www/nagvis/share/server/core/classes/CoreAuthHandler.php(47):
spl_autoload_call('CoreAuthModIcin...')
#4 /usr/local/www/nagvis/share/server/core/functions/index.php(44):
CoreAuthHandler->__construct()
#5 /usr/local/www/nagvis/share/frontend/nagvis-js/index.php(53):
require('/usr/local/www/...') #6 {main} thrown
in /usr/local/www/nagvis/share/server/core/functions/autoload.php on line 40

Fatal error: NagVisAutoload(): Failed opening required
'CoreAuthModIcingaweb2.php' 
(include_path='.:/usr/local/share/pear:../../server/core/classes:../../server/core/classes/objects:../../server/core/ext/php-gettext-1.0.9:../../frontend/nagvis-js/classes/')
in /usr/local/www/nagvis/share/server/core/functions/autoload.php on line 40
[...]


With the instructions taken from
https://github.com/Icinga/icingaweb2-module-nagvis, especially the very last
part which injects some PHP code at
/share/server/core/functions/index.php,

one receive this error:

[...]
Warning: Uncaught Error: (0) require_once(Icinga/Application/EmbeddedWeb.php):
failed to open stream: No such file or directory
(/usr/local/www/nagvis/share/server/core/functions/index.php:33)

#0 /usr/local/www/nagvis/share/server/core/functions/index.php(33):
nagvisExceptionErrorHandler(2, 'require_once(Ic...', '/usr/local/www/...', 33,
Array)
#1 /usr/local/www/nagvis/share/server/core/functions/index.php(33):
require_once()
#2 /usr/local/www/nagvis/share/frontend/nagvis-js/index.php(53):
require('/usr/local/www/...')
#3 {main} thrown in /usr/local/www/nagvis/share/server/core/functions/index.php
on line 33

Fatal error: main(): Failed opening required
'Icinga/Application/EmbeddedWeb.php' 
(include_path='.:/usr/local/share/pear:../../server/core/classes:../../server/core/classes/objects:../../server/core/ext/php-gettext-1.0.9:../../frontend/nagvis-js/classes/')
in /usr/local/www/nagvis/share/server/core/functions/index.php on line 33
[...]


The latter one indicates to me that PHP does not know the path, which is
supposed to start with

[/usr/local/www/icingaweb2/library]/Icinga/Application/EmbeddedWeb.php

Well, I'm lost here :-(

Thanks for your patience,

Regards

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

Re: poudriere: failing build after math/proj.4 has been introduced

[O. Hartmann]

Am Sat, 7 Jan 2017 14:48:25 -0700
Adam Weinberger <ad...@adamw.org> schrieb:

> > On 7 Jan, 2017, at 14:26, O. Hartmann <ohartm...@walstatt.org> wrote:
> > 
> > 
> > My poudriere setup fails after a ports tree update with the following error:
> > 
> > [00:00:04] >> Loading MOVED
> > /usr/local/share/poudriere/bulk.sh: cannot
> > create 
> > /pool/poudriere/data/.m/head-amd64-head-default/ref/.p/MOVED/math_libproj4:math/proj.4:
> > No such file or directory
> > 
> > How can this be fixed?
> > 
> > 
> > Please CC me, I'm not subscribing to this list.
> > 
> > Thanks in advance,
> > 
> > oh  
> 
> There was a typo in /usr/ports/MOVED. Should be fixed now.
> 
> # Adam
> 
> 

Thanks, indeed ...

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgproJBMJY53f.pgp
Description: OpenPGP digital signature

poudriere: failing build after math/proj.4 has been introduced

[O. Hartmann]

My poudriere setup fails after a ports tree update with the following error:

[00:00:04] >> Loading MOVED
/usr/local/share/poudriere/bulk.sh: cannot
create 
/pool/poudriere/data/.m/head-amd64-head-default/ref/.p/MOVED/math_libproj4:math/proj.4:
No such file or directory

How can this be fixed?


Please CC me, I'm not subscribing to this list.

Thanks in advance,

oh

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpDa_wHEQZ01.pgp
Description: OpenPGP digital signature

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

[O. Hartmann]

Am Thu, 29 Dec 2016 14:24:51 -0700
Ian Lepore <i...@freebsd.org> schrieb:

> On Thu, 2016-12-29 at 21:17 +0100, O. Hartmann wrote:
> > Am Thu, 29 Dec 2016 20:26:32 +0100
> > Dimitry Andric <d...@freebsd.org> schrieb:
> >   
> > > 
> > > On 29 Dec 2016, at 17:29, O. Hartmann <ohartm...@walstatt.org>
> > > wrote:  
> > > > 
> > > > 
> > > > Am Wed, 7 Dec 2016 23:31:01 +0100
> > > > Dimitry Andric <d...@freebsd.org> schrieb:
> > > >     
> > > > > 
> > > > > On 07 Dec 2016, at 10:42, O. Hartmann <ohartm...@walstatt.org>
> > > > > wrote:    
> > > > > > 
> > > > > > 
> > > > > > I try my first steps in cross compiling ports with poudriere
> > > > > > and therefore I try to
> > > > > > setup an appropriate jail and QEMU environment.
> > > > > > 
> > > > > > Well, I'm failing at the jail setup due to the non-exitence
> > > > > > of any suitable QEMU
> > > > > > environment and for that I tried to figure out to find some
> > > > > > proper HOWTO.
> > > > > > Searching via google ave some hints, but in questions which
> > > > > > QEMU from ports should
> > > > > > be used, all leave me alone, so I tried
> > > > > > 
> > > > > > emulators/qemu
> > > > > > emulators/qemu-devel
> > > > > > emulators/qemu-static
> > > > > > 
> > > > > > emulators/qemu is known for me to fail since months and the
> > > > > > days of 11-CURRENT,
> > > > > > there is a compiler error spit out with clang 3.8 and now
> > > > > > 3.9. The very same for
> > > > > > qemu-devel (both ports used with standard options, no
> > > > > > extras). See also Bug 214873
> > > > > > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214873)
> > > > > > and Bug 215100
> > > > > > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215100).    
> > > > > I couldn't reproduce the compilation errors, it builds fine for
> > > > > me until
> > > > > the link phase.    
> > > > Well, I face this in poudriere on the most recent 12-CURRENT, too
> > > > as well as
> > > > 12-CURRENT buildworld today.
> > > > 
> > > > On the host I'd like to run qemu for testing aarch64 binaries for
> > > > a Odroid-C2
> > > > project, I use a customized /etc/src.conf - but on poudriere,
> > > > there is no such
> > > > customisation but the failing is identical.    
> > > Looking at your errors, it seems that the port has decided to
> > > enable
> > > rdma support.  This is normally enabled using --enable-rdma with
> > > the
> > > configure script, but I don't see that at all in the port Makefile.
> > > 
> > > On my systems, it runs a test to check for rdma support, but this
> > > fails.
> > > Quoting from config.log:
> > > 
> > > cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> > > -D_LARGEFILE_SOURCE
> > > -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
> > > -Wmissing-prototypes -fno-strict-aliasing -fno-common
> > > -I/usr/work/share/dim/ports/emulators/qemu/work/qemu-2.6.1
> > > -I/usr/local/include
> > > -DPREFIX=\""/usr/local\"" -Wno-string-plus-int -Wno-initializer-
> > > overrides
> > > -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs 
> > > -Wformat-security
> > > -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-
> > > definition -Wtype-limits
> > > -fstack-protector-strong -I/usr/local/include
> > > -I/usr/local/include/p11-kit-1
> > > -I/usr/local/include -o config-temp/qemu-conf.exe config-temp/qemu-
> > > conf.c -m64 -g
> > > -fstack-protector -L"/usr/local/lib" -lrdmacm -libverbs config-
> > > temp/qemu-conf.c:1:10:
> > > fatal error: 'rdma/rdma_cma.h' file not found #include
> > >  ^
> > > 
> > > The minimal test program it tries to compile here is just this:
> > > 
> > > #include 
> > > int main(void) { return 0; }
> > > 
> > > and it attempts to link it with -lrdmacm -libverbs.  If this
> > > somehow
> > > succeeds on your s

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

[O. Hartmann]

Am Thu, 29 Dec 2016 20:26:32 +0100
Dimitry Andric <d...@freebsd.org> schrieb:

> On 29 Dec 2016, at 17:29, O. Hartmann <ohartm...@walstatt.org> wrote:
> > 
> > Am Wed, 7 Dec 2016 23:31:01 +0100
> > Dimitry Andric <d...@freebsd.org> schrieb:
> >   
> >> On 07 Dec 2016, at 10:42, O. Hartmann <ohartm...@walstatt.org> wrote:  
> >>> 
> >>> I try my first steps in cross compiling ports with poudriere and 
> >>> therefore I try to
> >>> setup an appropriate jail and QEMU environment.
> >>> 
> >>> Well, I'm failing at the jail setup due to the non-exitence of any 
> >>> suitable QEMU
> >>> environment and for that I tried to figure out to find some proper HOWTO.
> >>> Searching via google ave some hints, but in questions which QEMU from 
> >>> ports should
> >>> be used, all leave me alone, so I tried
> >>> 
> >>> emulators/qemu
> >>> emulators/qemu-devel
> >>> emulators/qemu-static
> >>> 
> >>> emulators/qemu is known for me to fail since months and the days of 
> >>> 11-CURRENT,
> >>> there is a compiler error spit out with clang 3.8 and now 3.9. The very 
> >>> same for
> >>> qemu-devel (both ports used with standard options, no extras). See also 
> >>> Bug 214873
> >>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214873) and Bug 215100
> >>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215100).  
> >> 
> >> I couldn't reproduce the compilation errors, it builds fine for me until
> >> the link phase.  
> > 
> > Well, I face this in poudriere on the most recent 12-CURRENT, too as well as
> > 12-CURRENT buildworld today.
> > 
> > On the host I'd like to run qemu for testing aarch64 binaries for a 
> > Odroid-C2
> > project, I use a customized /etc/src.conf - but on poudriere, there is no 
> > such
> > customisation but the failing is identical.  
> 
> Looking at your errors, it seems that the port has decided to enable
> rdma support.  This is normally enabled using --enable-rdma with the
> configure script, but I don't see that at all in the port Makefile.
> 
> On my systems, it runs a test to check for rdma support, but this fails.
> Quoting from config.log:
> 
> cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
> -Wmissing-prototypes -fno-strict-aliasing -fno-common
> -I/usr/work/share/dim/ports/emulators/qemu/work/qemu-2.6.1 
> -I/usr/local/include
> -DPREFIX=\""/usr/local\"" -Wno-string-plus-int -Wno-initializer-overrides
> -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs 
> -Wformat-security
> -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-definition 
> -Wtype-limits
> -fstack-protector-strong -I/usr/local/include -I/usr/local/include/p11-kit-1
> -I/usr/local/include -o config-temp/qemu-conf.exe config-temp/qemu-conf.c 
> -m64 -g
> -fstack-protector -L"/usr/local/lib" -lrdmacm -libverbs 
> config-temp/qemu-conf.c:1:10:
> fatal error: 'rdma/rdma_cma.h' file not found #include  ^
> 
> The minimal test program it tries to compile here is just this:
> 
> #include 
> int main(void) { return 0; }
> 
> and it attempts to link it with -lrdmacm -libverbs.  If this somehow
> succeeds on your system, then it will think rdma support is available,
> while apparently the support is not complete, if it misses the
> rdma_getaddrinfo() function.
> 
> Do you have some Linux rdma or infiniband headers or libraries installed
> into /usr or /usr/local?  This might be the cause of the problems.
> 
> If you don't want or care about rdma, you can try the following patch
> (should similarly apply to the other qemu ports):
> 
> Index: emulators/qemu/Makefile
> ===
> --- emulators/qemu/Makefile (revision 429888)
> +++ emulators/qemu/Makefile (working copy)
> @@ -78,6 +78,7 @@
> --disable-libssh2 --enable-debug \
> --prefix=${PREFIX} --cc=${CC} --enable-docs --disable-kvm \
> --disable-linux-user --disable-linux-aio --disable-xen \
> +   --disable-rdma \
> --smbd=${LOCALBASE}/sbin/smbd --enable-debug-info
> --python=${PYTHON_CMD} \ --extra-cflags=-I${WRKSRC}\ -I${LOCALBASE}/include\
> -DPREFIX=\\\"\"${PREFIX}\\\"\"
> 
> -Dimitry
> 

emulators/qemu bugged out at:

[...]
/usr/bin/ld:../config-host.ld:14: syntax error
c++: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[3]: *** [Makefile:195: qemu-sparc64] Error 1

I think so far this is a real bug?

I'll adjust the PR in bugzilla.

I also opened another PR regarding the real bug reported earlier, you'll find 
the PR here:

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


Kind regards,
oh

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpODZN0F4vom.pgp
Description: OpenPGP digital signature

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

[O. Hartmann]

Am Thu, 29 Dec 2016 20:26:32 +0100
Dimitry Andric <d...@freebsd.org> schrieb:

> On 29 Dec 2016, at 17:29, O. Hartmann <ohartm...@walstatt.org> wrote:
> > 
> > Am Wed, 7 Dec 2016 23:31:01 +0100
> > Dimitry Andric <d...@freebsd.org> schrieb:
> >   
> >> On 07 Dec 2016, at 10:42, O. Hartmann <ohartm...@walstatt.org> wrote:  
> >>> 
> >>> I try my first steps in cross compiling ports with poudriere and 
> >>> therefore I try to
> >>> setup an appropriate jail and QEMU environment.
> >>> 
> >>> Well, I'm failing at the jail setup due to the non-exitence of any 
> >>> suitable QEMU
> >>> environment and for that I tried to figure out to find some proper HOWTO.
> >>> Searching via google ave some hints, but in questions which QEMU from 
> >>> ports should
> >>> be used, all leave me alone, so I tried
> >>> 
> >>> emulators/qemu
> >>> emulators/qemu-devel
> >>> emulators/qemu-static
> >>> 
> >>> emulators/qemu is known for me to fail since months and the days of 
> >>> 11-CURRENT,
> >>> there is a compiler error spit out with clang 3.8 and now 3.9. The very 
> >>> same for
> >>> qemu-devel (both ports used with standard options, no extras). See also 
> >>> Bug 214873
> >>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214873) and Bug 215100
> >>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215100).  
> >> 
> >> I couldn't reproduce the compilation errors, it builds fine for me until
> >> the link phase.  
> > 
> > Well, I face this in poudriere on the most recent 12-CURRENT, too as well as
> > 12-CURRENT buildworld today.
> > 
> > On the host I'd like to run qemu for testing aarch64 binaries for a 
> > Odroid-C2
> > project, I use a customized /etc/src.conf - but on poudriere, there is no 
> > such
> > customisation but the failing is identical.  
> 
> Looking at your errors, it seems that the port has decided to enable
> rdma support.  This is normally enabled using --enable-rdma with the
> configure script, but I don't see that at all in the port Makefile.
> 
> On my systems, it runs a test to check for rdma support, but this fails.
> Quoting from config.log:
> 
> cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
> -Wmissing-prototypes -fno-strict-aliasing -fno-common
> -I/usr/work/share/dim/ports/emulators/qemu/work/qemu-2.6.1 
> -I/usr/local/include
> -DPREFIX=\""/usr/local\"" -Wno-string-plus-int -Wno-initializer-overrides
> -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs 
> -Wformat-security
> -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-definition 
> -Wtype-limits
> -fstack-protector-strong -I/usr/local/include -I/usr/local/include/p11-kit-1
> -I/usr/local/include -o config-temp/qemu-conf.exe config-temp/qemu-conf.c 
> -m64 -g
> -fstack-protector -L"/usr/local/lib" -lrdmacm -libverbs 
> config-temp/qemu-conf.c:1:10:
> fatal error: 'rdma/rdma_cma.h' file not found #include  ^
> 
> The minimal test program it tries to compile here is just this:
> 
> #include 
> int main(void) { return 0; }
> 
> and it attempts to link it with -lrdmacm -libverbs.  If this somehow
> succeeds on your system, then it will think rdma support is available,
> while apparently the support is not complete, if it misses the
> rdma_getaddrinfo() function.
> 
> Do you have some Linux rdma or infiniband headers or libraries installed
> into /usr or /usr/local?  This might be the cause of the problems.

No Linux, but I found these files on all of the boxes in question:

locate rdma

[...]
/usr/include/rdma
/usr/include/rdma/rdma_cma.h
/usr/include/rdma/rdma_cma_abi.h
/usr/lib/librdmacm.a
/usr/lib/librdmacm.so
/usr/lib/librdmacm.so.1

ll usr/include/rdma discovers:

total 44
322075 drwxr-xr-x   2 root  wheel  -  512B Oct  7 13:52 ./
240768 drwxr-xr-x  55 root  wheel  -  6.5K Dec 29 19:14 ../
324275 -r--r--r--   1 root  wheel  -   21K Oct  7 13:52 rdma_cma.h
324276 -r--r--r--   1 root  wheel  -  4.7K Oct  7 13:52 rdma_cma_abi.h

and

ll /usr/lib/librdma*
804463 -r--r--r--  1 root  wheel  -   28K Dec 18 16:34 /usr/lib/librdmacm.a
804127 lrwxr-xr-x  1 root  wheel  -   14B Dec 29 19:15 /usr/lib/librdmacm.so@ ->
librdmacm.so.1 804128 -r--r--r--  1 root  wheel  -   24K Dec 29
19:15 /usr/lib/librdmacm.so.1


As you can see, the libraries are of the date of the last full install of the 
system,
while the headers seem to be remains from October?

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

[O. Hartmann]

Am Wed, 7 Dec 2016 23:31:01 +0100
Dimitry Andric <d...@freebsd.org> schrieb:

> On 07 Dec 2016, at 10:42, O. Hartmann <ohartm...@walstatt.org> wrote:
> > 
> > I try my first steps in cross compiling ports with poudriere and therefore 
> > I try to
> > setup an appropriate jail and QEMU environment.
> > 
> > Well, I'm failing at the jail setup due to the non-exitence of any suitable 
> > QEMU
> > environment and for that I tried to figure out to find some proper HOWTO.
> > Searching via google ave some hints, but in questions which QEMU from ports 
> > should be
> > used, all leave me alone, so I tried
> > 
> > emulators/qemu
> > emulators/qemu-devel
> > emulators/qemu-static
> > 
> > emulators/qemu is known for me to fail since months and the days of 
> > 11-CURRENT, there
> > is a compiler error spit out with clang 3.8 and now 3.9. The very same for 
> > qemu-devel
> > (both ports used with standard options, no extras). See also Bug 214873
> > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214873) and Bug 215100
> > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215100).  
> 
> I couldn't reproduce the compilation errors, it builds fine for me until
> the link phase.

Well, I face this in poudriere on the most recent 12-CURRENT, too as well as 
12-CURRENT
buildworld today.

On the host I'd like to run qemu for testing aarch64 binaries for a Odroid-C2 
project, I
use a customized /etc/src.conf - but on poudriere, there is no such 
customisation but
the failing is identical.

> 
> 
> > I tried also emulators/qemu-static, but it also fails compiling on most 
> > recent
> > 12-CURRENT (as the others, too, also my poudriere environment, which has 
> > also CURRENT
> > jails) with
> > 
> > [...]
> > /usr/bin/ld:../config-host.ld:14: syntax error
> > c++: error: linker command failed with exit code 1 (use -v to see 
> > invocation)
> > [...]  
> 
> But this I *can* reproduce.  It appears qemu wants to set the text
> segment start address, using the -Ttext-segment=0x6000 option to ld.
> 
> However, our base ld does not yet support this option, and then the
> configure script tries to patch the default linker script using the
> following construct:
> 
>   $ld --verbose | sed \
> -e '1,/==/d' \
> -e '/==/,$d' \
> -e "s/[.] = [0-9a-fx]* [+] SIZEOF_HEADERS/. = $textseg_addr + 
> SIZEOF_HEADERS/" \
> -e "s/__executable_start = [0-9a-fx]*/__executable_start = 
> $textseg_addr/" >
> config-host.ld
> 
> Unfortunately, it seems to run /usr/local/bin/ld in this case, and this
> results in the following busted linker script line, which cannot be
> parsed:
> 
>   PROVIDE (__executable_start = 0x6000SEGMENT_START("text-segment", 
> 0x08048000)); .
> = SEGMENT_START("text-segment", 0x08048000) + SIZEOF_HEADERS;
> 
> If it would use /usr/bin/ld instead, the patching would succeed, and
> the line would become:
> 
>   PROVIDE (__executable_start = 0x6000); . = 0x6000 + SIZEOF_HEADERS;
> 
> which is probably what was intended.
> 
> Probably, the configure script needs to be patched to run base ld,
> or use the same ld invocation for both checking the -Ttext-segment
> option support and patching the linker script.
> 
> -Dimitry
> 

Since for now all three QEMU ports are incapacitated, I start to float like a 
dead man in
the water. I do not know where to start looking for possible sources for the
miscompilations and I'm wondering why others running 12-CURRENT do not see the 
problem. I
tried on different 12-CURRENT systems I have access to and its everwhere the 
same.
Either, a mysterious configuration issue that finds its way also into poudriere 
- over
clang 3.8 as well as 3.9.0 and 3.9.1 (I think it is 3.9.1 the most recent one I 
used).

Any hope?


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpHtaDcFZIIP.pgp
Description: OpenPGP digital signature

emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

[O. Hartmann]

Hello out there.

I try my first steps in cross compiling ports with poudriere and therefore I 
try to setup
an appropriate jail and QEMU environment.

Well, I'm failing at the jail setup due to the non-exitence of any suitable QEMU
environment and for that I tried to figure out to find some proper HOWTO. 
Searching via google ave some hints, but in questions which QEMU from ports 
should be
used, all leave me alone, so I tried

emulators/qemu
emulators/qemu-devel
emulators/qemu-static

emulators/qemu is known for me to fail since months and the days of 11-CURRENT, 
there is a
compiler error spit out with clang 3.8 and now 3.9. The very same for 
qemu-devel (both
ports used with standard options, no extras). See also Bug 214873
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214873) and Bug 215100
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215100).

I tried also emulators/qemu-static, but it also fails compiling on most recent 
12-CURRENT
(as the others, too, also my poudriere environment, which has also CURRENT 
jails) with 

[...]
/usr/bin/ld:../config-host.ld:14: syntax error
c++: error: linker command failed with exit code 1 (use -v to see invocation)
[...]

in several occurences.

At the moment I feel lost at this point, since the likelyhood of all ports 
failing is
either incompatibility with CURRENT/clang 3.9 or something is weird with my 
setup. But on
the other hand, my poudriere environment is setup a kind of "vanilla" - no 
extras, just
straight forward compiler options.

I need some advice here how to build QEMU on my on.

Pleas CC me, I do not subscribe "freebsd-ports" list. And please apoligize for
crossposting, but I didn't really know to which list this might could belong 
to. 

Thanks in advance for patience and advice,

Oliver


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpQbTCiEPoXL.pgp
Description: OpenPGP digital signature

poudriere: problems setting options/build failure ZTS related stuff

[O. Hartmann]

Hello out here,

first, please CC me, I'm not actively subscribing this list.

Since a couple of weeks now I face a nasty problem with building ports using 
poudriere.
For our department's infrastructure and my home office's jails, I provide 
packages build
with poudriere.

Having a threaded Apache, port www/apache24, this requires several ports to 
have option
ZTS enabled, in particular lang/php56, www/mod_php56 and subsequent ports.


I have already filed a PR:

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

But obviusly, there is nobody else facing this problem and this lead to the 
conclusion,
that no one else is using a threaded Apache 2.4 with the requirement of setting 
option
ZTS in related PHP stuff. The problem is always the same:

devel/pear: ERR: pear-1.10.1 depends on file: 
/usr/local/lib/php/20131226/xml.so - not
found

or

textproc/php56-xmlreader: ERR: php56-xmlreader-5.6.28 depends on
file: /usr/local/lib/php/20131226/dom.so - not found

or

databases/php56-pdo_pgsql: ERR: php56-pdo_pgsql-5.6.28 depends on
file: /usr/local/lib/php/20131226/pdo.so - not found

and so forth. The missing modules are expected to reside
in /usr/local/lib/php/20131226-zts/ instead of the error
triggering /usr/local/lib/php/20131226.

That would indicated to me that some ports, especially related to XML, PDO and 
so forth
are not found by the specific ports. They are definitely installed
in /usr/local/lib/php/20131226-zts/ during the poudriere build - but the ports 
requiring
those modules seem to not to respect the ZTS appendix to the path.

I deleted ALL(!) php56 related packages from the packaged folder forcing 
pourdriere to
start rebuilding all of these packages and further I ran again through the very 
time
costly procidure of configuration. But that didn't help much, the problems 
stayed. So I
decided to delete all packages with "poudriere bulk -c" - that is something 
people want
to avoid since it takes ages on slow machines. But even that is without effect!

Since a lot of ports require a working php56 environment, like wikimedia,
icinga2/icingaweb2 and many others we use, updating the jails automatically via 
pkg is a
mess resulting in non-working bugzilla50, for instance - its php environment 
complains
about not finding the required modules anymore. That corrupts the whole 
ports/pkg idea!

On the contrary, when doing a classical, rock-solid installation via the "make 
install"
way, everything is smooth. Even packages build via "make package" respect the 
ZTS
settings. On four target servers and two other machines I tried this and it 
worked.

I'm not much familiar with poudriere but this problem popped out of the blue a 
couple of
weeks for now and I'm unwilling to bisect it. I thought pkg/poudriere might be 
a solution
to reduce workload on updates for a bunch of jails we use, but this problem is 
bugging me
really hard. I have no clue how to circumvent or fix it. 

I'll try to build a manual package via make and commit this to the package repo 
in the
hope it will temporarily fix the problem, but this couldn't be a long-term 
solution.

It would be nice if someone could hint me towards what I'm doing wrong here or 
look at
the problem. The other question is: is ZTS REALLY(?) necessary? There is a 
strong warning
popping up when building www/mod_php56 regarding to this.


Many thanks in advance,

Oliver





-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgp1AXICJxKBo.pgp
Description: OpenPGP digital signature

Re: [poudriere]: lang/php56 is unwilling to build with ZTS

[O. Hartmann]

Am Thu, 3 Nov 2016 12:03:55 +1000
Dima Panov <flu...@freebsd.org> schrieb:

> 01.11.16 20:49, O. Hartmann пишет:
> > Obviously I ran into a problem with recent poudriere on CURRENT building 
> > ports
> > in a CURRENT jail.
> > 
> > Building threaded www/apache24 requires lang/php56 having option ZTS set. I 
> > did
> > so. I tried to rebuild all depending ports, but I run into rpoblems then 
> > with
> > php56: for instance, textproc/php56-xmlreader fails to build, the poudriere 
> > log
> > gives the reason:
> >   
> > ===>   php56-xmlreader-5.6.27 depends on  
> > file: /usr/local/lib/php/20131226/dom.so - not found
> > 
> > On systems with properly set ZTS, the expected folder for PHP modules would 
> > be
> > 
> > /usr/local/lib/php/20131226-zts/
> > 
> > When I first discovered this, I tried to delete and rebuild lang/php56 from
> > packages - definitely with option ZTS set - but the error is persistant.
> > 
> > I'm unwilling to rebuild ALL thousands of packages, so I need some advice 
> > how
> > to solve this problem.
> > 
> > Please CC me, I do not subscribe the list. Thanks.
> > 
> > Thank you very much in advance,
> >   
> 
> Some tweaks with poudriere build environment requred to suport ZTS build:
> 
> cat /usr/local/poudriere.d/make.conf
> 
> # www/apache24
> WITH_MPM=event
> 
> 
> Meanwhile, I've got today another problem with poudriere. 
> 
> 'poudriere options' with non-default portstree uses options subdir from 
> default tree, 
> but 'poudriere bulk' hooks up the right options tree, without configured 
> options, at
> all. 
> 
> 
> 
> 

I have not come far since then, the problem still persists. I figured out that 
even if
issuing the command:

poudriere bulk -p head -z default -j head-amd64 -C lang/php56

which is supposed to delete the package lang/php56 and rebuild it, the package 
is
rebuilt, but it does not respect the option WITH ZTS. The jail's sources are 
most recent
12-CURRENT, the build system is residing on a ZFS volume for convenience. I 
keep three
instances of old packages, so in my case the location

/pool/poudriere/data/packages/head-amd64-head-default/.latest 

which is a symbolic link to the most recent and last built, still holds a 
package
lang/php56 which ist several days old, although I changed the option ZTS twice 
AND
issuing the above command forcing a rebuild! Obviously poudriere does not 
respect this
and seems to be ignoring or confusing the directories - I do not know. By now, 
I manually
deleted several packages in the lates ".latest" folder, selected by date and 
tried to
restart building my packages. poudriere then came up with more than 600 
packages to be
rebuild. But it still fails on some key packages:

textproc/php56-wddx:
[...]
===>   php56-wddx-5.6.27 depends on file: /usr/local/lib/php/20131226/xml.so - 
not found
===>   Installing existing package /packages/All/php56-xml-5.6.27.txz


devel/pear:
===>   pear-1.10.1 depends on file: /usr/local/lib/php/20131226/xml.so - not 
found
===>   Installing existing package /packages/All/php56-xml-5.6.27.txz

and additionally:
textproc/php56-xmlreader
textproc/php56-xsl
databases/php56-pdo_pgsql


They all seem to have their problems sourced in php56-xml-5.6.27.txz. I also 
tried to
rebuild exactly this package php56-xml-5.6.27.txz - but without success, I also 
deleted
it and all(!) php56-xxx ports and jumping into the very same problem of a huge 
amount of
rebuilds.

So, I suspect some problems regarding ZTS build in XML-related ports, or a 
general
problem of poudriere. By deleting all php56-xxx packages and proper configuring 
the
options for lang/php56 as well as www/apache24 and devel/apr1, I would expect 
that 

/usr/local/lib/php/20131226-zts/xml.so

would appear instead of

/usr/local/lib/php/20131226/xml.so.

I'm lost here! My resources are limited, builds take a whole day on my box and 
I'm no
expert in the abyss of poudriere, so to answere the question, what my 

usr/local/etc/php.conf

(in poudriere) look like, I need help.

/usr/local/etc/php.conf on my systems which use custom build via portmaster 
looks correct:

PHP_VER=56
PHP_VERSION=5.6.27
PHP_SAPI=cli cgi fpm
PHP_EXT_INC=pcre spl
PHP_EXT_DIR=20131226-zts

But this is not poudriere's environment.

Kind regards,

Oliver

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [poudriere]: lang/php56 is unwilling to build with ZTS

[O. Hartmann]

Am Thu, 3 Nov 2016 12:03:55 +1000
Dima Panov <flu...@freebsd.org> schrieb:

> 01.11.16 20:49, O. Hartmann пишет:
> > Obviously I ran into a problem with recent poudriere on CURRENT building 
> > ports
> > in a CURRENT jail.
> > 
> > Building threaded www/apache24 requires lang/php56 having option ZTS set. I 
> > did
> > so. I tried to rebuild all depending ports, but I run into rpoblems then 
> > with
> > php56: for instance, textproc/php56-xmlreader fails to build, the poudriere 
> > log
> > gives the reason:
> >   
> > ===>   php56-xmlreader-5.6.27 depends on  
> > file: /usr/local/lib/php/20131226/dom.so - not found
> > 
> > On systems with properly set ZTS, the expected folder for PHP modules would 
> > be
> > 
> > /usr/local/lib/php/20131226-zts/
> > 
> > When I first discovered this, I tried to delete and rebuild lang/php56 from
> > packages - definitely with option ZTS set - but the error is persistant.
> > 
> > I'm unwilling to rebuild ALL thousands of packages, so I need some advice 
> > how
> > to solve this problem.
> > 
> > Please CC me, I do not subscribe the list. Thanks.
> > 
> > Thank you very much in advance,
> >   
> 
> Some tweaks with poudriere build environment requred to suport ZTS build:
> 
> cat /usr/local/poudriere.d/make.conf
> 
> # www/apache24
> WITH_MPM=event

I used WITH_MPM=worker which should provide also a threaded Apache 2.4

> 
> 
> Meanwhile, I've got today another problem with poudriere. 
> 
> 'poudriere options' with non-default portstree uses options subdir from 
> default tree, 
> but 'poudriere bulk' hooks up the right options tree, without configured 
> options, at
> all. 
> 
> 
> 
> 

The problem must be located around the lang/php56 port/package. When ZTS 
enabled, I would
expect to find php plugin libs in 

/usr/local/lib/php/20131226-zts/

but the failing ports report all a non-available /usr/local/lib/php/20131226/ 
folder,
please consider the difference!

At this very moment, even a fresh clean start of the poudriere build does end 
up in
failures for the follwoing ports:

textproc/php56-wddx
databases/php56-pdo_sqlite
databases/php56-pdo_pgsql
databases/php56-pdo_mysql
devel/pear
textproc/php56-xmlreader
textproc/php56-xsl
net/phpldapadmin
databases/phppgadmin
devel/websvn

This failure occurs only in poudriere. If the ports are installed the proper way
via /usr/ports and make, everything seems correct.


pgp6pHMDJvkk1.pgp
Description: OpenPGP digital signature

[poudriere]: lang/php56 is unwilling to build with ZTS

[O. Hartmann]

Obviously I ran into a problem with recent poudriere on CURRENT building ports
in a CURRENT jail.

Building threaded www/apache24 requires lang/php56 having option ZTS set. I did
so. I tried to rebuild all depending ports, but I run into rpoblems then with
php56: for instance, textproc/php56-xmlreader fails to build, the poudriere log
gives the reason:

===>   php56-xmlreader-5.6.27 depends on
file: /usr/local/lib/php/20131226/dom.so - not found

On systems with properly set ZTS, the expected folder for PHP modules would be

/usr/local/lib/php/20131226-zts/

When I first discovered this, I tried to delete and rebuild lang/php56 from
packages - definitely with option ZTS set - but the error is persistant.

I'm unwilling to rebuild ALL thousands of packages, so I need some advice how
to solve this problem.

Please CC me, I do not subscribe the list. Thanks.

Thank you very much in advance,

oh
___
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: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

[O. Hartmann]

Am Fri, 7 Oct 2016 14:03:52 +0200
Dimitry Andric <d...@freebsd.org> schrieb:

> On 07 Oct 2016, at 13:59, Dimitry Andric <d...@freebsd.org> wrote:
> > 
> > On 07 Oct 2016, at 13:43, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:  
> ...
> >> YES :-(
> >> 
> >> /usr/include/include does exist ...  
> > 
> > Right, so that is pretty strange.  Maybe it was an artefact of some
> > failed installation?  In any case, I would blow it away.
> > 
> > Btw, it looks like the eigen port uses pkgconfig, can you please post
> > the contents of your /usr/local/libdata/pkgconfig/eigen3.pc file?  
> 
> For reference, on my system where I just freshly compiled eigen3, the
> contents is this:
> 
> 
> prefix=/usr/local
> exec_prefix=${prefix}
> 
> Name: Eigen3
> Description: A C++ template library for linear algebra: vectors, matrices, 
> and related
> algorithms Requires:
> Version: 3.2.10
> Libs:
> Cflags: -I${prefix}/include/eigen3
> 
> 
> -Dimitry
> 

Mine looks the same:
---
prefix=/usr/local
exec_prefix=${prefix}

Name: Eigen3
Description: A C++ template library for linear algebra: vectors, matrices, and 
related
algorithms Requires:
Version: 3.2.10
Libs:
Cflags: -I${prefix}/include/eigen3
---


pgpurtt4JBOGf.pgp
Description: OpenPGP digital signature

Re: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

[O. Hartmann]

Am Fri, 7 Oct 2016 13:59:05 +0200
Dimitry Andric <d...@freebsd.org> schrieb:

> On 07 Oct 2016, at 13:43, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
> > 
> > Am Fri, 7 Oct 2016 13:27:19 +0200
> > Dimitry Andric <d...@freebsd.org> schrieb:  
> >> On 07 Oct 2016, at 10:26, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote: 
> >>  
> ...
> >>> In file included
> >>> from 
> >>> /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
> >>> In file included from /usr/include/c++/v1/algorithm:624: In file included
> >>> from /usr/include/c++/v1/initializer_list:47: 
> >>> /usr/include/c++/v1/cstddef:43:15:
> >>> fatal error: 'stddef.h' file not found #include_next   
> >> 
> >> So for some reason, on your system, the compilation flags include
> >> -isystem /usr/include/include, which is rather strange.  I would not
> >> expect this to break compilation in the fashion you are seeing.  Do you
> >> have an /usr/include/include directory on your system, by any chance?  
> > 
> > YES :-(
> > 
> > /usr/include/include does exist ...  
> 
> Right, so that is pretty strange.  Maybe it was an artefact of some
> failed installation?  In any case, I would blow it away.

Within the past years, I slide from one CURRENT to the next. There was no 
accdent as far
as I can recall, but due to the fact I do quite often a recompilation of the 
system, the
likelyhood of hitting the fan (or problems) is quite high. I gues this is a 
remnant of
some problems not visible to me.


I blew the /usr/include/include folder, but then the system rejected to 
buildworld. I had
to reinstall world, did a complete buildworld/buildkernel with recent sources 
and started
recompilation of updated ports. Now, graphics/opencv2-core compiles!

Thank you very much. Quite impressive!

> 
> Btw, it looks like the eigen port uses pkgconfig, can you please post
> the contents of your /usr/local/libdata/pkgconfig/eigen3.pc file?
> 
> -Dimitry
> 

Content of /usr/local/libdata/pkgconfig/eigen3.pc:

prefix=/usr/local
exec_prefix=${prefix}

Name: Eigen3
Description: A C++ template library for linear algebra: vectors, matrices, and 
related
algorithms Requires:
Version: 3.2.10
Libs:
Cflags: -I${prefix}/include/eigen3

Thank you very much and kind regards,

Oliver



pgpMOt6T5uwuW.pgp
Description: OpenPGP digital signature

Re: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

[O. Hartmann]

Am Fri, 7 Oct 2016 13:27:19 +0200
Dimitry Andric <d...@freebsd.org> schrieb:

> On 07 Oct 2016, at 10:26, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
> > 
> > I'm being haunted by this error on two CURRENT systems, while several other 
> > CURRENT
> > systems with identical src.conf and make.conf are not affected, please see 
> > below.  
> ...
> > cd /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core && 
> > /usr/bin/c++
> > -DCVAPI_EXPORTS
> > -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/dynamicuda/include
> > -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core
> > -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src
> > -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include
> > -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1
> > -isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 -pipe 
> > -O3
> > -march=native -fstack-protector -fno-strict-aliasing   -fsigned-char -W
> > -Werror=return-type -Werror=address -Werror=sequence-point -Wformat
> > -Werror=format-security -Wmissing-declarations -Wmissing-prototypes
> > -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow 
> > -Wsign-promo
> > -Wno-narrowing -Wno-delete-non-virtual-dtor -Wno-unnamed-type-template-args
> > -Wno-array-bounds -fdiagnostics-show-option -Wno-long-long -pthread
> > -fomit-frame-pointer -msse -msse2 -mavx -mavx2 -ffunction-sections -O2 
> > -pipe -O3
> > -march=native -fstack-protector -fno-strict-aliasing  -DNDEBUG -fPIC -o
> > CMakeFiles/opencv_core.dir/src/arithm.cpp.o  
> ...
> > In file included
> > from 
> > /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
> > In file included from /usr/include/c++/v1/algorithm:624: In file included
> > from /usr/include/c++/v1/initializer_list:47: 
> > /usr/include/c++/v1/cstddef:43:15: fatal
> > error: 'stddef.h' file not found #include_next   
> 
> So for some reason, on your system, the compilation flags include
> -isystem /usr/include/include, which is rather strange.  I would not
> expect this to break compilation in the fashion you are seeing.  Do you
> have an /usr/include/include directory on your system, by any chance?

YES :-(

/usr/include/include does exist ... 

> 
> That said, for me graphics/opencv2-core compiles just fine, and the
> compilation flags only have an -isystem option to point at the
> /usr/local/include/eigen3 directory.
> 
> Maybe the problem lies in the eigen3 port?  I assume this will have a
> pkg-config file, or some other way at getting the required CFLAGS and
> CXXFLAGS for using it.
> 
> -Dimitry
> 



pgpneRHRk0FK3.pgp
Description: OpenPGP digital signature

Re: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

[O. Hartmann]

Am Fri, 7 Oct 2016 02:31:54 -0700
Mark Millard <mar...@dsl-only.net> schrieb:

> On 2016-Oct-7, at 2:14 AM, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
> > 
> > Am Fri, 7 Oct 2016 02:00:34 -0700
> > Mark Millard <mar...@dsl-only.net> schrieb:
> >   
> >> O. Hartmann ohartman at zedat.fu-berlin.de wrote on Fri Oct 7 08:26:27 UTC 
> >> 2016 . . .
> >> 
> >> . . . of having problems with not finding  during some port 
> >> builds.
> >> 
> >> 
> >> Is there a difference in the -isystem command line options for c++ for the 
> >> working
> >> vs. failing contexts?
> >> 
> >> I will presume that there is based on the following. . . (At least it 
> >> gives you
> >> something to look into.)
> >> 
> >> 
> >> 
> >> The issue is not specific to just graphics/opencv-core and 
> >> graphics/blender ports:
> >> others also have problems with the use of -isystem for C++ compiles. See:
> >> 
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213217
> >> 
> >> in particular Comment #2 from Dimitry Andric.
> >> 
> >> The problem is in how -isystem is used vs. what is needed for libc++ 3.8.0 
> >> .
> >> 
> >> From O. Hartmann's message text:
> >> 
> >> . . .  
> >>> -isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 
> >>> -pipe -O3
> >> . . .  
> >>> In file included from /usr/include/c++/v1/algorithm:624: In file included
> >>> from /usr/include/c++/v1/initializer_list:47: 
> >>> /usr/include/c++/v1/cstddef:43:15:
> >>> fatal error: 'stddef.h' file not found #include_next  ^ ---
> >> . . .  
> >>> In file included from /usr/include/c++/v1/algorithm:624: In file included
> >>> from /usr/include/c++/v1/initializer_list:47: 
> >>> /usr/include/c++/v1/cstddef:43:15:
> >>> fatal error: 'stddef.h' file not found #include_next 
> >> 
> >> 
> >> Dimitry wrote for this issue of  not being found:
> >>   
> >>> Summary: If for some reason you must completely rebuild the header search 
> >>> path
> >>> from scratch, you need to add  -isystem /usr/include/c++/v1 *before* 
> >>> -isystem
> >>> /usr/include.  But it is better not to do this at all. :)
> >> 
> >> There is more background/supporting information in that comment.
> >> 
> >> ===
> >> Mark Millard
> >> markmi at dsl-only.net  
> > 
> > Hello Mark,
> > 
> > thanks a lot for the hint.
> > 
> > I can not fathom - at the moment - what is different on the two failing 
> > systems
> > compared to the non-failing ones. There must be something changing the 
> > order of how
> > the include path is searched now  
> 
> Do the log files from the various working systems show any differences in the 
> -isystem
> sequence compared to the failing ones (for the same source file being 
> compiled)?

I have not checked that yet, but it is an excellent advice. I have a notebook 
compiling
both ports perfectly.

> 
> It might be appropriate for your submittals (buszizlla and list) to also 
> include
> extractions of a working context's -isystem sequence vs. a failing context's 
> -isystem
> sequence for compiling the same source file. (Your list submittal already 
> showed an
> example of the failing -isystem sequence, one that matches what Dimitry A. 
> reports: So
> expected to fail.) The working -isystem sequence one is not currently shown, 
> at least
> in the list submittal.)

As soon I find something different, I'll do.

But this will take a while as I'm not in lab at themoment.

> 
> If both types of contexts have the same -isystem sequence then something more 
> is likely
> going on. But then showing examples of the matching log file text for the 
> -isystem
> sequences for the two types of contexts would then be appropriate to identify 
> the
> problem as unique.
> 
> 
> > - presumably I understood Dimitry Andric comment right (who explains the 
> > problem very
> > good for my taste).
> > 
> > I will make a reference to Dimitri's comment on both PRs I filed.
> > 
> > Oliver  
> 
> ===
> Mark Millard
> mar...@dsl-only.net



pgp5E4ikOiedp.pgp
Description: OpenPGP digital signature

Re: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

[O. Hartmann]

Am Fri, 7 Oct 2016 02:00:34 -0700
Mark Millard <mar...@dsl-only.net> schrieb:

> O. Hartmann ohartman at zedat.fu-berlin.de wrote on Fri Oct 7 08:26:27 UTC 
> 2016 . . .
> 
> . . . of having problems with not finding  during some port builds.
> 
> 
> Is there a difference in the -isystem command line options for c++ for the 
> working vs.
> failing contexts?
> 
> I will presume that there is based on the following. . . (At least it gives 
> you
> something to look into.)
> 
> 
> 
> The issue is not specific to just graphics/opencv-core and graphics/blender 
> ports:
> others also have problems with the use of -isystem for C++ compiles. See:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213217
> 
> in particular Comment #2 from Dimitry Andric.
> 
> The problem is in how -isystem is used vs. what is needed for libc++ 3.8.0 .
> 
> From O. Hartmann's message text:
> 
> . . .
> > -isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 -pipe 
> > -O3  
> . . .
> > In file included from /usr/include/c++/v1/algorithm:624: In file included
> > from /usr/include/c++/v1/initializer_list:47: 
> > /usr/include/c++/v1/cstddef:43:15: fatal
> > error: 'stddef.h' file not found #include_next  ^ ---  
> . . .
> > In file included from /usr/include/c++/v1/algorithm:624: In file included
> > from /usr/include/c++/v1/initializer_list:47: 
> > /usr/include/c++/v1/cstddef:43:15: fatal
> > error: 'stddef.h' file not found #include_next   
> 
> 
> Dimitry wrote for this issue of  not being found:
> 
> > Summary: If for some reason you must completely rebuild the header search 
> > path
> > from scratch, you need to add  -isystem /usr/include/c++/v1 *before* 
> > -isystem
> > /usr/include.  But it is better not to do this at all. :)  
> 
> There is more background/supporting information in that comment.
> 
> ===
> Mark Millard
> markmi at dsl-only.net

I'd like to mention, that I do updates and recompilation of the system on a 
almost daily
basis. Might it be possible thta I hit some transitional effects in the 
toolchain?

This is our/my src.conf:

#
CPUTYPE?=   native
#
CFLAGS+=-O3
COPTFLAGS+= -O3
#
#CXXFLAGS+= -std=c++11
#
WITH_CLANG_FULL=YES
WITH_CLANG_EXTRAS=  YES
WITH_LLDB=  YES


The /etc/makefile has

CPUTYPE?=native
COPTFLAGS+=-O3

I once compiled the systems (all of them without exceptions) with also
CXXFLAGS+=-std=c++11 set, but since the problems arose, I avoid that.


pgp65MrE2t3oo.pgp
Description: OpenPGP digital signature

Re: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

[O. Hartmann]

Am Fri, 7 Oct 2016 02:00:34 -0700
Mark Millard <mar...@dsl-only.net> schrieb:

> O. Hartmann ohartman at zedat.fu-berlin.de wrote on Fri Oct 7 08:26:27 UTC 
> 2016 . . .
> 
> . . . of having problems with not finding  during some port builds.
> 
> 
> Is there a difference in the -isystem command line options for c++ for the 
> working vs.
> failing contexts?
> 
> I will presume that there is based on the following. . . (At least it gives 
> you
> something to look into.)
> 
> 
> 
> The issue is not specific to just graphics/opencv-core and graphics/blender 
> ports:
> others also have problems with the use of -isystem for C++ compiles. See:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213217
> 
> in particular Comment #2 from Dimitry Andric.
> 
> The problem is in how -isystem is used vs. what is needed for libc++ 3.8.0 .
> 
> From O. Hartmann's message text:
> 
> . . .
> > -isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 -pipe 
> > -O3  
> . . .
> > In file included from /usr/include/c++/v1/algorithm:624: In file included
> > from /usr/include/c++/v1/initializer_list:47: 
> > /usr/include/c++/v1/cstddef:43:15: fatal
> > error: 'stddef.h' file not found #include_next  ^ ---  
> . . .
> > In file included from /usr/include/c++/v1/algorithm:624: In file included
> > from /usr/include/c++/v1/initializer_list:47: 
> > /usr/include/c++/v1/cstddef:43:15: fatal
> > error: 'stddef.h' file not found #include_next   
> 
> 
> Dimitry wrote for this issue of  not being found:
> 
> > Summary: If for some reason you must completely rebuild the header search 
> > path
> > from scratch, you need to add  -isystem /usr/include/c++/v1 *before* 
> > -isystem
> > /usr/include.  But it is better not to do this at all. :)  
> 
> There is more background/supporting information in that comment.
> 
> ===
> Mark Millard
> markmi at dsl-only.net

Hello Mark,

thanks a lot for the hint.

I can not fathom - at the moment - what is different on the two failing systems 
compared
to the non-failing ones. There must be something changing the order of how the 
include
path is searched now
- presumably I understood Dimitry Andric comment right (who explains the 
problem very good
for my taste).

I will make a reference to Dimitri's comment on both PRs I filed.

Oliver


pgpGvh4tB1RU1.pgp
Description: OpenPGP digital signature

graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

[O. Hartmann]

I'm being haunted by this error on two CURRENT systems, while several other 
CURRENT
systems with identical src.conf and make.conf are not affected, please see 
below.

It seems, that somehow the compiler environment doesn't find standard c++/c 
includes.

Albeit the fact I spread my setups around other systems, I change sometimes
configuration, so it might be possible that on the both systems in questions a 
remnant or
miscompiled library might be the culprit.

The most important fact, always questioned here, is that I use CPUTYPE?+native 
on both
IvyNridge (failing systems, both consumer and XEON type) and COPTS+=-O3 as 
well. The very
same I use on systems with Haswell XEONs and SkyLake XEONs.

I tried to comment these "optimizations" out and restart a full recompilation 
of all
requiremets via "portmaster -df graphics/opencv-core" (the same is with
graphics/blender!), as well as with vanilla/default settings shipped with 
FreeBSD
CURRENT/11-STABLE (same on 11-STABLE/11-RELEASE since I smoothly moved from 
there to
12-CURRENT) - but with a NULL effect.

I also use a poudriere framework compiling packages with the very same 
optimixations
set(!) for some embedded appliances and it's driving me nuts: on those systems, 
the
compilation works fine, I have the proper ports including graphics/blender!

So, I guess I have a polluted/sick system which needs some investigation. Since 
I can
definitely not delete every port and recompile it and I'm willing to spend some 
time to
clean up the mess manually, I'd like to ask for some help, tipps, suggestions.

I already filed PRs regarding graphics/blender
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211809) and 
graphics/opencv-core
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211808).

Maybe someone has made similar experiences.

Please CC me, I do not subscribe this list although I try to watch on a regular 
basis.

Thanks in advance,

Oliver

[...]
cd /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core && 
/usr/bin/c++
-DCVAPI_EXPORTS
-I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/dynamicuda/include
-I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core
-I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src
-I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include
-I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1
-isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 -pipe -O3
-march=native -fstack-protector -fno-strict-aliasing   -fsigned-char -W
-Werror=return-type -Werror=address -Werror=sequence-point -Wformat
-Werror=format-security -Wmissing-declarations -Wmissing-prototypes 
-Wstrict-prototypes
-Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing
-Wno-delete-non-virtual-dtor -Wno-unnamed-type-template-args -Wno-array-bounds
-fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse 
-msse2 -mavx
-mavx2 -ffunction-sections -O2 -pipe -O3 -march=native -fstack-protector
-fno-strict-aliasing  -DNDEBUG -fPIC -o 
CMakeFiles/opencv_core.dir/src/arithm.cpp.o
-c 
/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src/arithm.cpp
 In
file included
from 
/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src/arithm.cpp:49:
In file included
from 
/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src/precomp.hpp:48:
In file included
from 
/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
--- modules/core/CMakeFiles/opencv_core.dir/src/array.cpp.o --- In file included
from 
/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src/array.cpp:49:
In file included
from 
/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src/precomp.hpp:48:
In file included
from 
/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
In file included from /usr/include/c++/v1/algorithm:624: In file included
from /usr/include/c++/v1/initializer_list:47: 
/usr/include/c++/v1/cstddef:43:15: fatal
error: 'stddef.h' file not found #include_next  ^ ---
modules/core/CMakeFiles/opencv_core.dir/src/arithm.cpp.o --- In file included
from /usr/include/c++/v1/algorithm:624: ---
modules/core/CMakeFiles/opencv_core.dir/src/alloc.cpp.o --- In file included
from 
/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src/alloc.cpp:43:
In file included
from 
/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src/precomp.hpp:48:
In file included
from 
/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
In file included from /usr/include/c++/v1/algorithm:624: In file included
from /usr/include/c++/v1/initializer_list:47: 
/usr/include/c++/v1/cstddef:43:15: fatal
error: 'stddef.h' file not found #include_next 


pgpJwiSrP4QPp.pgp
Description: OpenPGP digital signature

Check constistency of the installed ports

[O. Hartmann]

As a user of ports-mgmt/portmaster, I face very often the situation with this
tool, that it fails in the very last stage of registering an installation or
update of a port. So it happens to, for example, updates for print/tex-xetex
and somehow (not being aware of) print/tex-luatex. Anyway, if someone skips the
error messages produced by portmaster - like me by rerunning portmaster again -
the installed ports are somehow inconsistent. Rerunning "portmaster
texlive-full" reveals the obvious:

===>>> The following actions will be taken if you choose to proceed:
Re-install texlive-full-20150521
Install print/tex-luatex
Install print/tex-xetex

I use "old-style" port building via compiler and and the sources in the ports
tree. This is due to a lot of individual configurations and personal likes. I
mention this avoiding people delegating me towards "pkg" for this task.

The major question is: I sthere a way to check the consistency of the installed
ports to reveal such gaps as shown above?

Thank you very much in advance for the time taken to answer, please CC me, I do
not subscribe the list.

Kind regards,

Oliver
___
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: Passwordless accounts vi ports!

[O. Hartmann]

On Thu, 11 Aug 2016 15:29:03 +1000
Dewayne Geraghty  wrote:

> Olivier,
> I've checked my 10.3Stable systems and they all have '*' as their password,
> which is consistent with /usr/ports/Mk/UIDs.  You might like to check the
> age of the latter.
> Regards, Dewayne.
> PS Both ports and src were built from updated src and ports from 2016-08-09

The system is a most recent CURRENT as compiled yesterday last time. The ports
tree is also up to date and updated on a daily basis, so are the ports.

Interestingly, the problem shows up only on one box so far, although all
other systems are also CURRENT and updated the very same way.

On another system, only user "bacula" has an empty password, were this user is
set correctly with a "*"-password on another system, on which I installed
bacula months earlier.

I checked the installation of the ports and their installating the
password-result again and all I tested (polkit, bacula, sane) did set the "*"
as expected (I deleted manually the password entry via vipw before).

I guess this "problem" is due to the fact I install ports and world on a daily
basis on such systems and the likelyhood hitting a interim bug is very high.

Regards,
Oliver
___
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"

Passwordless accounts vi ports!

[O. Hartmann]

I just checked the security scanning outputs of FreeBSD and found this
surprising result:

[...]
Checking for passwordless accounts:
polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin
pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin
saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh
clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin
bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin
[...]

Obviously, some ports install accounts but do not secure them as there is an
empty password.

I consider this not a feature, but a bug.

Regards,
Oliver
___
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"

x11/nvidia-driver and CURRENT: update results in full fan blow on MSI GTX 960 Gaming 4G

[O. Hartmann]

Three months ago I purchased a new GPU to replace a non-UEFI capable GTX560 Ti 
(MSI). The
choice was the MSI GTX 960 Gaming 4G. Apart from the part, that this GPU 
doesn't show the
performance boost on FreeBSD CURRENT, even with the most recent BLOB from 
nVidia, 367.18,
I realized that after the update from FreeBSD 11-CURRENT r300830 to r300956 (I 
guess,
Forgot the exact revision number, but it was > 300950), the fans of that 
specific GPU
blow at full speed when xdm/Xorg server has been started. This is annoying, 
since the
noise is incredible.

I tried to recompile the whole ports xorg relies on via

portmaster -df xorg xdm

hoping, that some sort of bug or API incompatibility could have caused the 
problems, but
that wasn't at all the case.

I run now r301300 and the "problem" is still present.

The environmental conditions did not change - not in a way that the full speed 
fan of the
GPU could be explained by raised temperatures of the environment. I tried to 
find via
Google some help, but it seems that I'm the first and only one having this 
problem,
especially with FreeBSD and this type of GPU. I also tried the official 
supported
x11/nvidia-driver (346.96 and the proposed 364.19) with no success.

Below, You will find some data I picked up from the kernel environment (if 
there are
other ways, please tell me) and the logfile of Xorg/X server.


[...]
hw.nvidia.gpus.0.type: PCIe
hw.nvidia.gpus.0.uuid: GPU-85fde95a-7974-9962-f1a4-d7c164413929
hw.nvidia.gpus.0.vbios: 84.06.26.00.21
hw.nvidia.gpus.0.irq: 270
hw.nvidia.gpus.0.model: GeForce GTX 960
hw.nvidia.registry.dwords: 
hw.nvidia.registry.TCEBypassMode: 0
hw.nvidia.registry.MemoryPoolSize: 0
hw.nvidia.registry.EnablePCIeGen3: 1
hw.nvidia.registry.CheckPCIConfigSpace: 4294967295
hw.nvidia.registry.RegisterForACPIEvents: 1
hw.nvidia.registry.MapRegistersEarly: 0
hw.nvidia.registry.EnableMSI: 1
hw.nvidia.registry.UsePageAttributeTable: 4294967295
hw.nvidia.registry.InitializeSystemMemoryAllocations: 1
hw.nvidia.registry.UpdateMemoryTypes: 4294967295
hw.nvidia.registry.DeviceFileMode: 438
hw.nvidia.registry.DeviceFileGID: 0
hw.nvidia.registry.DeviceFileUID: 0
hw.nvidia.registry.ModifyDeviceFiles: 1
hw.nvidia.registry.RmLogonRC: 1
hw.nvidia.registry.ResmanDebugLevel: 4294967295
hw.nvidia.registry.Mobile: 4294967295
hw.nvidia.version: NVIDIA UNIX x86_64 Kernel Module  367.18  Mon May 16 
18:13:16 PDT 2016
dev.nvidia.0.%parent: vgapci0
dev.nvidia.0.%pnpinfo: 
dev.nvidia.0.%location: 
dev.nvidia.0.%driver: nvidia
dev.nvidia.0.%desc: GeForce GTX 960
dev.nvidia.%parent: 


Hopefully someone can give some hints what could trigger the problem ...

Thanks in advance and please CC me (due to not subscribing this list).

Kind regards,

Oliver


pgp567nHhF1UE.pgp
Description: OpenPGP digital signature

devel/beignet: build error: call to 'abs' is ambiguous insn->extra.longjmp = abs(index - origin) > 800

[O. Hartmann]

Building/updating  port devel/beignet fails with

[ 42%] Building CXX object backend/src/CMakeFiles/gbe.dir/llvm/llvm_unroll.cpp.o
[ 42%] Building C object 
backend/src/CMakeFiles/gbe.dir/backend/gen/gen_mesa_disasm.c.o
[ 42%] Building CXX object 
backend/src/CMakeFiles/gbe.dir/backend/gen_insn_selection.cpp.o
[ 43%] Building CXX object
backend/src/CMakeFiles/gbe.dir/backend/gen_insn_scheduling.cpp.o [ 43%] 
Building CXX
object
backend/src/CMakeFiles/gbe.dir/backend/gen_reg_allocation.cpp.o 
/usr/ports/lang/beignet/work/Beignet-1.1.2-Source/backend/src/backend/gen_insn_selection.cpp:1156:27:
error: call to 'abs' is ambiguous insn->extra.longjmp = abs(index - origin) > 
800; ^~~
/usr/include/stdlib.h:83:6: note: candidate function
int  abs(int) __pure2;
 ^
/usr/include/c++/v1/stdlib.h:115:44: note: candidate function
inline _LIBCPP_INLINE_VISIBILITY long  abs( long __x) _NOEXCEPT {return
labs(__x);} ^
/usr/include/c++/v1/stdlib.h:117:44: note: candidate function
inline _LIBCPP_INLINE_VISIBILITY long long abs(long long __x) _NOEXCEPT {return
llabs(__x);} ^
/usr/include/c++/v1/math.h:646:1: note: candidate function
abs(float __lcpp_x) _NOEXCEPT {return fabsf(__lcpp_x);}
^
/usr/include/c++/v1/math.h:650:1: note: candidate function
abs(double __lcpp_x) _NOEXCEPT {return fabs(__lcpp_x);}
^
/usr/include/c++/v1/math.h:654:1: note: candidate function
abs(long double __lcpp_x) _NOEXCEPT {return fabsl(__lcpp_x);}


Regards,

oh


pgpVuKmVpVSnU.pgp
Description: OpenPGP digital signature

make index fails in print/enscript-a4 with: describe.print] Error code 1

[O. Hartmann]

Performing make index on /usr/ports fails:

[...]
--- describe.devel ---
PHP Warning:  phpinfo(): It is not safe to rely on the system's timezone 
settings. You
are *required* to use the date.timezone setting or the 
date_default_timezone_set()
function. In case you used any of those methods and you are still getting this 
warning,
you most likely misspelled the timezone identifier. We selected the timezone 
'UTC' for
now, but please set date.timezone to select your timezone. in Command line code 
on line 1
--- describe.news --- --- describe.palm --- --- describe.polish --- ---
describe.ports-mgmt --- --- describe.portuguese --- --- describe.print ---
===> print/enscript-a4 failed
*** [describe.print] Error code 1


pgpvR63kyo7o4.pgp
Description: OpenPGP digital signature

firefox fails to update due to failure in lang/rust: elf_update() failed: Layout constraint violation

[O. Hartmann]

On recent CURRENT (FreeBSD 11.0-CURRENT #32 r297237: Thu Mar 24 17:54:15 CET 
2016 amd64)
an update of ports and so www/firefox (svn Revision: 411904) fails:

[...]
mkdir -p tmp/empty_dir
gmake[3]: Leaving directory '/usr/ports/lang/rust/work/rustc-1.7.0'
install: creating uninstall script
at /usr/ports/lang/rust/work/stage/usr/local/lib/rustlib/uninstall.sh install: 
installing
component 'rust-std-x86_64-unknown-freebsd'

std is standing at the ready.

install: creating uninstall script
at /usr/ports/lang/rust/work/stage/usr/local/lib/rustlib/uninstall.sh install: 
installing
component 'rustc'

Rust is ready to roll.

gmake[2]: Leaving directory '/usr/ports/lang/rust/work/rustc-1.7.0'
strip: elf_update() failed: Layout constraint violation
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/lang/rust
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/rust

===>>> make stage failed for lang/rust
===>>> Aborting update

===>>> Update for lang/rust failed
===>>> Aborting update

===>>> Update for www/firefox failed
===>>> Aborting update

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

pkg: ALTABI - where is this variable documented?

[O. Hartmann]

I try to fetch freebsd:10:x86:64 binary packages from a CURRENT host for
further processing. I got a hint using pkg with -o ALTABI=... -o ABI=... set to
the specific ABI. I try to find some explanations what I'm doing by studying
the documentation of pkg, pkg.conf, pkg-repo, and pkg-fetch. But I'm unable to
find any documentation/explanation about ALTABI.

Can someone shed some light onto my clouded view? Is there a manpage where all
pkg-related variables are gathered an listed?

Thanks in advance and kind regards,

Oliver

P.S. Please CC me as I'm not subsribing this specific list. 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: poudriere and MAKEOBJDIRPREFIX

[O. Hartmann]

Am Fri, 11 Mar 2016 09:47:06 -0800
Bryan Drewery <bdrew...@freebsd.org> schrieb:

> On 3/10/2016 5:37 AM, O. Hartmann wrote:
> > env MAKEOBJDIRPREFIX=/some/place poudriere jail -c -j 10-stable-amd64 \
> > -a amd64 -v stable/10 -m src=/somesrc/srcplace/
> > 
> > In poudriere.conf I added 
> > 
> > export MAKEOBJDIRPREFIX=$MAKEOBJDIRPREFIX
> > 
> > as recommended in some posts I found googling for a solution. Please
> > have in mind that I use csh - the export and poudriere's environment is
> > obviously sh.
> > 
> > This fails, the PATH is always cut down to /somesrc/srcplace/, missing
> > the prepending portion taken from MAKEOBJDIRPREFIX - it is set to zero
> > length it seems. Ommitting env MAKEOBJDIRPREFIX=/some/place to the
> > poudriere command as shown above results in "usr/obj" being prepended.
> > This seems odd!
> > 
> > The only sollution to this was to give the specific jail its private
> > 10-stable-amd64-poudriere.conf. But this seems to be not the correct
> > way to do so, since  MAKEOBJDIRPREFIX is supposed to be set in the
> > environment.
> > 
> > What am I missing here?  
> 
> The poudriere command clears the environment except for PATH and TERM.
> A 10-stable-amd64-poudriere.conf with export MAKEOBJDIRPREFIX=value
> would work.
> 

Thank you Bryan.
Indeed, it worked that way. It would be great if there would be a hint 
somewhere in the
docs or in the example poudriere.conf file.

I found no hint whether compilation/building packages on a base system running a
fifferent major release that the jail would work or not - it is made clear, 
that within
a major release, the head or most recent of the release is capable to build 
minors of
the same major release due to ABI/KABI compatibility.

What is about the recent CURRENT as host with 10.X-Rel or 10-stable jails?

I have problems building lang/python27 within the 10-stable jail. The build 
fails in the
stagin phase with "bad c++ code". A natural "make" build on CURRENT works 
flawlessly.
The config of the 10-stable jail is "vanilla".

Regards and thanks,

Oliver 


pgpJZBESUhCXY.pgp
Description: OpenPGP digital signature

Re: pkg: fetching binary packages to a local dumpdir for a different ABI

[O. Hartmann]

Am Fri, 11 Mar 2016 11:00:28 +0100
Miroslav Lachman <000.f...@quip.cz> schrieb:

> O. Hartmann wrote on 03/11/2016 10:42:
> 
> [...]
> 
> > The ABI is also unclear. Some documents say it is freebsd:10:x86:64 (which
> > looks more the Intel/Linux dominated terminology) and also this one is
> > considered correct: FreeBSD:10:amd64 (looks more FreeBSD'ish). It is said 
> > that
> > the variable ABI is derived from "sh" - how?  
> 
> It is freebsd:10:x86:64. You can look at http://pkg.freebsd.org/
> The full URL is http://pkg.freebsd.org/freebsd:10:x86:64/
> 
> Miroslav Lachman

Thank you very much. 

Kind regards,

O. Hartmann


pgpc_x1O3B2bT.pgp
Description: OpenPGP digital signature

pkg: fetching binary packages to a local dumpdir for a different ABI

[O. Hartmann]

On CURRENT, I try to "silly fetch" a selection of binary packages for FreeBSD
10-STABLE from a regular user via this command sequence:

env ABI=freebsd:10:x86:64 PKG_CACHEDIR=./tmp/packages/cache \
REPOS_DIR=./tmp/packages cat /usr/local/etc/poudriere.d/pkglist | \
xargs pkg fetch -y -U -d -o ./tmp/packages/

pkg trie to fecth, but then it simply complains about crap being fetched:

[...]
The process will require 4 GiB more space.
4 GiB to be downloaded.
Fetching pkg-1.6.4_1.txz: 100%3 MiB 562.3kB/s00:05
pkg-static: cached package pkg-1.6.4_1: size mismatch, fetching from remote
Fetching pkg-1.6.4_1.txz: 100%3 MiB 562.3kB/s00:05
pkg-static: cached package pkg-1.6.4_1: size mismatch, cannot continue

Well, it seems clear - somewhere (on that specific box nowhere!) is a cache and
the size-hash is compared - but where? The list in pkglist contains also
ports-mgmt/pkg and it is the first package to be fetched.

How can I force package to download "brutal force" the specified package for
the desired ABI?

Background: since poudriere fails building packages (especially lang/python27,
see my posts prior to this) within a 10-stable jail running on CURRENT (maybe
this doesn't work, but I didn't find anything regarding this on the rush), I'd
like to have a set of packages for installation on some 10-STABLE appliance
images.

The ABI is also unclear. Some documents say it is freebsd:10:x86:64 (which
looks more the Intel/Linux dominated terminology) and also this one is
considered correct: FreeBSD:10:amd64 (looks more FreeBSD'ish). It is said that
the variable ABI is derived from "sh" - how?

Many thanks in advance,

Oliver

P.S. Please CC me - I'm not subscribing this specific list. Thank you.
___
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"

lang/python27: Failed: stage

[O. Hartmann]

Try to build lang/python27 within poudriere. The base system is running recent
CURRENT, the jail used is a 10-STABLE, compiled locally on the CURRENT box.
While lang/python27 compiles fine using a head-jail built from the CURRENT
sources, I receive a sticky and nasty error when trying to build the  port
lang/python27 via the 10-stable jail. Other ports are seemingly not affected,
the error is in the staging phase:

[...]
Python build finished, but the necessary bits to build these modules were not
found: _bsddb _sqlite3   _tkinter
dl gdbm   imageop 
linuxaudiodev  spwd   sunaudiodev 
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.

running build_scripts
copying and
adjusting 
/wrkdirs/usr/ports/lang/python27/work/Python-2.7.11/Tools/scripts/pydoc
-> build/scripts-2.7 copying and
adjusting /wrkdirs/usr/ports/lang/python27/work/Python-2.7.11/Tools/scripts/idle
-> build/scripts-2.7 copying and
adjusting /wrkdirs/usr/ports/lang/python27/work/Python-2.7.11/Tools/scripts/2to3
-> build/scripts-2.7 changing mode of build/scripts-2.7/pydoc from 644 to 755
changing mode of build/scripts-2.7/idle from 644 to 755 changing mode of
build/scripts-2.7/2to3 from 644 to 755 renaming build/scripts-2.7/pydoc to
build/scripts-2.7/pydoc2.7 renaming build/scripts-2.7/idle to
build/scripts-2.7/idle2.7 renaming build/scripts-2.7/2to3 to
build/scripts-2.7/2to3-2.7 running install_lib error: error listing files in
'build/lib.freebsd-10.3-PRERELEASE-amd64-2.7': Operation not supported ***
Error code 1

Stop.
make[1]: stopped in /wrkdirs/usr/ports/lang/python27/work/Python-2.7.11
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/python27
[...]


Is there any further investigation possible?

Please CC me. 

Thanks in advance,

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

poudriere and MAKEOBJDIRPREFIX

[O. Hartmann]

There are some issues with using MAKEOBJDIRPREFIX in poudriere I wasn't
able to solve and I'd like to ask whether there is an official, still
for me undiscovered way, to do so.

The base system is running CURRENT. The intention is to have both
CURRENT and 10-STABLE jails to build appropriate packages via
poudriere. With CURRENT there is no problem, using the
canonical /usr/src and/usr/obj infrastructure works as well as building
the package repositorium.

The command line

env MAKEOBJDIRPREFIX=/some/place make -j12 buildworld

while residing within the sources of 10-STABLE from within a csh
environment gives me the object tree of FreeBSD 10-STABLE as expected.

Then I'd like to use this obj tree to build the jail needed for ports
compliant with 10-STABLE, so I issue

env MAKEOBJDIRPREFIX=/some/place poudriere jail -c -j 10-stable-amd64 \
-a amd64 -v stable/10 -m src=/somesrc/srcplace/

In poudriere.conf I added 

export MAKEOBJDIRPREFIX=$MAKEOBJDIRPREFIX

as recommended in some posts I found googling for a solution. Please
have in mind that I use csh - the export and poudriere's environment is
obviously sh.

This fails, the PATH is always cut down to /somesrc/srcplace/, missing
the prepending portion taken from MAKEOBJDIRPREFIX - it is set to zero
length it seems. Ommitting env MAKEOBJDIRPREFIX=/some/place to the
poudriere command as shown above results in "usr/obj" being prepended.
This seems odd!

The only sollution to this was to give the specific jail its private
10-stable-amd64-poudriere.conf. But this seems to be not the correct
way to do so, since  MAKEOBJDIRPREFIX is supposed to be set in the
environment.

What am I missing here?

Thanks and regards,

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

poudriere: build failing permanently for lang/python27

[O. Hartmann]

My setup is as follows:

the base system is most recent CURRENT (as of today, FreeBSD 11.0-CURRENT #2
r296556: Wed Mar  9 06:50:02 CET 2016 amd64). The used jail is a
built-from-source 10-STABLE, as of today, also. The ports tree is head and also
up to date.

Building a ports tree (customized/selected, not the whole FreeBSD's ports tree)
works fine using a jail running HEAD as denoted above. But using the same
(vanilla) configs (src.conf, make.conf) with the 10-STABLE jail, port
lang/python fails in staging the port:

bad_c++ code (message in webinterface),

[...]
install  -m 0644
Modules/Setup.config 
/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/config/Setup.config
install  -m 0644
Misc/python.pc 
/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/libdata/pkgconfig/python-2.7.pc
install  -m
555 ./Modules/makesetup 
/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/config/makesetup
install  -m
555 ./install-sh 
/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/config/install-sh
install  -m 555
python-config 
/wrkdirs/usr/ports/lang/python27/work/stage/usr/local/bin/python2.7-config
rm python-config
LD_LIBRARY_PATH=/wrkdirs/usr/ports/lang/python27/work/Python-2.7.11 ./python
-E ./setup.py install  --prefix=/usr/local  --install-scripts=/usr/local/bin
--install-platlib=/usr/local/lib/python2.7/lib-dynload
--root=/wrkdirs/usr/ports/lang/python27/work/stage/ running install running
build running build_ext building dbm using ndbm INFO: Can't locate Tcl/Tk libs
and/or headers

Python build finished, but the necessary bits to build these modules were not
found: _bsddb _sqlite3   _tkinter
dl gdbm   imageop 
linuxaudiodev  spwd   sunaudiodev 
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.

running build_scripts
copying and
adjusting 
/wrkdirs/usr/ports/lang/python27/work/Python-2.7.11/Tools/scripts/pydoc
-> build/scripts-2.7 copying and
adjusting /wrkdirs/usr/ports/lang/python27/work/Python-2.7.11/Tools/scripts/idle
-> build/scripts-2.7 copying and
adjusting /wrkdirs/usr/ports/lang/python27/work/Python-2.7.11/Tools/scripts/2to3
-> build/scripts-2.7 changing mode of build/scripts-2.7/pydoc from 644 to 755
changing mode of build/scripts-2.7/idle from 644 to 755 changing mode of
build/scripts-2.7/2to3 from 644 to 755 renaming build/scripts-2.7/pydoc to
build/scripts-2.7/pydoc2.7 renaming build/scripts-2.7/idle to
build/scripts-2.7/idle2.7 renaming build/scripts-2.7/2to3 to
build/scripts-2.7/2to3-2.7 running install_lib error: error listing files in
'build/lib.freebsd-10.3-PRERELEASE-amd64-2.7': Operation not supported ***
Error code 1

Stop.
make[1]: stopped in /wrkdirs/usr/ports/lang/python27/work/Python-2.7.11
*** Error code 1
[...]



What is wrong here? Am I mistaken that I can build on CURRENT by using a
10-STABLE jail a ports tree dedicated to 10-STABLE?


Help is appreciated. Please CC me, I do not subscribe this list.

Thank you very much in advance,
Regards,

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

poudriere: can not set MAKEOBJDIRPREFIX

[O. Hartmann]

I have already built 10-STABLE and try now to use this built as base for a jail
in poudriere, using MAKEOBJDIRPREFIX; the already built system is ready and
fine residing under

MAKEOBJDIRPREFIX=/empty/10-STABLE/obj

Using

export MAKEOBJDIRPREFIX=$MAKEOBJDIRPREFIX in poudriere.conf

and

env MAKEOBJDIRPREFIX=/empty/10-STABLE/obj poudriere jail -c -j 10-stable-amd64 \
-a amd64 -v stable/10 -m src=/empty/10-STABLE/src

results in an immediate error:

[...]
export
PATH=/empty/10-STABLE/src/tmp/legacy/usr/sbin:/empty/10-STABLE/src/tmp/legacy/usr/bin:/empty/10-STABLE/src/tmp/legacy/usr/games:/empty/10-STABLE/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
 ;
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown  date echo egrep
find grep id install install-info  ln lockf make mkdir mtree nmtree mv
pwd_mkdb  rm sed sh strip sysctl test true uname wc zic tzsetup   makewhatis;
do  if progpath=`which $prog`; then  echo $progpath;  else  echo "Required tool
$prog not found in PATH." >&2;  exit 1;  fi;  done);  libs=$(ldd -f "%o %p\n"
-f "%o %p\n" $progs 2>/dev/null | sort -u |  while read line; do  set --
$line;  if [ "$2 $3" != "not found" ]; then  echo $2;  else  echo "Required
library $1 not found." >&2;  exit 1;  fi;  done);  cp $libs
$progs /tmp/install.RF32dD2c Required tool install-info not found in PATH. ***
Error code 1

[...]

This is really funny: ommitting the MAKEOBJDIRPREFIX=/empty/10-STABLE/obj part
results in a prepended "/usr/obj" as expected to the path portion given by
src=. With setting the environment it seems that the prepended string is ZERO!

How to tell this piece of software to use MAKEOBJDIRPREFIX?

regards,

Oliver
___
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: emulators/virtualbox-ose-kmod build error

[O. Hartmann]

On Thu, 25 Feb 2016 09:31:00 +0100
Tommy Scheunemann  wrote:

> > Am Wed, 24 Feb 2016 22:04:29 +0200
> > Ivan Klymenko  schrieb:
> >  
> >> After update from r295867 to r295994:
> >>
> >> ...
> >> /usr/local/bin/ccache cc -O2 -pipe -march=native -fno-strict-aliasing
> >> -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0
> >> -DSUPDRV_WITH_RELEASE_LOGGER -DVBOX -DRT_WITH_VBOX -w
> >> -DVBOX_WITH_HARDENING -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_AMD64
> >> -march=native  -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -Iinclude -I.
> >> -Ir0drv -I. -I/usr/src/sys -fno-common -fno-omit-frame-pointer
> >> -mno-omit-leaf-frame-pointer  -mcmodel=kernel -mno-red-zone -mno-mmx
> >> -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding
> >> -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs
> >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
> >> -Wcast-qual  -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
> >> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
> >> -Wno-error-tautological-compare -Wno-error-empty-body
> >> -Wno-error-parentheses-equality -Wno-error-unused-function
> >> -Wno-error-pointer-sign -Wno-error-shift-negative-value  -fvectorize
> >> -fslp-vectorize -fbloc ks -fcolor-diagnostics -mno-aes -mno-avx
> >> -std=iso9899:1999
> >> -c 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c
> >> -o memobj-r0drv-freebsd.o --- assert-r0drv-freebsd.o --- In file included
> >> from 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/assert-r0drv-freebsd.c:34:
> >> In file included
> >> from 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
> >>  /usr/src/sys/sys/bus.h:659:10:
> >> fatal error: 'device_if.h' file not found #include "device_if.h" ^ ---
> >> alloc-r0drv-freebsd.o --- In file included
> >> from 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:34:
> >> In file included
> >> from 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
> >>  /usr/src/sys/sys/bus.h:659:10:
> >> fatal error: 'device_if.h' file not found #include "device_if.h" ^ ---
> >> assert-r0drv-freebsd.o --- 1 error generated. --- initterm-r0drv-freebsd.o
> >> --- In file included
> >> from 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/initterm-r0drv-freebsd.c:34:
> >> In file included
> >> from 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
> >>  /usr/src/sys/sys/bus.h:659:10:
> >> fatal error: 'device_if.h' file not found #include "device_if.h" ^ ---
> >> assert-r0drv-freebsd.o --- *** [assert-r0drv-freebsd.o] Error code 1
> >>
> >> make[3]: stopped
> >> in 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
> >> --- initterm-r0drv-freebsd.o --- 1 error generated.
> >> --- alloc-r0drv-freebsd.o ---
> >> 1 error generated.
> >> --- initterm-r0drv-freebsd.o ---
> >> *** [initterm-r0drv-freebsd.o] Error code 1
> >>
> >> make[3]: stopped
> >> in 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
> >> --- memobj-r0drv-freebsd.o --- In file included
> >> from 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:36:
> >> In file included
> >> from 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
> >>  /usr/src/sys/sys/bus.h:659:10:
> >> fatal error: 'device_if.h' file not found #include "device_if.h" ^
> >> --- alloc-r0drv-freebsd.o ---
> >> *** [alloc-r0drv-freebsd.o] Error code 1
> >>
> >> make[3]: stopped
> >> in 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
> >> --- memobj-r0drv-freebsd.o --- 1 error generated.
> >> *** [memobj-r0drv-freebsd.o] Error code 1
> >>
> >> make[3]: stopped
> >> in 
> >> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
> >> 4 errors
> >>
> >> make[3]: stopped
> >> in 
> >> 

Re: emulators/virtualbox-ose-kmod build error

[O. Hartmann]

Am Wed, 24 Feb 2016 22:04:29 +0200
Ivan Klymenko  schrieb:

> After update from r295867 to r295994:
> 
> ...
> /usr/local/bin/ccache cc -O2 -pipe -march=native -fno-strict-aliasing 
> -DRT_OS_FREEBSD
> -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DSUPDRV_WITH_RELEASE_LOGGER -DVBOX 
> -DRT_WITH_VBOX -w
> -DVBOX_WITH_HARDENING -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_AMD64 
> -march=native  -Werror
> -D_KERNEL -DKLD_MODULE -nostdinc  -Iinclude -I. -Ir0drv -I. -I/usr/src/sys 
> -fno-common
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -mcmodel=kernel 
> -mno-red-zone
> -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
> -ffreestanding -fwrapv
> -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
> -fdiagnostics-show-option
> -Wno-unknown-pragmas  -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function  
> -Wno-error-pointer-sign
> -Wno-error-shift-negative-value  -fvectorize -fslp-vectorize -fbloc ks
> -fcolor-diagnostics -mno-aes -mno-avx  -std=iso9899:1999
> -c 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c
> -o memobj-r0drv-freebsd.o --- assert-r0drv-freebsd.o --- In file included
> from 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/assert-r0drv-freebsd.c:34:
> In file included
> from 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
>  /usr/src/sys/sys/bus.h:659:10:
> fatal error: 'device_if.h' file not found #include "device_if.h" ^ ---
> alloc-r0drv-freebsd.o --- In file included
> from 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:34:
> In file included
> from 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
>  /usr/src/sys/sys/bus.h:659:10:
> fatal error: 'device_if.h' file not found #include "device_if.h" ^ ---
> assert-r0drv-freebsd.o --- 1 error generated. --- initterm-r0drv-freebsd.o 
> --- In file
> included
> from 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/initterm-r0drv-freebsd.c:34:
> In file included
> from 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
>  /usr/src/sys/sys/bus.h:659:10:
> fatal error: 'device_if.h' file not found #include "device_if.h" ^ ---
> assert-r0drv-freebsd.o --- *** [assert-r0drv-freebsd.o] Error code 1
> 
> make[3]: stopped
> in 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
> --- initterm-r0drv-freebsd.o --- 1 error generated.
> --- alloc-r0drv-freebsd.o ---
> 1 error generated.
> --- initterm-r0drv-freebsd.o ---
> *** [initterm-r0drv-freebsd.o] Error code 1
> 
> make[3]: stopped
> in 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
> --- memobj-r0drv-freebsd.o --- In file included
> from 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:36:
> In file included
> from 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
>  /usr/src/sys/sys/bus.h:659:10:
> fatal error: 'device_if.h' file not found #include "device_if.h" ^
> --- alloc-r0drv-freebsd.o ---
> *** [alloc-r0drv-freebsd.o] Error code 1
> 
> make[3]: stopped
> in 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
> --- memobj-r0drv-freebsd.o --- 1 error generated.
> *** [memobj-r0drv-freebsd.o] Error code 1
> 
> make[3]: stopped
> in 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
> 4 errors
> 
> make[3]: stopped
> in 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
> *** [all] Error code 2
> 
> make[2]: stopped
> in 
> /media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src
> 1 error
> 
> make[2]: stopped
> in 
> 

pkg: fails with local repository (file:///) [WAS: Re: pkg: fail to install packages from local file repository targeted via file:///]

[O. Hartmann]

On Tue, 02 Feb 2016 18:34:01 +0100
Patrick Hess <patrickh...@gmx.net> wrote:

> O. Hartmann wrote:
> > file:///pool/poudriere/data/packages/head-amd64-head-default/meta.txz: No
> > such file or directory repository myrepo has no meta file, using default
> > settings pkg:
> > file:///pool/poudriere/data/packages/head-amd64-head-default/packagesite.txz:
> > No such file or directory Unable to update repository myrepo  
> 
> These files are supposed to be created by "pkg repo". I'm not
> familiar with this nanoBSDbuilding thingamabob, but what happens
> if you just run
> 
> pkg repo /pool/poudriere/data/packages/head-amd64-head-default
> 
> manually?
> 
> > the documentation doesn't give much about handling local repositories  
> 
> This particular issue is not specific to local repos. In fact,
> any pkg repo, no matter how it's being accessed, should provide
> these two files.
> 
> Patrick

After checking the setup of NanoBSD's and after ensuring the correct
installation of a local package repository via poudriere, exchanging the
PACKAGESITE (url: in repos.conf) with an official site like 

url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest;,

does not have any issues.

poudriere(8) provides at the location specified by my alternative, local
repositories' path 

meta.txz

as well as 

packagesite.txz

but they are symbolic links,

[...]
ls -l /pool/poudriere/data/packages/head-amd64-head-default/
total 3
lrwxr-xr-x  1 root  wheel  11  1 Feb. 15:04 All -> .latest/All
lrwxr-xr-x  1 root  wheel  14  1 Feb. 15:04 Latest -> .latest/Latest
lrwxr-xr-x  1 root  wheel  19  1 Feb. 15:04 digests.txz -> .latest/digests.txz
lrwxr-xr-x  1 root  wheel  16  1 Feb. 15:04 meta.txz -> .latest/meta.txz
lrwxr-xr-x  1 root  wheel  23  1 Feb. 15:04 packagesite.txz

It seems that pkg is not handling links - either by intention for security
reasons or by mistake - or I miss some neat configuration option.

Since a remote repo works perfectly as mentioned above, but the local
repository created by poudriere (I do not doubt the correctnes of poudriere's
directory hierarchy because it is as described in pkg-repo(8) and
pkg-repository(5)), I consider this behaviour a bug. FILE: is supported by
fetch(3), and there is no menetioning of the exclusion of symbolic links.

Regards,
oh
___
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"

pkg: fail to install packages from local file repository targeted via file:///

[O. Hartmann]

Using nanoBSDbuilding images for embedded systems and poudriere for the
provision of ports, I run into a problem installing packages from the
poudriere repository located on the same filesystem as the nanoBSD build. 

While installing the world and doing configuration steps in etc, I run into the
error shown here while trying to install packages via pkg:

[...]
file:///pool/poudriere/data/packages/head-amd64-head-default/meta.txz: No such
file or directory repository myrepo has no meta file, using default settings
pkg:
file:///pool/poudriere/data/packages/head-amd64-head-default/packagesite.txz:
No such file or directory Unable to update repository myrepo
[...]

The culprit skript-portion in nano.conf is like this section:

[...]

: ${L_ABI={head-amd64"}
cust_pkg_local_cfg() {

local   RCCONF_PKG RCCONF_REPOS

RCCONF_PKG="usr/local/etc/pkg.conf"
RCCONF_REPOS="usr/local/etc/pkg/repos/myrepo.conf"

mkdir -p ${NANO_WORLDDIR}/usr/local/etc/pkg/repos

cd ${NANO_WORLDDIR}

cat > ${RCCONF_PKG} < ${RCCONF_REPOS} 

poudriere: problems building ports

[O. Hartmann]

Running poudriere (most recent installation from ports) on recent CURRENT
(FreeBSD 11.0-CURRENT #25 r294905: Wed Jan 27 08:52:04 CET 2016 amd64) leads to
problems when building the following ports:

www/nginx: Failed: fetch

and 

print/tex-formats: Failed: build-depends

The latter leads to a bunch of dependend, unbuilt ports, so texlive doesn
build, for instance.

Building www/nginx on the same host via the "manual" way works flawless - I can
fetch the tarball with no error. Also the build of texlive works, too.

The logfile presents me with the following errors:
www/nginx:

===>  License BSD2CLAUSE accepted by the user
===>  Found saved configuration for nginx-1.8.0_3,2
=> nginx-1.8.0.tar.gz doesn't seem to exist in /portdistfiles/.
=> Attempting to fetch http://nginx.org/download/nginx-1.8.0.tar.gz
nginx-1.8.0.tar.gz   0  B0  Bps
[...]
=> Attempting to fetch
http://distcache.FreeBSD.org/ports-distfiles/nginx_udplog_module-1.0.0.tar.gz
fetch:
http://distcache.FreeBSD.org/ports-distfiles/nginx_udplog_module-1.0.0.tar.gz:
Not Found => Couldn't fetch it - please try to retrieve this => port manually
into /portdistfiles/ and try again. *** Error code 1

The fun part is: On my attempt to fetch the tarball via "make fetch" in
www/nginx the first source for the tarball works. Since I build many other
ports via the very same jail (in a rather vanilla setup taken from the
handbook), i do not suspect any network problems or specialities concerning
http/ftp proxy (do not use proxy either way).


Mot confusing is 

print/tex-formats:
[...]
 Extracting texlive-texmf-20150523_3: ..
pkg-static: archive_read_extract(): Lzma library error:  No progress is possible

so all depending ports fail to build. I see no problems on a non-jailed build.

Is there a rsource limit set for the jail supposed to build the port running in
RAM or diskspace shortage I do not see?

Thanks for your suggestions/help and regards,

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

graphics/blender: crahs due to Assertion failed:

[O. Hartmann]

On CURRENT ( FreeBSD 11.0-CURRENT #2 r292123: Fri Dec 11 23:06:04 CET 2015  
amd64),
blender crashes spontanously or reproducible via trying to access 

File -> User Preferences -> System

with the error shown below.

The error is similar to the error popping up while trying to work on blender, 
which isn't
possible for long (~1 min or less, depending on the action performed).

What is wrong here?

I also filed a PR on that, please see 

Bug 204699 

Please CC me.

Regards,

oh

[...]
host: [~] blender
Assertion failed: (findOption(Name) == Values.size() && "Option already 
exists!"),
function addLiteralOption,
file 
/usr/ports/devel/llvm37/work/llvm-3.7.0.src/include/llvm/Support/CommandLine.h, 
line
698. Abort


pgpmYyYrmSFBL.pgp
Description: OpenPGP digital signature

svn: E000022: ?\A0@@?\C8V @8@@@?\84?\D4

[O. Hartmann]

I get this in my /usr/ports directory out of the blue when doing a svn update:

[...]
cd /usr/ports; /usr/bin/svn update
Updating '.':
svn: E22: Error converting entry in directory '/usr/ports/www/links1' to 
UTF-8
svn: E22: Can't convert string from native encoding to 'UTF-8':
svn: E22: ?\A0@@?\C8V
 @8@@@?\84?\D4
*** Error code 1

Stop.
make: stopped in /usr/ports


What is up here?

Kind regards,
Oliver


pgpynNkBjdJoQ.pgp
Description: OpenPGP digital signature

Re: svn: E000022: ?\A0@@?\C8V @8@@@?\84?\D4

[O. Hartmann]

Am Wed, 9 Dec 2015 19:42:20 +0100
Kurt Jaeger  schrieb:

> Hi!
> 
> > I get this in my /usr/ports directory out of the blue when doing a svn 
> > update:
> > 
> > [...]
> > cd /usr/ports; /usr/bin/svn update
> [...]
> 
> I tested it on one host, can't reproduce.
> 


Found a strange entry in ports/www/links1:


total 435
 766755 -rw-r--r-- 1 root  wheel  uarch0B Dec  9 16:26 
???@@?V?@8?@@@??
  29563 drwxr-xr-x 3 root  wheel  uarch8B Dec  9 16:26 ./
1911685 drwxr-xr-x  2384 root  wheel  uarch  2.3K Dec  8 18:01 ../
  29601 -rw-r--r-- 1 root  wheel  uarch  474B Jul  9 19:51 Makefile
  29582 -rw-r--r-- 1 root  wheel  uarch  128B Jul  9 19:51 distinfo
  29571 drwxr-xr-x 2 root  wheel  uarch5B Jul  9 19:51 files/
  29584 -rw-r--r-- 1 root  wheel  uarch  557B Jul  9 19:51 pkg-descr
  29599 -rw-r--r-- 1 root  wheel  uarch   30B Jul  9 19:51 pkg-plist

This host's /usr/ports tree resides on a ZFS volume.

Aftere deletion of the folder and another svn update, everything was as normal 
as before.


pgpDdUBiNeOqw.pgp
Description: OpenPGP digital signature

lang/gcc: on CURRENT build fails with ./options.h:4301:3: error: redefinition of enumerator 'OPT_d'

[O. Hartmann]

Can not update/build lang/gcc on CURRENT, see error message below.

Tried with and without bootstrap and also delete packages related to lang/gcc
to ensure no disturbing remnants are left over.


[...]

echo timestamp > s-options
/usr/bin/awk -f .././../gcc-4.8.5/gcc/opt-functions.awk
-f .././../gcc-4.8.5/gcc/opt-read.awk \ -f .././../gcc-4.8.5/gcc/opth-gen.awk \
   < optionlist > tmp-options.h
/usr/bin/awk -f .././../gcc-4.8.5/gcc/opt-functions.awk
-f .././../gcc-4.8.5/gcc/opt-read.awk \
-f .././../gcc-4.8.5/gcc/optc-save-gen.awk \ -v header_name="config.h system.h
coretypes.h tm.h" < optionlist > options-save.c /usr/bin/awk
-f .././../gcc-4.8.5/gcc/opt-functions.awk
-f .././../gcc-4.8.5/gcc/opt-read.awk \ -f .././../gcc-4.8.5/gcc/optc-gen.awk \
-v header_name="config.h system.h coretypes.h options.h tm.h" < optionlist >
options.c /bin/sh .././../gcc-4.8.5/gcc/../move-if-change tmp-options.h
options.h echo timestamp > s-options-h build/gengtype  \
-S .././../gcc-4.8.5/gcc -I gtyp-input.list -w
tmp-gtype.state c++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I.././../gcc-4.8.5/gcc
-I.././../gcc-4.8.5/gcc/build -I.././../gcc-4.8.5/gcc/../include
-I.././../gcc-4.8.5/gcc/../libcpp/include -DLIBICONV_PLUG \ -o
build/gencheck.o .././../gcc-4.8.5/gcc/gencheck.c c++: warning: treating 'c'
input as 'c++' when in C++ mode, this behavior is deprecated In file included
from .././../gcc-4.8.5/gcc/gencheck.c:23: In file included
from ./tm.h:16: ./options.h:4293:3: error: redefinition of enumerator 'OPT_C'
OPT_C = 129,   /* -C */ ^ ./options.h:4290:3: note:
previous definition is here OPT_C = 126,   /* -C */
^ ./options.h:4301:3: error: redefinition of enumerator 'OPT_d' OPT_d =
137,   /* -d */ ^ ./options.h:4299:3: note:
previous definition is here OPT_d = 135,   /* -d */
  ^
./options.h:4302:3: error: redefinition of enumerator 'OPT_D'
  OPT_D = 138,   /* -D */
  ^
./options.h:4300:3: note: previous definition is here
  OPT_D = 136,   /* -D */
  ^
./options.h:4305:3: error: redefinition of enumerator 'OPT_d'
  OPT_d = 141,   /* -d */
___
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"

graphics/gimp-app: pkg-static: Unable to access ... plug-ins/file-mng: No such file or directory

[O. Hartmann]

Updating ports fails on most recent CURRENT and most recent ports tree
(as of today, both worlds) with the error shown below:

[]
gmake[5]: Leaving directory
'/usr/ports/graphics/gimp-app/work/gimp-2.8.16' gmake[4]: Leaving
directory '/usr/ports/graphics/gimp-app/work/gimp-2.8.16' gmake[3]:
Leaving directory '/usr/ports/graphics/gimp-app/work/gimp-2.8.16'
gmake[2]: Leaving directory
'/usr/ports/graphics/gimp-app/work/gimp-2.8.16' > Compressing man
pages (compress-man) ===>>> Starting check for runtime dependencies
===>>> Gathering dependency list for graphics/gimp-app from ports
===>>> Dependency check complete for graphics/gimp-app

===>>> All >> gimp-gutenprint-5.2.10_2 >> graphics/gimp-app (2/4)

===>  Installing for gimp-app-2.8.16,1
===>   Registering installation for gimp-app-2.8.16,1 as automatic
pkg-static: Unable to access
file 
/usr/ports/graphics/gimp-app/work/stage/usr/local/libexec/gimp/2.2/plug-ins/file-mng:
No such file or directory *** Error code 74

Stop.
make[1]: stopped in /usr/ports/graphics/gimp-app
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/gimp-app

===>>> Installation of gimp-app-2.8.16,1 (graphics/gimp-app) failed
===>>> Aborting update

===>>> Update for graphics/gimp-app failed
===>>> Aborting update

===>>> Update for print/gimp-gutenprint failed
===>>> Aborting update
___
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"

www/[firefox|libxul]: configure: error: --enable-chrome-format must be set to either jar, flat, or omni

[O. Hartmann]

A day or two ago, I updated ports without any problems, especially www/firefox.
Doing the same mainatining process yesterday and today on several other boxes
results in a fail of either updating www/firefox with the very similar error as
shown below, or with the error shown below after I tried a "portmaster -f
www/libxul' as I suspected a problem in www/libxul.

This problem now makes www/firefox unusable on several systems since yesterday
(Tuesday, 17th of November) with port revision most recently updated.

Since the problem now appears to destroy every firefox installation on CURRENT
(most recent, amd64), the problem got severe for us.

Please fix!

Kind regards,

oh

[...]
configure: error: --enable-chrome-format must be set to either jar, flat, or
omni *** Fix above errors and then restart with\
   "gmake -f client.mk build"
/usr/ports/www/libxul/work/mozilla-esr38/client.mk:361: recipe for target
'configure' failed gmake[2]: *** [configure] Error 1
gmake[2]: Leaving directory '/usr/ports/www/libxul'
===>  Script "configure" failed unexpectedly.
Please report the problem to ge...@freebsd.org [maintainer] and attach the
"/usr/ports/www/libxul/work/mozilla-esr38/config.log" including the output
of the failure of your make command. Also, it might be a good idea to provide
an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/www/libxul
*** Error code 1

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

www/firefox: configure: error: --enable-chrome-format must be set to either jar, flat, or omni

[O. Hartmann]

I'm unable to perform a port update on www/firefox due to the error
shown below.

Ports: Revision: 401759

System: CURRENT: FreeBSD 11.0-CURRENT #35 r290927: Mon Nov 16 12:39:46
CET 2015 amd64

[...]
configure:27490: c++ -o conftest -O2 -pipe -O3 -march=native -O3
-DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing  -DLIBICONV_PLUG
-fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections
-fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x
-Qunused-arguments -isystem/usr/local/include -DLIBICONV_PLUG
-pthread  -L/usr/local/lib -Wl,-rpath,/usr/local/lib/firefox
-fstack-protector -Wl,-z,noexecstack -Wl,-z,text conftest.C  1>&5
configure: error: --enable-chrome-format must be set to either jar,
flat, or omni *** Fix above errors and then restart with\ "gmake -f
client.mk
build" /usr/ports/www/firefox/work/mozilla-release/client.mk:364:
recipe for target 'configure' failed gmake[2]: *** [configure] Error 1
gmake[2]: Leaving directory '/usr/ports/www/firefox' ===>  Script
"configure" failed unexpectedly. Please report the problem to
ge...@freebsd.org [maintainer] and attach the
"/usr/ports/www/firefox/work/mozilla-release/config.log" including the
output of the failure of your make command. Also, it might be a good
idea to provide an overview of all packages installed on your system
(e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1

Stop.
make[1]: stopped in /usr/ports/www/firefox
*** Error code 1

Stop.
make: stopped in /usr/ports/www/firefox

===>>> make build failed for www/firefox
===>>> Aborting update

===>>> Update for firefox-41.0.2,1 failed
===>>> Aborting update
___
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"

lang/python3: port build with "package-recursive" fails

[O. Hartmann]

I use nanoBSD (sources: most recent CURRENT, build system: most recent CURRENT)
and try building ports via Makefile environment:

WHEREWEARE=`pwd`

package:
@export PKGREPOSITORY=${WHEREWEARE}/Pkg && \
cd /usr/ports/ports-mgmt/pkg && make clean && \
cd /usr/ports/lang/python34 && make clean && \
cd /usr/ports/lang/python3 && make clean && \
make package-recursive


I receive the error shown
below. I also run into the same trouble building the package on a
regular basis. It seems that some dependencies crucial for the installation are
not built. One reason seems to be that from earlier builds, some remnants (work
and content) are leftover, not cleaned up by the "make clean". I looked for a
"make clean-recursive", which, in my logical, naive thinking, could be the
salvation for this problem, but I didn't find a solution.

Somehow a solution seemed to arise when thinking about the toplevel port,
cleaning all its dependencies, but this also failed.

Is there an elegant solution to figure out for a port which one of them are
necessary to cleanup all dependencies? I thought lang/python3 would do, but
cleaning its repo directory doesn't clean everything recursively.

Please CC me, I do not subscribe the list.

Thanks in advance,

oh



[...]

+ CR env 'ASSUME_ALWAYS_YES=YES' /usr/sbin/pkg info
+ chroot /empty/obj/ALG_amd64-CUR/_.w /bin/sh -exc 'env
  ASSUME_ALWAYS_YES=YES /usr/sbin/pkg info'
+ /usr/bin/wc -l
+ env 'ASSUME_ALWAYS_YES=YES' /usr/sbin/pkg info
+ have='   2'
+ CR0 'ls Pkg/*txz | xargs env ASSUME_ALWAYS_YES=YES /usr/sbin/pkg add'
+ chroot /empty/obj/ALG_amd64-CUR/_.w /bin/sh -c 'ls Pkg/*txz | xargs env
  ASSUME_ALWAYS_YES=YES /usr/sbin/pkg add' Installing gettext-runtime-0.19.6...
pkg: Missing dependency 'indexinfo'
Installing gettext-tools-0.19.6...
pkg: Missing dependency 'expat'
Installing libffi-3.2.1...
pkg: Missing dependency 'indexinfo'
Installing pkgconf-0.9.12_1...
the most recent version of pkgconf-0.9.12_1 is already installed
Installing python3-3_3...
`-- Installing python34-3.4.3_1...
|   `-- Installing libffi-3.2.1...
pkg: Missing dependency 'indexinfo'
Installing python34-3.4.3_1...
`-- Installing libffi-3.2.1...
pkg: Missing dependency 'indexinfo'
Installing readline-6.3.8...
pkg: Missing dependency 'indexinfo'

Failed to install the following 6 package(s): Pkg/gettext-runtime-0.19.6.txz,
Pkg/gettext-tools-0.19.6.txz, Pkg/libffi-3.2.1.txz, Pkg/python3-3_3.txz,
Pkg/python34-3.4.3_1.txz, Pkg/readline-6.3.8.txz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: pkg: fetching packages for 10.2 on 11-CURRENT

[O. Hartmann]

On Mon, 5 Oct 2015 18:55:06 +0200
Baptiste Daroussin <b...@freebsd.org> wrote:

> On Mon, Oct 05, 2015 at 07:00:01AM +0200, O. Hartmann wrote:
> > Is it possible and doable via a simple setup (script/environment) to fetch
> > pre-built packages for 10.2-STABLE/10.2-RELEASE with pkg/pkgng on
> > 11-CURRENT?
> > 
> > Background: running a development system on 11-CURRENT, on which I prefer to
> > build my packages in the traditional way from sources without that massive
> > overhead poudriere pushes me sometimes into the situation for the need of 
> > ordinary binary packages for a 10.2-platform. On 11-CURRENT, I use a lot of
> > individual configurations on the ports making the binary packages useless,
> > but for that specific project (based on NanoBSD), it would be great to to
> > simply fetch binary packages for a "foreign" system's version.
> > 
> > Thank you very much in advance and pelase do CC me, I'm not subscribing the
> > list.
> 
> as root
> pkg -o ABI=FreeBSD:10:amd64 -o ALTABI=freebsd:10:x86:64 -o
> PKG_DBDIR=/tmp/tothrowaway fetch ... or as a user
> pkg -o ABI=FreeBSD:10:amd64 -o ALTABI=freebsd:10:x86:64 -o
> PKG_DBDIR=/tmp/tothrowaway -o INSTALL_AS_USER=yes fetch ...
> 
> 
> The fact you have to specify both ABI and ALTABI is a bug I will fix.
> 
> Best regards,
> Bapt

Thank you very much. This sounds easy to perform. Sorry for the late response.

Regards,
Oliver
___
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"

pkg: fetching packages for 10.2 on 11-CURRENT

[O. Hartmann]

Is it possible and doable via a simple setup (script/environment) to fetch
pre-built packages for 10.2-STABLE/10.2-RELEASE with pkg/pkgng on 11-CURRENT?

Background: running a development system on 11-CURRENT, on which I prefer to
build my packages in the traditional way from sources without that massive
overhead poudriere pushes me sometimes into the situation for the need of 
ordinary binary packages for a 10.2-platform. On 11-CURRENT, I use a lot of
individual configurations on the ports making the binary packages useless, but
for that specific project (based on NanoBSD), it would be great to to simply
fetch binary packages for a "foreign" system's version.

Thank you very much in advance and pelase do CC me, I'm not subscribing the
list.

Regards,
Oliver
___
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"

[emulators/VirtualBox]: System unresponsive/unusable with CPUs with more than 4 physical cores

[O. Hartmann]

Running emulators/virtualbox-ose (most recent due to daily ports updates and
daily kernel/kernel-module compilations) on 11.0-CURRENT FreeBSD 11.0-CURRENT #2
r287433: Thu Sep 3 15:14:30 CEST 2015 amd64 ontop of a 6-Core XEON Haswell:
CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3491.99-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x306f2 Family=0x6 Model=0x3f Stepping=2.

I realise a very strange behaviour on ALL VBox systems we run on FreeBSD since
9.0 that do have more than 4 physical cores. No matter how many cores I
delegate to a guest system (Windows 7), the 6 or 10 core XEON systems (12 or 20
logical cores) starts getting irresponsive, dramatic slow and within the Guest
and outside USB mice become highly jumpy and not very responsive.

Compared to a reference box running the very same OS revision, but with a
low-end 4-core XEON with only 4/8 physical/logical cores, the system is
dramaticallt slow. A system update of the guest was performed within 2 minutes
on the small XEON e3-12XX Haswell (16GB RAM), it is still running after 75
minutes on one of the 6-core systems (technical specs as shown above) (with
32GB RAM).

Is there a known issue (couldn't find something useful via Google) with FreeBSD?


Regards,
Oliver

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

www/firefox: 40.0 continously crashing

[O. Hartmann]

Since www/firefox has been updated to version 40.0, it keeps crashing 
erratically and
unpredictable.

Does anyone else recognise this misbehavious?

Regards,

oh


pgpEvhLTF8EyR.pgp
Description: OpenPGP digital signature

Re: databases/postgresql9[234]-server: LDAP support broken since last update!

[O. Hartmann]

On Fri, 24 Jul 2015 08:06:51 +0200
Baptiste Daroussin b...@freebsd.org wrote:

 On Fri, Jul 24, 2015 at 06:51:21AM +0200, O. Hartmann wrote:
  Someone broke databases/postgresql94-server's LDAP support (also 9.2, 9.3)!
  
  The LDAP support isn't compiled in anymore although explicitely selected.
  Obviously a --with-ldap switch gets lost during the procedure.
  
  See PR 201782 and PR 201795.
  
 Fixed, sorry about that.
 
 Bapt

Great,

thank you.

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

databases/postgresql9[234]-server: LDAP support broken since last update!

[O. Hartmann]

Someone broke databases/postgresql94-server's LDAP support (also 9.2, 9.3)!

The LDAP support isn't compiled in anymore although explicitely selected.
Obviously a --with-ldap switch gets lost during the procedure.

See PR 201782 and PR 201795.

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

WARNING: 'automake-1.14' is missing on your system.

[O. Hartmann]

Trying to perform building a port, I receive on several ports I'm about to
propose a nasty, sticky error and I can not fathom where it is rooted. For one
proposed port, devel/ocl-icd, please refer to

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

which contains on the very last few comments the problemacy.

Using the port's Makefile modified by Koop Mast and the fact, that he claims
(with no doubt) that he can build the port without the option USES= ...
autoconf and I can not, confuses me. I receive this error:

[...]
===  Building for ocl-icd-2.2.7
gmake[4]: Entering directory '/usr/ports/devel/ocl-icd/work/ocl-icd-2.2.7'
 cd .  /bin/sh /usr/ports/devel/ocl-icd/work/ocl-icd-2.2.7/build-aux/missing
automake-1.14 --foreign
Makefile /usr/ports/devel/ocl-icd/work/ocl-icd-2.2.7/build-aux/missing:
automake-1.14: not found WARNING: 'automake-1.14' is missing on your system.
[...]

I have also another port proposal, devel/pocl, which fails the same way.

The failure happens on ALL CURRENT machines I use (I have CURRENT only). The
systems are live-systems, not artificial or sterile environemnts, where ports
are installed without any option.

Well, I'd like to trackdown the problem but I fail. Somehow the GNU autotool
environment is a kind of messed up. devel/autotools has been successfully
installed so far and I did also on all boxes several times a portmaster -f to
ensure a complete installation. 

My root user is using shell csh, not sh, if this would make a difference (I
guess not, since I tried unsuccessfully otherwise).

Can someone please shed light on what is happening here? 

How to track down where autotool is failing?

Many thanks in advance,
Oliver

P.S.: Please CC me, I'm not subscribing freebsd-ports@
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

svn: E130003: The XML response contains invalid XML

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Since this morning, updating ports tree via SVN isn't possible anymore, I
receive :

Updating '.':
svn: E130003: The XML response contains invalid XML
*** Error code 1

Stop.
make: stopped in /usr/ports


Can somebody please explain whats happening? the problem occurs on several
locations here and several CURRENT/10-STABLE boxes

Regards,

O. Hartmann
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVLNVeAAoJEOgBcD7A/5N8jnsIAJgs1Dslbs4szz4G/w/O6zdC
3+KnZ567ock66LhA7SQ3JgdmiqyGIsh5FKS22VWlzeVS8XEiTBrJpzK2y8Q4rNzR
ByTLBWGRKsxpB2YfDC64M+KhXuYb5H6uneez46ebCiHeaXDVJzUfX36qW+8Yv8rK
sjjHMJ/5EvOVHobHXAVr0CFIdtN2toh17b+0+TA+lBQfeY8ki/kTl+ZkNsaj+eAI
Ogrmn7rnB2mY8evgtERaIJqNOWwF17vcjP+KxRqbb7LMBLIho2HEZ/ctQaKCMizK
1mQX8ouKB1gfe4m7m6JOKzJHRp0T3jShBCFlgUAb4cIbZgemhxTg0bB5CZ+XZOk=
=CSBs
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

pkg-static: sqlite error while executing INSERT OR REPLACE INTO

[O. Hartmann]

I can not update/reinstall port textproc/clucene due to the following error 
message:

[...]
===  Installing for clucene-2.3.3.4_6
===   Registering installation for clucene-2.3.3.4_6
Installing clucene-2.3.3.4_6...
pkg-static: sqlite error while executing INSERT OR REPLACE INTO packages( 
origin, name,
version, comment, desc, message, arch, maintainer, www, prefix, flatsize, 
automatic,
licenselogic, mtree_id, time, manifestdigest)
VALUES( ?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, (SELECT id FROM 
mtree
WHERE content = ?14), NOW(), ?15) in file pkgdb.c:1602: FOREIGN KEY constraint 
failed ***
Error code 70
[...]

It seems that the sql statement gets trapped in some inconsistent databasefile 
and I do
not know how to fix this problem.

How can I fix/repair this issue if related to a sqlite problem?

The system is
FreeBSD 11.0-CURRENT #2 r280457: Tue Mar 24 21:30:21 CET 2015 amd64,
the /usr/ports tree is at Revision: 382449, I use portmaster as the tool of 
choice.

Please CC me, do not subscribe this list.

Regards and thanks in advance,
Oliver


pgpaax1DXkRT0.pgp
Description: OpenPGP digital signature

textproc/clucene: pkg-static: sqlite error while executing INSERT OR REPLACE INTO packages

[O. Hartmann]

Since today's CURRENT update (running FreeBSD 11.0-CURRENT #1 r280149: Mon Mar 
16
19:41:00 CET 2015 amd64) I receive this nasty error on a box while updating 
ports:

textproc/clucene:

Installing clucene-2.3.3.4_5... pkg-static: sqlite error while executing INSERT 
OR
REPLACE INTO packages( origin, name, version, comment, desc, message, arch, 
maintainer,
www, prefix, flatsize, automatic, licenselogic, mtree_id, time, manifestdigest)
VALUES( ?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, (SELECT id FROM 
mtree
WHERE content = ?14), NOW(), ?15) in file pkgdb.c:1602: FOREIGN KEY constraint 
failed ***
Error code 70

It seems that something went wrong after the system's update and I have no clue 
what it
could mean. Filesystem doesn't seem to be corrupted.

Is there a way to solve this problem?

Please CC me, I'm not subscribing the list.

Regards and thanks in advance,

Oliver 


pgpYusxawXAKM.pgp
Description: OpenPGP digital signature

net-mgmt/icinga2 + net-mgmt/monitoring-plugins: check_snmp not working

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Using net-mgmt/icinga2 and net-mgmt/monitoring-plugins for observation of some
swithces and routers via check_snmp fails lately with the error on all systems
with a

CRITICAL - Plugin timed out while executing system call

Even those examples taken from the handbook do not work on FreeBSD CURRENT and
FreeBSD 10.1-p6 (systems and ports tree uptodate to the most recent sources).

I tried the command check_snmp manually as well as the snmpget (implicitely
installed from port net-mgmt/net-snmp) and they work well.

I suspect that the plugin is missing some variables (community, version, oid or
even host address), which are not passed properly by ICINGA2 to the plugin or
the handbook of icinga2 claims they're set but in reality they aren't.

I need some hints how to debug the call of a specific plugin and what that
plugin is provided with (variables) from ICINGA2. I only found some debugging
hints and features for ICINGA2 itself, but they do not help much since the logs
do not reveal the calling  of the plugin.

Can someone help with some hints?

Thanks in adavance,

Oliver
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJU9X7VAAoJEOgBcD7A/5N8yREIAK68nLugEEZBQwQ2QKOsMWf4
Q7gjrNwi5itQNVNX+ryHyg0kuzJSR+imqKDtFYslX/91Z2tgkDjr4G1sGvOD8dVd
uaznmLBguRz/PuPGFoQRxTJFhdv8OUGz28EH6JVcXD36huBSMfvUU5Vpd08MXbmM
Edb1mgHmmFYAFEYwJSWudXcX0lVR+AN83NnmZJ8hLUcHNM/Ia1kKDGtOh9DZpS1Q
b1GexUv7FYlilxUOcf5tnTGTGp/Q7I2oEE66BEzzCJsW48y37k/EiyWmqsT6dLPP
SoP9E6jNQy03vdr3Z0D6ZVU5vbs2YPKi+WHmXVri1VHFbZoc8JzqDT/oKpHpUcw=
=EIMy
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

net-mgmt/monitoring-pluginss: check_snmp always fails with: CRTICAL - Plugin timed out while executing system call

[O. Hartmann]

Having port net-mgmt/icinga2 in addition with net-mgmt/monitoring-plugins
running and monitoring installed on most recent CURRENT and 10.1-p6 systems, I
face a nasty bug/error/misconfiguration I cannot fathom and I need some
help/ideas.

The service I configured is taken from the handbook (Icinga2) and looks like


apply   Service snmp {
import  generic-service

check_command   = snmp

/* sysUpTimeInstance(0), see also http://www.oid-info.com/get/ */
vars.snmp_oid   = 1.3.6.1.2.1.1.3.0

assign where host.vars.snmp_community != 
}

and a specific host definition looks like



object Host B4132-SW01 {
import generic-host

address = 192.168.178.238

groups += [ switches ]

vars.snmp_community = public

vars.sla = 24x7
}


The problem is that almost every command out of the port
net-mgmt/monitoring-plugins works as expected - but check_snmp not! It always
fails with

CRITICAL - Plugin timed out while executing system call

I checked the plugin /usr/local/libexec/nagios/check_snmp manually and fed it
with parameters and it returns correct values.

So, since even the examples from the handbook don't work, I consider a bug.

Has anyone any ideas?

I have rebuilt icinga2, net-snmp (on 10.1.-p6, on CURRENT it is broken) and
monitoring plugins.

Please CC me.


Thanks in advance,

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

editors/libreoffice[-i18n]: compile failure: cannot install: the port wants postgresql-client

[O. Hartmann]

Updating and installig of port editors/libreoffice[-i18n] fails with
the strange error shown below. Port
databases/postgresql94-[server|client] is installed on the system in
question, running 

11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279201: Mon Feb 23 10:00:43 CET
2015 amd64

What is wrong with this installation/with the ports tree? Deleting the
port doesn't solve the problem.

Please CC 

Regards and thanks in advance,

OH

=== Port directory: /usr/ports/editors/libreoffice

=== This port is marked IGNORE
=== cannot install: the port wants postgresql-client version
9.0 9.1 9.2 9.3 9.4 and you have version 9.4 installed


=== If you are sure you can build it, remove the
   IGNORE line in the Makefile and try again.

=== Update for editors/libreoffice failed
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

net-mgmt/net-snmp: compile error: error: variable has incomplete type 'struct ifaddr' struct ifaddr ifaddr;

[O. Hartmann]

Portnet-mgmt/net-snmp fails to update/build on CURRENT:

libtool: compile:  cc -I../../include -I. -I../../agent
-I../../agent/mibgroup -I../../snmplib -I/usr/include
-DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -O2 -pipe -O3 -march=native
-I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector
-fno-strict-aliasing -std=c99 -Ufreebsd11 -Dfreebsd11=freebsd11
-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include
-I/usr/local/lib/perl5/5.18/mach/CORE -c mibII/ipv6.c  -fPIC -DPIC -o
mibII/.libs/ipv6.o mibII/ipv6.c:806:20: warning: returning 'char *'
from a function with result type 'u_char *' (aka 'unsigned char *')
converts between pointers to integer types with different sign
[-Wpointer-sign] return p; ^ mibII/ipv6.c:848:29: error: variable has
incomplete type 'struct ifaddr' struct ifaddr   ifaddr;
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

emulators/virtualbox-ose: /tstVMStructRC: 1: Syntax error: ( unexpected

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On all CURRENT systems (most recent and modern  IvyBridge hardware installed
after 9/2014) I face a nasty problem in compiling emulators/virtualbox-ose, as
the error below documents. The compilation error is sticky now for months and
occurs on CURRENT since September 2014. The systems in question have been
installed around that time and later (last box Jabuary 2015).

The strange part is that I also run some other systems with the same recent
CURRENT and most recent ports tree, but they have been installed a long time
ago and they slide from one revision of CURRENT to the next. Those boxes are
also equipted with recent CPU architectures (most recent is a IvyBridge XEON).

I tried to rebuild everything prerequisite for mulators/virtualbox-ose via
portmaster -f, but without any success. All systems in questions do have a
very similar setup and a identical /etc/src.conf and /etc/make.conf.


Please CC me, as i do not subscribe the list.

Regards,

oh

[...]

kBuild: bin2c vboxweb-wsdl
- - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.22/out/freebsd.amd64/release/obj/webservice/vboxweb.wsdl
kBuild: Installing tstVMStructRC
= 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.22/out/freebsd.amd64/release/bin/tstVMStructRC
kBuild: Generating tstVMStructSize
- - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.22/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h
 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.22/out/freebsd.amd64/release/bin/tstVMStructRC:
1: Syntax error: ( unexpected kmk: ***
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.22/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h]
Error 2 kmk: *** Deleting file
`/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.22/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h'
kmk: *** Waiting for unfinished jobs filesplitter: Out of 144 files: 144
rewritten, 0 unchanged.
(/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.22/out/freebsd.amd64/release/obj/VirtualBox/include)
kmk_builtin_append
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.22/out/freebsd.amd64/release/obj/VirtualBox/include/COMWrappers
kmk: *** Exiting with status 2 *** Error code 2

Stop.
make[1]: stopped in /usr/ports/emulators/virtualbox-ose
*** Error code 1

Stop.
make: stopped in /usr/ports/emulators/virtualbox-ose
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJU4wAyAAoJEOgBcD7A/5N8zykH/iNxnmbKu4Qlxq2ftmYtA4zx
PPA/NVDvkkhFHyQmIH8VqguPVAjEl5gVPJo/6mfu8iEtfL0Rx7TqlPYiaUn+cEbL
Jf2hIjE3zClKIHeZ6T1Sw4mEgnnWddYZb1YFJfsLOUCIPKWU9n9GKTTllJK3qid1
Hv83w+zxS1lPQRhdoVkNy6zZ0lhdBvxh0x+CqCb9SyS26wI/UDga91p+meHFi5iv
szU54AHDcyXHbZD2FrFUsm4mPwUR0CUg48W0DiJqPu/NQXIRYSnabz4mZmY3jBiQ
QpZInXWKTW/5p4ySrXPUt7b538l5NAbFsYHJbbaepGLZLysKEJtvsZvpE8m+rbU=
=l2B+
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: emulators/virtualbox-ose: Syntax error: ( unexpected kmk: ***

[O. Hartmann]

On Sat, 03 Jan 2015 00:50:26 +0100
Michelle Sullivan miche...@sorbs.net wrote:

 O. Hartmann wrote:
  On a CURRENT box, I run always into this very sticky error, shown below. I
  already deinstalled the port and tried to recompile (using portmaster),
  without success. Also have I recompiled every requisite port via
  portmaster -f, but the error is still glued to my butt:
 
  [...]
  kBuild: Linking VBoxKeyboard
  kBuild: bin2c VBoxSDL
  - 
  /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/src/VBox/Frontends/VBoxSDL/ico64x01.pnm
  kBuild: Generating VirtualBox
  - 
  /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VirtualBox_stripped.xidl
  kBuild: rcc VirtualBox
  - 
  /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VirtualBox/misc/VirtualBoxBrand.qrc
  kBuild: Compiling VBoxOGLhosterrorspu
  - 
  /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VBoxOGLgen/errorspu.c
  4 warnings generated. kBuild: bin2c vboxweb-wsdl
  - 
  /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/webservice/vboxweb.wsdl
  kBuild: Installing tstVMStructRC
  = 
  /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/bin/tstVMStructRC
  kBuild: Generating tstVMStructSize
  - 
  /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h
   
  /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/bin/tstVMStructRC:
  1: Syntax error: ( unexpected kmk: ***
  [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h]
  Error 2 kmk: *** Deleting file
  `/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h'
  kmk: *** Waiting for unfinished jobs filesplitter: Out of 144 files: 144
  rewritten, 0 unchanged.
  (/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VirtualBox/include)
  kmk_builtin_append
  /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VirtualBox/include/COMWrappers
  kmk: *** Exiting with status 2 *** Error code 2
  [...]

 
 
  I had this a while ago after an upgrade IIRC make deinstall distclean
 config package fixed it for me... though I might have manually
 shutdown/removed the kernel modules and deleted them first...
 
 Regards,
 

Hello,

thank you for the response.

I deinstalled everything related to VirtualBox, inclusive kBuild and made a
rmconfig in every port folder. I also deinstalled/checked for deinstallation
of the kernel modules and rebooted after the switch-off. After that I installed
emulators/virtualbox-ose again. But I always run into this specific error! 
On several other systems, running the very same OS revision and optimizations
defined in /etc/src.conf, I do not get this error message. Something seems very
fishy ...

Regards,

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

emulators/virtualbox-ose: Syntax error: ( unexpected kmk: ***

[O. Hartmann]

On a CURRENT box, I run always into this very sticky error, shown below. I
already deinstalled the port and tried to recompile (using portmaster), without
success. Also have I recompiled every requisite port via portmaster -f, but
the error is still glued to my butt:

[...]
kBuild: Linking VBoxKeyboard
kBuild: bin2c VBoxSDL
- 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/src/VBox/Frontends/VBoxSDL/ico64x01.pnm
kBuild: Generating VirtualBox
- 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VirtualBox_stripped.xidl
kBuild: rcc VirtualBox
- 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VirtualBox/misc/VirtualBoxBrand.qrc
kBuild: Compiling VBoxOGLhosterrorspu
- 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VBoxOGLgen/errorspu.c
4 warnings generated. kBuild: bin2c vboxweb-wsdl
- 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/webservice/vboxweb.wsdl
kBuild: Installing tstVMStructRC
= 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/bin/tstVMStructRC
kBuild: Generating tstVMStructSize
- 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h
 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/bin/tstVMStructRC:
1: Syntax error: ( unexpected kmk: ***
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h]
Error 2 kmk: *** Deleting file
`/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h'
kmk: *** Waiting for unfinished jobs filesplitter: Out of 144 files: 144
rewritten, 0 unchanged.
(/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VirtualBox/include)
kmk_builtin_append
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.20/out/freebsd.amd64/release/obj/VirtualBox/include/COMWrappers
kmk: *** Exiting with status 2 *** Error code 2
[...]


Please CC me.

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

After Update today: No origin available for eigen~pkg-renamed~3FCF-3.2.2

[O. Hartmann]

On several CURRENT and 10.1-boxes with today's ports tree update, I run into a 
very
strange problem with a non-responsive, non-updatable portstree, with errors like


=== Gathering distinfo list for installed ports

=== Starting check of installed ports for available updates
=== No origin available for eigen~pkg-renamed~3FCF-3.2.2


=== Cannot continue
=== Aborting update


This -renamed~3FCF-3.2.2 extension occurs on many ports and in UPDATING, 
there is no
mark that should give me a hint ...


pgpULK6SxSOvA.pgp
Description: OpenPGP digital signature

Re: Difference between fetch(1) and firefox http-access

[O. Hartmann]

On Mon, 8 Dec 2014 16:19:01 +0700
Olivier Nicole olivier.nic...@cs.ait.ac.th wrote:

 Olivier,
 
  Running CURRENT (FreeBSD 11.0-CURRENT #2 r275512: Fri Dec  5
  16:00:34 CET 2014 amd64), I ran into some kind of obscurity I can
  not fathom.
 
  Updating ports fails since a couple of days by now (I do updates on
  a daily basis). fetch isn't capable of reaching any(!) server it
  tries to download sourcecode tarballs from (neither via ports ftp,
  http, https).
 
  When manually copied the sources of the tarball to Firefox' URL
  requester, I can luckily download the sources to whatever
  destination I like and I have to copy them to
  the /usr/ports/distfiles[/blabla] destination manually.
 
 Did you try to fetch the source manually: fetch URL...

Yes I did, no success, see below for the magic solution of the
problem ...
 
 Just to confirm/infirm the problem with fetch. Do you have some
 HTTP_PROXY env variable set?

That was the hint of the hints. I swapped from a secured environment
back to a more open and forgot to reset/unset the http_proxy and
ftp_proxy environment variables :-( I wasn't aware of the fact that I
had set them. So, the problem is bewtween my eyes ...

Sorry for the noise, many thanks for the quick solution ...


Oliver
 
 Olivier
 
 
  As I understood fetch it establishes a simple ftp, http or https
  connection, as Firefox does. But it seems that something is going
  terribly wrong.
 
  It would be nice if someone could push me towards a hint or
  something to solve the problem. I hope it's not a serious bug but a
  simple error in the configuration.
 
  Thanks in advance,
  Oliver
  ___
  freebsd-questi...@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-questions
  To unsubscribe, send any mail to
  freebsd-questions-unsubscr...@freebsd.org

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

Difference between fetch(1) and firefox http-access

[O. Hartmann]

Running CURRENT (FreeBSD 11.0-CURRENT #2 r275512: Fri Dec  5 16:00:34
CET 2014 amd64), I ran into some kind of obscurity I can not fathom.

Updating ports fails since a couple of days by now (I do updates on
a daily basis). fetch isn't capable of reaching any(!) server it tries
to download sourcecode tarballs from (neither via ports ftp, http,
https).

When manually copied the sources of the tarball to Firefox' URL
requester, I can luckily download the sources to whatever destination I
like and I have to copy them to the /usr/ports/distfiles[/blabla]
destination manually.

As I understood fetch it establishes a simple ftp, http or https
connection, as Firefox does. But it seems that something is going
terribly wrong.

It would be nice if someone could push me towards a hint or something
to solve the problem. I hope it's not a serious bug but a simple error
in the configuration.

Thanks in advance,
Oliver
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

CURRENT Revision: 274250 breaks build of x11/nvidia-driver: pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2

[O. Hartmann]

Out of the blue the build of port x11/nvidia-driver fails - portmaster is that 
sloppy
that it can not check BEFORE it kills the existent driver and fails to install 
after the
deletion!

The src tree is at Revision: 274250 and with Revision r274177 the build works. 
The
failure is:

===   Registering installation for nvidia-driver-343.22
pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2 (installs files 
into the
same place).  Problematic file: /usr/local/lib/libEGL.so To use these drivers, 
make sure
that you have loaded the NVidia kernel module, by doing

[...]

Please can someone fix this? I have three boxes now without graphics due to 
this.

Regards,

Oliver


pgpxpHCLzxOSI.pgp
Description: OpenPGP digital signature

CURRENT breaks build of x11/nvidia-driver: pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2

[O. Hartmann]

Out of the blue the build of port x11/nvidia-driver fails - portmaster is that 
sloppy
that it can not check BEFORE it kills the existent driver and fails to install 
after the
deletion!

The src tree is at Revision: 274250 and with Revision r274177 the build works. 
The
failure is:

===   Registering installation for nvidia-driver-343.22
pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2 (installs files 
into the
same place).  Problematic file: /usr/local/lib/libEGL.so To use these drivers, 
make sure
that you have loaded the NVidia kernel module, by doing

[...]

Please can someone fix this? I have three boxes now without graphics due to 
this.

Regards,

Oliver


pgpPLUfwLQ9uk.pgp
Description: OpenPGP digital signature

Re: net-mgmt/icinga2: Icinga Web is not working: Error: Could not read object configuration data!

[O. Hartmann]

Am Sat, 1 Nov 2014 14:12:08 +0100
Lars Engels lars.eng...@0x20.net schrieb:

 On Fri, Oct 31, 2014 at 07:55:04PM +0100, O. Hartmann wrote:
  
  On CURRENT (most recent), I run net-mgmt/icinga2. Setup ran smooth, I also 
  set up the
  IDO for PostgreSQL. Checking whether icinga2 logs data to the PostgreSQL 
  database
  resulted positive.
  
  I try to install/configure a Web Interface a sdescribed in the Icinga2 
  docs. IDO is a
  prerequiste for Icinga Web (I'm not using Icinga Web 2!).
  
  For that purpose, I installed net/mgmt/icinga (which contains the web 
  interface). I
  made the proper changes to /usr/local/etc/icinga/cgi.cfg as reported in 
  this HowTo:
  http://lists.freebsd.org/pipermail/freebsd-ports/2014-June/093372.html. 
  Please see
  also https://forums.freebsd.org/threads/icinga2-network-monitoring.47106/. 
  Via
  icinga2-enable-feature I also enabled all requested modules as described in 
  the
  Icinga2 docs.
  
  So far. Having doen EXACTLY as suggested, I do not get any kind of 
  Webinterface. The
  web browser (Mozilla Firefox) reports always: Error: Could not read object
  configuration data!
  
  There is something missing.
  
  Is someone using Icinga2 with the classical Web and has followed these 
  instructions
  and gets a different result?
  
 
 Hi Oliver,
 
 on a clean system, I just followed (my own) CFT instructions you also
 used. I didn't encounter a problem. The only typo in the list is that
 this:
 cp /usr/local/share/examples/icinga/apache22/icinga.conf-sample 
 /usr/local/etc/apache2/Includes/icinga.conf
   
   
  
 should be
 apache22
 
 Apart from this, there wasn't anything that didn't work. I used
 pkg install apache22 icinga icinga2 though and didn't need to copy the
 .cfg-sample file as the icinga port does this by itself now.
 
 Can you please check all file and directory locations you changed in
 icinga/cgi.cfg? I guess the status_file line leads to a non-existing
 status.dat.
 
 
 Please also CC me on any questions you have regarding icinga[2] and
 FreeBSD as I maintain both ports.
 
 
 Lars

Correct - I had a type in cgi.cfg.

I use Apache 2.4 (www/apache24) by the way. I have now a web page - but it is 
empty/ugly
looking. I guess there is a bit of further work.

Thanks a lot for the hint.

Kind Regards,
Oliver


pgptEo7KEmxJR.pgp
Description: OpenPGP digital signature

net-mgmt/icinga2: Icinga Web is not working: Error: Could not read object configuration data!

[O. Hartmann]

On CURRENT (most recent), I run net-mgmt/icinga2. Setup ran smooth, I also set 
up the IDO
for PostgreSQL. Checking whether icinga2 logs data to the PostgreSQL database 
resulted
positive.

I try to install/configure a Web Interface a sdescribed in the Icinga2 docs. 
IDO is a
prerequiste for Icinga Web (I'm not using Icinga Web 2!).

For that purpose, I installed net/mgmt/icinga (which contains the web 
interface). I made
the proper changes to /usr/local/etc/icinga/cgi.cfg as reported in this HowTo:
http://lists.freebsd.org/pipermail/freebsd-ports/2014-June/093372.html. Please 
see also
https://forums.freebsd.org/threads/icinga2-network-monitoring.47106/. Via
icinga2-enable-feature I also enabled all requested modules as described in the 
Icinga2
docs.

So far. Having doen EXACTLY as suggested, I do not get any kind of 
Webinterface. The web
browser (Mozilla Firefox) reports always: Error: Could not read object 
configuration data!

There is something missing.

Is someone using Icinga2 with the classical Web and has followed these 
instructions and
gets a different result?

Please CC me.

Kind regards,
Oliver


pgpgiET08OzNe.pgp
Description: OpenPGP digital signature

net-mgmt/icinga2: web interface with FreeBSD?

[O. Hartmann]

I was wondering if someone has successfully configured ICINGA2 on
FreeBSD, using the Web-2 or even Web frontend.

ICINGA2 is successfully installed on my systems, also IDO on PostgreSQL.

While almost EVERY Howto relates to Linux and a port/package
called icinga-web, FreeBSD seems to be without any notes - not even the
port has any informations about what  and where to find (I find it not
very pleasant having to search for pgsql.conf, which is important for
setting up the database and is located
in /usr/local/share/examples/icinga2/... - a note in the pkg_message
would be helpful).

Well, I'm now back to ICINGA and try to configure io2db. As I
understand the Linux HowTo, ido2db is taken from ICINGA 1 and is not a
separate or ICINGA 2 specific facility. So, my thinking is that it must
be possible to install and configure net-mgmt/icinga with only the
ido2db portions and install/run port net-mgmt/icinga2 instead of
net-mgmt/icinga. 

Any hints appreciated. Please CC me.

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

emulators/virtualbox-ose: compilation on CURRENT fails due to: tstVMStructRC: 1: Syntax error: ( unexpected

[O. Hartmann]

Compiling emulators/virtualbox-ose on a freshly installed CURRENT
(FreeBSD 11.0-CURRENT #0 r273719: Mon Oct 27 07:59:12 CET 2014 amd64)
results in the below shown error.

I also tried to install the package on CURRENT via pkg install, but
this results in a 32-Bit VirtualBox only - which is inacceptable.

I have running emulators/virtualbox-ose on several other CURRENT
machines, but most of those boxes are grown, that means, they got
CURRENT months ago and are maintained as usual (buildworld/portmaster).
This box has been installed a couple of weeks ago and is successfully
rejecting compilation of port emulators/virtualbox-ose, although I
already updated the ports tree and did successfully a portmaster -R
-fd /emulators/virtualbox-ose.

Since I use some non-standard optimization flags in /etc/src.conf
and /etc/make.conf (-O3 and CPUTYPE=native instead of plain -O and
outdated architectural compatibilities), I switched back to the FreeBSD
vanilla standard - but still the same. I can not imagine that the CPU
of that specific box could be the culprit:


dmesg output:

CPU: Intel(R) Core(TM)
i5-3470 CPU @ 3.20GHz (3192.82-MHz K8-class CPU) Origin=GenuineIntel
Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0x7fbae3ffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND
AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF
  Structured Extended Features=0x281FSGSBASE,SMEP,ERMS
  XSAVE Features=0x1XSAVEOPT
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 9107931136 (8686 MB)
avail memory = 8147902464 (7770 MB)

The error is:


[...]

kBuild: Generating tstVMStructSize
- 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h
 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/bin/tstVMStructRC:
1: Syntax error: ( unexpected kmk: ***
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h]
Error 2 kmk: *** Deleting file
`/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h'
kmk: *** Waiting for unfinished jobs filesplitter: Out of 144
files: 144 rewritten, 0 unchanged.
(/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include)
kmk_builtin_append
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include/COMWrappers
kmk: *** Exiting with status 2 *** Error code 2
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

x11/nvidia-driver: fails to build: @/sys/filedesc.h:37:10: fatal error: 'opt_capsicum.h' file not found

[O. Hartmann]

Most recent CURRENT (Revision: 272559) is unwilling to compile the port
x11/nvidia-driver. The error occurs with all avaiable nVidia BLOBs.

Sorry for the messy output, claws-mail seems to kill the line terminating 
character.

I also filed a PR to make this recorded:

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


[...]
cc  -O2 -pipe -O3 -O3 -pipe -march=native -fno-strict-aliasing -O3 -O3 -pipe
-march=native  -DNV_VERSION_STRING=\343.22\ -D__KERNEL__ -DNVRM 
-Wno-unused-function
-Wuninitialized -O2 -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -UDEBUG 
-U_DEBUG
-DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I. -I@ -I@/contrib/altq
-fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  
-mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables
-ffreestanding -fstack-protector -mno-aes -mno-avx -Qunused-arguments 
-std=iso9899:1999
-fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign
-fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality
-Wno-error-unused-function  -mno-aes -mno-avx -Qunused-arguments -c 
nvidia_acpi.c In file
included from nvidia_acpi.c:14: In file included from ./nv-freebsd.h:89:
@/sys/filedesc.h:37:10: fatal error: 'opt_capsicum.h' file not found 
#include opt_capsicum.h ^ 1 error generated. *** Error code 1

Stop.
make[6]: stopped
in 
/usr/obj/usr/src/sys/HERMANN/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-343.22/src
*** Error code 1


Regards,

Oliver


signature.asc
Description: PGP signature

pkg/ports system terribly messed up?

[O. Hartmann]

Hello.

I just made the last update of the ports yesterday (I use portmaster -da 
performing this
task) and obviously or superficially everything went all right.

I'm running on the boxes in question most recent CURRENT.

On one system, a subsequent start of updating ports starts to freak out when 
updateing
lang/gcc: it loops over and over on some ports already updated, especially
devel/binutils, but the port looping on isn't specific and varies.

On every CURRENT box I tried this morning to update the ports again, I find this
frsutrating message (depends on installation, but it seems in principal the 
same, only
the affected ports in dependency chain varies):

 === Gathering distinfo list for installed ports

=== Starting check of installed ports for available updates
=== Launching child to update openldap-sasl-client-2.4.39_2 to
openldap-sasl-client-2.4.40

=== All  openldap-sasl-client-2.4.39_2 (1/1)

=== Currently installed version: openldap-sasl-client-2.4.39_2
=== Port directory: /usr/ports/net/openldap24-sasl-client

=== Launching 'make checksum' for net/openldap24-sasl-client in background
=== Gathering dependency list for net/openldap24-sasl-client from ports
=== Launching child to install 
net/openldap24-sasl-client/../../ports-mgmt/pkg

=== All  openldap-sasl-client-2.4.39_2 
net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2)

=== Port directory: 
/usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg


=== Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed
=== Aborting update

=== Update for openldap-sasl-client-2.4.39_2 failed
=== Aborting update

You have new mail.


This isn't, so far, OpenLDAP specific, on other systems without LDAP the update 
fails on
another port.

Oliver


signature.asc
Description: PGP signature

Re: pkg/ports system terribly messed up?

[O. Hartmann]

Am Tue, 30 Sep 2014 08:40:19 +0200 (CEST)
Trond Endrestøl trond.endres...@fagskolen.gjovik.no schrieb:

 On Tue, 30 Sep 2014 08:13+0200, O. Hartmann wrote:
 
  
  Hello.
  
  I just made the last update of the ports yesterday (I use portmaster -da 
  performing
  this task) and obviously or superficially everything went all right.
  
  I'm running on the boxes in question most recent CURRENT.
  
  On one system, a subsequent start of updating ports starts to freak out 
  when updateing
  lang/gcc: it loops over and over on some ports already updated, especially
  devel/binutils, but the port looping on isn't specific and varies.
  
  On every CURRENT box I tried this morning to update the ports again, I find 
  this
  frsutrating message (depends on installation, but it seems in principal the 
  same, only
  the affected ports in dependency chain varies):
  
   === Gathering distinfo list for installed ports
  
  === Starting check of installed ports for available updates
  === Launching child to update openldap-sasl-client-2.4.39_2 to
  openldap-sasl-client-2.4.40
  
  === All  openldap-sasl-client-2.4.39_2 (1/1)
  
  === Currently installed version: openldap-sasl-client-2.4.39_2
  === Port directory: /usr/ports/net/openldap24-sasl-client
  
  === Launching 'make checksum' for net/openldap24-sasl-client in 
  background
  === Gathering dependency list for net/openldap24-sasl-client from ports
  === Launching child to install 
  net/openldap24-sasl-client/../../ports-mgmt/pkg
  
  === All  openldap-sasl-client-2.4.39_2 
  net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2)
  
  === Port directory: 
  /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg
  
  
  === Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed
  === Aborting update
  
  === Update for openldap-sasl-client-2.4.39_2 failed
  === Aborting update
  
  You have new mail.
  
  
  This isn't, so far, OpenLDAP specific, on other systems without LDAP the 
  update fails
  on another port.
  
  Oliver
 
 What happens if you manually upgrade ports-mgmt/pkg, assuming it's out 
 of date?

I tried this already, each port in particular, reinstalled via make clean 
reinstall
clean works fine. I did this with ports-mgnt/pkg and ports-mgmt/portmaster in 
the first
place.

 
 I've noticed running make missing from /usr/ports/ports-mgmt/pkg 
 produces some interesting results _only_ when pkg is up-to-date:
 
 trond@enterprise:/usr/ports/ports-mgmt/pkgmake missing
 /usr/ports/workdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.3.8/src/pkg-static: 
 not found
 *** [missing] Error code 127
 
 Stop in /usr/ports/ports-mgmt/pkg.
 
 Using portupgrade, I finally created a script to help me get past some 
 of the deficiency of the duo pkg and portupgrade. The script checks to 
 see if ports-mgmt/pkg needs an upgrade and upgrades pkg before 
 proceeding with the remaining outdated ports. As portupgrade doesn't 
 always properly install _new_ dependencies, my script also checks for 
 any missing ports and installs them prior to upgrading the outdated 
 ports. If anyone's interested, here's my script: 
 http://ximalas.info/~trond/create-zfs/canmount/upgrade-outdated-ports.sh
 


I'm running portmaster and an update of ports now on an Laptop with CURRENT 
that hasn't
been touched for two days by now and there the update runs quite well and 
passes through.
All boxes I ran an update of ports by yesterday fail!


signature.asc
Description: PGP signature

Re: service doen't get started at boottime, but can start manually

[O. Hartmann]

Am Sun, 7 Sep 2014 11:16:37 -0500
Scot Hetzel swhet...@gmail.com schrieb:

 On Sun, Sep 7, 2014 at 10:44 AM, Scot Hetzel swhet...@gmail.com wrote:
  I created the rc.d/refdbd script by copying /etc/rc.d/inetd and make a
  few minor changes.
  This script (untested) should do what the scripts/refdb.in and
  scripts/refdbctl.in were doing:
 
  #!/bin/sh
  #
  # $FreeBSD$
  #
 
  # PROVIDE: refdbd
  # REQUIRE: LOGIN
  # KEYWORD: shutdown
 
  . /etc/rc.subr
 
  name=refdbd
  rcvar=refdbd_enable
  command=%%PREFIX%%/bin/${name}
  pidfile=/var/run/${name}.pid
  required_files=/etc/${name}.conf
 
 I missed required_files in my editing of the original script.
 
 If refdbd does have a configuration file, changes this to point to the
 correct file, otherwise this can be removed.
 
  extra_commands=reload
 
  load_rc_config $name
  run_rc_command $1
 
  Place the above in textproc/refdb/files/refdb.in, then add:
 
  USE_RC_SUBR= refdbd
 
  in textproc/refdb/Makefile.
 
 

It seems to me, that when a port installs a script appended with *.sh in 
etc/rc.d/, the
script gets executed anyway - regardless wether the service is enabled
in /etc/rc.conf[.local] or not. This is especially the case for the original 
port
textproc/refdb.

The reason why especially one particular machine rejected the startup of the 
service was:
I changed the script's name from refdb.sh to refdb and with the lack of the 
correct
syntax and definitions inside it, the system (11.0 CURRENT) did not start the 
service
while the other systems running refdb used the oldstyle refdb.sh script.

Just for the conclusion of the obscure (at least for me) behaviour.

Thanks for your time,

Oliver


signature.asc
Description: PGP signature

Re: [Bug 144203] textproc/refdb: network clients loop indefinitely when hitting Ctrl-D while client asks for passowrd

[O. Hartmann]

Am Tue, 09 Sep 2014 06:35:29 +
bugzilla-nore...@freebsd.org schrieb:

 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144203
 
 --- Comment #8 from John Marino mar...@freebsd.org ---
 FYI, I'm removing this port tonight.   We've waited long enough.
 


In the strain of a bug I reported I also tried to fix this port, since the prior
maintainer seems to have abandonded this great port.

I'm a bit pissed off about the rude tune I feel treated!

The developer has patched the original sources to meet some FreeBSD requirements
regarding a readline issue now fixed and especially some serious bugs in 
bib2ris and a
transforming/migrating tool using UTF-8 encodings for LaTeX codings. Since not 
all
patches are 100% tested (but they work graeat for me in a scientific 
environment), the
upstream developer hestiates creating the new tarball. 

As I documented with this PR, I'm wating for the developer to publish a new
tarball.

I spent lot of time to provide a workaround for fixing the lack of the new 
tarball and
some serious previously unresolved FreeBSD issues and the time I sacrificed is 
not only
working time! I mention this since I'm feeling put under pressure as the note 
sent to
me documents.

What is the policy of FreeBSD's port system? There are lots of ports waiting to 
be fixed
since they have serious issue, like silc-toolkit. Is this port also about to be 
deleted
or isn't there a lobby preventing this?

In a hurry, to prevent the destruction of the port textproc/refdb, I provided a 
patch.
The patch is a bit messy since I had to incorporate all changes made in the 
meanwhile
after creation of refdb-1.0.2.tar.gz (provided at:
http://sourceforge.net/projects/refdb/files/latest/download). 

Please see PR Bug 193484 - [textproc/refdb] Update port.

With regards,

oh


signature.asc
Description: PGP signature