FreeBSD ports you maintain which are out of date

2017-01-25 Thread portscout 
Dear port maintainer,

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

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

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


Port| Current version | New version
+-+
emulators/mame  | 0.166   | mame0182
+-+
emulators/mess  | 0.166   | mame0182
+-+
graphics/ayam   | 1.23| 1.24
+-+
math/giacxcas   | 1.2.2-57| 1.2.3-15
+-+
math/glpk   | 4.55| 4.61
+-+
misc/rname  | 1.0 | 1.0.2
+-+


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

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

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

Re: 11.0-RC1 unsupported by ports?

2017-01-25 Thread Kurt Jaeger 
Hi!

> > 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit
> > drastic, there's a point to it.
> 
> With that argument only the latest version would be supported.

https://www.freebsd.org/releases/ lists the supported releases.
There are no release candidates listed.

> That said, it is a release candidate and as such one could argue that
> there never had been any official support at all.
> In that case however the message is wrong, because when a support has
> ended it implies that there was support.
> 
> The check in the code is this one:
> .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 
> 110 && ${OSVERSION} < 1100122))) || \
> (${OPSYS} == DragonFly && ${DFLYVERSION} < 400400)
> 
> It is not about RC as such, it is explicitly about 11.0-RC.
> My OSVERSION is 1100121.
> So obviously support starts with the first release.
> Fair enough, but then the message is still wrong unless it was supported.

What's stopping you from upgrading to -REL ?

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: 11.0-RC1 unsupported by ports?

2017-01-25 Thread Mark Millard 

On 2017-Jan-24, at 11:55 PM, Bernd Walter  wrote:

On Wed, Jan 25, 2017 at 07:20:45AM +0100, Kurt Jaeger wrote:
> Hi!
> 
>>> [61]cnc# make install
>>> /!\ ERROR: /!\
>>> 
>>> Ports Collection support for your FreeBSD version has ended, and no ports 
>>> are
>>> guaranteed to build on this system. Please upgrade to a supported release.
>>> 
>>> No support will be provided if you silence this message by defining
>>> ALLOW_UNSUPPORTED_SYSTEM.
>> 
>> 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit
>> drastic, there's a point to it.
> 
> With that argument only the latest version would be supported.
> That said, it is a release candidate and as such one could argue that
> there never had been any official support at all.
> In that case however the message is wrong, because when a support has
> ended it implies that there was support.
> 
> The check in the code is this one:
> .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 
> 110 && ${OSVERSION} < 1100122))) || \
>(${OPSYS} == DragonFly && ${DFLYVERSION} < 400400)
> 
> It is not about RC as such, it is explicitly about 11.0-RC.
> My OSVERSION is 1100121.
> So obviously support starts with the first release.
> Fair enough, but then the message is still wrong unless it was supported.
> 
> -- 
> B.Walter  http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

This is a new check as of -r431746 (Jan 17). The wording
is simply not explicit about prior history from before
the check was added.

For as "as if the check had been in place for a long time"
interpretation I'd guess:

A) 11.0-RC1 would be considered supported when first created.

https://www.freebsd.org/security/security.html#sup says:

In the run-up to a release, a number of -BETA and -RC releases may be published 
for testing purposes. These releases are only supported for a few weeks, as 
resources permit, and will not be listed as supported on this page. Users are 
strongly discouraged from running these releases on production systems.

B) 11.0-RELEASE would have made 11.0-RC1 not be supported
   (if 11.0-RC1 was even supported for that long).

C) stable/11 is supported

D) head is "supported" (no complaint anyway).

That last (head) is despite:

https://www.freebsd.org/security/security.html#sup

reporting as currently supported:

stable/10
releng/10.3 (10.3-RELEASE)
stable/11
releng/11.0 (11.0-RELEASE)

(head is not mentioned.)



Quoting https://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?view=log
. . .

Revision 431746 - (view) (download) (annotate) - [select for diffs] 
Modified Tue Jan 17 15:49:16 2017 UTC (7 days, 16 hours ago) by amdmi3 
File length: 181933 byte(s) 
Diff to previous 431681
- Refuse (overridable) to build ports on unsupported system version

Unfortunately, it's not uncommon for FreeBSD users to not update
their systems timely and thus end up using unsupported FreeBSD
release. These users continue to update ports tree as usual and
expect it to work, either unaware of the release EoL, or not clearly
understanding the consequences, which results in unexpected build
failures, bogus bug reports, attempts to bring back removed legacy
support bits and general discontent.

This change introduces system version check which makes ports refuse
to build anything on unsupported system. This makes users aware of
EoL of their system and makes it clear that no port is guaranteed to
build.

The error message tells how to override the check (by defining
ALLOW_UNSUPPORTED_SYSTEM, in which case it's turned into a simple
warning), additionally stressing that this configurartion is not
supported.

Currently outdated are OSVERSION < 1003000 (pre 10.3-RELEASE) and
110 <= OSVERSION < 1100122 (from 11-CURRENT'2013 to 11.0-PRERELEASE)

I expect these to be kept up to date with base system lifetimes,
be updated BEFORE removing any support for outdated release from
the tree and also serve as a reference of which OSVERSION checks
may be removed.

Approved by:portmgr (swills, mat)
Differential Revision:  D9210




===
Mark Millard
markmi at dsl-only.net

___
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: devel/cargo build failure

2017-01-25 Thread David Demelier 

On 01/25/2017 01:53 AM, Don Zavitz wrote:

www/firefox pulls this in, didn't know firefox used rust?


Yes, some parts of Firefox are now written in Rust :)

--
David Demelier
___
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: 11.0-RC1 unsupported by ports?

2017-01-25 Thread Kurt Jaeger 
Hi!!

Mark wrote:
> In the run-up to a release, a number of -BETA and -RC releases may be 
> published for testing purposes. These releases are only supported for a few 
> weeks, as resources permit, and will not be listed as supported on this page. 
> Users are strongly discouraged from running these releases on production 
> systems.
> 
> B) 11.0-RELEASE would have made 11.0-RC1 not be supported
>(if 11.0-RC1 was even supported for that long).
> 
> C) stable/11 is supported
> 
> D) head is "supported" (no complaint anyway).

HEAD is for testing, it's not supported in the word-smithing kind of way 8-}

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: 11.0-RC1 unsupported by ports?

