Re: Bug in make setting wrong MAKESYSPATH

2017-05-25 Thread Thomas Mueller 
>From Simon J. Gerraty:

> Thomas Mueller  wrote:

> > I go into /BETA1/usr/ports/ports-mgmt/synth , run
> > env MAKESYSPATH make all-depends-list

> I assume you mean MAKESYSPATH=something? otherwise env itself should
> vomit

When I did those last examples, that last line was
env MAKESYSPATH=/usr/share/mk make all-depends-list

> > and then it seems to work correctly with no syntax error in
> > /BETA1/usr/share/mk/bsd.compiler.mk
>
> > Maybe I need to file a bug.

> For what?

Bug occurs when building or configuring ports, syntax error in 
/BETA1/usr/share/mk/bsd.compiler.mk  line 52

I don't know about other situations such as building doc.

I could avoid this error either by setting (setenv or export, depending on 
shell) MAKESYSPATH or
by null-mounting /BETA1/usr/ports at /usr/ports .

> > What happens if src, ports and doc trees are installed on an NFS
> > share, where there would be no FreeBSD installation?

> Not sure what you mean. make doesn't care what the filesystem is
> if there is a share/mk found in . or somewhere above it, the default
> MAKESYSPATH will find it.

Tom

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

Re: ino64: desastrous update - recommendations not working!!!

2017-05-25 Thread O. Hartmann 
Am Wed, 24 May 2017 08:40:17 -0600
Alan Somers  schrieb:

> On Wed, May 24, 2017 at 4:42 AM, Hartmann, O.  wrote:
> > On almost every CURRENT that has been updated according to UPDATING
> > entry 2017-05-23 regarding ino64, the recommended update process ends
> > up in a desaster or, if the old environemnt/kernel is intact, itr
> > doesn't work.
> >
> > Procedure:
> >
> > make -jX buildworld buildkernel [successful]
> > make installkernel [successful]
> > reboot
> > Booting single user mode as recommended withnthe newly installed kernel
> > BUMMER!
> > When it comes to the point to type in the full path of /bin/sh, /bin/sh
> > immediately fails with SIGNAL 12  
> 
> Did you use a custom kernel config file without COMPAT_FREEBSD11?
> ___

