java/openjdk7 update fails to build

2020-03-09 Thread Jonathan Chen
Hi,

The latest update to java/openjdk7 on 8-Mar to 7u251 is currently failing with:

echo Linking launcher...
Linking launcher...
cc -m64 -Xlinker -O1  -Xlinker -z -Xlinker noexecstack -m64 -Xlinker
-export-dynamic  -L`pwd`  -o gamma launcher/java_md.o
launcher/jli_util.o launcher/wildcard.o launcher/java.o -ljvm  -lm
-pthread
ld: error: undefined symbol: JNI_CreateJavaVM
>>> referenced by java_md.c:752 
>>> (/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1/hotspot/src/os/posix/launcher/java_md.c:752)
>>>   launcher/java_md.o:(LoadJavaVM)

ld: error: undefined symbol: JNI_GetDefaultJavaVMInitArgs
>>> referenced by java_md.c:753 
>>> (/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1/hotspot/src/os/posix/launcher/java_md.c:753)
>>>   launcher/java_md.o:(LoadJavaVM)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[7]: *** 
[/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1/hotspot/make/bsd/makefiles/launcher.make:102:
gamma] Error 1
gmake[7]: Leaving directory
'/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1/build/bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product'
gmake[6]: *** 
[/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1/hotspot/make/bsd/makefiles/top.make:129:
the_vm] Error 2
gmake[6]: Leaving directory
'/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1/build/bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product'
gmake[5]: *** 
[/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1/hotspot/make/bsd/Makefile:292:
product] Error 2
gmake[5]: Leaving directory
'/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1/build/bsd-amd64/hotspot/outputdir'
gmake[4]: *** [Makefile:203: generic_build2] Error 2
gmake[4]: Leaving directory
'/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1/hotspot/make'
gmake[3]: *** [Makefile:158: product] Error 2
gmake[3]: Leaving directory
'/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1/hotspot/make'
gmake[2]: *** [make/hotspot-rules.gmk:128: hotspot-build] Error 2
gmake[2]: Leaving directory
'/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1'
gmake[1]: *** [Makefile:251: build_product_image] Error 2
gmake[1]: Leaving directory
'/construction/xports/java/openjdk7/work/jdk7u-jdk7u251-b02.1'
*** Error code 1

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


Re: amdgpu panics

2020-03-09 Thread Hans Petter Selasky

On 2020-03-10 00:03, Grzegorz Junka wrote:
I've upgraded my system to 12.1. I have recompiled all ports with 
poudriere using jail 12.1. As soon as "amdgpu" kernel module is loaded 
the system panics. Tried with both, "drm-kmo" and "drm-fbsd12.0-kmod". 
Any ideas?




Are the kernel sources in the jail matched with your system?

--HPS

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


amdgpu panics

2020-03-09 Thread Grzegorz Junka
I've upgraded my system to 12.1. I have recompiled all ports with 
poudriere using jail 12.1. As soon as "amdgpu" kernel module is loaded 
the system panics. Tried with both, "drm-kmo" and "drm-fbsd12.0-kmod". 
Any ideas?


Grzegorzj

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


2020Q1 and firefox/thunderbird

2020-03-09 Thread Boris Samorodov

Hi all,

There are no firefox/thunderbird ports at the
quarterly repository. Is there any ETA to fix this?

--
WBR, bsam
___
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"


level/py-setuptools failing

2020-03-09 Thread joe mcguckin
===>  Checking if py37-setuptools is already installed
===>   Registering installation for py37-setuptools-44.0.0
Installing py37-setuptools-44.0.0...
pkg-static: py37-setuptools-44.0.0 conflicts with py36-setuptools-41.2.0 
(installs files into the same place).  Problematic file: 
/usr/local/bin/easy_install
*** Error code 70



Joe McGuckin
ViaNet Communications

j...@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



___
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: [RFC] Adding a Rados block driver to bhyve

2020-03-09 Thread Dave Horsfall

On Mon, 9 Mar 2020, Miroslav Lachman wrote:

There are some ports (for example sysutils/lsof) which need kernel 
sources to build.  [...]


Kernel sources, or just the headers?

-- Dave
___
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: [RFC] Adding a Rados block driver to bhyve

2020-03-09 Thread Willem Jan Withagen

On 9-3-2020 12:38, Miroslav Lachman wrote:

Willem Jan Withagen wrote on 2020/03/09 11:31:

[...]


3) Create a bhyve-rbd port.
 Problem with that is that it will require the FreeBSD source tree 
for the

 bhyve sources, but there is no Ports option for that?
     Or bhyve sources are manually copied into the port. And then
 try to keep these sources up to date.
 Then compile and install a bhyve-rbd into /usr/local/sbin


There are some ports (for example sysutils/lsof) which need kernel 
sources to build. So this can be a way too. I cannot say if this is the 
best way or not.


Yes, there seems a flag for kernel sources...
But not for world-sources.??

--WjW
___
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: [RFC] Adding a Rados block driver to bhyve

2020-03-09 Thread Miroslav Lachman

Willem Jan Withagen wrote on 2020/03/09 11:31:

[...]


3) Create a bhyve-rbd port.
     Problem with that is that it will require the FreeBSD source tree 
for the

     bhyve sources, but there is no Ports option for that?
     Or bhyve sources are manually copied into the port. And then
     try to keep these sources up to date.
     Then compile and install a bhyve-rbd into /usr/local/sbin


There are some ports (for example sysutils/lsof) which need kernel 
sources to build. So this can be a way too. I cannot say if this is the 
best way or not.


[...]

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


[RFC] Adding a Rados block driver to bhyve

2020-03-09 Thread Willem Jan Withagen

Hi all,

And sorry for crosspoing three groups, but the answer can/could be a mix
of things to do in these three areas.

I have a prototype of bhyve running on Rados/Ceph working:
    https://github.com/freebsd/freebsd/pull/426

But there are a few catches on how to get it in the FreeBSd sources...

1) Easiest would be to just compile it in with the code of the current 
bhyve.

    That will require librados/librbd libraries...
    Ceph of this purpose is LGPL2/3 and could go into contrib.
    In this case bhyve will hold the rbd-driver by default and a user 
does not

    need to do anything by himself
    But I have the feeling that this is the most unwanted scenario

2) User first installs a Ceph package and FreeBSD sources, and then 
recompiles

    bhyve with the option BHYVE_RBD.
    And then reinstalls this new version as bhyve or bhyve-rbd in /usr/sbin

3) Create a bhyve-rbd port.
    Problem with that is that it will require the FreeBSD source tree 
for the

    bhyve sources, but there is no Ports option for that?
    Or bhyve sources are manually copied into the port. And then
    try to keep these sources up to date.
    Then compile and install a bhyve-rbd into /usr/local/sbin

4) Create a bhyve-blockrbd port.
    This is much like 3) but instead of building a bhyve-rbd executable,
    it delivers a libblockrbd.so that is dynamically loadable by the
    standaard bhyve that comes with base.

    For this bhyve needs to be extended with dynamic loadable driver 
modules.
    This is reasonably doable, but is this acceptable for the bhyve 
maintainers?


    For building the port, the bhyve-blockrbd code will only need a 
limited set
    of files from /usr/src/usr.bin/bhyve thus limiting the chance of 
running out

    sequence with the bhyve from base.

Looking over these 4 options, I think that 4 is the most desirable one?
But 2 would parhaps be workable for users as well, but the project might 
think

otherwise.

Are there other options?
And/or is 4 the best way to go, with 2 as a nice intermediate?

Thanx,
--WjW
___
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"