2017-01-25 Thread Bernd Walter 
On Wed, Jan 25, 2017 at 09:13:18AM +0100, Kurt Jaeger wrote:
> Hi!
> 
> > > 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit
> > > drastic, there's a point to it.
> > 
> > With that argument only the latest version would be supported.
> 
> https://www.freebsd.org/releases/ lists the supported releases.
> There are no release candidates listed.
>
> > That said, it is a release candidate and as such one could argue that
> > there never had been any official support at all.
> > In that case however the message is wrong, because when a support has
> > ended it implies that there was support.
> > 
> > The check in the code is this one:
> > .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 
> > 110 && ${OSVERSION} < 1100122))) || \
> > (${OPSYS} == DragonFly && ${DFLYVERSION} < 400400)
> > 
> > It is not about RC as such, it is explicitly about 11.0-RC.
> > My OSVERSION is 1100121.
> > So obviously support starts with the first release.
> > Fair enough, but then the message is still wrong unless it was supported.
> 
> What's stopping you from upgrading to -REL ?

Buildworld on a raspberry isn't fun - if it works at all.
Even if you crossbuild and just copy the binaries, the wear of
MicroSD cards isn't something you want to test unless you really
have to.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: VirtualBox port not working with USB

2017-01-25 Thread Graham Menhennitt 

On 25/01/2017 00:43, Hans Petter Selasky wrote:

On 01/24/17 12:03, Graham Menhennitt wrote:

On 24/01/2017 04:19, Alfred Perlstein wrote:

Graham, can you follow what Hans is asking and report back please?



On Jan 23, 2017, at 8:14 AM, Hans Petter Selasky 
wrote:


There hasn't been any big changes in the FreeBSD userspace interfaces
used by virtualbox for a while. Maybe you can try to collect output
from "usbdump -i usbusX -f Y -s 65536 > log.txt" where X and Y are
the numbers after ugenX.Y for the device in question. I'll give
virtualbox from FreeBSD ports a spin and see if there is something
obvious broken.






Can you compile VirtualBox with full debugging enabled (make config 
and add all debug flags before building) and capture the resulting 
debug log(s) and send to me?


There are some debug prints in "USBProxyBackendFreeBSD.cpp" and 
"USBProxyDevice-freebsd.cpp" which I need to see and you should see 
them too when you add/remove USB devices. 


Hans,

I think that this is what you're after. If not, I can have another go. 
But it dies pretty quickly so I'm not sure what more I can do.


Thanks,
Graham


Log created: 2017-01-25T08:38:42.439099000Z
Executable: /usr/local/lib/virtualbox/VBoxSVC
Arg[0]: /usr/local/lib/virtualbox/VBoxSVC
Arg[1]: --auto-shutdown

!!Assertion Failed!!
Expression: mUniState == kHostUSBDeviceState_DetachingFromVM || 
(mUniState == kHostUSBDeviceState_UsedByVM && aAbnormal)
Location  : 
/usr/ports_build/usr/data/FreeBSD/ports/emulators/virtualbox-ose/work/VirtualBox-5.1.14/src/VBox/Main/src-server/HostUSBDeviceImpl.cpp(671) 
nsresult HostUSBDevice::i_onDetachFromVM(SessionMachine *, bool, bool *, 
bool)

{EPSON EPSON Scanner} CapturingForVM

!!Assertion Failed!!
Expression: aReason == Uninit::Abnormal
Location  : 
/usr/ports_build/usr/data/FreeBSD/ports/emulators/virtualbox-ose/work/VirtualBox-5.1.14/src/VBox/Main/src-server/MachineImpl.cpp(12749) 
void SessionMachine::uninit(Uninit::Reason)


!!Assertion Failed!!
Expression: SUCCEEDED(rc)
Location  : 
/usr/ports_build/usr/data/FreeBSD/ports/emulators/virtualbox-ose/work/VirtualBox-5.1.14/src/VBox/Main/glue/initterm.cpp(636) 
nsresult com::Shutdown()

COM RC = NS_ERROR_UNEXPECTED (0x8000)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: neo4j-3.0.4_1

2017-01-25 Thread Radek Krejča 
Hello,

After install and trying to run, I got:

eval: /usr/local/libexec/neo4j: Permission denied


This directory has owner root and no other messagess is shown.

Thank you
Radek

Odesláno z aplikace Pošta pro 
Windows 10

___
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: 11.0-RC1 unsupported by ports?

2017-01-25 Thread Bernd Walter 
On Wed, Jan 25, 2017 at 09:33:46AM +0100, Kurt Jaeger wrote:
> Hi!!
> 
> Mark wrote:
> > In the run-up to a release, a number of -BETA and -RC releases may be 
> > published for testing purposes. These releases are only supported for a few 
> > weeks, as resources permit, and will not be listed as supported on this 
> > page. Users are strongly discouraged from running these releases on 
> > production systems.
> > 
> > B) 11.0-RELEASE would have made 11.0-RC1 not be supported
> >(if 11.0-RC1 was even supported for that long).
> > 
> > C) stable/11 is supported
> > 
> > D) head is "supported" (no complaint anyway).
> 
> HEAD is for testing, it's not supported in the word-smithing kind of way 8-}

Well, the main cause for confusion was the wording and I didn't know
what exactly it triggers, plus it first happened to me on an arm
based system and wasn't sure if that unsupported was related to arm.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: 11.0-RC1 unsupported by ports?

2017-01-25 Thread Daniel Braniss 

> On 25 Jan 2017, at 10:47, Bernd Walter  wrote:
> 
> On Wed, Jan 25, 2017 at 09:13:18AM +0100, Kurt Jaeger wrote:
>> Hi!
>> 
 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit
 drastic, there's a point to it.
>>> 
>>> With that argument only the latest version would be supported.
>> 
>> https://www.freebsd.org/releases/ lists the supported releases.
>> There are no release candidates listed.
>> 
>>> That said, it is a release candidate and as such one could argue that
>>> there never had been any official support at all.
>>> In that case however the message is wrong, because when a support has
>>> ended it implies that there was support.
>>> 
>>> The check in the code is this one:
>>> .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 
>>> 110 && ${OSVERSION} < 1100122))) || \
>>>(${OPSYS} == DragonFly && ${DFLYVERSION} < 400400)
>>> 
>>> It is not about RC as such, it is explicitly about 11.0-RC.
>>> My OSVERSION is 1100121.
>>> So obviously support starts with the first release.
>>> Fair enough, but then the message is still wrong unless it was supported.
>> 
>> What's stopping you from upgrading to -REL ?
> 
> Buildworld on a raspberry isn't fun - if it works at all.
> Even if you crossbuild and just copy the binaries, the wear of
> MicroSD cards isn't something you want to test unless you really
> have to.