YES :-(

First, I wasn't aware of the fact since it hasn't been mentioned in UPDATING, 
secondly,
after I've read it many times, I realised too late that I had COMPAT_FREEBSD10 
instead of
COMPAT_FREEBSD11 defined ... after a very stressful day mistake after mistake 
...

Now, after recompiling a proper kernel, on working systems which do have the 
"old" world
but the "new" kernel the SIGSYS for /bin/sh vanished and the procedure of 
updating went
as expected.

On boxes, where I had a terrible mixture of both world and no proper kernel, I 
recompiled
the kernel stuff on a working and compatible system and copied /boot/kernel to 
the
wrecked system and proceeded as recommended. That made things working again.

-- 
O. Hartmann

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


pgpfBiDw3KBBr.pgp
Description: OpenPGP digital signature

Re: NFS client performance degradation when SMP enabled

2017-05-25 Thread Rick Macklem 
Nope, it's an alc and the driver has very few changes between the old and
new kernel (a change in the DMA channel from 3 to 4, whatever that means?).

rick

From: Ryan Stone 
Sent: Wednesday, May 24, 2017 8:12:54 PM
To: Rick Macklem
Cc: freebsd-current@freebsd.org
Subject: Re: NFS client performance degradation when SMP enabled

What type of network interface do you have?  The Intel 1G (em and igb) were 
switched over to the "iflib" framework a few months ago and that could be the 
cause.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

2017-05-25 Thread David Wolfskill 
On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote:
> This is on my "build machine"; running GENERIC/amd64 built yesterday:
> 
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353  
> r318739M/318739:1200031: Wed May 24 10:00:20 PDT 2017 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 

Well, the laptop, running:

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #355  
r318781M/318781:1200031: Wed May 24 19:23:41 PDT 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

failed to exhibit the failure.  I'll poke a bit more at the build machine.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

2017-05-25 Thread David Wolfskill 
This is on my "build machine"; running GENERIC/amd64 built yesterday:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353  
r318739M/318739:1200031: Wed May 24 10:00:20 PDT 2017 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

after updating sources to r318863:

>>> World build started on Thu May 25 03:59:04 PDT 2017
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 3.1: recording compiler metadata
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: building everything
>>> stage 5.1: building lib32 shim libraries
>>> World build completed on Thu May 25 04:45:02 PDT 2017
>>> Kernel build for GENERIC started on Thu May 25 04:45:02 PDT 2017
>>> stage 1: configuring the kernel
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: building everything
...
--- all_subdir_drm2/radeonkms ---
Building 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkms/iicbus_if.h
--- all_subdir_ctl ---
Building 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/ctl/ctl.ko.debug
--- all_subdir_drm2 ---
--- all_subdir_drm2/radeonkmsfw ---
--- ARUBA_pfp.bin ---
uudecode: stdin: missing or bad "begin" line
--- all_subdir_ctl ---
Building 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/ctl/ctl.ko
--- all_subdir_drm2 ---
--- all_subdir_drm2/radeonkmsfw/ARUBA_me ---
Building 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin


bmake[6]: stopped in /usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp
.ERROR_TARGET='ARUBA_pfp.bin'
.ERROR_META_FILE='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp/ARUBA_pfp.bin.meta'
.MAKE.LEVEL='6'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp'
.TARGETS='all'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/common/S4/obj/usr/src/sys/GENERIC/modules'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tm
p/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /
usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/share/mk/local.sys.mk 
/usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/sys/modules/drm2/radeonkmsfw/
ARUBA_pfp/Makefile /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu
.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk 
/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp/../Makefile.inc 
/usr/src/share/mk/bsd.own.mk /
usr/src/share/mk/bsd.compiler.mk /usr/src/sys/conf/kern.opts.mk 
/usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src
/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk 
/usr/src/share/mk/bsd.subdir.mk /usr/src/sys/conf/kern.mk'



I have attached a copy of the meta file in question.

The only file in /usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp
is a Makefile ... last updated Oct 23 07:29:55 2014 (US/Pacific
time).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: The futur of the roff toolchain

2017-05-25 Thread Baptiste Daroussin 
On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote:
> On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote:
> > No the problem left is documentations available in share/doc.
> > 
> > I would like to push them elsewhere. Those documents are mostly useful for
> > historical reason (hence we want to keep them) but not really for daily use 
> > of
> > modern FreeBSD.
> > Another issue with those documentation, they are installed as text/ascii 
> > version
> > in base, which makes most of them not really readable (as the documents has 
> > not
> > be written for a ascii/text target but more for a PDF/html view - using 
> > pic(1)
> > for example)
> > 
> > A plan was to push as sources in the svn doc repository and continue to 
> > build
> > them. This approach also have an issue: over the time roff evolved a bit and
> > while working on heirloom doctools import I had to fix a bunch of markup to 
> > make
> > the rendering of those documents clean (also meaning almost noone should 
> > read
> > them considering some were not really readable).
> > 
> > What I want to propose now, it to render them as PDF (html?) once and push 
> > them
> > somewhere (to be defined) as static document on our documentation website.
> > Please doceng@ provide me a location where to push them.
> > 
> 
> Unless anyone on doceng@ objects within the next three days, I will
> create a new directory for the PDFs under doc/head/en_US.ISO8859-1/.
> 

Thank you,

For the record I have pushed the generated PDF:
https://people.freebsd.org/~bapt/pdfdocs/

The have been built with a modern groff and I forced the embedded fonts for all
fonts used.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

2017-05-25 Thread David Wolfskill 
On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote:
> ...
> I have attached a copy of the meta file in question.
> 

Bah.  Really attaching this time.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
# Meta data file 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp/ARUBA_pfp.bin.meta
CMD uudecode -p  > ARUBA_pfp.bin
CWD 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp
TARGET ARUBA_pfp.bin
-- command output --
uudecode: stdin: missing or bad "begin" line
*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 17403
# Start 1495712760.942230
V 5
E 17502 /bin/sh
R 17502 /etc/libmap.conf
R 17502 /var/run/ld-elf.so.hints
R 17502 /lib/libedit.so.7
R 17502 /lib/libc.so.7
R 17502 /lib/libncursesw.so.8
R 17502 /usr/share/locale/en_US.UTF-8/LC_COLLATE
R 17502 /usr/share/locale/en_US.UTF-8/LC_CTYPE
R 17502 /usr/share/locale/en_US.UTF-8/LC_MONETARY
R 17502 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
R 17502 /usr/share/locale/en_US.UTF-8/LC_TIME
R 17502 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
F 17502 17505
W 17505 ARUBA_pfp.bin
E 17505 /usr/bin/uudecode
R 17505 /etc/libmap.conf
R 17505 /var/run/ld-elf.so.hints
R 17505 /lib/libc.so.7
X 17505 1 0
X 17502 1 0
# Stop 1495712760.979230
# Bye bye


signature.asc
Description: PGP signature

Re: The futur of the roff toolchain

2017-05-25 Thread Glen Barber 
On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote:
> No the problem left is documentations available in share/doc.
> 
> I would like to push them elsewhere. Those documents are mostly useful for
> historical reason (hence we want to keep them) but not really for daily use of
> modern FreeBSD.
> Another issue with those documentation, they are installed as text/ascii 
> version
> in base, which makes most of them not really readable (as the documents has 
> not
> be written for a ascii/text target but more for a PDF/html view - using pic(1)
> for example)
> 
> A plan was to push as sources in the svn doc repository and continue to build
> them. This approach also have an issue: over the time roff evolved a bit and
> while working on heirloom doctools import I had to fix a bunch of markup to 
> make
> the rendering of those documents clean (also meaning almost noone should read
> them considering some were not really readable).
> 
> What I want to propose now, it to render them as PDF (html?) once and push 
> them
> somewhere (to be defined) as static document on our documentation website.
> Please doceng@ provide me a location where to push them.
> 

Unless anyone on doceng@ objects within the next three days, I will
create a new directory for the PDFs under doc/head/en_US.ISO8859-1/.

Glen
Hat:doceng@



signature.asc
Description: PGP signature

Re: The futur of the roff toolchain

2017-05-25 Thread Baptiste Daroussin 
On Thu, May 25, 2017 at 01:12:51PM +0100, tj wrote:
> On Thu, May 25, 2017 at 02:07:00PM +0200, Baptiste Daroussin wrote:
> > On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote:
> > > On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote:
> > > > No the problem left is documentations available in share/doc.
> > > > 
> > > > I would like to push them elsewhere. Those documents are mostly useful 
> > > > for
> > > > historical reason (hence we want to keep them) but not really for daily 
> > > > use of
> > > > modern FreeBSD.
> > > > Another issue with those documentation, they are installed as 
> > > > text/ascii version
> > > > in base, which makes most of them not really readable (as the documents 
> > > > has not
> > > > be written for a ascii/text target but more for a PDF/html view - using 
> > > > pic(1)
> > > > for example)
> > > > 
> > > > A plan was to push as sources in the svn doc repository and continue to 
> > > > build
> > > > them. This approach also have an issue: over the time roff evolved a 
> > > > bit and
> > > > while working on heirloom doctools import I had to fix a bunch of 
> > > > markup to make
> > > > the rendering of those documents clean (also meaning almost noone 
> > > > should read
> > > > them considering some were not really readable).
> > > > 
> > > > What I want to propose now, it to render them as PDF (html?) once and 
> > > > push them
> > > > somewhere (to be defined) as static document on our documentation 
> > > > website.
> > > > Please doceng@ provide me a location where to push them.
> > > > 
> > > 
> > > Unless anyone on doceng@ objects within the next three days, I will
> > > create a new directory for the PDFs under doc/head/en_US.ISO8859-1/.
> > > 
> > 
> > Thank you,
> > 
> > For the record I have pushed the generated PDF:
> > https://people.freebsd.org/~bapt/pdfdocs/
> > 
> > The have been built with a modern groff and I forced the embedded fonts for 
> > all
> > fonts used.
> > 
> 
> Multicolumn doesn't render correct in firefox for this:
> 
> https://people.freebsd.org/~bapt/pdfdocs/papers/timecounter.pdf
> 
> but is fine for this:
> 
> https://people.freebsd.org/~bapt/pdfdocs/papers/devfs.pdf
> 
Good catch thanks! I will see what I can do

Bapt


signature.asc
Description: PGP signature

pkg weirdness

2017-05-25 Thread Jeffrey Bouquet 
On a machine, pkg install xorg-server.
It wants to install the 1G llvm40
downloads... errors out.  Reboot

boot up
use tty1 rather than tty0
pkg install xorg-server
AGAIN downloads the metadata.
starts to AGAIN download llvm40, I cntl-C it.
I add 'pkg add ' the llvm40 that is ALREADY in /var/cache/pkg
Now pkg install xorg-server runs again, but RE downloading the smaller [... 
xorg-server ]
.
It lists the packages it is going to download.
Then, not in the new install... upgrade... reinstall... Y/N? ... it starts
downloading seamonkey!   I only asked it to 'install xorg-server!'
.
I think some more huge transparency [ pkg tells us in a verbose way what it
is doing, and why, and eventually have fine grained menu control before an
action... so that one can begin to make more sense of a post like this 
>> eventual bugzilla if need be.
..
Just curious more than anything this time, though... 
.
Sounds like did not happen, but did.   Sorry... 
[ by the way on the desktop, if I build from ports it is v11, but if I use pkg, 
it is v12. ] 
So I build from ports, all is good, but next pkg [week] it wants to upgrade a 
port
from v11 to v12.  too many places to look, I don't see that setting [v11 on a 
v12 machine]
anywhere.12.0-CURRENT by the way...
..
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

2017-05-25 Thread Simon J. Gerraty 
David Wolfskill  wrote:

> On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote:
> > This is on my "build machine"; running GENERIC/amd64 built yesterday:
> > 
> > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353  
> > r318739M/318739:1200031: Wed May 24 10:00:20 PDT 2017 
> > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> > 
> 
> Well, the laptop, running:

Compare the meta files for ARUBA_pfp.bin
in the failure case it looks very much like a input file was not
supplied (eg empty variable)

A possibility is .OODATE being used; which will be empty if none of the
srcs are out-of-date.


A quick scan didn't identify where the target for that comes from
so guessing...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg weirdness [corrected]

2017-05-25 Thread Jeffrey Bouquet 
Errata... on a part of the below...

On Thu, 25 May 2017 17:19:05 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> On a machine, pkg install xorg-server.
> It wants to install the 1G llvm40
> downloads... errors out.  Reboot
> 
> boot up
> use tty1 rather than tty0
> pkg install xorg-server
> AGAIN downloads the metadata.
> starts to AGAIN download llvm40, I cntl-C it.
> I add 'pkg add ' the llvm40 that is ALREADY in /var/cache/pkg
> Now pkg install xorg-server runs again, but RE downloading the smaller [... 
> xorg-server ]
> .
> It lists the packages it is going to download.
> Then, not in the new install... upgrade... reinstall... Y/N? ... it starts

  ^^^ was in a later version of the 
list...

> downloading seamonkey!   I only asked it to 'install xorg-server!'
> .
> I think some more huge transparency [ pkg tells us in a verbose way what it
> is doing, and why, and eventually have fine grained menu control before an
> action... so that one can begin to make more sense of a post like this 
> >> eventual bugzilla if need be.
> ..
> Just curious more than anything this time, though... 
> .
> Sounds like did not happen, but did.   Sorry... 
> [ by the way on the desktop, if I build from ports it is v11, but if I use 
> pkg, it is v12. ] 
> So I build from ports, all is good, but next pkg [week] it wants to upgrade a 
> port
> from v11 to v12.  too many places to look, I don't see that setting [v11 on a 
> v12 machine]
> anywhere.12.0-CURRENT by the way...
> ..
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Sorry. seamonkey WAS in the list...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

adding -R to the skeleton file for the PAGER variable

2017-05-25 Thread Larry Rosenman 
I ran into an "interesting" issue today using the devel/awscli
port. 

aws help

generates almost unreadable output using the "standard" shell .profile, etc. 

The reason is it uses $PAGER or $MANPAGER if it's present, and the skeleton
sets:

PAGER=more

which, using the .rst files that awscli has, just makes the output ESC 
sequences get printed and not acted upon. 

I'm wondering if there would be any objections to changing the "standard" 
skeleton PAGER environment to:

PAGER="more -R"

so the ESC sequences get passed through to the terminal unmolested and do the
right thing.

Comments?


-- 
Larry Rosenman https://people.FreeBSD.org/~ler/
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281


signature.asc
Description: PGP signature

Re: The futur of the roff toolchain

2017-05-25 Thread Baptiste Daroussin 
On Thu, May 25, 2017 at 01:12:51PM +0100, tj wrote:
> On Thu, May 25, 2017 at 02:07:00PM +0200, Baptiste Daroussin wrote:
> > On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote:
> > > On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote:
> > > > No the problem left is documentations available in share/doc.
> > > > 
> > > > I would like to push them elsewhere. Those documents are mostly useful 
> > > > for
> > > > historical reason (hence we want to keep them) but not really for daily 
> > > > use of
> > > > modern FreeBSD.
> > > > Another issue with those documentation, they are installed as 
> > > > text/ascii version
> > > > in base, which makes most of them not really readable (as the documents 
> > > > has not
> > > > be written for a ascii/text target but more for a PDF/html view - using 
> > > > pic(1)
> > > > for example)
> > > > 
> > > > A plan was to push as sources in the svn doc repository and continue to 
> > > > build
> > > > them. This approach also have an issue: over the time roff evolved a 
> > > > bit and
> > > > while working on heirloom doctools import I had to fix a bunch of 
> > > > markup to make
> > > > the rendering of those documents clean (also meaning almost noone 
> > > > should read
> > > > them considering some were not really readable).
> > > > 
> > > > What I want to propose now, it to render them as PDF (html?) once and 
> > > > push them
> > > > somewhere (to be defined) as static document on our documentation 
> > > > website.
> > > > Please doceng@ provide me a location where to push them.
> > > > 
> > > 
> > > Unless anyone on doceng@ objects within the next three days, I will
> > > create a new directory for the PDFs under doc/head/en_US.ISO8859-1/.
> > > 
> > 
> > Thank you,
> > 
> > For the record I have pushed the generated PDF:
> > https://people.freebsd.org/~bapt/pdfdocs/
> > 
> > The have been built with a modern groff and I forced the embedded fonts for 
> > all
> > fonts used.
> > 
> 
> Multicolumn doesn't render correct in firefox for this:
> 
> https://people.freebsd.org/~bapt/pdfdocs/papers/timecounter.pdf
> 
> but is fine for this:
> 
> https://people.freebsd.org/~bapt/pdfdocs/papers/devfs.pdf
> 
> - [tj]

Fixed, and reuploaded. because there should be some caching on people.f.o you
cannot yet see the fixed version but I have fixed it. It is supposed to be a
monocolumn as far as I understand it.

Bapt


signature.asc
Description: PGP signature

Re: The futur of the roff toolchain

2017-05-25 Thread tj 
> 
> Fixed, and reuploaded. because there should be some caching on people.f.o you
> cannot yet see the fixed version but I have fixed it. It is supposed to be a
> monocolumn as far as I understand it.


Yup, that renders fine for me now too.


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

Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

2017-05-25 Thread David Wolfskill 
On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote:
> This is on my "build machine"; running GENERIC/amd64 built yesterday:
> 

Nevermind.  Replacing /usr/src with a fresh checkout resolved the issue.

Peace,
davdi
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: The futur of the roff toolchain

2017-05-25 Thread tj 
On Thu, May 25, 2017 at 02:07:00PM +0200, Baptiste Daroussin wrote:
> On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote:
> > On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote:
> > > No the problem left is documentations available in share/doc.
> > > 
> > > I would like to push them elsewhere. Those documents are mostly useful for
> > > historical reason (hence we want to keep them) but not really for daily 
> > > use of
> > > modern FreeBSD.
> > > Another issue with those documentation, they are installed as text/ascii 
> > > version
> > > in base, which makes most of them not really readable (as the documents 
> > > has not
> > > be written for a ascii/text target but more for a PDF/html view - using 
> > > pic(1)
> > > for example)
> > > 
> > > A plan was to push as sources in the svn doc repository and continue to 
> > > build
> > > them. This approach also have an issue: over the time roff evolved a bit 
> > > and
> > > while working on heirloom doctools import I had to fix a bunch of markup 
> > > to make
> > > the rendering of those documents clean (also meaning almost noone should 
> > > read
> > > them considering some were not really readable).
> > > 
> > > What I want to propose now, it to render them as PDF (html?) once and 
> > > push them
> > > somewhere (to be defined) as static document on our documentation website.
> > > Please doceng@ provide me a location where to push them.
> > > 
> > 
> > Unless anyone on doceng@ objects within the next three days, I will
> > create a new directory for the PDFs under doc/head/en_US.ISO8859-1/.
> > 
> 
> Thank you,
> 
> For the record I have pushed the generated PDF:
> https://people.freebsd.org/~bapt/pdfdocs/
> 
> The have been built with a modern groff and I forced the embedded fonts for 
> all
> fonts used.
> 

Multicolumn doesn't render correct in firefox for this:

https://people.freebsd.org/~bapt/pdfdocs/papers/timecounter.pdf

but is fine for this:

https://people.freebsd.org/~bapt/pdfdocs/papers/devfs.pdf

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

Re: ino64 package fallout

2017-05-25 Thread Konstantin Belousov 
On Wed, May 24, 2017 at 05:49:04PM -0700, Don Lewis wrote:
> On 24 May, Konstantin Belousov wrote:
> > On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote:
> >> I just upgraded by package build box and its poudriere jail to r318776
> >> and ran into some significant package build fallout.
> > 
> > There are several reviews that fix ports with most significant fallouts,
> >lang/llvm39  D10796
> >lang/llvm40  D10797
> >lang/ghc D10798
> >multimedia/webcamd   D10800
> >devel/libgtopD10795
> >sysutils/py-psutil   D1081
> >lang/rustD10799
> > 
> > I intend to commit this tomorrow, after the ino64 get some probation time,
> > long enough to ensure that it does not get immediate revert.  You may
> > see the discussions and use the patches locally, meantime.
> 
> devel/libgtop is also broken:
> 
> procopenfiles.c:325:39: error: no member named 'kf_sa_local' in 'struct 
> kinfo_file'
> sun = (struct sockaddr_un *)>kf_sa_local;
>  ~~~  ^
> procopenfiles.c:330:37: error: no member named 'kf_sa_local' in 'struct 
> kinfo_file'
> addrstr = 
> addr_to_string(>kf_sa_local);
>   ~~~  ^
> procopenfiles.c:338:37: error: no member named 'kf_sa_peer' in 'struct 
> kinfo_file'
> addrstr = 
> addr_to_string(>kf_sa_peer);
>   ~~~  ^
> procopenfiles.c:352:36: error: no member named 'kf_sa_peer' in 'struct 
> kinfo_file'
> addrstr = addr_to_string(>kf_sa_peer);
>   ~~~  ^
> procopenfiles.c:357:52: error: no member named 'kf_sa_peer' in 'struct 
> kinfo_file'
> entry.info.sock.dest_port = 
> addr_to_port(>kf_sa_peer);
> procwd.c:155:16: warning: comparison of integers of different signs: 'int' 
> and 'unsigned long' [-Wsign-compare]
> for (i = 0; i < len / sizeof(*kif); i++, kif++) {
> ~ ^ ~~
>   ~~~ 
>  ^
> procopenfiles.c:388:9: warning: cast from 'gchar *' (aka 'char *') to 
> 'glibtop_open_files_entry *' (aka 'struct _glibtop_open_files_entry *') 
> increases required alignment from 1 to 4 [-Wcast-align]
> return (glibtop_open_files_entry*)g_array_free(entries, FALSE);
>^~~
> procopenfiles.c:305:16: warning: comparison of integers of different signs: 
> 'ssize_t' (aka 'long') and 'unsigned long' [-Wsign-compare]
> for (i = 0; i < len / sizeof(*kif); i++, kif++) {
> ~ ^ ~~
> 2 warnings and 5 errors generated.

This looks like errors from the unpatched port.  For instance, in my
working directory, content of the file
devel/libgtop/work/libgtop-2.32.0/sysdeps/freebsd/procopenfiles.c
around line 325 is:
struct sockaddr_un *sun;
   
entry.type = GLIBTOP_FILE_TYPE_LOCALSOCKET;
sun = (struct sockaddr_un *)>kf_un.kf_sock.
kf_sa_local;
which is not
sun = (struct sockaddr_un *)>kf_sa_local;
as reported by compiler in your case.

The patch is applied as extra-patch, might be you have OSVERSION set
forcibly ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-25 Thread Simon J. Gerraty 
Simon J. Gerraty  wrote:

> Peter Jeremy  wrote:
> > In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was
> > using "make buildworld" - which failed.  The upgrade worked cleanly
> > when I manually deleted all the .meta files.  If I get a round tuit,
> 
> sys.mk is setup such that missing .meta file makes the target
> out-of-date.
> 
> FWIW I just did a buildworld -DWITH_META_MODE followed by the same with
> -DNO_CLEAN - but no change to the tree.
> That at least worked fine (and quickly) tree was last updated to r318755
> 
> Wonder if it is safe to update...

FWIW I updated to r318860
and again

make -j12  -DWITHOUT_TESTS buildworld -DWITH_META_MODE -DNO_CLEAN

completed happily.

I guess need to update to/from the specific grns people had issue with
to reproduce.

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

Re: Bug in make setting wrong MAKESYSPATH

2017-05-25 Thread Simon J. Gerraty 
Thomas Mueller  wrote:
> When I did those last examples, that last line was
> env MAKESYSPATH=/usr/share/mk make all-depends-list

ok, that makes sense.

> > > and then it seems to work correctly with no syntax error in
> > > /BETA1/usr/share/mk/bsd.compiler.mk
> >
> > > Maybe I need to file a bug.
> 
> > For what?
> 
> Bug occurs when building or configuring ports, syntax error in 
> /BETA1/usr/share/mk/bsd.compiler.mk  line 52

This is of course specific to your particular arrangement
if you'd mounted /BETA1/usr/ports on /usr/ports, it would function as
you wish, or if /BETA1/usr/share/mk happend to match /usr/share/mk
it would work fine.

So, anoying in this case, but not a bug.

> I don't know about other situations such as building doc.
> 
> I could avoid this error either by setting (setenv or export, depending on 
> shell) MAKESYSPATH or
> by null-mounting /BETA1/usr/ports at /usr/ports .

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

Rangeley C2758: missed IOMMU support for Xen Dom0

2017-05-25 Thread Alex Deiter 
Hello,

Could you please help me understand what and were i did wrong?  

Running a FreeBSD 12.0-CURRENT-r318425 GENERIC-NODEBUG and trying to install 
Xen Dom0 (xen-4.7.0_2 from ports).

HW setup:
Supermicro A1SRM-2758F [Intel Rangeley Atom processor C2758]
Motherboard spec: 
http://supermicro.com/products/motherboard/Atom/X10/A1SRM-2758F.cfm
CPU spec: 
https://ark.intel.com/products/77988/Intel-Atom-Processor-C2758-4M-Cache-2_40-GHz

loader.conf:
hw.pci.mcfg=0
xen_kernel="/boot/xen"
xen_cmdline="dom0_mem=2048M dom0_max_vcpus=4 dom0pvh=1 com1=115200,8n1 
com2=115200,8n1 console=com2 guest_loglvl=all loglvl=all"

Xen Dom0 boot failed with error
Full boot log - https://cloud.deiter.ru/index.php/s/bg5lQSjPPSkiTAq

...
(XEN) I/O virtualisation disabled
...
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Presently, iommu must be enabled for PVH hardware domain
(XEN)
(XEN) 
 

Boot without Xen kernel is OK
Full boot log - https://cloud.deiter.ru/index.php/s/lUXLPnPSTWqqQNO

...
CPU: Intel(R) Atom(TM) CPU  C2758  @ 2.40GHz (2400.06-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x406d8  Family=0x6  Model=0x4d  Stepping=8
  
Features=0xbfebfbff
  
Features2=0x43d8e3bf
  AMD Features=0x28100800
  AMD Features2=0x101
  Structured Extended Features=0x2282
  VT-x: Basic Features=0xda0400
Pin-Based Controls=0x7f
Primary Processor 
Controls=0xfff9fffe
Secondary Processor 
Controls=0x28ef
Exit Controls=0xda0400
Entry Controls=0xda0400
EPT Features=0x6114141
VPID Features=0xf01
...
pci0:  at device 15.0 (no driver attached)
pci0:  at device 19.0 (no driver attached)
...

# pciconf -lv
none1@pci0:0:15:0:  class=0x080600 card=0x082015d9 chip=0x1f168086 rev=0x02 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Atom processor C2000 RCEC'
class  = base peripheral
subclass   = IOMMU


Thank you!

Alex Deiter
alex.dei...@gmail.com



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