most of the time this works for me:
mount host:/export-to-rpi/local /usr/local
echo ‘WRKDIRPREFIX=/var/tmp’ >> /etc/make.conf
mount via nfs /var/tmp, i.e.
mount host:/export-to-rpi/tmp  /var/tmp
also add swap via nfs:
mount host:/export-to-rpi/swap /mnt-swap
swapon /mnt-swap




> 
> -- 
> B.Walter mailto:be...@bwct.de>> http://www.bwct.de 
> 
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> ___
> freebsd-...@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm 
> 
> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org 
> "

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

Re: FreeBSD Port: neo4j-3.0.4_1

2017-01-25 Thread Chris Rees 
Hey,

I guess your Java is working?

# chmod +x /usr/local/libexec/neo4j

Try that?  Should be done by the package.

Cheers,

Chris

On 25 January 2017 09:35:48 GMT+00:00, "Radek Krejča"  
wrote:
>Hello,
>
>After install and trying to run, I got:
>
>eval: /usr/local/libexec/neo4j: Permission denied
>
>
>This directory has owner root and no other messagess is shown.
>
>Thank you
>Radek
>
>Odesláno z aplikace
>Pošta pro Windows 10
>
>
>-- 
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: neo4j-3.0.4_1

2017-01-25 Thread Radek Krejča 
Hi,

total 23204
drwxr-xr-x   7 root  wheel   512 Jan 25 10:16 .
drwxr-xr-x  16 root  wheel   512 Dec 30 00:56 ..
drwxr-xr-x   2 root  wheel  5632 Jan  4 16:33 apache24
drwxr-xr-x   2 root  wheel   512 Dec 30 00:51 elasticsearch
drwxr-xr-x   3 root  wheel  6656 Nov 11 08:41 git-core
-rwxr-xr-x   1 root  wheel  23660448 Nov  4 00:48 mysqld
drwxr-xr-x   3 root  wheel   512 Jan 25 10:16 neo4j
drwxr-xr-x   2 root  wheel   512 Nov 11 08:37 sudo

java -version
openjdk version "1.8.0_102"
OpenJDK Runtime Environment (build 1.8.0_102-b14)
OpenJDK 64-Bit Server VM (build 25.102-b14, mixed mode)

I have neo4j default configuration without any changes. Only with pkg install 
neo4j and I have added neo4j_enable="YES" to rc.conf

Here is my truss tracking:

mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366304256 
(0x800643000)
issetugid()  = 0 (0x0)
lstat("/etc",{ mode=drwxr-xr-x ,inode=22792704,size=2560,blksize=32768 }) = 0 
(0x0)
lstat("/etc/libmap.conf",{ mode=-rw-r--r-- 
,inode=22792786,size=109,blksize=32768 }) = 0 (0x0)
openat(AT_FDCWD,"/etc/libmap.conf",O_CLOEXEC,00) = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=22792786,size=109,blksize=32768 }) = 0 (0x0)
mmap(0x0,109,PROT_READ,MAP_PRIVATE,3,0x0)= 34366337024 (0x80064b000)
close(3) = 0 (0x0)
lstat("/usr",{ mode=drwxr-xr-x ,inode=13723776,size=512,blksize=32768 }) = 0 
(0x0)
lstat("/usr/local",{ mode=drwxr-xr-x ,inode=13804034,size=512,blksize=32768 }) 
= 0 (0x0)
lstat("/usr/local/etc",{ mode=drwxr-xr-x 
,inode=13984924,size=1536,blksize=32768 }) = 0 (0x0)
lstat("/usr/local/etc/libmap.d",0x7fffcb98)  ERR#2 'No such file or 
directory'
munmap(0x80064b000,109)  = 0 (0x0)
openat(AT_FDCWD,"/var/run/ld-elf.so.hints",O_CLOEXEC,00) = 3 (0x3)
read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\M^B\0\0"...,128) = 128 (0x80)
fstat(3,{ mode=-r--r--r-- ,inode=10435110,size=258,blksize=32768 }) = 0 (0x0)
lseek(3,0x80,SEEK_SET)   = 128 (0x80)
read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,130) = 130 (0x82)
close(3) = 0 (0x0)
access("/lib/libedit.so.7",F_OK) = 0 (0x0)
openat(AT_FDCWD,"/lib/libedit.so.7",O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=18218138,size=226424,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34366337024 
(0x80064b000)
mmap(0x0,2334720,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 
34368409600 (0x800845000)
mmap(0x800845000,212992,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0)
 = 34368409600 (0x800845000)
mmap(0x800a79000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x34000)
 = 34370719744 (0x800a79000)
mmap(0x800a7b000,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0)
 = 34370727936 (0x800a7b000)
munmap(0x80064b000,4096) = 0 (0x0)
close(3) = 0 (0x0)
access("/lib/libc.so.7",F_OK)= 0 (0x0)
openat(AT_FDCWD,"/lib/libc.so.7",O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=18218188,size=1744432,blksize=32768 }) = 0 
(0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34366337024 
(0x80064b000)
mmap(0x0,3883008,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 
34370744320 (0x800a7f000)
mmap(0x800a7f000,1634304,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0)
 = 34370744320 (0x800a7f000)
mmap(0x800e0d000,49152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x18e000)
 = 34374471680 (0x800e0d000)
mmap(0x800e19000,106496,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0)
 = 34374520832 (0x800e19000)
munmap(0x80064b000,4096) = 0 (0x0)
close(3) = 0 (0x0)
access("/lib/libncursesw.so.8",F_OK) = 0 (0x0)
openat(AT_FDCWD,"/lib/libncursesw.so.8",O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=18218132,size=375096,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34366337024 
(0x80064b000)
mmap(0x0,2473984,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 
34374627328 (0x800e33000)
mmap(0x800e33000,356352,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0)
 = 34374627328 (0x800e33000)
mmap(0x801089000,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x56000)
 = 34377076736 (0x801089000)
mmap(0x80108e000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0)
 = 34377097216 (0x80108e000)
munmap(0x80064b000,4096) = 0 (0x0)
close(3) = 0 (0x0)
munmap(0x80064a000,4096) = 0 (0x0)
mmap(0x0,40960,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366332928 
(0x80064a000)
munmap(0x

Re: unable to build java in poudriere

2017-01-25 Thread Julian Elischer 

On 25/1/17 10:36 am, Ultima wrote:
Sorry Julian but your details are kind of vague. Are you on head? 
I'm not sure when my last build for openjdk7 or 8 were but I have 
them built in my repo. Is there enough memory on the system building 
it? or is it limited? that is usually the culprit for the openjdk 
ports.


I ask if you were on head because I know java was broken for 
sometime in January but was fixed, or at least r312388 is working.

Sorry, one item missing..  compile is on FreeBSD 10.3

Poudriere is populated with the head ports tree as of yesterday, but I 
had hte same problem a few weeks ago.

the list of packages includes openjdk8
it would probably have the same issue if openjdk8 was the ONLY port to 
make, because jdk8 wants jdk7 to jdb7 won't build.
Should poudriere or ports give a warning "you need to install package 
X before we can do this compile"?






On Tue, Jan 24, 2017 at 8:56 PM, Julian Elischer > wrote:


from he log file:  (see below)

This dies almost immediately.
Do we need to prime the build with an older java? (e.g. the
bootstrap pkg)?
If so why does  poudriere not do this?
I actually want jdk8 but iti insists on building 7 first, which
fails.
Since I don't care about 7 I can prime the pump by downloading a
7 pkg but should all this be automatic somehow?

Log:



# Entering langtools for target(s) all#


(cd  ./langtools/make && \
  gmake
JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk

JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk/make/common/shared
EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
TARGET_CLASS_VERSION=7 MILESTONE=fcs BUILD_NUMBER=b01
JDK_BUILD_NUMBER=b01 FULL_VERSION=1.7.0_111-b01
PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111
JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7
JDK_MICRO_VERSION=0_111 PREVIOUS_MAJOR_VERSION=1
PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=
PAX_COMMAND=/usr/sbin/paxmark.sh PAX_COMMAND_ARGS="-vm"
ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1
ANT_HOME="/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7"

ALT_OUTPUTDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools
ALT_BOOTDIR=/usr/local/bootstrap-openjdk all)
gmake[3]: Entering directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
JAVA_HOME=/usr/local/bootstrap-openjdk

ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
-diagnostics >

/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log
; \
  JAVA_HOME=/usr/local/bootstrap-openjdk

ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
-version >>

/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log
Could not create the Java virtual machine.
Could not create the Java virtual machine.
gmake[3]: *** [Makefile:196:

/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log]
Error 1
gmake[3]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
gmake[2]: *** [make/langtools-rules.gmk:39: langtools-build] Error 2
gmake[2]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk'
gmake[1]: *** [Makefile:251: build_product_image] Error 2
gmake[1]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk'
*** 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
"




___
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: devel/cargo build failure

2017-01-25 Thread Mathieu Arnold 
Le 25/01/2017 à 01:53, Don Zavitz a écrit :
>
>
> On 1/24/2017 4:20 PM, Fernando Herrero Carrón wrote:
>> El 24 ene. 2017 9:18 p. m., "Mathieu Arnold"  escribió:
>>
>> Le 24/01/2017 à 20:27, Fernando Herrero Carrón a écrit :
>>>
>>> El 24 ene. 2017 6:57 p. m., "Mathieu Arnold" >> > escribió:
>>>
>>>  Le 24/01/2017 à 18:47, David Wolfskill a écrit :
>>>  > On Tue, Jan 24, 2017 at 06:33:29PM +0100, Mathieu Arnold wrote:
>>>  >> Le 24/01/2017 à 16:52, Bob Willcox a écrit :
>>>  >>> When trying to build devel/cargo I get this error:
>>>  >>>
>>>  >>> /xports/Mk/Scripts/checksum.sh: cannot open
>>>  2016-11-02/cargo-nightly-x86_64-unknown-freebsd.tar.gz: No such
>>>  file or directory
>>>  >>> *** Error code 2
>>>  >>>
>>>  >>> Stop.
>>>  >>> make: stopped in /xports/devel/cargo
>>>  >>>
>>>  >>> Anyone have any ideas why and what I can do to overcome it?
>>>  >> Ok, so, the port changed the directory this file is fetched in,
>>>  to fix
>>>  >> the problem, you'll need to remove the
>>>  >> cargo-nightly-x86_64-unknown-freebsd.tar.gz from
>>>  /usr/ports/distfiles
>>>  >> (or whereever your distfiles are)
>>>  >> 
>>>  > Thanks -- that worked for me.
>>>
>>>  So, I opened PR #216442 to see if the code that made this
>>> problem was
>>>  legacy or not, an exp-run will tell :-)
>>>
>>>  --
>>>  Mathieu Arnold
>>>
>>>
>>> Wow, cool to see more people doing rust on freebsd, count me in!
>>
>> I have no idea what rust is, but sure.
>>
>>
>> http://www.freshports.org/devel/cargo:
>>
>> Cargo is Rust's Package Manager. Cargo downloads your Rust project's
>> dependencies and compiles your project.
>> ___
>> 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"
>
> I ran into this issue, removing
> cargo-nightly-x86_64-unknown-freebsd.tar.gz from /usr/ports/distfiles
> fixed it for me...
>
> www/firefox pulls this in, didn't know firefox used rust?

Like I said, there is a "feature" in the fetch code that I'm currently
having PR #216442 test if its removal breaks something.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: 11.0-RC1 unsupported by ports?

2017-01-25 Thread Mathieu Arnold 
Le 25/01/2017 à 08:55, Bernd Walter a écrit :
> On Wed, Jan 25, 2017 at 07:20:45AM +0100, Kurt Jaeger wrote:
>> Hi!
>>
>>> [61]cnc# make install
>>> /!\ ERROR: /!\
>>>
>>> Ports Collection support for your FreeBSD version has ended, and no ports 
>>> are
>>> guaranteed to build on this system. Please upgrade to a supported release.
>>>
>>> No support will be provided if you silence this message by defining
>>> ALLOW_UNSUPPORTED_SYSTEM.
>> 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit
>> drastic, there's a point to it.
> With that argument only the latest version would be supported.
> That said, it is a release candidate and as such one could argue that
> there never had been any official support at all.
> In that case however the message is wrong, because when a support has
> ended it implies that there was support.
>
> The check in the code is this one:
> .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 
> 110 && ${OSVERSION} < 1100122))) || \
> (${OPSYS} == DragonFly && ${DFLYVERSION} < 400400)
>
> It is not about RC as such, it is explicitly about 11.0-RC.
> My OSVERSION is 1100121.
> So obviously support starts with the first release.
> Fair enough, but then the message is still wrong unless it was supported.

The alpha/beta/rc versions preceding a release are never supported after
the next alpha/beta/rc is released (meaning beta3 stops being supported
when rc1 goes out, and the last rc stops being supported when the
release goes out.)

Like the message says, you can define ALLOW_UNSUPPORTED_SYSTEM to
continue using the non supported version you are running.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: 11.0-RC1 unsupported by ports?

2017-01-25 Thread Mathieu Arnold 
Le 25/01/2017 à 09:47, Bernd Walter a écrit :
> On Wed, Jan 25, 2017 at 09:13:18AM +0100, Kurt Jaeger wrote:
>> Hi!
>>
 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit
 drastic, there's a point to it.
>>> With that argument only the latest version would be supported.
>> https://www.freebsd.org/releases/ lists the supported releases.
>> There are no release candidates listed.
>>
>>> That said, it is a release candidate and as such one could argue that
>>> there never had been any official support at all.
>>> In that case however the message is wrong, because when a support has
>>> ended it implies that there was support.
>>>
>>> The check in the code is this one:
>>> .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 
>>> 110 && ${OSVERSION} < 1100122))) || \
>>> (${OPSYS} == DragonFly && ${DFLYVERSION} < 400400)
>>>
>>> It is not about RC as such, it is explicitly about 11.0-RC.
>>> My OSVERSION is 1100121.
>>> So obviously support starts with the first release.
>>> Fair enough, but then the message is still wrong unless it was supported.
>> What's stopping you from upgrading to -REL ?
> Buildworld on a raspberry isn't fun - if it works at all.
> Even if you crossbuild and just copy the binaries, the wear of
> MicroSD cards isn't something you want to test unless you really
> have to.

If you have other computers running FreeBSD, you can build /usr/obj on
the other box (using make buildworld TARGET_ARCH=foo (you may have to
check the exact incantation)) copy the /usr/obj, and only run make
installworld.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: 11.0-RC1 unsupported by ports?

2017-01-25 Thread Bernd Walter 
On Wed, Jan 25, 2017 at 11:52:10AM +0200, Daniel Braniss wrote:
> 
> > On 25 Jan 2017, at 10:47, Bernd Walter  wrote:
> > 
> > On Wed, Jan 25, 2017 at 09:13:18AM +0100, Kurt Jaeger wrote:
> >> Hi!
> >> 
>  11.0-RC1 was superseded by 11.0-REL, so while that message is a bit
>  drastic, there's a point to it.
> >>> 
> >>> With that argument only the latest version would be supported.
> >> 
> >> https://www.freebsd.org/releases/ lists the supported releases.
> >> There are no release candidates listed.
> >> 
> >>> That said, it is a release candidate and as such one could argue that
> >>> there never had been any official support at all.
> >>> In that case however the message is wrong, because when a support has
> >>> ended it implies that there was support.
> >>> 
> >>> The check in the code is this one:
> >>> .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 
> >>> 110 && ${OSVERSION} < 1100122))) || \
> >>>(${OPSYS} == DragonFly && ${DFLYVERSION} < 400400)
> >>> 
> >>> It is not about RC as such, it is explicitly about 11.0-RC.
> >>> My OSVERSION is 1100121.
> >>> So obviously support starts with the first release.
> >>> Fair enough, but then the message is still wrong unless it was supported.
> >> 
> >> What's stopping you from upgrading to -REL ?
> > 
> > Buildworld on a raspberry isn't fun - if it works at all.
> > Even if you crossbuild and just copy the binaries, the wear of
> > MicroSD cards isn't something you want to test unless you really
> > have to.
> 
> most of the time this works for me:
>   mount host:/export-to-rpi/local /usr/local
>   echo ???WRKDIRPREFIX=/var/tmp??? >> /etc/make.conf
>   mount via nfs /var/tmp, i.e.
>   mount host:/export-to-rpi/tmp  /var/tmp
>   also add swap via nfs:
>   mount host:/export-to-rpi/swap /mnt-swap
>   swapon /mnt-swap

This has nothing to do with updating the OS itself.

That said, I assume host:/export-to-rpi/local is only used by a
single host.
It gets tricky with shared /usr/local, since the package registration
is in a different path and ports/packages may also touch /etc - e.g.
/etc/shells, or add service users for a specific software.
It is possible to do, but unless you are very carefull things can
easily get messy.
Same goes for /tmp.
Needless to say that swap isn't to be shared at all...
But I'm not sure if swap on NFS is completely deadlock free.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: unable to build java in poudriere

2017-01-25 Thread Julian Elischer 

On 25/1/17 6:30 pm, Julian Elischer wrote:

On 25/1/17 10:36 am, Ultima wrote:
Sorry Julian but your details are kind of vague. Are you on head? 
I'm not sure when my last build for openjdk7 or 8 were but I have 
them built in my repo. Is there enough memory on the system 
building it? or is it limited? that is usually the culprit for the 
openjdk ports.


I ask if you were on head because I know java was broken for 
sometime in January but was fixed, or at least r312388 is working.

Sorry, one item missing..  compile is on FreeBSD 10.3

Poudriere is populated with the head ports tree as of yesterday, but 
I had hte same problem a few weeks ago.

the list of packages includes openjdk8
it would probably have the same issue if openjdk8 was the ONLY port 
to make, because jdk8 wants jdk7 to jdb7 won't build.
Should poudriere or ports give a warning "you need to install 
package X before we can do this compile"?


I will add that bootstrap-openjdk-r351880_1.txz  is already finished 
and available.
I'm guessing that openjdk7 should be using that, but isn't for some 
reason.


in fact is it possible that 8 should be using that to bootstrap itself 
up as well instead of using 7?


I'm not experienced with java, I just need to get it into the machine 
image at $JOB for others to use.









On Tue, Jan 24, 2017 at 8:56 PM, Julian Elischer 
mailto:jul...@freebsd.org>> wrote:


from he log file:  (see below)

This dies almost immediately.
Do we need to prime the build with an older java? (e.g. the
bootstrap pkg)?
If so why does  poudriere not do this?
I actually want jdk8 but iti insists on building 7 first, which
fails.
Since I don't care about 7 I can prime the pump by downloading a
7 pkg but should all this be automatic somehow?

Log:

 

 


# Entering langtools for target(s) all#
 



(cd  ./langtools/make && \
  gmake
JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk
JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk/make/common/shared
EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
TARGET_CLASS_VERSION=7 MILESTONE=fcs BUILD_NUMBER=b01
JDK_BUILD_NUMBER=b01 FULL_VERSION=1.7.0_111-b01
PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111
JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7
JDK_MICRO_VERSION=0_111 PREVIOUS_MAJOR_VERSION=1
PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=
PAX_COMMAND=/usr/sbin/paxmark.sh PAX_COMMAND_ARGS="-vm"
ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1
ANT_HOME="/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7"
ALT_OUTPUTDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools
ALT_BOOTDIR=/usr/local/bootstrap-openjdk all)
gmake[3]: Entering directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
JAVA_HOME=/usr/local/bootstrap-openjdk
ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
-diagnostics >
/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log
; \
  JAVA_HOME=/usr/local/bootstrap-openjdk
ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
-version >>
/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log
Could not create the Java virtual machine.
Could not create the Java virtual machine.
gmake[3]: *** [Makefile:196:
/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log]
Error 1
gmake[3]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
gmake[2]: *** [make/langtools-rules.gmk:39: langtools-build] 
Error 2

gmake[2]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk'
gmake[1]: *** [Makefile:251: build_product_image] Error 2
gmake[1]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk'
*** 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
"




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

Re: 11.0-RC1 unsupported by ports?

2017-01-25 Thread Daniel Braniss 

> On 25 Jan 2017, at 12:39, Bernd Walter  wrote:
> 
> On Wed, Jan 25, 2017 at 11:52:10AM +0200, Daniel Braniss wrote:
>> 
>>> On 25 Jan 2017, at 10:47, Bernd Walter  wrote:
>>> 
>>> On Wed, Jan 25, 2017 at 09:13:18AM +0100, Kurt Jaeger wrote:
 Hi!
 
>> 11.0-RC1 was superseded by 11.0-REL, so while that message is a bit
>> drastic, there's a point to it.
> 
> With that argument only the latest version would be supported.
 
 https://www.freebsd.org/releases/ lists the supported releases.
 There are no release candidates listed.
 
> That said, it is a release candidate and as such one could argue that
> there never had been any official support at all.
> In that case however the message is wrong, because when a support has
> ended it implies that there was support.
> 
> The check in the code is this one:
> .if (${OPSYS} == FreeBSD && (${OSVERSION} < 1003000 || (${OSVERSION} >= 
> 110 && ${OSVERSION} < 1100122))) || \
>   (${OPSYS} == DragonFly && ${DFLYVERSION} < 400400)
> 
> It is not about RC as such, it is explicitly about 11.0-RC.
> My OSVERSION is 1100121.
> So obviously support starts with the first release.
> Fair enough, but then the message is still wrong unless it was supported.
 
 What's stopping you from upgrading to -REL ?
>>> 
>>> Buildworld on a raspberry isn't fun - if it works at all.
>>> Even if you crossbuild and just copy the binaries, the wear of
>>> MicroSD cards isn't something you want to test unless you really
>>> have to.
>> 
>> most of the time this works for me:
>>  mount host:/export-to-rpi/local /usr/local
>>  echo ???WRKDIRPREFIX=/var/tmp??? >> /etc/make.conf
>>  mount via nfs /var/tmp, i.e.
>>  mount host:/export-to-rpi/tmp  /var/tmp
>>  also add swap via nfs:
>>  mount host:/export-to-rpi/swap /mnt-swap
>>  swapon /mnt-swap
> 
> This has nothing to do with updating the OS itself.
somehow the subject was ‘compiling ports’ to build the os I cross compile
and that works fine.

> 
> That said, I assume host:/export-to-rpi/local is only used by a
> single host.
no, if you take care, we have been sharing /usr/local since way back.
btw, it’s read only for the clients.

> It gets tricky with shared /usr/local, since the package registration
> is in a different path and ports/packages may also touch /etc - e.g.
> /etc/shells, or add service users for a specific software.
> It is possible to do, but unless you are very carefull things can
> easily get messy.
the ports compilation keep things in /var/db, and that tends to cause problems
with pkg - since it insists in locking the sqlite db, so I see that on the SD, 
and copy it
to more secure location when I’m done (I keep losing track of those small sd 
cards,
there is hardly any place to put a label on them :-)


> Same goes for /tmp.
> Needless to say that swap isn't to be shared at all…
that would certainly be foolish :-)

> But I'm not sure if swap on NFS is completely deadlock free.

so far It’s been just fine, e.g., compiling pkg takes up a lot of resources
and this was the only way it worked, not to mention gcc. I compiled all
of the X11! 

> 
> -- 
> B.Walter  http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

___
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: devel/cargo build failure

2017-01-25 Thread Jean-Sébastien Pédron 
On 24.01.2017 18:57, Mathieu Arnold wrote:
> So, I opened PR #216442 to see if the code that made this problem was
> legacy or not, an exp-run will tell :-)

Thank you for working on this!

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: VirtualBox port not working with USB

2017-01-25 Thread Hans Petter Selasky 

On 01/25/17 10:00, Graham Menhennitt wrote:

On 25/01/2017 00:43, Hans Petter Selasky wrote:

On 01/24/17 12:03, Graham Menhennitt wrote:

On 24/01/2017 04:19, Alfred Perlstein wrote:

Graham, can you follow what Hans is asking and report back please?



On Jan 23, 2017, at 8:14 AM, Hans Petter Selasky 
wrote:


There hasn't been any big changes in the FreeBSD userspace interfaces
used by virtualbox for a while. Maybe you can try to collect output
from "usbdump -i usbusX -f Y -s 65536 > log.txt" where X and Y are
the numbers after ugenX.Y for the device in question. I'll give
virtualbox from FreeBSD ports a spin and see if there is something
obvious broken.






Can you compile VirtualBox with full debugging enabled (make config
and add all debug flags before building) and capture the resulting
debug log(s) and send to me?

There are some debug prints in "USBProxyBackendFreeBSD.cpp" and
"USBProxyDevice-freebsd.cpp" which I need to see and you should see
them too when you add/remove USB devices.


Hans,

I think that this is what you're after. If not, I can have another go.
But it dies pretty quickly so I'm not sure what more I can do.

Thanks,
Graham



Hi Graham,

Can you try to replace the two attached files in 
/usr/ports/...virtualbox-ose/files and re-build. Can someone here 
interacting with the VBOX team make sure these patches gets pushed upstream?


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

Re: VirtualBox port not working with USB

2017-01-25 Thread Hans Petter Selasky 

On 01/25/17 20:41, Hans Petter Selasky wrote:

Hi Graham,

Can you try to replace the two attached files in
/usr/ports/...virtualbox-ose/files and re-build. Can someone here
interacting with the VBOX team make sure these patches gets pushed
upstream?

--HPS



You might need to disable VBOX debugging.

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

Re: VirtualBox port not working with USB

2017-01-25 Thread Graham Menhennitt 

On 26/01/2017 06:41, Hans Petter Selasky wrote:

On 01/25/17 10:00, Graham Menhennitt wrote:

On 25/01/2017 00:43, Hans Petter Selasky wrote:

On 01/24/17 12:03, Graham Menhennitt wrote:

On 24/01/2017 04:19, Alfred Perlstein wrote:

Graham, can you follow what Hans is asking and report back please?



On Jan 23, 2017, at 8:14 AM, Hans Petter Selasky 
wrote:


There hasn't been any big changes in the FreeBSD userspace 
interfaces

used by virtualbox for a while. Maybe you can try to collect output
from "usbdump -i usbusX -f Y -s 65536 > log.txt" where X and Y are
the numbers after ugenX.Y for the device in question. I'll give
virtualbox from FreeBSD ports a spin and see if there is something
obvious broken.






Can you compile VirtualBox with full debugging enabled (make config
and add all debug flags before building) and capture the resulting
debug log(s) and send to me?

There are some debug prints in "USBProxyBackendFreeBSD.cpp" and
"USBProxyDevice-freebsd.cpp" which I need to see and you should see
them too when you add/remove USB devices.


Hans,

I think that this is what you're after. If not, I can have another go.
But it dies pretty quickly so I'm not sure what more I can do.

Thanks,
Graham



Hi Graham,

Can you try to replace the two attached files in 
/usr/ports/...virtualbox-ose/files and re-build. Can someone here 
interacting with the VBOX team make sure these patches gets pushed 
upstream?


--HPS


Thank you very much, Hans. Working for me now.

Thanks,

Graham

___
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: VirtualBox port not working with USB

2017-01-25 Thread Alfred Perlstein 
Nice!

Sent from my iPhone

> On Jan 25, 2017, at 12:15 PM, Graham Menhennitt  
> wrote:
> 
>> On 26/01/2017 06:41, Hans Petter Selasky wrote:
>>> On 01/25/17 10:00, Graham Menhennitt wrote:
 On 25/01/2017 00:43, Hans Petter Selasky wrote:
> On 01/24/17 12:03, Graham Menhennitt wrote:
>> On 24/01/2017 04:19, Alfred Perlstein wrote:
>> Graham, can you follow what Hans is asking and report back please?
>> 
>> 
>>> On Jan 23, 2017, at 8:14 AM, Hans Petter Selasky 
>>> wrote:
>>> 
>>> 
>>> There hasn't been any big changes in the FreeBSD userspace interfaces
>>> used by virtualbox for a while. Maybe you can try to collect output
>>> from "usbdump -i usbusX -f Y -s 65536 > log.txt" where X and Y are
>>> the numbers after ugenX.Y for the device in question. I'll give
>>> virtualbox from FreeBSD ports a spin and see if there is something
>>> obvious broken.
>>> 
> 
 
 
 Can you compile VirtualBox with full debugging enabled (make config
 and add all debug flags before building) and capture the resulting
 debug log(s) and send to me?
 
 There are some debug prints in "USBProxyBackendFreeBSD.cpp" and
 "USBProxyDevice-freebsd.cpp" which I need to see and you should see
 them too when you add/remove USB devices.
>>> 
>>> Hans,
>>> 
>>> I think that this is what you're after. If not, I can have another go.
>>> But it dies pretty quickly so I'm not sure what more I can do.
>>> 
>>> Thanks,
>>>Graham
>>> 
>> 
>> Hi Graham,
>> 
>> Can you try to replace the two attached files in 
>> /usr/ports/...virtualbox-ose/files and re-build. Can someone here 
>> interacting with the VBOX team make sure these patches gets pushed upstream?
>> 
>> --HPS
>> 
> Thank you very much, Hans. Working for me now.
> 
> Thanks,
> 
>Graham
> 

___
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: unable to build java in poudriere

2017-01-25 Thread Ultima 
I just finished building openjdk8 with a fresh repo and it built just fine.

poudriere bulk -p git -j 103amd64 java/openjdk8
ref:
https://poudriere.ultimasbox.com/build.html?mastername=103amd64-git&build=2017-01-25_14h51m15s



A google search on the error suggests that it is most likely related to
some form of memory issue.

If you follow this post from a few years ago, it could lead you to the same
conclusion. More or less it seemed to be a problem with java determining
incorrect memory values which was causing that error. Could be completely
wrong but it is worth looking into.

https://lists.freebsd.org/pipermail/freebsd-java/2013-December/010441.html

Explicit setting maximum memory starts the vm, but being that this is a
port building, I'm not really sure what to suggest. I guess you could try
add an arg on the Makefile setting max memory, but I'm not sure how much
memory it requires to build. I know building openjdk does need quite a bit.
Another solution, likely less desired is using another system to build it
or using the FreeBSD repo to download it. Sorry if this isn't helpful.
Someone else may have a better solution.

Good luck,
Ultima

On Wed, Jan 25, 2017 at 5:48 AM, Julian Elischer  wrote:

> On 25/1/17 6:30 pm, Julian Elischer wrote:
>
>> On 25/1/17 10:36 am, Ultima wrote:
>>
>>> Sorry Julian but your details are kind of vague. Are you on head? I'm
>>> not sure when my last build for openjdk7 or 8 were but I have them built in
>>> my repo. Is there enough memory on the system building it? or is it
>>> limited? that is usually the culprit for the openjdk ports.
>>>
>>> I ask if you were on head because I know java was broken for sometime in
>>> January but was fixed, or at least r312388 is working.
>>>
>> Sorry, one item missing..  compile is on FreeBSD 10.3
>>
>> Poudriere is populated with the head ports tree as of yesterday, but I
>> had hte same problem a few weeks ago.
>> the list of packages includes openjdk8
>> it would probably have the same issue if openjdk8 was the ONLY port to
>> make, because jdk8 wants jdk7 to jdb7 won't build.
>> Should poudriere or ports give a warning "you need to install package X
>> before we can do this compile"?
>>
>
> I will add that bootstrap-openjdk-r351880_1.txz  is already finished and
> available.
> I'm guessing that openjdk7 should be using that, but isn't for some reason.
>
> in fact is it possible that 8 should be using that to bootstrap itself up
> as well instead of using 7?
>
> I'm not experienced with java, I just need to get it into the machine
> image at $JOB for others to use.
>
>
>
>>
>>
>>
>>> On Tue, Jan 24, 2017 at 8:56 PM, Julian Elischer >> > wrote:
>>>
>>> from he log file:  (see below)
>>>
>>> This dies almost immediately.
>>> Do we need to prime the build with an older java? (e.g. the
>>> bootstrap pkg)?
>>> If so why does  poudriere not do this?
>>> I actually want jdk8 but iti insists on building 7 first, which
>>> fails.
>>> Since I don't care about 7 I can prime the pump by downloading a
>>> 7 pkg but should all this be automatic somehow?
>>>
>>> Log:
>>>
>>> 
>>>
>>> 
>>>
>>> # Entering langtools for target(s) all#
>>> 
>>>
>>>
>>> (cd  ./langtools/make && \
>>>   gmake
>>> JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk
>>> JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/op
>>> enjdk/jdk/make/common/shared
>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>>> TARGET_CLASS_VERSION=7 MILESTONE=fcs BUILD_NUMBER=b01
>>> JDK_BUILD_NUMBER=b01 FULL_VERSION=1.7.0_111-b01
>>> PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111
>>> JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7
>>> JDK_MICRO_VERSION=0_111 PREVIOUS_MAJOR_VERSION=1
>>> PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=
>>> PAX_COMMAND=/usr/sbin/paxmark.sh PAX_COMMAND_ARGS="-vm"
>>> ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1
>>> ANT_HOME="/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7"
>>> ALT_OUTPUTDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/
>>> build/bsd-amd64/langtools
>>> ALT_BOOTDIR=/usr/local/bootstrap-openjdk all)
>>> gmake[3]: Entering directory
>>> '/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
>>> JAVA_HOME=/usr/local/bootstrap-openjdk
>>> ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/
>>> work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
>>> /wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
>>> -diagnostics >
>>> /wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-
>>> amd64/langtools/build/ant-diagnostics.log
>>> ; \
>>>   JAVA_HOME=/usr/local/bootstrap-openjdk
>>> ANT_OPTS=-Djava.io.tmpdir='/wr

Re: unable to build java in poudriere

2017-01-25 Thread Don Lewis 
On 25 Jan, Ultima wrote:
> I just finished building openjdk8 with a fresh repo and it built just fine.
> 
> poudriere bulk -p git -j 103amd64 java/openjdk8
> ref:
> https://poudriere.ultimasbox.com/build.html?mastername=103amd64-git&build=2017-01-25_14h51m15s
> 
> 
> 
> A google search on the error suggests that it is most likely related to
> some form of memory issue.
> 
> If you follow this post from a few years ago, it could lead you to the same
> conclusion. More or less it seemed to be a problem with java determining
> incorrect memory values which was causing that error. Could be completely
> wrong but it is worth looking into.
> 
> https://lists.freebsd.org/pipermail/freebsd-java/2013-December/010441.html
> 
> Explicit setting maximum memory starts the vm, but being that this is a
> port building, I'm not really sure what to suggest. I guess you could try
> add an arg on the Makefile setting max memory, but I'm not sure how much
> memory it requires to build. I know building openjdk does need quite a bit.
> Another solution, likely less desired is using another system to build it
> or using the FreeBSD repo to download it. Sorry if this isn't helpful.
> Someone else may have a better solution.
> 
> Good luck,
> Ultima
> 
> On Wed, Jan 25, 2017 at 5:48 AM, Julian Elischer  wrote:
> 
>> On 25/1/17 6:30 pm, Julian Elischer wrote:
>>
>>> On 25/1/17 10:36 am, Ultima wrote:
>>>
 Sorry Julian but your details are kind of vague. Are you on head? I'm
 not sure when my last build for openjdk7 or 8 were but I have them built in
 my repo. Is there enough memory on the system building it? or is it
 limited? that is usually the culprit for the openjdk ports.

 I ask if you were on head because I know java was broken for sometime in
 January but was fixed, or at least r312388 is working.

>>> Sorry, one item missing..  compile is on FreeBSD 10.3
>>>
>>> Poudriere is populated with the head ports tree as of yesterday, but I
>>> had hte same problem a few weeks ago.
>>> the list of packages includes openjdk8
>>> it would probably have the same issue if openjdk8 was the ONLY port to
>>> make, because jdk8 wants jdk7 to jdb7 won't build.
>>> Should poudriere or ports give a warning "you need to install package X
>>> before we can do this compile"?
>>>
>>
>> I will add that bootstrap-openjdk-r351880_1.txz  is already finished and
>> available.
>> I'm guessing that openjdk7 should be using that, but isn't for some reason.
>>
>> in fact is it possible that 8 should be using that to bootstrap itself up
>> as well instead of using 7?
>>
>> I'm not experienced with java, I just need to get it into the machine
>> image at $JOB for others to use.
>>
>>
>>
>>>
>>>
>>>
 On Tue, Jan 24, 2017 at 8:56 PM, Julian Elischer >>> > wrote:

 from he log file:  (see below)

 This dies almost immediately.
 Do we need to prime the build with an older java? (e.g. the
 bootstrap pkg)?
 If so why does  poudriere not do this?
 I actually want jdk8 but iti insists on building 7 first, which
 fails.
 Since I don't care about 7 I can prime the pump by downloading a
 7 pkg but should all this be automatic somehow?

 Log:

 

 

 # Entering langtools for target(s) all#
 


 (cd  ./langtools/make && \
   gmake
 JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk
 JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/op
 enjdk/jdk/make/common/shared
 EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
 TARGET_CLASS_VERSION=7 MILESTONE=fcs BUILD_NUMBER=b01
 JDK_BUILD_NUMBER=b01 FULL_VERSION=1.7.0_111-b01
 PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111
 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7
 JDK_MICRO_VERSION=0_111 PREVIOUS_MAJOR_VERSION=1
 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=
 PAX_COMMAND=/usr/sbin/paxmark.sh PAX_COMMAND_ARGS="-vm"
 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1
 ANT_HOME="/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7"
 ALT_OUTPUTDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/
 build/bsd-amd64/langtools
 ALT_BOOTDIR=/usr/local/bootstrap-openjdk all)
 gmake[3]: Entering directory
 '/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
 JAVA_HOME=/usr/local/bootstrap-openjdk
 ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/
 work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
 /wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
 -diagnostics >
 /wrkdirs/usr/ports/java

hard links in llvm39 and binutils

2017-01-25 Thread john--- via freebsd-ports 
Both llvm39 and binutils failed to install recently because they both have
hard links that cross directories. On this machine, those directories, both
in /usr/local on on different zfs filesystems.

I've had this directory structure for several years without issue, so this use
of hard links is new.

Is this use of hard links something I should expect to see looking forward or
is it an error?

John Theus
TheUs Group
___
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"