Re: Jenkins build is back to stable : FreeBSD_HEAD #578

[Craig Rodrigues]

Thank you for fixing this.

--
Craig

On Wednesday, August 31, 2016,  wrote:

> See 
>
>
___
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: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Craig Rodrigues]

On Wed, Jun 8, 2016 at 11:41 PM, Xin Li  wrote:

>
> (I think the current implementation
> would do everything with plaintext protocol over wire, so while it
>

You are correct.  This document http://puffysecurity.com/wiki/ypldap.html#2
states:

#
# ypldap cant use SSL or SASL...
# You must allow unsecured authentication with the following line
# Then setup OpenIKED VPN or use OpenSSH Socket or Port Forwording
#


There is still value to ypldap as it is now, and getting feedback from
users (especially Active Directory) would be very useful.
If someone could document a configuration which uses IPSEC or OpenSSH
forwarding, that would be nice.

In future, maybe someone in OpenBSD or FreeBSD will implement things like
LDAP over SSL.

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

[CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Craig Rodrigues]

Hi,

I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD
current.

In latest current, it should be possible to put in /etc/rc.conf:

nis_ypldap_enable="YES"
to activate the ypldap daemon.

When set up properly, it should be possible to log into FreeBSD, and have
the backend password database come from an LDAP database such
as OpenLDAP

There is some documentation for setting this up, but it is OpenBSD specific:

http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client
http://puffysecurity.com/wiki/ypldap.html#2

I did not bother porting the OpenBSD LDAP server to FreeBSD, so that
information
does not apply.  I figure that openldap from ports should work fine.

I was wondering if there is someone out there familiar enough with LDAP
and has a setup they can test this stuff out with, provide feedback, and
help
improve the documentation for FreeBSD?

I would also be interested in hearing from someone who can see if
ypldap can work against a Microsoft Active Directory setup?

Thanks.
--
Craig
___
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: [CFT] WITH_META_MODE: Working incremental build

[Craig Rodrigues]

On Fri, May 27, 2016 at 05:16:25PM -0700, Bryan Drewery wrote:
> The way that "meta mode" works is to enable the bmake "meta mode"
> feature that tracks the build command for each target and uses the
> filemon(4) [1] module to track all files read/written/executed for
> building target.  If any of these change (see src.conf(5) WITH_META_MODE
> for details) then the target will be rebuilt.  This means that even
> changes to CFLAGS or the cross compiler will be detected and cause
> rebuilds.  This is quite an aggressive system but it works and removes
> the need for cleaning any of the tree.  In this mode .depend.* files
> (WITH_FAST_DEPEND) are not generated since they are mostly redundant
> with filemon(4)'s tracking.

Excellent!!  You sent out this mail, nearly seven years to the
day when John Birrell originally committed this code to FreeBSD:

https://svnweb.freebsd.org/base?view=revision=192702

It is fantastic that you and others have managed to continue with
this work, stabilize it, and get it into the mainstream of FreeBSD usage.

I think John would have been very happy with what you have achieved,
since he was always focused on pushing this work into FreeBSD,
rather than keeping it locked inside a single company as a proprietary solution.

--
Craig

___
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: HEADS UP Avoid r295167 - r295187

[Craig Rodrigues]

On Tuesday, February 2, 2016, Bryan Drewery  wrote:

> Avoid this range of revisions. I broke 'make distribution', causing
> etcupdate to nuke /etc. Sorry about that.


Ah ok, that explains this failure:
https://jenkins.freebsd.org/job/FreeBSD_HEAD/108/

--
Craig
___
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: Missing locales causing test failures

[Craig Rodrigues]

On Mon, Nov 16, 2015 at 12:25 AM, Baptiste Daroussin <b...@freebsd.org>
wrote:

> On Mon, Nov 16, 2015 at 12:09:01AM -0800, Craig Rodrigues wrote:
> > Hi,
> >
> > I compared the output of "locale -a" from a CURRENT system built
> > a few days ago, to the latest build.  The latest build still has some
> > missing locales,
> >
> >
> > af_ZA.ISO8859-15
> > en_AU.ISO8859-15
> > en_CA.ISO8859-15
> > en_NZ.ISO8859-15
> > en_US.ISO8859-15
> > fr_CA.ISO8859-15
> > lt_LT.ISO8859-4
> > sr_YU.ISO8859-2
> > sr_YU.ISO8859-5
> > sr_YU.UTF-8
> >
> > Can we bring these back?  Their absence is causing test failures.
> >
> I would be surprised they do cause any failures. do you have a link to the
> said
> failures?
>

https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1695/testReport/
___
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"

Missing locales causing test failures

[Craig Rodrigues]

Hi,

I compared the output of "locale -a" from a CURRENT system built
a few days ago, to the latest build.  The latest build still has some
missing locales,


af_ZA.ISO8859-15
en_AU.ISO8859-15
en_CA.ISO8859-15
en_NZ.ISO8859-15
en_US.ISO8859-15
fr_CA.ISO8859-15
lt_LT.ISO8859-4
sr_YU.ISO8859-2
sr_YU.ISO8859-5
sr_YU.UTF-8

Can we bring these back?  Their absence is causing test failures.

--
Craig
___
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: Need help fixing failing locale tests

[Craig Rodrigues]

On Sat, Nov 14, 2015 at 11:47 PM, John Marino 
wrote:

>
> With 4.) they have been removed from FreeBSD when "Make upgrade" is run
> after rebuilding.  Does FreeBSD have a cleanup like that, and did you
> run it?  If not, then maybe that needs to be updated.
>
>
I did not run "make upgrade".
I did this:
cd /usr/src
svn up

I then ran the 11 steps listed in /usr/src/Makefile:

https://github.com/freebsd/freebsd/blob/master/Makefile#L73

It looks like after running those steps, my system is in an inconsistent
state.  I see that the following symlinks point to nonexistent files.

/usr/share/locale/nl_BE.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/nl_BE.ISO8859-1/LC_COLLATE ->
../la_LN.ISO8859-1/LC_COLLATE
/usr/share/locale/en_CA.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE
/usr/share/locale/en_CA.ISO8859-15/LC_COLLATE ->
../la_LN.ISO8859-15/LC_COLLATE
/usr/share/locale/en_US.ISO8859-15/LC_COLLATE ->
../la_LN.ISO8859-15/LC_COLLATE
/usr/share/locale/en_US.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE
/usr/share/locale/ca_FR.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/nb_NO.ISO8859-1/LC_MONETARY ->
../no_NO.ISO8859-1/LC_MONETARY
/usr/share/locale/nb_NO.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/nb_NO.ISO8859-1/LC_COLLATE ->
../no_NO.ISO8859-1/LC_COLLATE
/usr/share/locale/nb_NO.ISO8859-1/LC_MESSAGES ->
../no_NO.ISO8859-1/LC_MESSAGES
/usr/share/locale/nb_NO.ISO8859-1/LC_NUMERIC ->
../no_NO.ISO8859-1/LC_NUMERIC
/usr/share/locale/sr_YU.ISO8859-2/LC_COLLATE ->
../la_LN.ISO8859-2/LC_COLLATE
/usr/share/locale/sr_YU.ISO8859-2/LC_CTYPE -> ../la_LN.ISO8859-2/LC_CTYPE
/usr/share/locale/is_IS.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/zh_TW.Big5/zh_Hant_TW.Big5 -> zh_Hant_TW.Big5
/usr/share/locale/af_ZA.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE
/usr/share/locale/af_ZA.ISO8859-15/LC_COLLATE ->
../la_LN.ISO8859-15/LC_COLLATE
/usr/share/locale/en_AU.ISO8859-15/LC_COLLATE ->
../la_LN.ISO8859-15/LC_COLLATE
/usr/share/locale/en_AU.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE
/usr/share/locale/fr_CH.ISO8859-1/LC_COLLATE ->
../la_LN.ISO8859-1/LC_COLLATE
/usr/share/locale/fr_CH.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/zh_CN.UTF-8/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE
/usr/share/locale/zh_CN.UTF-8/zh_Hans_CN.UTF-8 -> zh_Hans_CN.UTF-8
/usr/share/locale/zh_CN.UTF-8/LC_CTYPE -> ../UTF-8/LC_CTYPE
/usr/share/locale/sv_SE.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/it_IT.ISO8859-1/LC_COLLATE ->
../la_LN.ISO8859-1/LC_COLLATE
/usr/share/locale/it_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/it_CH.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/it_CH.ISO8859-1/LC_COLLATE ->
../la_LN.ISO8859-1/LC_COLLATE
/usr/share/locale/nn_NO.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/nn_NO.ISO8859-1/LC_COLLATE ->
../no_NO.ISO8859-1/LC_COLLATE
/usr/share/locale/nn_NO.ISO8859-1/LC_MONETARY ->
../no_NO.ISO8859-1/LC_MONETARY
/usr/share/locale/nn_NO.ISO8859-1/LC_NUMERIC ->
../no_NO.ISO8859-1/LC_NUMERIC
/usr/share/locale/nn_NO.ISO8859-1/LC_MESSAGES ->
../no_NO.ISO8859-1/LC_MESSAGES
/usr/share/locale/nl_NL.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/nl_NL.ISO8859-1/LC_COLLATE ->
../la_LN.ISO8859-1/LC_COLLATE
/usr/share/locale/zh_TW.UTF-8/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE
/usr/share/locale/zh_TW.UTF-8/zh_Hant_TW.UTF-8 -> zh_Hant_TW.UTF-8
/usr/share/locale/zh_TW.UTF-8/LC_CTYPE -> ../UTF-8/LC_CTYPE
/usr/share/locale/de_AT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/en_GB.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/en_GB.ISO8859-1/LC_COLLATE ->
../la_LN.ISO8859-1/LC_COLLATE
/usr/share/locale/ca_ES.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/zh_CN.GBK/zh_Hans_CN.GBK -> zh_Hans_CN.GBK
/usr/share/locale/zh_CN.GBK/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE
/usr/share/locale/de_DE.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/fi_FI.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
/usr/share/locale/fi_FI.ISO8859-1/LC_COLLATE ->
../la_LN.ISO8859-1/LC_COLLATE
/usr/share/locale/zh_CN.eucCN/zh_Hans_CN.eucCN -> zh_Hans_CN.eucCN
/usr/share/locale/zh_CN.eucCN/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE
/usr/share/locale/zh_HK.UTF-8/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE
/usr/share/locale/zh_HK.UTF-8/LC_CTYPE -> ../UTF-8/LC_CTYPE
/usr/share/locale/sr_YU.UTF-8/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE
/usr/share/locale/sr_YU.UTF-8/LC_CTYPE -> ../UTF-8/LC_CTYPE
/usr/share/locale/zh_CN.GB18030/zh_Hans_CN.GB18030 -> zh_Hans_CN.GB18030
/usr/share/locale/zh_CN.GB18030/LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE
/usr/share/locale/fr_CA.ISO8859-15/LC_CTYPE -> ../la_LN.ISO8859-15/LC_CTYPE

Re: make installworld failing with locales due to broken symlinks

[Craig Rodrigues]

On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper  wrote:

> $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE`
> ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory
>


I built the latest world, and then did the following:

rm -fr /tmp/testdir
mkdir /tmp/testdir

make installworld DESTDIR=/tmp/testdir

cd /tmp/testdir/usr/share/locale
for f in $(find . -type l) ; do [ ! -e $f ] && echo "$f does not exist";
done

./zh_CN.GB2312/LC_NUMERIC does not exist
./zh_CN.GB2312/LC_MONETARY does not exist
./zh_CN.GB2312/LC_COLLATE does not exist
./zh_CN.GB2312/LC_CTYPE does not exist
./zh_CN.GB2312/LC_MESSAGES does not exist
./zh_CN.GB2312/LC_TIME does not exist
./zh_CN.eucCN/LC_MESSAGES does not exist
./zh_CN.eucCN/LC_NUMERIC does not exist
./zh_CN.eucCN/LC_TIME does not exist
./zh_CN.eucCN/LC_CTYPE does not exist
./zh_CN.eucCN/LC_MONETARY does not exist
./zh_CN.eucCN/LC_COLLATE does not exist
./zh_HK.UTF-8/LC_NUMERIC does not exist
./zh_HK.UTF-8/LC_MONETARY does not exist
./zh_HK.UTF-8/LC_COLLATE does not exist
./zh_HK.UTF-8/LC_MESSAGES does not exist
./zh_HK.UTF-8/LC_TIME does not exist
./zh_HK.UTF-8/LC_CTYPE does not exist
./zh_CN.GBK/LC_CTYPE does not exist
./zh_CN.GBK/LC_NUMERIC does not exist
./zh_CN.GBK/LC_MESSAGES does not exist
./zh_CN.GBK/LC_COLLATE does not exist
./zh_CN.GBK/LC_MONETARY does not exist
./zh_CN.GBK/LC_TIME does not exist
./zh_CN.GB18030/LC_COLLATE does not exist
./zh_CN.GB18030/LC_MESSAGES does not exist
./zh_CN.GB18030/LC_CTYPE does not exist
./zh_CN.GB18030/LC_TIME does not exist
./zh_CN.GB18030/LC_NUMERIC does not exist
./zh_CN.GB18030/LC_MONETARY does not exist
./zh_TW.UTF-8/LC_MESSAGES does not exist
./zh_TW.UTF-8/LC_NUMERIC does not exist
./zh_TW.UTF-8/LC_MONETARY does not exist
./zh_TW.UTF-8/LC_TIME does not exist
./zh_TW.UTF-8/LC_CTYPE does not exist
./zh_TW.UTF-8/LC_COLLATE does not exist
./zh_HK.Big5HKSCS/LC_MONETARY does not exist
./zh_HK.Big5HKSCS/LC_NUMERIC does not exist
./zh_HK.Big5HKSCS/LC_CTYPE does not exist
./zh_HK.Big5HKSCS/LC_TIME does not exist
./zh_HK.Big5HKSCS/LC_COLLATE does not exist
./zh_HK.Big5HKSCS/LC_MESSAGES does not exist
./zh_TW.Big5/LC_MONETARY does not exist
./zh_TW.Big5/LC_CTYPE does not exist
./zh_TW.Big5/LC_TIME does not exist
./zh_TW.Big5/LC_NUMERIC does not exist
./zh_TW.Big5/LC_MESSAGES does not exist
./zh_TW.Big5/LC_COLLATE does not exist

--
Craig
___
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: make installworld failing with locales due to broken symlinks

[Craig Rodrigues]

On Sun, Nov 15, 2015 at 6:27 PM, Craig Rodrigues <rodr...@freebsd.org>
wrote:

> On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper <yaneurab...@gmail.com>
> wrote:
>
>> $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE`
>> ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory
>>
>
>
> I built the latest world, and then did the following:
>
> rm -fr /tmp/testdir
> mkdir /tmp/testdir
>
> make installworld DESTDIR=/tmp/testdir
>
> cd /tmp/testdir/usr/share/locale
> for f in $(find . -type l) ; do [ ! -e $f ] && echo "$f does not exist";
> done
>
> ./zh_CN.GB2312/LC_NUMERIC does not exist
> ./zh_CN.GB2312/LC_MONETARY does not exist
> ./zh_CN.GB2312/LC_COLLATE does not exist
> ./zh_CN.GB2312/LC_CTYPE does not exist
> ./zh_CN.GB2312/LC_MESSAGES does not exist
> ./zh_CN.GB2312/LC_TIME does not exist
> ./zh_CN.eucCN/LC_MESSAGES does not exist
> ./zh_CN.eucCN/LC_NUMERIC does not exist
> ./zh_CN.eucCN/LC_TIME does not exist
> ./zh_CN.eucCN/LC_CTYPE does not exist
> ./zh_CN.eucCN/LC_MONETARY does not exist
> ./zh_CN.eucCN/LC_COLLATE does not exist
> ./zh_HK.UTF-8/LC_NUMERIC does not exist
> ./zh_HK.UTF-8/LC_MONETARY does not exist
> ./zh_HK.UTF-8/LC_COLLATE does not exist
> ./zh_HK.UTF-8/LC_MESSAGES does not exist
> ./zh_HK.UTF-8/LC_TIME does not exist
> ./zh_HK.UTF-8/LC_CTYPE does not exist
> ./zh_CN.GBK/LC_CTYPE does not exist
> ./zh_CN.GBK/LC_NUMERIC does not exist
> ./zh_CN.GBK/LC_MESSAGES does not exist
> ./zh_CN.GBK/LC_COLLATE does not exist
> ./zh_CN.GBK/LC_MONETARY does not exist
> ./zh_CN.GBK/LC_TIME does not exist
> ./zh_CN.GB18030/LC_COLLATE does not exist
> ./zh_CN.GB18030/LC_MESSAGES does not exist
> ./zh_CN.GB18030/LC_CTYPE does not exist
> ./zh_CN.GB18030/LC_TIME does not exist
> ./zh_CN.GB18030/LC_NUMERIC does not exist
> ./zh_CN.GB18030/LC_MONETARY does not exist
> ./zh_TW.UTF-8/LC_MESSAGES does not exist
> ./zh_TW.UTF-8/LC_NUMERIC does not exist
> ./zh_TW.UTF-8/LC_MONETARY does not exist
> ./zh_TW.UTF-8/LC_TIME does not exist
> ./zh_TW.UTF-8/LC_CTYPE does not exist
> ./zh_TW.UTF-8/LC_COLLATE does not exist
> ./zh_HK.Big5HKSCS/LC_MONETARY does not exist
> ./zh_HK.Big5HKSCS/LC_NUMERIC does not exist
> ./zh_HK.Big5HKSCS/LC_CTYPE does not exist
> ./zh_HK.Big5HKSCS/LC_TIME does not exist
> ./zh_HK.Big5HKSCS/LC_COLLATE does not exist
> ./zh_HK.Big5HKSCS/LC_MESSAGES does not exist
> ./zh_TW.Big5/LC_MONETARY does not exist
> ./zh_TW.Big5/LC_CTYPE does not exist
> ./zh_TW.Big5/LC_TIME does not exist
> ./zh_TW.Big5/LC_NUMERIC does not exist
> ./zh_TW.Big5/LC_MESSAGES does not exist
> ./zh_TW.Big5/LC_COLLATE does not exist
>
> --
> Craig
>
>


This fixed it for me:

Index: Makefile
===
--- Makefile(revision 290902)
+++ Makefile(working copy)
@@ -15,7 +15,7 @@

 .for from to in ${ALIASES}
 .for f in ${LC_FILES}
-SYMLINKS+= ${from}/${f} ${LOCALEDIR}/${to}/${f}
+SYMLINKS+= ../${from}/${f} ${LOCALEDIR}/${to}/${f}
 .endfor
 .endfor

--
Craig
___
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: make installworld failing with locales due to broken symlinks

[Craig Rodrigues]

On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper  wrote:

> $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE`
> ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory
>


I built the latest world, and then did the following:

rm -fr /tmp/testdir
mkdir /tmp/testdir

make installworld DESTDIR=/tmp/testdir

cd /tmp/testdir/usr/share/locale
for f in $(find . -type l) ; do [ ! -e $f ] && echo "$f does not exist";
done

./zh_CN.GB2312/LC_NUMERIC does not exist
./zh_CN.GB2312/LC_MONETARY does not exist
./zh_CN.GB2312/LC_COLLATE does not exist
./zh_CN.GB2312/LC_CTYPE does not exist
./zh_CN.GB2312/LC_MESSAGES does not exist
./zh_CN.GB2312/LC_TIME does not exist
./zh_CN.eucCN/LC_MESSAGES does not exist
./zh_CN.eucCN/LC_NUMERIC does not exist
./zh_CN.eucCN/LC_TIME does not exist
./zh_CN.eucCN/LC_CTYPE does not exist
./zh_CN.eucCN/LC_MONETARY does not exist
./zh_CN.eucCN/LC_COLLATE does not exist
./zh_HK.UTF-8/LC_NUMERIC does not exist
./zh_HK.UTF-8/LC_MONETARY does not exist
./zh_HK.UTF-8/LC_COLLATE does not exist
./zh_HK.UTF-8/LC_MESSAGES does not exist
./zh_HK.UTF-8/LC_TIME does not exist
./zh_HK.UTF-8/LC_CTYPE does not exist
./zh_CN.GBK/LC_CTYPE does not exist
./zh_CN.GBK/LC_NUMERIC does not exist
./zh_CN.GBK/LC_MESSAGES does not exist
./zh_CN.GBK/LC_COLLATE does not exist
./zh_CN.GBK/LC_MONETARY does not exist
./zh_CN.GBK/LC_TIME does not exist
./zh_CN.GB18030/LC_COLLATE does not exist
./zh_CN.GB18030/LC_MESSAGES does not exist
./zh_CN.GB18030/LC_CTYPE does not exist
./zh_CN.GB18030/LC_TIME does not exist
./zh_CN.GB18030/LC_NUMERIC does not exist
./zh_CN.GB18030/LC_MONETARY does not exist
./zh_TW.UTF-8/LC_MESSAGES does not exist
./zh_TW.UTF-8/LC_NUMERIC does not exist
./zh_TW.UTF-8/LC_MONETARY does not exist
./zh_TW.UTF-8/LC_TIME does not exist
./zh_TW.UTF-8/LC_CTYPE does not exist
./zh_TW.UTF-8/LC_COLLATE does not exist
./zh_HK.Big5HKSCS/LC_MONETARY does not exist
./zh_HK.Big5HKSCS/LC_NUMERIC does not exist
./zh_HK.Big5HKSCS/LC_CTYPE does not exist
./zh_HK.Big5HKSCS/LC_TIME does not exist
./zh_HK.Big5HKSCS/LC_COLLATE does not exist
./zh_HK.Big5HKSCS/LC_MESSAGES does not exist
./zh_TW.Big5/LC_MONETARY does not exist
./zh_TW.Big5/LC_CTYPE does not exist
./zh_TW.Big5/LC_TIME does not exist
./zh_TW.Big5/LC_NUMERIC does not exist
./zh_TW.Big5/LC_MESSAGES does not exist
./zh_TW.Big5/LC_COLLATE does not exist

--
Craig
___
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: make installworld failing with locales due to broken symlinks

[Craig Rodrigues]

On Sun, Nov 15, 2015 at 5:57 PM, NGie Cooper  wrote:

>
> install: //usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE: No such file or
> directory
> *** Error code 71
>
> $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE
> lrwxr-xr-x  1 root  wheel  27 Nov  1 16:24
> /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
> $ readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE
> /usr/share/locale/la_LN.ISO8859-1
> $ ls `readlink -f /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE`
> ls: /usr/share/locale/la_LN.ISO8859-1: No such file or directory
>


Hi,

I ran into the same error when I tried to upgrade a system that I did an
installworld on
2 days ago.

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

Need help fixing failing locale tests

[Craig Rodrigues]

Hi,

After the recent locale commits, some of the tests are failing:

https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1675/testReport/

I can reproduce two failures quite easily by doing with a newly built world:

/bin/sh /usr/tests/bin/sh/builtins/case7.0
/bin/sh /usr/tests/bin/sh/builtins/locale1.0

Can someone look into this and help fix this?

I don't know much about locales, so don't know what to do.

--
Craig
___
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: Need help fixing failing locale tests

[Craig Rodrigues]

On Sat, Nov 14, 2015 at 7:05 PM, Craig Rodrigues <rodr...@freebsd.org>
wrote:

> Hi,
>
> After the recent locale commits, some of the tests are failing:
>
> https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1675/testReport/
>
> I can reproduce two failures quite easily by doing with a newly built
> world:
>
> /bin/sh /usr/tests/bin/sh/builtins/case7.0
> /bin/sh /usr/tests/bin/sh/builtins/locale1.0
>
> Can someone look into this and help fix this?
>
> I don't know much about locales, so don't know what to do.
>


I ran the two tests using bash, and got different error messages:

/usr/local/bin/bash /usr/tests/bin/sh/builtins/case7.0
/usr/tests/bin/sh/builtins/case7.0: line 7: warning: setlocale: LC_CTYPE:
cannot change locale (de_DE.ISO8859-1): Invalid argument
/usr/tests/bin/sh/builtins/case7.0: line 9: warning: setlocale: LC_COLLATE:
cannot change locale (de_DE.ISO8859-1): Invalid argument
wrong at 18
wrong at 23

/usr/local/bin/bash /usr/tests/bin/sh/builtins/locale1.0
/usr/tests/bin/sh/builtins/locale1.0: line 45: warning: setlocale:
LC_CTYPE: cannot change locale (nl_NL.ISO8859-1): Invalid argument
Failed: $ok -eq 1 at 56
/usr/tests/bin/sh/builtins/locale1.0: line 64: warning: setlocale: LC_ALL:
cannot change locale (nl_NL.ISO8859-1): No such file or directory
Failed: $ok -eq 1 at 68
Failed: $ok -eq 1 at 74
/usr/tests/bin/sh/builtins/locale1.0: regel 82: waarschuwing: setlocale():
LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file
or directory
Failed: $ok -eq 1 at 86
Failed: $ok -eq 1 at 99
/usr/tests/bin/sh/builtins/locale1.0: regel 107: waarschuwing: setlocale():
LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file
or directory
Failed: $ok -eq 1 at 111
/usr/tests/bin/sh/builtins/locale1.0: regel 114: waarschuwing: setlocale():
LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file
or directory
Failed: $ok -eq 1 at 118
/usr/tests/bin/sh/builtins/locale1.0: regel 122: waarschuwing: setlocale():
LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file
or directory
/usr/tests/bin/sh/builtins/locale1.0: regel 128: waarschuwing: setlocale():
LC_ALL: kan niet van taalregio veranderen (nl_NL.ISO8859-1): No such file
or directory
Failed: $ok -eq 1 at 132


On my system, I did:
ls -l /usr/share/locale/de_DE.ISO8859-1/*
-r--r--r--  1 root  wheel  4642 Nov  6 12:53
/usr/share/locale/de_DE.ISO8859-1/LC_COLLATE
lrwxr-xr-x  1 root  wheel27 Nov  6 12:53
/usr/share/locale/de_DE.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
-r--r--r--  1 root  wheel18 Nov  6 12:53
/usr/share/locale/de_DE.ISO8859-1/LC_MESSAGES
-r--r--r--  1 root  wheel35 Nov  6 12:53
/usr/share/locale/de_DE.ISO8859-1/LC_MONETARY
-r--r--r--  1 root  wheel 6 Nov  6 12:53
/usr/share/locale/de_DE.ISO8859-1/LC_NUMERIC
-r--r--r--  1 root  wheel   367 Nov  6 12:53
/usr/share/locale/de_DE.ISO8859-1/LC_TIME

ls -l /usr/share/locale/nl_NL.ISO8859-1/*
lrwxr-xr-x  1 root  wheel   29 Nov  6 12:53
/usr/share/locale/nl_NL.ISO8859-1/LC_COLLATE ->
../la_LN.ISO8859-1/LC_COLLATE
lrwxr-xr-x  1 root  wheel   27 Nov  6 12:53
/usr/share/locale/nl_NL.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE
-r--r--r--  1 root  wheel   18 Nov  6 12:53
/usr/share/locale/nl_NL.ISO8859-1/LC_MESSAGES
-r--r--r--  1 root  wheel   35 Nov  6 12:53
/usr/share/locale/nl_NL.ISO8859-1/LC_MONETARY
-r--r--r--  1 root  wheel6 Nov  6 12:53
/usr/share/locale/nl_NL.ISO8859-1/LC_NUMERIC
-r--r--r--  1 root  wheel  376 Nov  6 12:53
/usr/share/locale/nl_NL.ISO8859-1/LC_TIME

I saw that la_LN.ISO8859-1 does not exist, so the LC_CTYPE symlink is
pointing to  nothing.

--
Craig
___
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: [CFT] build: WITH_FAST_DEPEND and WITH_CCACHE_BUILD

[Craig Rodrigues]

On Thu, Nov 12, 2015 at 9:40 AM, Bryan Drewery  wrote:

> - The first is WITH_FAST_DEPEND. Please see the commit for its full
>

I have enabled WITH_FAST_DEPEND in make.conf for several builds.

(1) Job: https://jenkins.freebsd.org/job/FreeBSD_HEAD
 Before WITH_FAST_DEPEND:
https://jenkins.freebsd.org/job/FreeBSD_HEAD/3488/1 hour, 23 minutes
 After WITH_FAST_DEPEND:
https://jenkins.freebsd.org/job/FreeBSD_HEAD/3497/ ,  1 hour, 17 minutes

 Compiler used: clang

(2)   Job: https://jenkins.freebsd.org/job/FreeBSD_HEAD_sparc64/
Before WITH_FAST_DEPEND:
https://jenkins.freebsd.org/job/FreeBSD_HEAD_sparc64/1309/ , 23 minutes
After WITH_FAST_DEPEND:
https://jenkins.freebsd.org/job/FreeBSD_HEAD_sparc64/1329/ , 22 minutes

Compiler used: gcc 4.2.1

(3)  Job: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/
   Before WITH_FAST_DEPEND:
https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/761/ , 1 hour, 7
minutes
   After WITH_FAST_DEPEND:
https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/762/ , 1 hour 2
minutes

   Compiler:  gcc 4.9.2

The timings are not very scientific, because the VM's in which the builds
are occurring are
very loaded, since each build host is running multiple VM's, which are
building different things.

This gives you a basic idea though, that WITH_FAST_DEPEND works on a few
compilers (clang, gcc 4.2, gcc 4.9),
and there is some build time reduction, and no increase in build time.

Congratulations for tackling this stuff in FreeBSD.  As you mentioned, this
area has not been touched
in 14 years.
--
Craig
___
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"

Tunnelling IPv4 over IPv6 for GitHub access?

[Craig Rodrigues]

Hi,

I have some machines which are on an IPv6 only network.
It works great and I can access most things on the IPv6 Internet
that I need like Google ( [2607:f8b0:4004:808::1014]) , Facebook
([2a03:2880:1010:df05:face:b00c:0:2]), CNN ( [2620:100:e000::8001]), etc.

However, the one thing I cannot access is GitHub, which does not
support IPv6 ().

Is there a way that I can tunnel IPv4 over an IPv6 network?

I read this blog post:
http://www.aisecure.net/2013/02/03/tunneling-ipv4-over-ipv6-vpn/
and wasn't sure if this was an approach that I could use.

--
Craig
___
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: Tunnelling IPv4 over IPv6 for GitHub access?

[Craig Rodrigues]

On Mon, Nov 2, 2015 at 3:50 PM, Michael Gmelin  wrote:
>
>
>
> On Mon, 2 Nov 2015 14:04:18 -0800
>
> ikvjwd.com once offered a service using haproxy, you can find their
> configuration here:
>
>
https://github.com/rcsheets/ikvjwd/commit/58979dcaf42fbbd9203067a6ba4629ba01469120
>

We were using ikvjwd.com, but that service did not seem to be very reliable.


>
> Another way to tunnel all IPv4 traffic is set up an OpenVPN server on
> a dual stack machine and route your client IPv4 traffic over it (that
> approach is actually very easy to accomplish, stable and will work
> with any service).
>

Can you point me to some docs for how to do this?  This could work for me.

I have two separate networks that are connected:

+--+   +--+
|  |   |  |
|  |   |  |
|Dual  +-> |   IPv6   |
|stack |   |   only   |
|  |   |  |
+--+   +--+


My machine is in the IPv6 only network, but it has access to
a dual stack network.  I still need to run my stuff which accesses
GitHub in the IPv6 only network.

--
Craig
___
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: FreeBSD_HEAD - Build #3394 - Failure

[Craig Rodrigues]

On Wed, Oct 14, 2015 at 7:55 AM,  wrote:

>
>
> --- english ---
> echo "... english";
> rm -f english;  env LANG=C
> sort -u english.base |   awk '{
>   if ($1 == 1) {
>   print "\nMESSAGE NUMBER 1 IS NOT LEGAL";
>   exit 1; }
>if (++nline > $1) {
>print "DUPLICATE MESSAGE NUMBER " $1;   exit 1;
>}
>print $0;
>}' |sed
> -e '1s/^/$set 1~$quote "~/; 1y/~/\n/' | gencat english
> /dev/stdin;  chmod 444
> english;  if grep
> DUPLICATE english > /dev/null; then grep
> DUPLICATE english; fi;
>if grep 'NOT LEGAL' english
> > /dev/null; then   grep 'NOT LEGAL' english;
>  fi
> ... english
> --- _sub.buildfiles ---
> --- english ---
> echo "... english";
> rm -f english;  env LANG=C
> sort -u english.base |   awk '{
>   if ($1 == 1) {
>   print "\nMESSAGE NUMBER 1 IS NOT LEGAL";
>   exit 1; }
>if (++nline > $1) {
>print "DUPLICATE MESSAGE NUMBER " $1;   exit 1;
>}
>print $0;
>}' |sed
> -e '1s/^/$set 1~$quote "~/; 1y/~/\n/' | gencat english
> /dev/stdin;  chmod 444
> english;  if grep
> DUPLICATE english > /dev/null; then grep
> DUPLICATE english; fi;
>if grep 'NOT LEGAL' english
> > /dev/null; then   grep 'NOT LEGAL' english;
>  fi
> ... english
> gencat: Unable to create a new english: Permission denied
> *** [english] Error code 1
>
> make[5]: stopped in /builds/FreeBSD_HEAD/usr.bin/vi/catalog
> 1 error
>
>
Bryan,

Is this error related to this change:
http://svnweb.freebsd.org/base?view=revision=289282 ?

--
Craig
___
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: FreeBSD_HEAD_amd64_gcc4.9 - Build #652 - Failure

[Craig Rodrigues]

On Tue, Oct 13, 2015 at 9:44 PM, Bryan Drewery 
wrote:

> >
> > It looks like a bsd.progs.mk issue. I'll look more.
> >
> >
>
> r289286 will handle this and similar cases. Hopefully this holds.
>


Thank you for investigating the problem and coming up with a fix so quickly!

--
Craig
___
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: FreeBSD_HEAD_amd64_gcc4.9 - Build #652 - Failure

[Craig Rodrigues]

On Tue, Oct 13, 2015 at 12:05 AM,  wrote:

> --- env_test ---
> /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem
> /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include
> -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp
> -B/usr/local/x86_64-freebsd/bin/
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1
> -std=gnu++11
> -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/../lib/libc++
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp
> -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DHAVE_CONFIG_H
> -DATF_C_TESTS_BASE='"/usr/tests/lib/atf/libatf-c"'
> -DATF_INCLUDEDIR='"/usr/include"'
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/contrib/atf -fstack-protector-strong
> -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter
> -Wpointer-arith -Wno-uninitialized-o env_test env_test.o test_helpers.o
> -lprivateatf-c++ -lprivateatf-c -lprivateatf-c
> test_helpers.o: file not recognized: File truncated
>


I think that there is a race condition in
src//lib/atf/libatf-c++/tests/detail/Makefile ,
where if built with parallel jobs ( -j ), once in a while, test_helpers.o
is not fully built
before another job tries to link it.  This doesn't fail all the time, but
fails intermittently,
which makes it hard to spot.

--
Craig
___
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: kyua SIGBUS'ing with clang 3.7.0 (was FreeBSD_HEAD-tests - Build #1540 - Unstable)

[Craig Rodrigues]

On Fri, Oct 9, 2015 at 11:37 AM, Dimitry Andric  wrote:

>
> I have committed a (hopefully temporary) workaround in r289072.  If you
> don't want to do a full buildworld, first rebuild clang and install it,
> then rebuild libc++ and install it.
>

After some back-and-forth about the cause, I am now reasonably convinced
> that it is due to a bug in clang 3.7.0, as I noted in the commit message:
>
> Some further explanation: libc++'s iostream.cpp contains the definitions
> of std::cout, std::cerr and so on.  These global objects are effectively
> declared with an alignment of 8 bytes.  When an executable is linked
> against libc++.so, it can sometimes get a copy of the global object,
> which is then at the same alignment.
>
> However, with clang 3.7.0, the initialization of these global objects
> will incorrectly use SSE instructions (e.g. movdqa), whenever the
> optimization level is high enough, and SSE is enabled, such as on amd64.
> When any of these objects is not aligned to 16 bytes, this will result
> in a SIGBUS during iostream initialization.  In contrast, clang 3.6.x
> and earlier took the 8 byte alignment into consideration, and avoided
> SSE for those particular operations.
>
> After bisecting of upstream changes, I found that the above revision
> [llvm r240144] caused the change of this behavior, so I am reverting it
> now as a workaround, while a discussion and test case is being prepared
> for upstream.
>
> -Dimitry
>
>

Thank you for analyzing and fixing the problem.  You have excellent
detective
skills and worked hard to fix this!

--
Craig
___
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: kyua SIGBUS'ing with clang 3.7.0 (was FreeBSD_HEAD-tests - Build #1540 - Unstable)

[Craig Rodrigues]

On Wed, Oct 7, 2015 at 2:28 PM, Dimitry Andric  wrote:

>
> Do you still have a copy of the earlier executable?  Can you post it
> somewhere?
>

I was able to reproduce the problem.

pkg install devel/kyua
cd /usr/tests/local/kyua/bootstrap/
./plain_helpers
Bus error (core dumped)

root@:/usr/tests/local/kyua/bootstrap # gdb plain_helpers plain_helpers.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols
found)...
Core was generated by `plain_helpers'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/lib/libc++.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libc++.so.1
Reading symbols from /lib/libcxxrt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libcxxrt.so.1
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x00080085dcfd in std::__1::ios_base::Init::Init ()
   from /usr/lib/libc++.so.1
(gdb) where
#0  0x00080085dcfd in std::__1::ios_base::Init::Init ()
   from /usr/lib/libc++.so.1
#1  0x00080085e029 in std::__1::ios_base::Init::~Init ()
   from /usr/lib/libc++.so.1
#2  0x0008008b7352 in std::__throw_bad_alloc () from
/usr/lib/libc++.so.1
#3  0x00080085a5c6 in _init () from /usr/lib/libc++.so.1
#4  0x7fffe570 in ?? ()
#5  0x0008006059b8 in r_debug_state () from /libexec/ld-elf.so.1
#6  0x00080060506f in __tls_get_addr () from /libexec/ld-elf.so.1
#7  0x000800603439 in .text () from /libexec/ld-elf.so.1
#8  0x in ?? ()
(gdb)
#0  0x00080085dcfd in std::__1::ios_base::Init::Init ()
   from /usr/lib/libc++.so.1
#1  0x00080085e029 in std::__1::ios_base::Init::~Init ()
   from /usr/lib/libc++.so.1
#2  0x0008008b7352 in std::__throw_bad_alloc () from
/usr/lib/libc++.so.1
#3  0x00080085a5c6 in _init () from /usr/lib/libc++.so.1
#4  0x7fffe570 in ?? ()
#5  0x0008006059b8 in r_debug_state () from /libexec/ld-elf.so.1
#6  0x00080060506f in __tls_get_addr () from /libexec/ld-elf.so.1
#7  0x000800603439 in .text () from /libexec/ld-elf.so.1
#8  0x in ?? ()
(gdb)


The core file is here:  https://people.freebsd.org/~rodrigc/kyua-core/

--
Craig
___
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: FreeBSD_HEAD_amd64_gcc4.9 - Build #614 - Failure

[Craig Rodrigues]

On Tue, Oct 6, 2015 at 3:17 PM,  wrote:

>
> --- Module.o ---
> /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem
> /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include
> -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp
> -B/usr/local/x86_64-freebsd/bin/
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1
> -std=gnu++11
> -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/../lib/libc++
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp
> -B/usr/local/x86_64-freebsd/bin/  -O2 -pipe
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/include
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic
> -I.
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/../../lib/clang/include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
> -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT
> -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
> -fstack-protector-strong  -std=c++11 -fno-exceptions -fno-rtti  -c
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp
> -o Module.o
> In file included from
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/SourceLocation.h:22:0,
>  from
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Module.h:18,
>  from
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp:15:
> /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/functional:1322:17:
> error: '_Rp std::__1::__function::__base<_Rp(_ArgTypes
> ...)>::operator()(_ArgTypes&& ...) [with _Rp = void; _ArgTypes =
> {clang::VisibleModuleSet::setVisible(clang::Module*, clang::SourceLocation,
> clang::VisibleModuleSet::VisibleCallback,
> clang::VisibleModuleSet::ConflictCallback)::Visiting}]', declared using
> local type 'clang::VisibleModuleSet::setVisible(clang::Module*,
> clang::SourceLocation, clang::VisibleModuleSet::VisibleCallback,
> clang::VisibleModuleSet::ConflictCallback)::Visiting', is used but never
> defined [-fpermissive]
>  virtual _Rp operator()(_ArgTypes&& ...) = 0;
>  ^
> *** [Module.o] Error code 1
>
> make[6]: stopped in
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic
> 1 error
>
>
Hi,

I took a look at this, and was also able to reproduce this with gcc 5.0.

I was able to eliminate this error with gcc by moving  the definition of
"struct Visiting"
from outside the function by doing:

Index: llvm/tools/clang/lib/Basic/Module.cpp
===
--- llvm/tools/clang/lib/Basic/Module.cpp   (revision 288962)
+++ llvm/tools/clang/lib/Basic/Module.cpp   (working copy)
@@ -480,6 +480,12 @@
   print(llvm::errs());
 }

+struct Visiting {
+Module *M;
+Visiting *ExportedBy;
+};
+
+
 void VisibleModuleSet::setVisible(Module *M, SourceLocation Loc,
   VisibleCallback Vis, ConflictCallback
Cb) {
   if (isVisible(M))
@@ -487,11 +493,6 @@

   ++Generation;

-  struct Visiting {
-Module *M;
-Visiting *ExportedBy;
-  };
-
   std::function VisitModule = [&](Visiting V) {
 // Modules that aren't available cannot be made visible.
 if (!V.M->isAvailable())


I am not C++11 savvy enough to know if this is a gcc bug, or
a problem in the clang code.

Can we have something like this as a local patch in our FreeBSD tree until
we can get a better fix from LLVM?

--
Craig
___
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: ramblings.. or not

[Craig Rodrigues]

On Wed, Aug 26, 2015 at 8:44 PM, Julian Elischer jul...@freebsd.org wrote:

 I just enjoyed the following video.

   http://nextbsd.org/jordan-hubbard-visits-bafug/


That is a very good video.  It is good to see the NextBSD folks pushing
the boundaries and innovating with BSD.  A lot of the Apple technologies
have been battle tested by millions of users, so if FreeBSD can benefit
from themwhy not?



 Do we have a standard path for ideas from these projects and DragonFly?


From what I can tell, there is no official standard path for getting
anything into FreeBSD.
Ideally, people should bring up ideas and discuss things on the mailing
lists
beforehand.
That usually happens, but not always.

At the end of the day, getting things into FreeBSD involves someone
with a commit bit, who is motivated to slam the code into the tree.
Occasionally there are problems, but for the most part, things seem to work
out, and we've gotten cool things like ZFS, Dtrace, Netmap, etc.

At the end of Jordan's video, he mentioned that while it took him a while to
get accustomed to git, he realizes that git and git ecosystems like GitHub
greatly facilitate interacting with an open source project.  Forking,
submitting patches,
etc. are greatly




 We should also do a better job of productising and incorporating GSOC
 work..


Definitely!  It's sad to see people put a lot of working into something via
GSOC,
and then have the work die on the vine once the summer is over.



 Maybe we should make the ideas page more mainline.  Where people can put
 in a more standard way links to their pet projects and offically submit
 work for inclusion.
 and then make it better known..


I've been working with a software developer in Egypt, Ahmed Kamal, who has
helped
me a lot with devops issues in the Jenkins cluster.  Ahmed attended BSDCan
this year
and is eager to help out.  Many thanks to FreeBSD Foundation for giving him
a travel grant!

One comment that Ahmed made to me, and also to the FreeBSD Foundation,
is that for a complete newcomer to FreeBSD, it is very difficult for a
newcomer to
navigate all our web pages and wikis, and figure out where they can jump in
and contribute
to the project.

The FreeBSD project could definitely work to improve this area,
in order to attract new blood and new ideas to the project.  Streamlining
the ideas
page would be a good start.

--
Craig
___
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: cron/python3: python script acts weird, no debug output

[Craig Rodrigues]

On Fri, Aug 21, 2015 at 8:20 AM, O. Hartmann ohart...@zedat.fu-berlin.de
wrote:

 When the job is run from cron, the situation changes dramatically. The
 setup is
 like this:

 SHELL=/bin/sh
 TZ=Europe/Berlin
 MAILTO=
 PATH=/usr/local/bin:/usr/local/sbin:${PATH}

   ^
The line which specifies PATH is wrong in your crontab.  See:
https://lists.freebsd.org/pipermail/freebsd-python/2015-June/008384.html

--
Craig
___
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: FreeBSD_HEAD-tests - Build #1262 - Still Unstable

[Craig Rodrigues]

On Sun, Aug 09, 2015 at 10:40:49PM +0200, Jilles Tjoelker wrote:
 SVN r286490 exposed the brokenness of these tests. Since RFC 3629
 (November 2003), UTF-8 has been restricted to code points up to 0x10
 (inclusive). The higher sequences should be removed from the tests (or,
 even better, be expected to cause [EILSEQ]).
 
 I can provide a patch, but thought I'd explain the problem first.

Thanks for the analysis.
If you have an idea how to fix the tests, please commit the patch.

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

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #85 - Failure

[Craig Rodrigues]

On Sun, Jun 14, 2015 at 8:09 AM, Adrian Chadd adr...@freebsd.org wrote:

 + make -j 4 CROSS_TOOLCHAIN=amd64-gcc buildworld
 __MAKE_CONF=/builds/FreeBSD_HEAD_amd64_gcc4.9/make.conf
 make: /builds/FreeBSD_HEAD_amd64_gcc4.9/Makefile line 102: Malformed
 conditional (${MK_META_MODE} == yes)

 ?



See:

https://lists.freebsd.org/pipermail/svn-src-all/2015-June/105777.html

I'm waiting for Simon to respond since I'm not sure if that is the
correct fix.

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

Re: FreeBSD_HEAD-tests - Build #1075 - Fixed

[Craig Rodrigues]

On Sun, May 31, 2015 at 6:19 PM, jenkins-ad...@freebsd.org wrote:

 FreeBSD_HEAD-tests - Build #1075 - Fixed:

 Check console output at
 https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1075/ to view the
 results.


John,

Thanks for this:
https://lists.freebsd.org/pipermail/svn-src-all/2015-May/105098.html
which fixed it.

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

Re: Need help reducing compilation warnings in CURRENT

[Craig Rodrigues]

On Thu, May 28, 2015 at 9:49 AM, Konstantin Belousov kostik...@gmail.com
wrote:

 On Wed, May 27, 2015 at 11:30:45PM -0700, Craig Rodrigues wrote:

 I take some time to do a pass over mine code or code I am somewhat
 knowledgable, to correct some 'assigned but not used variable' warnings.
 There might be even one real bug in SU code uncovered, but I am not
 sure yet.

 Please review at https://reviews.freebsd.org/D2665 .
 I do not have an intention of splitting this into individual changes.


Thanks for committing these fixes.
Jenkins detected this as fixing 42 warnings:

https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/34/warnings17Result/

Every little bit helps!

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

Re: Need help reducing compilation warnings in CURRENT

[Craig Rodrigues]

On Thu, May 28, 2015 at 5:38 AM, Johannes Jost Meixner x...@freebsd.org
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi Craig,

 I'll gladly help (good excuse to learn C), but looking at those errors
 in general, one thing pops out:

 The warnings are almost all in contrib/ areas. Hence, any fix might
 want to probably be submitted to upstream first.



Sure, if we can push fixes upstream that would be great.
However, we shouldn't let that block us from comitting fixes to FreeBSD.
The advantage of having code in the FreeBSD repo is that we can
change it if we need to, even if the fix isn't yet in the upstream sources.
Contrib code is not made out of stone that can't be modified!

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

Re: Need help reducing compilation warnings in CURRENT

[Craig Rodrigues]

On Thu, May 28, 2015 at 5:45 AM, Muhammad Moinur Rahman b...@freebsd.org
wrote:

 Hi,

 Can anyone give me any ideas about how can I contribute some of my idle
 times? Do I need commit bit to submit patches in Jenkins? Or should I
 submit through CODE Review?



Please read this: https://wiki.freebsd.org/CodeReview
for instructions on how you can send patches to our code review tool.

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

Need help reducing compilation warnings in CURRENT

[Craig Rodrigues]

Hi,

I've configured Jenkins to highlight compiler warnings and
generate a table.  Jenkins also keeps track of new compiler warnings
over time.  See:

https://jenkins.freebsd.org/job/FreeBSD_HEAD/warnings7

Can anyone help improve the code by periodically looking
at this table and submitting patches to clean up the code?

Cleaning up compiler warnings is always boring work,
but it is good to clean up the code over time.

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

Re: libc/gen: unused variables

[Craig Rodrigues]

On Wed, May 20, 2015 at 12:11 AM, Adrian Chadd adr...@freebsd.org wrote:

 Hi,

 here's a patch against -head that eliminates gcc-4.9 complaining about


I've set up a Jenkins build of trunk using gcc 4.9:

https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/

That build also keeps track of the number of compiler warnings over time,
so if you manage to reduce the warnings, we should see the trend.

How much of FreeBSD have you been able to compile with gcc 4.9, and on
which platform?

On amd64, I could get a buildkernel and buildworld to work, but I had to
forcibly
skip building sys/boot/i386/boot2 because the generated code is too big:

https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001547.html

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

Re: libc/gen: unused variables

[Craig Rodrigues]

On Wed, May 20, 2015 at 5:53 PM, Adrian Chadd adr...@freebsd.org wrote:

 
  How much of FreeBSD have you been able to compile with gcc 4.9, and on
 which
  platform?

 I get down to a little bit inside libc before I hit unused code warnings.


What platform are you compiling on?  Are you looking at anything else
besides unused code warnings?
In the Jenkins job, I put in the following in make.conf:

# disable -Werror in userland build
NO_WERROR=yes
# disable -Werror in kernel build
WERROR=

With this, I build and get all the warnings:
https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/4/warnings17Result/

If you commit stuff which deals with the warnings, it would be hepful if you
can periodically monitor that Jenkins job and see if the overall warnings
go down.
Thanks.

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

Build failed in Jenkins: FreeBSD_HEAD #2725

[Craig Rodrigues]

On Monday, May 4, 2015, Cy Schubert cy.schub...@komquats.com
javascript:_e(%7B%7D,'cvml','cy.schub...@komquats.com'); wrote:


 I cannot see where the problem is. All local tests, including universe,
 have built cleanly.


 In this log: https://jenkins.freebsd.org/job/FreeBSD_HEAD/2725/console
search for:

error: version control conflict marker in file


--

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

Re: Build failed in Jenkins: FreeBSD_HEAD #2725

[Craig Rodrigues]

You need to do a better job at figuring out why you broke things.
This is not the first time you've broken things with an ntp import.

--
Craig
 On May 4, 2015 8:45 AM, Cy Schubert cy.schub...@komquats.com wrote:

 That file was deleted long ago.

 Cy Schubert
 cy.schub...@cschubert.com
 On May 4, 2015 7:49 AM, Craig Rodrigues rodr...@freebsd.org wrote:



 On Monday, May 4, 2015, Cy Schubert cy.schub...@komquats.com wrote:


 I cannot see where the problem is. All local tests, including universe,
 have built cleanly.


  In this log: https://jenkins.freebsd.org/job/FreeBSD_HEAD/2725/console
 search for:

 error: version control conflict marker in file


 --

 Craig




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

Re: backward dependencies on libzfs

[Craig Rodrigues]

On Mon, Apr 27, 2015 at 1:17 AM, Andriy Gapon a...@freebsd.org wrote:


 I am not sure what's the best list to discuss this issue, so let me raise
 it here.

 It seems that libzfs_core can not be used without also linking / loading
 libzfs:
 /lib/libzfs_core.so.2: Undefined symbol zcmd_ioctl_compat

 The same is true for libnvpair but for a different reason (and it looks
 like mea
 culpa):
 /lib/libnvpair.so.2: Undefined symbol aok

 Both dependencies seem to be backward, because:
 $ ldd /lib/libzfs.so.2
 /lib/libzfs.so.2:
 libmd.so.6 = /lib/libmd.so.6 (0x801647000)
 libthr.so.3 = /lib/libthr.so.3 (0x801857000)
 libumem.so.2 = /lib/libumem.so.2 (0x801a7c000)
 libutil.so.9 = /lib/libutil.so.9 (0x801c7d000)
 libuutil.so.2 = /lib/libuutil.so.2 (0x801e8f000)
 libm.so.5 = /lib/libm.so.5 (0x802098000)
 *libnvpair.so.2 = /lib/libnvpair.so.2 (0x8022c1000)*
 libavl.so.2 = /lib/libavl.so.2 (0x8024d6000)
 libbsdxml.so.4 = /lib/libbsdxml.so.4 (0x8026d8000)
 libgeom.so.5 = /lib/libgeom.so.5 (0x8028ff000)
 *libzfs_core.so.2 = /lib/libzfs_core.so.2 (0x802b04000)*
 libc.so.7 = /lib/libc.so.7 (0x80081f000)
 libsbuf.so.6 = /lib/libsbuf.so.6 (0x802d08000)

 So, there are circular dependencies between libzfs and the other library
 in both
 cases.
 It seems that those dependencies do not cause much, if any trouble, in
 practice,
 but they are not nice, because they are unexpected and they are not
 present on
 other OpenZFS platforms.


Fixes similar to this:
https://svnweb.freebsd.org/changeset/base/272484

need to be done to plug these symbol dependency problems in the libraries.

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

Merging GitHub Pull Requests into Subversion using git-svn

[Craig Rodrigues]

Hi,

Alfred Perlstein recently wrote this document for how to use
git-svn for interacting between the FreeBSD Subversion repo,
and the GitHub mirror of this repo:

https://wiki.freebsd.org/GitWorkflow/GitSvn

By following the steps in that article, step-by-step,
I was able to:

(1)  take these three GitHub pull requests from Steve Kiernan:

https://github.com/freebsd/freebsd/pull/26
https://github.com/freebsd/freebsd/pull/27
https://github.com/freebsd/freebsd/pull/28

(2)  Pull them into my own git checkout of the FreeBSD src tree

(3)  Modify the commit message slightly

(4)  Use git svn dcommit to push these changes directly from my Git tree
back to the
  FreeBSD svn repo:

https://svnweb.freebsd.org/changeset/base/281844
https://svnweb.freebsd.org/changeset/base/281845
https://svnweb.freebsd.org/changeset/base/281855

While there were multiple steps involved, I just followed the steps in the
wiki article, and it *just worked*!  Thanks for writing this article,
Alfred!

While not as smooth as clicking a merge button in GitHub,
this is a valid way to accept patches submitted via GitHub pull requests,
and integrate them in our FreeBSD Subversion repo.

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

Re: [Request for Help] Reducing gcc 4.9 compilation warnings

[Craig Rodrigues]

On Sun, Apr 19, 2015 at 2:10 AM, Eitan Adler li...@eitanadler.com wrote:


 Perhaps it would be useful to do a second run of this, but with a
 modified share/mk to silence the most useless of these warnings?


Sure, that's fine.  Can you provide a modified share/mk which you think
does the right thing?  We can try it.

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

[Request for Help] Reducing gcc 4.9 compilation warnings

[Craig Rodrigues]

Hi,

After the latest commits by members of freebsd-toolchain@ ,
I have managed to compile latest CURRENT world and GENERIC
kernel on amd64 with an gcc 4.9 external toolchain by doing:

   pkg install devel/amd64-xtoolchain-gcc
   cd /usr/src
   sed -i  -e 's/boot2//' sys/boot/i386/Makefile
   make buildworld CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=
   make buildkernel CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=


It was necessary to skip boot2 from building because of errors
reported here:
https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001658.html

The boot2 compilation errors still need to be worked on.

However, most other things compile with warnings.  If folks are
interested in looking at the warnings, you can see them here:

https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/warnings17

Please look at these warnings, and if you see places to
patch the code to eliminate the warnings, please submit patches
and commit them if you can.

clang is still going to be the default compiler in the base system,
but it is nice to have FreeBSD compilable by multiple compilers.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Dual booting FreeBSD and Win95

[Craig Rodrigues]

On Wed, Apr 8, 2015 at 12:30 PM, Ryan Stone ryst...@gmail.com wrote:


 We're looking at dual-booting FreeBSD and Win95.  We're thinking of booting


Wow, I like your problem.  It's really weird, and I like weird problems. :)

Since you are looking at automating a complicated process,
here is a crazy idea which you might want to consider

(1)  Get two machines, interconnect them via a small Ethernet switch.
(2)  Designate one machine as a PXE server, and the other as your test
machine
(3)  Set up a FreeBSD PXE boot environment wit NFS root, as per:
https://www.freebsd.org/doc/handbook/network-diskless.html#network-pxe-nfs
(4)  Figure out how to PXE boot a Windows95 environment.  There are
articles out there for PXE booting FreeDOS which might be a place to start:

http://www.cs.waikato.ac.nz/~dbaird/work/2013/11/05/pxe-boot-freedos-hard-disk-image/

On the DHCP server, you can modify dhcpd.conf to change which OS will boot
via PXE boot.
If you can:
   - automate the reboot of your test server
   - automate the modification of dhcpd.conf on your PXE server via some
process

then you might be able to get it to work. :)
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Bazaaring the cathedral (Lowering the Barrier to Entry)

[Craig Rodrigues]

On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler li...@eitanadler.com wrote:


 To solve this problem I propose a simple solution: self-serve commit
 access.  We create a web service on accounts.freebsd.org via which
 users can create themselves a freefall account.  In addition to a
 freefall account, the identical username would be created for the wiki
 and phabricator, bugzilla, and any other service we might provide.


I support the creation of accounts.freebsd.org.

I suggest that we use PWM ( http://code.google.com/p/pwm/ ) as
a web-based front-end to a back-end LDAP database.

The FreeBSD cluster already has LDAP (
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#kerberos-ldap
)

The FreeBSD cluster LDAP + Kerberos back-end infrastructure is something
developed by clusteradm
(most likely Peter Wemm).  It works quite well.   I succeeded in
using the FreeBSD cluster LDAP system for Jenkins authentication, and
it just worked like a champ.

The FreeBSD cluster LDAP system just needs a better front-end that is more
user friendly, and easier to manage.

If you log into hub.freebsd.org and look at /etc/aliases, you will
see that there are 12 people who receive clusteradm e-mails.
My experience working with Jenkins is that only about 2-3 people
actively do clusteradm work, and they are *way* overloaded.

If we could have accounts.freebsd.org which streamlines a lot of
the account creation and management, and works across many
modern web applications, that would be super cool, and would
hopefully reduce the load on clusteradm!

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

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Craig Rodrigues]

On Sun, Mar 22, 2015 at 3:01 PM, Craig Rodrigues rodr...@freebsd.org
wrote:



 On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric d...@freebsd.org wrote:

 On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
 
  On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org
 wrote:
 
  Ah right, that was on i386, on amd64 it does result in -2^63.  It is
 indeed caused by reliance on signed integer wrapping.
 
  This diff should fix it, without rewriting the utility:
 
  Index: bin/expr/Makefile
  ===
  --- bin/expr/Makefile   (revision 280156)
  +++ bin/expr/Makefile   (working copy)
  @@ -6,6 +6,9 @@ PROG=   expr
   SRCS=  expr.y
   YFLAGS=
 
  +# expr relies on signed integer wrapping
  +CFLAGS+= -fwrapv
  +
   NO_WMISSING_VARIABLE_DECLARATIONS=
 
   .if ${MK_TESTS} != no
 
 
  Well, another alternative is to patch expr.y:
 
  Index: expr.y
  ===
  --- expr.y  (revision 280353)
  +++ expr.y  (working copy)
  @@ -393,7 +393,7 @@
   }
 
   void
  -assert_plus(intmax_t a, intmax_t b, intmax_t r)
  +assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
   {
  /*
   * sum of two positive numbers must be positive,
  @@ -420,7 +420,7 @@
   }
 
   void
  -assert_minus(intmax_t a, intmax_t b, intmax_t r)
  +assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
   {
  /* special case subtraction of INTMAX_MIN */
  if (b == INTMAX_MIN  a  0)
 
 
  There were already some patches previously done to this
  file to add volatile, so maybe this would be OK to do.
 
  What do you think?

 Volatile is not the solution, it is completely orthogonal.  The correct
 way would be to use unsigned integers, for which wrapping is defined,
 then convert those back and forth when presenting the results to the
 user.


 OK, converting expr.y to use unsigned integers would require a bit of work.

 Can you commit your patch to the Makefile?  It fixes the problem for now.


Thanks for committing the fix.  I wasn't aware of this topic, but it is
explained
quite nicely in this LLVM blog post:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html#signed_overflow

Do you think we should further change expr.y with something like this:

Index: expr.y
===
--- expr.y  (revision 280357)
+++ expr.y  (working copy)
@@ -445,12 +445,13 @@
 }

 /*
- * We depend on undefined behaviour giving a result (in r).
- * To test this result, pass it as volatile.  This prevents
- * optimizing away of the test based on the undefined behaviour.
+ * We depend on undefined signed integer overflow behaviour
+ * giving a result (in r).
+ * This file must be compiled with the -fwrapv compiler
+ * flag which forces defined behavior for signed integer overflow.
  */
 void
-assert_times(intmax_t a, intmax_t b, volatile intmax_t r)
+assert_times(intmax_t a, intmax_t b, intmax_t r)
 {
/*
 * If the first operand is 0, no overflow is possible,


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

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Craig Rodrigues]

On Sun, Mar 22, 2015 at 11:26 AM, jenkins-ad...@freebsd.org wrote:

 See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/867/


Can someone with toolchain expertise look at this?
After the clang 3.6.1 import, /bin/expr behaves differently.

With clang 3.5.0:

# expr 4611686018427387904 + 4611686018427387904
expr: overflow

With clang 3.6.1:

# expr 4611686018427387904 + 4611686018427387904
-9223372036854775808

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

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Craig Rodrigues]

On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:


 Ah right, that was on i386, on amd64 it does result in -2^63.  It is
 indeed caused by reliance on signed integer wrapping.

 This diff should fix it, without rewriting the utility:

 Index: bin/expr/Makefile
 ===
 --- bin/expr/Makefile   (revision 280156)
 +++ bin/expr/Makefile   (working copy)
 @@ -6,6 +6,9 @@ PROG=   expr
  SRCS=  expr.y
  YFLAGS=

 +# expr relies on signed integer wrapping
 +CFLAGS+= -fwrapv
 +
  NO_WMISSING_VARIABLE_DECLARATIONS=

  .if ${MK_TESTS} != no



Well, another alternative is to patch expr.y:

Index: expr.y
===
--- expr.y  (revision 280353)
+++ expr.y  (working copy)
@@ -393,7 +393,7 @@
 }

 void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
 {
/*
 * sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
 }

 void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
 {
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN  a  0)


There were already some patches previously done to this
file to add volatile, so maybe this would be OK to do.

What do you think?

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

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Craig Rodrigues]

On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric d...@freebsd.org wrote:

 On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
 
  On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
 
  Ah right, that was on i386, on amd64 it does result in -2^63.  It is
 indeed caused by reliance on signed integer wrapping.
 
  This diff should fix it, without rewriting the utility:
 
  Index: bin/expr/Makefile
  ===
  --- bin/expr/Makefile   (revision 280156)
  +++ bin/expr/Makefile   (working copy)
  @@ -6,6 +6,9 @@ PROG=   expr
   SRCS=  expr.y
   YFLAGS=
 
  +# expr relies on signed integer wrapping
  +CFLAGS+= -fwrapv
  +
   NO_WMISSING_VARIABLE_DECLARATIONS=
 
   .if ${MK_TESTS} != no
 
 
  Well, another alternative is to patch expr.y:
 
  Index: expr.y
  ===
  --- expr.y  (revision 280353)
  +++ expr.y  (working copy)
  @@ -393,7 +393,7 @@
   }
 
   void
  -assert_plus(intmax_t a, intmax_t b, intmax_t r)
  +assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
   {
  /*
   * sum of two positive numbers must be positive,
  @@ -420,7 +420,7 @@
   }
 
   void
  -assert_minus(intmax_t a, intmax_t b, intmax_t r)
  +assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
   {
  /* special case subtraction of INTMAX_MIN */
  if (b == INTMAX_MIN  a  0)
 
 
  There were already some patches previously done to this
  file to add volatile, so maybe this would be OK to do.
 
  What do you think?

 Volatile is not the solution, it is completely orthogonal.  The correct
 way would be to use unsigned integers, for which wrapping is defined,
 then convert those back and forth when presenting the results to the
 user.


OK, converting expr.y to use unsigned integers would require a bit of work.

Can you commit your patch to the Makefile?  It fixes the problem for now.

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

Re: sbuf-related panic

[Craig Rodrigues]

On Tue, Mar 17, 2015 at 11:49 AM, Mark Felder f...@freebsd.org wrote:



 On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote:
  On amd64, doing a Poudriere run. On r280133:
 

 I appeared to be hitting this on 280130, the most recent CURRENT
 snapshot. I'm going to build the latest since some sbuf fixes have
 landed and see if I can finish a poudriere build run.


The Jenkins build which boots a VM and runs the kyua tests is kernel
panicking in sbuf as well:

https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/853/console

You might want to see if that build passes before updating.

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

Re: sbuf-related panic

[Craig Rodrigues]

On Tue, Mar 17, 2015 at 11:57 AM, Ian Lepore i...@freebsd.org wrote:


 There is still a panic, one that I can't yet figure out why it wasn't
 panicking before my changes, but I'm working on it.


Can you run the kyua tests on your system?


https://wiki.freebsd.org/201411DevAndVendorSummit?action=AttachFiledo=viewtarget=kyua_jenkins.pdf

Those tests seem to be reproducibly triggering the problem.

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

Re: Massive libxo-zation that breaks everything

[Craig Rodrigues]

On Tue, Mar 3, 2015 at 11:07 AM, Justin Hibbits jr...@alumni.cwru.edu
wrote:

 On Tue, Mar 3, 2015 at 10:39 AM, Alfred Perlstein bri...@mu.org wrote:
 
 
  Sent from my iPhone
 
  On Mar 3, 2015, at 9:32 AM, hiren panchasara 
 hi...@strugglingcoder.info wrote:
 
  On 03/02/15 at 07:33P, Alfred Perlstein wrote:
 
 
 
  Actually I want to shame third party ports into adopting libxo (or at
 least providing machine readable output).
 
  I know it's scary to try to lead the pack, after all we could be
 wrong, but maybe it's time to try something new and see what happens.
 
  And no, your idea doesn't make sense it just will lead to those files
 bit rotting.
 
  Bedsides that you don't even have a real spec other than it should be
 done differently.
 
  Again, show the code.
 
  Wow. He told you want he didn't like and he moved on. I hope/wish we as
  a project can take criticism more positively than this.
 
  Answer to every criticism should not be show me your code. We (should)
  know better than that.
 
  Maybe I am too old school but the motd on freefall is still now shut up
 and code. I still believe that's right.
 
  We ALL need to know when to step back from an issue we really do not
 have the bandwidth to constructively contribute to.
 
  This doesn't mean ideas or concerns aren't valid, but that unless you
 truly have the bandwidth to contribute, taking a step back is a good idea.
 
  -Alfred.

 You're both right.  Maybe we need a hackathon on this.  Is BSDCan too late?


BSDCan Devsummit has a room available for a Hackathon.  If you or anybody
else wants
to add work items to the Hackathon that you are interested in working on,
please add it to
the wiki page:

https://wiki.freebsd.org/action/login/201506DevSummit#Hackathon_Topics

It's OK to add work items there, but please only add them to the wiki page
unless you are confident that you will show up to the hackathon and at
least try to work on the item. :)

Many thanks to the Devsummit organizers for providing a room for the
Hackathon.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Massive libxo-zation that breaks everything

[Craig Rodrigues]

On Mon, Mar 2, 2015 at 7:33 PM, Alfred Perlstein bri...@mu.org wrote:


 Actually I want to shame third party ports into adopting libxo (or at
least providing machine readable output).


Well if upstream third party ports adopt libxo will remain to be seen.
However, one thing we can do is to make it super-duper easy for them to
incorporate.
Then it will be a no-brainer for them to use libxo.

I would like to see a Debian package of libxo made, so it can be
incorporated
into Debian and Ubuntu derived Linux distributions.

I have done similar Debian packaging efforts for kyua, atf, and lutok:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773277
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773278
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773279

Does anyone have connections in the Debian community to push
these kinds of reviews forward?  I've asked on the debian-bsd mailing list,
but got no help.  I basically need a Debian Developer who has
privileges to upload packages to the Debian distribution to take the
packages that I have made
and upload them (after making sure they pass lintian checks).

I can take a whack and do something similar for libxo.

I was actually very surprised at how hard/bureaucratic it is to get a new
package
into Debian.  FreeBSD ports and Mac Homebrew are actually way easier to
work with in terms
of adding a new package.  However, Debian and Ubuntu have a lot of users,
so it is worth
the effort to push this kind of stuff through.

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

Re: r279278 failed to build (yacc: maximum table size exceeded)

[Craig Rodrigues]

Hi,

I ran into this problem when doing a src upgrade
of a HEAD system compiled on Oct. 21, 2014 to
HEAD on March 4, 2015:

  yacc -d -pAslCompiler -oaslcompilerparse.c
aslcompiler.y
  maximum table size exceeded
  *** [aslcompilerparse.c] Error code 2
make[5]: stopped in /usr/src/usr.sbin/acpi/iasl
  1 error


Does your fix address the problem in HEAD or just STABLE?

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

Re: Massive libxo-zation that breaks everything

[Craig Rodrigues]

On Sun, Mar 1, 2015 at 10:49 AM, Harrison Grundy 
harrison.gru...@astrodoggroup.com wrote:

 Thanks!

 That does seem useful, but I'm not sure I see the reasoning behind
 putting into base, over a port or package



 , since processing XML in base is a pain, and it can't serve up JSON or
 HTML without additional
 utilities anyway.



I think if you take another pass at reading the entire thread  of responses
to see the discussion for the motivation behind libxo, you will get the
idea:
 https://lists.freebsd.org/pipermail/freebsd-arch/2014-July/015633.html


There are many people who are building products on top of FreeBSD.
For these people, it is super useful for the base utilities in FreeBSD
to emit output in properly formatted XML or JSON.

That way, they do not need to write scripts to take the output of
say, netstat, and use awk/sed/whatever scripts to take the human readable
netstat output and convert it to a form which can be used in a script.

There are many, many parsers for XML and JSON not in the base system.
For people building products on top of FreeBSD, they don't care
if these parsers are not in the base, since they can add these parsers on
top of base FreeBSD.

For example, languages like Python and Ruby have excellent parsers
for JSON and XML.  Many people build products using these languages.
There are JSON and XML parsers in C, C++, and other languages as well.

In addition to people building products, the other audience of people who
benefit from libxo are devops people.
These days, devops folks have no problem using Python, Ruby, Perl,
whatever to write scripts to interact with Unix boxes and pull information
off of it.  Having the base utilities emit info in native JSON or XML
greatly facilitates this.

I talked to one person who is improving FreeBSD support for Saltstack (a
devops framework).   He told me
that if more base utilities such as sysctl, could use libxo to emit output
in JSON, that would greatly facilitate improving FreeBSD support for
these devops frameworks.  That is because Saltstack would require
less FreeBSD-specific parsing code for getting info from base utilities.

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

Re: Massive libxo-zation that breaks everything

[Craig Rodrigues]

On Sun, Mar 1, 2015 at 9:25 AM, Harrison Grundy 
harrison.gru...@astrodoggroup.com wrote:



 If someone could summarize what this is, I'd greatly appreciate it.


https://lists.freebsd.org/pipermail/freebsd-arch/2014-July/015633.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFC] Removin the old make

[Craig Rodrigues]

On Thu, Feb 12, 2015 at 3:49 PM, Julian H. Stacey j...@berklix.com wrote:


 In FreeBSD-9.3 :
   bmake is not default, merely there
 -r-xr-xr-x  1 root  wheel  518032 Nov  5 16:58 /usr/bin/bmake*
 -r-xr-xr-x  1 root  wheel  453176 Nov  5 16:58 /usr/bin/make*
man make has No Warning people should migrate to bmake.

 FreeBSD-10.0
   Has Only one /usr/bin/*make ( no make.old)
No warning that it's a new make called bmake or what if any differences
   might be from make in 9.


Well, there was *some* warning in the release notes:

https://www.freebsd.org/releases/9.3R/relnotes.html

https://www.freebsd.org/releases/10.0R/relnotes.html

Of course, the fmake/bmake changes are buried in a whole
pile of other changes, so users may have found this easy to miss.
It's hard to describe the impacts of changes like this, and
have readable release notes.  Oh well. :(

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

Re: Jenkins build became unstable: FreeBSD_HEAD-tests2 #604

[Craig Rodrigues]

On Tue, Jan 27, 2015 at 12:21 PM, jenkins-ad...@freebsd.org wrote:

 See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/604/


One of the expr tests seems to have broken after this change:
https://lists.freebsd.org/pipermail/svn-src-all/2015-January/098238.html

Can you take a look?

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

Re: Devops question: freebsd-update needs a real tty to run, problem for automation

[Craig Rodrigues]

On Tue, Jan 13, 2015 at 4:14 PM, Allan Jude allanj...@freebsd.org wrote:

 On 2015-01-13 18:11, Craig Rodrigues wrote:
  Hi,
 
  Ahmed Kamal, a devops expert, is helping me to script the steps to
  upgrade a cluster of FreeBSD machines.  For certain machines,
  we want to track the official FreeBSD releases and use freebsd-update
  to install official updates.
 
  We found that when the invocation of freebsd-update was scripted
  and not run via a real tty, we can into this error:
 
  freebsd-update fetch should not be run non-interactively.
 
  There are various workarounds mentioned on various web pages.
  However, should we modify freebsd-update so that it can work better
  when not run via a real tty?  This would make it more devops/automation
  friendly.
 
  The closest thing I have found is freebsd-update cron, which can fetch
  the updates and run without a real tty.  The only problem with
  freebsd-update cron
  is that it sleeps a random amount of time between 1 and 3600 seconds
 before
  fetching the updates.  This is OK when run in a cron job,
  but not OK when run as part of a devops automation framework.
 
  Anybody have ideas as to the best way to proceed in fixing this in
  freebsd-update?
  --
  Craig
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to 
 freebsd-current-unsubscr...@freebsd.org
 

 I think this requirement was originally added when Colin hosted the
 mirrors for FreeBSD update himself, and was worried about everyone
 scripting it to run via crontab at midnight every night.

 It is likely a false requirement, and can be safely removed.

 Dealing with the merges, only really affects version upgrades, and is
 less of an issue compared to being able to automate security fixes.



Hi,

I submitted this review: https://reviews.freebsd.org/D1665
to remove the check for an interactive tty in freebsd-update fetch.

Being able to run freebsd-update fetch via automation will make it much
more
convenient to update clusters of FreeBSD nodes.

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

Devops question: freebsd-update needs a real tty to run, problem for automation

[Craig Rodrigues]

Hi,

Ahmed Kamal, a devops expert, is helping me to script the steps to
upgrade a cluster of FreeBSD machines.  For certain machines,
we want to track the official FreeBSD releases and use freebsd-update
to install official updates.

We found that when the invocation of freebsd-update was scripted
and not run via a real tty, we can into this error:

freebsd-update fetch should not be run non-interactively.

There are various workarounds mentioned on various web pages.
However, should we modify freebsd-update so that it can work better
when not run via a real tty?  This would make it more devops/automation
friendly.

The closest thing I have found is freebsd-update cron, which can fetch
the updates and run without a real tty.  The only problem with
freebsd-update cron
is that it sleeps a random amount of time between 1 and 3600 seconds before
fetching the updates.  This is OK when run in a cron job,
but not OK when run as part of a devops automation framework.

Anybody have ideas as to the best way to proceed in fixing this in
freebsd-update?
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Devops question: unattended installs of FreeBSD?

[Craig Rodrigues]

On Mon, Jan 12, 2015 at 12:12 PM, John Nielsen li...@jnielsen.net wrote:


 I'd be happy to provide more specific suggestions if needed. It really
 depends on how fully automated you want things to be and how much
 customization you want to include, as well as what you have available in
 the install environment. If you're installing on live VMs then you first
 have to get them booted. A custom ISO or MFS image is probably the simplest
 for that, though PXE is also an option. (Actually, serving an mfsBSD image
 via PXE is pretty straightforward.)


Thanks!  You provided some excellent concrete examples for how to do
unattended FreeBSD installs.

In the past 6 months, I have had two different people ask me how to:
- create a PXE boot server
- take the ISO image for FreeBSD 9.2, FreeBSD 10.1, etc.
- create a kickstart environment where it is possible to PXE boot a
cluster of machines, and
have an unattended kickstart install take place of the various
FreeBSD versions

I have coded this kind of stuff up myself in the past and written my own
scripts.
However, it would be really nice if we had more straightforward
documentation and example scripts for doing this.
That way, the average devops engineer experienced with Linux and kickstart
can set this up with no problem, instead of having to struggle and figure
things out.

It looks like all this stuff is possible under FreeBSD.  The main problem I
see is that the
access to the documentation for doing this is not straightforward at all.

If I do a web search for Linux kickstart, the search results I get lead
me to documentation
that is actually quite good.  I am not a Linux expert, but I can read that
stuff and figure out how to set it
up reasonably quickly.

If I do a web search for FreeBSD kickstart, the top search results I get
lead to a few broken
web links, and some private notes from different people on the Internet.
The notes are not bad,
but not as straightforward to follow as the Linux documentation links.

Since you have some good experience with this, can we create a thread on
https://forums.freebsd.org
with the title FreeBSD kickstart with some step-by-step examples for
creating a kickstart environment?

That way over time, a web search for FreeBSD kickstart will show the
forum post with top-notch examples.

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

Devops question: unattended installs of FreeBSD?

[Craig Rodrigues]

Hi,

I had a devops person who is familiar with setting up hundreds of
Linux nodes in cloud environment ask me what is the best way
to do unattended installs in a cloud environment.
Linux has kickstart installs, which are quite useful and popular.

What is the equivalent in FreeBSD?

In the sysinstall days, the sysinstall.cfg config file could be created
which drove large parts of the installer.  Now that sysinstall is gone,
what is the alternative?  Searching the web, I found two answers:

(1)  Write your own script
(2)  Use pc-sysinstall from the PC-BSD project
http://wiki.pcbsd.org/index.php/Creating_an_Automated_Installation_with_pc-sysinstall/10.0/en

I am trying to work with a devops team who is very experienced
with setting up Linux environments in the cloud.  Based on the available
docs,
it is not clear to non-FreeBSD experts how to accomplish similar things
with FreeBSD.

By the way, I would be very interested in hearing from people who have
experience
in installing, configuring, and upgrading hundreds or even thousands of
FreeBSD
nodes in devops and cloud environments.  For people who are not FreeBSD
experts,
but who are Linux devops experts, is it easy to do, or is there a lot of
custom scripts which need to be written?

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

Re: any primer on running bhyve guests sharing disk with host ?

[Craig Rodrigues]

On Sat, Jan 3, 2015 at 8:15 AM, Luigi Rizzo ri...@iet.unipi.it wrote:

 Hi,
 in order to do some kernel testing, I would like to run bhyve guests
 using (through NFS, probably) the host's file system.
 diskless(8) is probably one way to go, i was wondering if
 someone has instructions for that.
 Specifically:
 - how to bhyveload a kernel (rather than the full disk image);
   as an alternative, given a kernel, something to build an image
   that can be passed to bhyveload

 - how to pass the necessary config (rootpath) to the client
   without having to rely on a specialized dhcp server

 I used to be familiar with diskless configs, so i can probably sort
 out the server side myself.



I don't think there is a way to do exactly what you want.
I would recommend doing the following:

(1)  Enable bvmdebug in your kernel config:
https://wiki.freebsd.org/BHyVe/gdb
  This allows you to do kgdb remote debugging into a bhyve VM.
(2)  Build your disk image with makefs.  You can use this script as an
example:

https://github.com/freebsd/freebsd-ci/tree/master/scripts/build/build-ufs-image.sh

If you still want the bhyve image to use the host's root file system, you
can start with the information here:
https://www.freebsd.org/doc/handbook/network-diskless.html
since you won't be using PXE, you will need to populate these variables in
loader.conf in your disk image:

http://svnweb.freebsd.org/base/head/sys/nfs/nfs_diskless.c?revision=273174view=markup#l146

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

Re: Build failed in Jenkins: Build-UFS-image #688

[Craig Rodrigues]

On Tue, Dec 16, 2014 at 5:35 PM, Garrett Cooper yaneurab...@gmail.com
wrote:


 ...

  install -s -o root -g wheel -m 555   dialog 
 https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/bin/dialog
 
  install: spawn strip: No such file or directory
  *** Error code 71

 I need to add strip to ITOOLS in Makefile.inc [unless alfred or someone
 else beats me to it first], to fix this make installworld issue.
 Thanks!


If you know what the problem is, please fix it.  Alfred is busy with other
things these days.

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

Re: console screen saver broken? -current

[Craig Rodrigues]

On Thu, Dec 11, 2014 at 9:42 AM, Alfred Perlstein alf...@freebsd.org
wrote:

 Up until a few months ago the following added to /etc/rc.conf would blank
 the screen:

 # /etc/rc.conf
 saver=green
 allscreens_flags=-t 60

 Now that no longer works.

 Can someone explain how to restore the power saving screen saver please?



 - Put this in /boot/loader.conf to use the older syscons(4) console
driver by default and reboot:
   kern.vty=sc


This lists the missing functionality in the new vt(4) driver such as
screensaver:

https://wiki.freebsd.org/Newcons#Feature_Comparison_with_syscons.284.29

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

Call for Help: Setting up Saltstack for devops of jenkins.freebsd.org cluster

[Craig Rodrigues]

FYI,

https://lists.freebsd.org/pipermail/freebsd-testing/2014-December/000693.html

Please send follow-ups to freebsd-test...@freebsd.org .  Thanks.

--
Craig

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

Re: Jenkins build became unstable: FreeBSD_HEAD-tests2 #311

[Craig Rodrigues]

On Tue, Nov 25, 2014 at 11:21 PM, Craig Rodrigues rodr...@freebsd.org
wrote:

 On Tue, Nov 25, 2014 at 8:42 PM, Craig Rodrigues rodr...@freebsd.org
 wrote:
 
 
 
  On Mon, Nov 24, 2014 at 9:25 PM, jenkins-ad...@freebsd.org wrote:
 
  See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/311/
 
 
  I'm not sure why this test is failing.  The VM running these tests has
 845MB
  of disk space free on /tmp and /usr/tests so it is
  definitely not running out of space.
 
  The test failures started occurring around here:
 
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/1909/
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/1910/
 
  That was around when a lot of Makefile related changes for library
 linking
  whent in the tree.


 Looking at:
 https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/311/consoleFull

 I see:

 usr.sbin/etcupdate/tests_test:main  -  Nov 25 05:15:48  kernel: pid 19939
 (cp), uid 0 inumber 23569 on /: out of inodes
 broken: Caught unexpected exception: Tester failed with code 2; this is a
 bug  [6.863s]



Yes, that seems to be the problem:

 df -m -i /
Filesystem1M-blocks Used Avail Capacity iused ifree %iused  Mounted
on
/dev/ufs/TESTROOT  2041 1027   85055%   23303  1015   96%   /


So there is enough disk space to run the tests,
but not enough inodes.  I'm creating the VM with makefs.
It looks like makefs creates disk images
with lower number of inodes than newfs.

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

Re: Jenkins build became unstable: FreeBSD_HEAD-tests2 #311

[Craig Rodrigues]

On Mon, Nov 24, 2014 at 9:25 PM, jenkins-ad...@freebsd.org wrote:

 See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/311/


I'm not sure why this test is failing.  The VM running these tests has 845MB
of disk space free on /tmp and /usr/tests so it is
definitely not running out of space.

The test failures started occurring around here:

https://jenkins.freebsd.org/job/FreeBSD_HEAD/1909/
https://jenkins.freebsd.org/job/FreeBSD_HEAD/1910/

That was around when a lot of Makefile related changes for library linking
whent in the tree.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Jenkins build became unstable: FreeBSD_HEAD-tests2 #311

[Craig Rodrigues]

On Tue, Nov 25, 2014 at 8:42 PM, Craig Rodrigues rodr...@freebsd.org
wrote:



 On Mon, Nov 24, 2014 at 9:25 PM, jenkins-ad...@freebsd.org wrote:

 See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/311/


 I'm not sure why this test is failing.  The VM running these tests has
845MB
 of disk space free on /tmp and /usr/tests so it is
 definitely not running out of space.

 The test failures started occurring around here:

 https://jenkins.freebsd.org/job/FreeBSD_HEAD/1909/
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/1910/

 That was around when a lot of Makefile related changes for library linking
 whent in the tree.


Looking at:
https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/311/consoleFull

I see:

usr.sbin/etcupdate/tests_test:main  -  Nov 25 05:15:48  kernel: pid 19939
(cp), uid 0 inumber 23569 on /: out of inodes
broken: Caught unexpected exception: Tester failed with code 2; this is a
bug  [6.863s]


--

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

Call for Help: Flame Graphs and Continuous Integration

[Craig Rodrigues]

FYI:

https://lists.freebsd.org/pipermail/freebsd-testing/2014-November/000667.html

Please send follow-ups to freebsd-test...@freebsd.org

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

Call for Help: openjdk8 tests under Continuous Integration

[Craig Rodrigues]

FYI,

https://lists.freebsd.org/pipermail/freebsd-testing/2014-November/000668.html

Please send followups to freebsd-test...@freebsd.org.

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

Re: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161

[Craig Rodrigues]

On Fri, Oct 31, 2014 at 10:04 AM, jenkins-ad...@freebsd.org wrote:

 See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/161/


Mateusz,

Can you take a look at:
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/

The last successful pass was GRN r273871.  I'm not sure, but you made a
bunch of commits
under /usr/src/sys/kern at about the time when things started failing.

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

Re: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161

[Craig Rodrigues]

On Oct 31, 2014 7:01 PM, Mateusz Guzik mjgu...@gmail.com wrote:

 There was a regression after commits related to new random code which
 resulted in /dev/md0 being created and mounted to /var.

 Looks like the test in question assumes it always gets /dev/md0.

 The test works for me not what the regression is fixed. I guess jenkins
 didn't catch up to it yet.

Thanks for the analysis.  Looks like things are OK as of
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/164/ .

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

Re: junior kernel tasks

[Craig Rodrigues]

On Sat, Oct 25, 2014 at 1:45 PM, Mateusz Guzik mjgu...@gmail.com wrote:

 Hello,

 In short, nice kernel tasks people with C language skills can do in few
 evenings.

 https://wiki.freebsd.org/JuniorJobs


Thanks for making that list.  I was looking at some other projects,
and noticed that on the front page of http://www.dragonflybsd.org/ ,
they have a Now Hiring section with multiple links to
Code Bounties, Summer of Code, etc., to help attract new people to the
project.

We need something like that on the front page of freebsd.org, to
help attract new blood to the project.  We have all the info,
but it is just scattered across many different web pages,
and is often outdated and not maintained.

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

Jenkins, Kyua, and Bhyve used for FreeBSD OS testing

[Craig Rodrigues]

Hi,

FYI, Kohsuke Kawaguchi, the lead developer of Jenkins,
accepted my posting on the Jenkins blog, which describes
how the FreeBSD project is using Jenkins, Kyua, and Bhyve
for FreeBSD OS testing:

http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testing

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

Re: Jenkins, Kyua, and Bhyve used for FreeBSD OS testing

[Craig Rodrigues]

Hi,

Thanks for those kind words, Alfred!  I would like to point out a few
things.

(1)  Jenkins team are really easy to work with, and I've been pushing fixes
upstream to them, such as:
https://github.com/jenkinsci/jenkins/pull/1387 which fixes shared
library support on FreeBSD, Windows, Linux/ARM, Linux/PPC.

   Jenkins has something called the Jenkins Pull Request builder, so
that when you submit a patch to them
   via a Github Pull Request, it checks out the Jenkins source, patches
it, builds it, and runs automated tests.
   This helps the Jenkins team to decide whether to pull in a patch or
not.
It's quick, easy, works welland honestly, makes working
with an open source project fun!

Unfortunately, working with FreeBSD can seem to be antiquated and a
drudgery in comparison, but things
are improving with things like Phabricator and Bugzilla.

(2)  By fixing up the unit tests and paying attention to failures, I've
found real problems that need to be fixed.
   The yacc unit tests started failing after recent imports of byacc.
I traced down the problem,
   and reported it upstream to Thomas Dickey who maintains byacc.  He
fixed the problem
   (see http://invisible-island.net/byacc/CHANGES 2014-10-05 and
2014-10-06) and I confirmed
   that fixed the unit tests.  We have the fixed byacc in HEAD and
stable/10 branches.

Although I've got the ball rolling, hopefully more people in the FreeBSD
community
can help out by writing tests, paying attention to test failures, helping
out with devops issues related to
Jenkins, etc.  For folks interested, hop on freebsd-test...@freebsd.org and
help pitch in!

--
Craig



On Mon, Oct 20, 2014 at 9:56 PM, Alfred Perlstein bri...@mu.org wrote:

 Craig this is really great.  Thanks for doing this and thanks for the
 Jenkins guys on giving a shout out!

 On Oct 20, 2014, at 9:42 AM, Craig Rodrigues wrote:

  Hi,
 
  FYI, Kohsuke Kawaguchi, the lead developer of Jenkins,
  accepted my posting on the Jenkins blog, which describes
  how the FreeBSD project is using Jenkins, Kyua, and Bhyve
  for FreeBSD OS testing:
 
  http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testing
 
  --
  Craig


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

Voxer using FreeBSD, BSDNow.tv interview

[Craig Rodrigues]

Hi,

If you don't watch BSDNow.tv ( http://bsdnow.tv ), I encourage you to do so.
Allan Jude and Kris Moore do a great job of doing a weekly video podcast
of news in the BSD world.  It is great stuff.

In episode 58 ( http://www.bsdnow.tv/episodes/2014_10_08-behind_the_masq )
BSDNow interviewed the CTO of Voxer ( http://voxer.com ),
a mobile messaging startup based in San Francisco.

Voxer mentioned how they transitioned from SmartOS (an Illumos/Solaris
distribution) to FreeBSD.

What Voxer liked:
 (1)  DTrace worked for their node.js apps
 (2)  ZFS worked nicely
 (3)  jails work nicely
 (4)  Easy to transition away from SmartOS/Illumos because of (1) and
(2)
 (5)  Better support for 3rd party applications (ports) than
SmartOS/Illumos
 (6)  Better hardware support than SmartOS/Illumos
 (7)  Good documentation, professional/technical discussions on mailing
lists
 (8)  For people who use MacOS X, the FreeBSD command-line utilities
were familiar

What Voxer didn't like:
 Voxer was super positive about FreeBSD in the interview, and didn't
really
 mention many downsides to their transition.  The only things I could
pick up on:

 (1)  Support for FreeBSD in Chef was not as good as they would have
liked.
   They actually have patches to Chef
for FreeBSD which they want to upstream.
 (2)  Most devops engineers in web/mobile companies are familiar with
Linux.  Any differences between Linux and FreeBSD in
command-line
utilities are not show-stoppers, but they are annoyances.
Anything FreeBSD could do to help people used to Linux would be
a big
help.  Allan Jude even brought up my request to symlink
/bin/bash (
https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095483.html
) :)

The interview was really good, and I encourage everyone to watch it.
It's nice to see a modern web/mobile company migrating *to* FreeBSD.

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

Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?

[Craig Rodrigues]

On Fri, Aug 15, 2014 at 12:01 PM, Craig Rodrigues rodr...@freebsd.org
wrote:

 On Wed, Aug 13, 2014 at 6:34 PM, Russell L. Carter rcar...@pinyon.org
 wrote:

 One complaint I have about the FreeBSD project, is that the core
 project contributors and developers rely too much on
 e-mail for communication.  This certainly works, and I use it too, but
 new and casual users getting into FreeBSD
 may get lost in the maze of FreeBSD mailing lists.  It would be nice
 if more of the core project contributors
 used the web forums ( http://forums.freebsd.org ), since stuff like
 that shows up nicely in web searches, and it is easier
 for newcomers to find stuff, and jump in and contribute to threads,
 versus mailing lists.



I just noticed this:
https://forums.freebsd.org/threads/new-forums-software-online.48495/
The FreeBSD Forums Administration team just upgraded the forum software
from phpBB to Xenforo.
They migrated 260,000 messages..wow, this is a huge achievement!

Xenforo is nice stuff, so hopefully more FreeBSD core developers can take
advantage of the
forums, in addition to the traditional mailing lists.

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

Re: BAFUG Oct 9: Kyua and jenkins testing framework

[Craig Rodrigues]

On Sat, Oct 4, 2014 at 6:10 PM, Craig Rodrigues rodr...@freebsd.org wrote:

 Hi,

 On October 9, 2014, in Mountain View, California, I will be giving a brief
 tech tech on:

 Kyua and Jenkins: Testing Framework for BSD

 Here are more details on the tak, plus directions to the location:

 http://www.meetup.com/BAFUG-Bay-Area-FreeBSD-User-Group/events/209548642/



Hi,

Slides from my talk are available online:

http://www.slideshare.net/CraigRodrigues1/kyua-jenkins

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

Kyua quickstart guide

[Craig Rodrigues]

Hi,

I've started writing a Kyua Quickstart guide, which hopefully help
peopel get started with kyua and writing tests:

https://github.com/rodrigc/kyua/wiki/Quickstart-Guide

Please review the document and provide feedback.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Need help fixing tests in CURRENT

[Craig Rodrigues]

Hi,

After committing this fix to yacc in HEAD (
https://lists.freebsd.org/pipermail/svn-src-all/2014-October/092553.html )
I've been able to do:  cd /usr/tests; kyua test

and get 0 test failures:

https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/16/testReport/

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

Automatically running /usr/tests under Jenkins

[Craig Rodrigues]

Hi,

I have created this Jenkins job:

https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1577/BuildGraph/

(1)  does a buildworld/buildkernel on amd64 when someone checks new
  code into CURRENT
(2)  Creates a bootable UFS image with makefs
(3)  Boots the image under bhyve
(4)  Runs these commands inside the bhyve VM:

  cd /usr/tests
  kyua test
  kyua report-junit --output=test-output.xml

(5)  Shuts down the bhyve VM
(6)  imports test-output.xml into Jenkins.


Hopefully we will be able to run this job very frequently,
so the tests will be run every time new commits hit the tree.

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

Re: Need help fixing tests in CURRENT

[Craig Rodrigues]

On Tue, Oct 7, 2014 at 4:30 PM, NGie Cooper yaneurab...@gmail.com wrote:

 On Tue, Oct 7, 2014 at 2:04 PM, Craig Rodrigues rodr...@freebsd.org
 wrote:
  Hi,
 
  After committing this fix to yacc in HEAD (
  https://lists.freebsd.org/pipermail/svn-src-all/2014-October/092553.html
 )
  I've been able to do:  cd /usr/tests; kyua test
 
  and get 0 test failures:
 
 
 https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/16/testReport/

 Awesome -- hopefully this will be sustained for several runs (this
 is part of the reason why I haven't integrated all of the NetBSD tests
 yet).
 Thank you for all your work in getting us to green!


For any type of test framework, if the tests aren't run regularly
and reported in an easy to understand manner,
then the tests will bitrot and people will ignore them.

I've seen this happen in multiple companies I have worked at.

Hopefully we can do better with FreeBSD, and foster a community
of people who are actively updating the tests, and taking test failures
seriously.

If we don't do this, then people will just ignore the tests.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Need help debugging yacc test failure in CURRENT

[Craig Rodrigues]

On Thu, Oct 2, 2014 at 2:23 AM, Craig Rodrigues rodr...@freebsd.org wrote:

 Hi,

 I have managed to eliminate all the test failures from /usr/tests in
 CURRENT
 except for one failure.  See:

 https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/8/testReport/

 I can reproduce the failure by doing the following:

 mkdir /tmp/x
 cd /tmp/x
 /usr/tests/usr.bin/yacc/yacc_tests  usr.bin.yacc.yacc_tests.main

 I then get a core file: /tmp/x/test/yacc.core



Thomas E. Dickey submitted a patch which fixes the test.  I committed the
patch:

http://lists.freebsd.org/pipermail/svn-src-all/2014-October/092553.html

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

BAFUG Oct 9: Kyua and jenkins testing framework

[Craig Rodrigues]

Hi,

On October 9, 2014, in Mountain View, California, I will be giving a brief
tech tech on:

Kyua and Jenkins: Testing Framework for BSD

Here are more details on the tak, plus directions to the location:

http://www.meetup.com/BAFUG-Bay-Area-FreeBSD-User-Group/events/209548642/

Feel free to sign up on the meetup site and attend if you are in the area,
so that the organizers can get a big enough room.

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

Jenkins and LLVM clang analyzer on FreeBSD

[Craig Rodrigues]

Hi,

FYI, Li-Wen Hsu lw...@freebsd.org has set up this Jenkins job which
builds FreeBSD
with the clang analyzer (
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-scan-build/ ):

https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-scan-build/

This job runs once a week.  Please view the results of this job, and provide
feedback to:  freebsd-test...@freebsd.org.

Also, if you can see any bugs in FreeBSD identified by this tool,
please feel free to submit patches to fix them! :)

Thank you Li-Wen, for setting this up!!
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

FreeBSD laptop compatibility list web page?

[Craig Rodrigues]

Hi,

I e-mailed Lukas Ertl l.e...@univie.ac about
the FreeBSD Laptop compatibility list web page
which used to be at:  http://laptop.bsdgroup.de/freebsd/
but got no response.

That was a really nice web page, and it is a shame it is no longer
accessible.  Does anyone know if the content has been moved
elsewhere?  There are some archives of it here:
http://archive.today/laptop.bsdgroup.de

It would be nice to get the content of that page and move it
somewhere more permanent, maybe to the PC-BSD or FreeBSD wiki pages.

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

Need help debugging yacc test failure in CURRENT

[Craig Rodrigues]

Hi,

I have managed to eliminate all the test failures from /usr/tests in CURRENT
except for one failure.  See:

https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/8/testReport/

I can reproduce the failure by doing the following:

mkdir /tmp/x
cd /tmp/x
/usr/tests/usr.bin/yacc/yacc_tests  usr.bin.yacc.yacc_tests.main

I then get a core file: /tmp/x/test/yacc.core

Can someone help debug and fix this?

Thanks.

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

Re: shells/bash port, add a knob which symlinks to /bin/bash ?

[Craig Rodrigues]

On Sun, Sep 14, 2014 at 10:44 AM, Alfred Perlstein bri...@mu.org wrote:


 On 9/13/14, 11:39 AM, Nathan Whitehorn wrote:

 Should really be a standalone package.


It's not exactly the same, but the lang/python2 port for example is a
meta-port which creates
symlinks such as  /usr/local/bin/python2 - python2.7.

So the precedent of having a metaport which creates symlinks is there.
What folks  have been complaining about in this thread is having symlinks
in the base system directories such as /bin.

My personal feeling is that we should look at this on a case-by-case basis
and allow these types
of ports, such as for /bin/bash but I'm sure others will disagree.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: shells/bash port, add a knob which symlinks to /bin/bash ?

[Craig Rodrigues]

On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery bdrew...@freebsd.org wrote:


 There's no reason for bash (and perl) to be exceptions to the 24000
 other ports that install to /usr/local/bin. I can think of dozens of
 other ports that will fall into the same arguments being made here, but
 it does not mean it is the right thing for FreeBSD.

 If you want to install the symlink on your system feel free to do it. I
 install a static bash to /bin/bash on mine and only because I prefer
 bash shell and want it in / for single-user mode. That's my personal
 choice though.

 The proper fix is to fix scripts to be portable and use #! /usr/bin/env
 bash rather than /bin/bash.


Technically, I agree with you that people should write portable shell
scripts,
and use #!/usr/bin/env bash rather than #!/bin/bash.

Pushing that behavior upstream is not always practical these days, where
FreeBSD is in the minority, while Linux and MacOS X are in the vast
majority of where
people are doing development and learning how to write shell scripts these
days.

The /bin/bash thing is relatively minor, but I brought it up, because I see
it so much.
I've seen it in the jobs that I've worked at.  I've also seen it when
dealing with Google
Summer of Code students.  I've seen it in blogs mentioned when Linux users
evaluate FreeBSD.
I've seen it when people design appliances based on FreeBSD, but want the
device to be
familiar enough for Linux-y devops people to interact with it.

If there are minor things that we can do in FreeBSD to improve the
out-of-box experience
of FreeBSD to new users who may be used to Linux or MacOS X, that would be
great.
Telling people to change their shell scripts, or manually create symlinks
to /bin/bash is doable,
but why not have something in the system do this automatically, so that the
average end-user does
not even have to think about it?

If adding an optional knob to the bash port which is OFF by default to do
this is a no-go,
would having an optional port like what Brooks Davis mentioned be allowed
which creates
the symlink and updates /etc/shells?

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

shells/bash port, add a knob which symlinks to /bin/bash ?

[Craig Rodrigues]

Hi,

In the last 3 jobs that I have worked at, there have been
a mix of Linux machines and FreeBSD machines.
When using an NIS or LDAP environment where
there is a single login across multiple machines, it is useful to
have a single shell setting.

Since Linux and MacOS X have /bin/bash as the shell,
in order to get the FreeBSD boxes to play in this environment,
I have seen admins do the following on FreeBSD setups:
   ln -s /usr/local/bin/bash /bin/bash

or

   ln /usr/local/bin/bash /bin/bash

and then make sure that /etc/shells as:
/usr/local/bin/bash
/bin/bash

Can we add an optional knob (turned off by default) which creates this
symlink
and updates /etc/shells?

This would help with interoperability of FreeBSD hosts in environments mixed
with Linux and MacOS X.

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

Re: shells/bash port, add a knob which symlinks to /bin/bash ?

[Craig Rodrigues]

Hi,

I could live with this solution of additional port outside of the main
bash port, which creates the symlink and updates /etc/shells.

One other thing I am seeing is that many, many shell scripts are written
assuming #!/bin/bash.
Forcing all upstream script writers to switch to #!/usr/bin/env bash, or
to convert their scripts to #!/bin/sh and remove all bash-specific
behaviors, is getting harder and harder,
since many people are exposed to MacOS X and Linux on desktops.

--
Craig



On Fri, Sep 12, 2014 at 3:02 PM, Alfred Perlstein bri...@mu.org wrote:

 The correct thing is to make a port/pkg that installs the symlink and
 /etc/shells this for the user.

 There is no need for changes to 'base' nor do we need a change to the
 system port.

 -Alfred


 On 9/12/14 2:40 PM, Baptiste Daroussin wrote:

 On Fri, Sep 12, 2014 at 02:12:45PM -0700, Craig Rodrigues wrote:

 Hi,

 In the last 3 jobs that I have worked at, there have been
 a mix of Linux machines and FreeBSD machines.
 When using an NIS or LDAP environment where
 there is a single login across multiple machines, it is useful to
 have a single shell setting.

 Since Linux and MacOS X have /bin/bash as the shell,
 in order to get the FreeBSD boxes to play in this environment,
 I have seen admins do the following on FreeBSD setups:
 ln -s /usr/local/bin/bash /bin/bash

 or

 ln /usr/local/bin/bash /bin/bash

 and then make sure that /etc/shells as:
 /usr/local/bin/bash
 /bin/bash

 Can we add an optional knob (turned off by default) which creates this
 symlink
 and updates /etc/shells?

 This would help with interoperability of FreeBSD hosts in environments
 mixed
 with Linux and MacOS X.

  Please no, no and no!

 We are fighting for a very long time to prevent the ports to pollute base.

 We have added the shebangfix USES to be able to catch with up with
 cleanup this
 properly as well as a qa test to discover it automatically.

 no interpreters at all have a symlink in base but perl and this one is
 going to
 be removed.

 If you want interoperability just use /usr/bin/env bash as a shebang. Btw
 you
 cannot get interoprability with OS-X in there because the bash they do
 provide
 is the last GPL-2 recent bash have many incompatiblities with this old
 version.

 regards,
 Bapt


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

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

Need help fixing tests in CURRENT

[Craig Rodrigues]

Hi,

Based on feedback from Garrett, it looks like there were some
problems in kyua, causing test failures.  I patched my local
copy of the kyua port:

https://github.com/rodrigc/kyua-port/

and re-ran the tests:

cd /usr/tests
kyua test
kyua report
kyua report-html
kyua report-junit


https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastCompletedBuild/testReport/

There are still 7 test failures which I don't understand.

Can someone help fix these?

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

Need help fixing tests in CURRENT

[Craig Rodrigues]

Hi,

I did a buildworld/installworld of current in a bhyve VM, and then did the
following.

pkg install devel/kyua
cd /usr/tests
kyua test
kyua report
kyua report-html
kyua report-junit

I then published the results in Jenkins:

The results are here:

https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastCompletedBuild/testReport/

There seem to be 31 test failures.  Can folks look into those
and see if the tests need to be fixed

Right now I ran these steps manually, but hopefully over time
we can automate more of this stuff.

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

Re: Need help fixing tests in CURRENT

[Craig Rodrigues]

On Tue, Sep 9, 2014 at 10:11 AM, Allan Jude allanj...@freebsd.org wrote:

 
 
 https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastCompletedBuild/testReport/
 
 Most of the errors (jot, m4, sed, etc) seems to be:

 kyua-tap-tester: Configuration variables not supported; ignoring
 'has.cleanup=false'
 kyua-tap-tester: Configuration variables not supported; ignoring
 'unprivileged-user=tests'

 while everything else about the test was successful.


Configuration variables not supported is a behavior of kyua.  I filed
an issue for it here: https://github.com/jmmv/kyua/issues/104

I'm not sure if that is the source of the test failures.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: make -DNO_ROOT to create chroot, problem installing into chroot with pkg

[Craig Rodrigues]

On Mon, Sep 8, 2014 at 8:48 AM, Brooks Davis bro...@freebsd.org wrote:


 If you don't mind the ownership being wrong and there being a few extra
 +FOO files tar works.  It would be great for someone to teach package to
 install without root and to update a METALOG file.  That's not 100% of
 the solution, but it's a solid 80-90% solution.


I've opened this feature request against pkg:

https://github.com/freebsd/pkg/issues/1002

Please add any comments/suggestions there, since you have very valuable
input.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

make -DNO_ROOT to create chroot, problem installing into chroot with pkg

[Craig Rodrigues]

Hi,

I am using pkg 1.3.7.

I did the following as a regular user, not root:

rm -fr /tmp/package
cd /usr/src
make buildworld
make buildkernel
make  -DNO_ROOT -DDB_FROM_SRC  installworld DESTDIR=/tmp/package
make  -DNO_ROOT -DDB_FROM_SRC  installkernel DESTDIR=/tmp/package
make  -DNO_ROOT -DDB_FROM_SRC  distribution DESTDIR=/tmp/package

This created an installed world under /tmp/package

Then I did:

pkg -c /tmp/package install -y devel/kyua

I got:

pkg: chroot failed!

Then I tried the same command under sudo:

sudo pkg -c /tmp/package install -y devel/kyua

I got:

pkg: /var/db/pkg wrong user or group ownership (expected 0/0 versus actual
818/0)

Is there a way to install packages into chroot without
being root?

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

Re: ddb_enable=YES by default?

[Craig Rodrigues]

On Fri, Sep 5, 2014 at 7:54 AM, John Baldwin j...@freebsd.org wrote:

 Probably at least 50% of the time when I work with a user on a bug report,
 I ask them to go into kgdb and run specific commands to extract more detailed
 info (print some struct, etc.).

Sure, I understand, but you are not working with every user who
encounters a kernel panic in FreeBSD.  For the average or casual
FreeBSD user, such as desktop
users of FreeBSD or PC-BSD, wouldn't it be better
to have ddb_enable=YES be the default in FreeBSD?  The ddb script
there does a fairly reasonable
job of gathering some useful info which can be analyzed later, and
then rebooting the box.

For more expert users, or people developing products, they can set
ddb_enable=NO
and do more advanced debugging.  Or hook into /etc/rc.d/ddb and define
a different
ddb script which doesn't do textdumps on kernel panic.

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

ddb_enable=YES by default?

[Craig Rodrigues]

Brooks,

In r178450, you set the default of ddb_enable to NO:


r178450 | brooks | 2008-04-23 15:40:59 -0700 (Wed, 23 Apr 2008) | 4 lines
Changed paths:
   M /head/etc/defaults/rc.conf

Revert rev 1.332 and keep ddb scripts off by default for now.  Minidumps
are more flexable and much text-dump like output can be produced from
them so there's a good argument they are a better default.

Index: head/etc/defaults/rc.conf
===
--- head/etc/defaults/rc.conf(revision 178449)
+++ head/etc/defaults/rc.conf(revision 178450)
@@ -33,7 +33,7 @@
 apm_enable=NO# Set to YES to enable APM BIOS functions (or NO).
 apmd_enable=NO# Run apmd to handle APM event from userland.
 apmd_flags=# Flags to apmd (if enabled).
-ddb_enable=YES# Load ddb scripts at boot.
+ddb_enable=NO# Set to YES to load ddb scripts at boot.
 ddb_config=/etc/ddb.conf# ddb(8) config file.
 devd_enable=YES # Run devd, to trigger programs on device tree changes.
 devd_flags=# Additional flags for devd(8).



Do you think this is OK to enable by default now?
Developers who know what they are doing can turn it off in /etc/rc.conf.

For the average end-user, this is super useful, because
it loads the ddb rules in /etc/ddb.conf, which do
useful things like enable textdumps, show all the locks, show all the
locked vnodes,
and reboots the box.

This will allow end-users who have a problem in the field with FreeBSD,
and are not kernel debugging experts, to get a lot of useful diagnostic
info that can be reported back to developers on the mailing lists.

Right now, a lot of times, people take camera pictures of their screen at the
ddb prompt.  That's pretty painful. :)

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

Modify bsdinstall to set the default locale?

[Craig Rodrigues]

Hi,

I recently did a fresh install of FreeBSD-10.stable on a new machine.

If I run the 'locale', I get this:

LANG=
LC_CTYPE=C
LC_COLLATE=C
LC_TIME=C
LC_NUMERIC=C
LC_MONETARY=C
LC_MESSAGES=C
LC_ALL=

Can we add something to bsdinstall/bsdconfig for setting the default locale?

We already have stuff in the installer for setting the keyboard and timezone.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Modify bsdinstall to set the default locale?

[Craig Rodrigues]

On Sun, Aug 31, 2014 at 9:41 AM, Allan Jude allanj...@freebsd.org wrote:
 On 2014-08-31 12:36, Craig Rodrigues wrote:

 That would seem to make sense. Where do these settings actually get
 stored? Where would I find a list of the possible settings to create the
 dialog?

 I've never tried to use any of the alternative locales

 --
 Allan Jude


See:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/using-localization.html

The locale gets set by setting certain environment variables.

I don't have a PC-BSD system handy, but I think on PC-BSD, some files
like /etc/login.conf  , /etc/csh.cshrc,
or /etc/profile are modified with the default locale information.
Maybe bsdinstall should do something similar.

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

Re: make installworld commands used to generate manifest for makefs?

[Craig Rodrigues]

On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis bro...@freebsd.org wrote:
 On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote:
 Hi,

 Is there an easy way to take most of the commands performed
 during make installworld and create a manifest file
 which is compatible with makefs?

 make -DNO_ROOT -DDB_FROM_SRC DESTDIR=foo installworld

 should result in a foo/METALOG file suitable for passing to makefs.
 You may also want the distribution target if you want a populated /etc.

 -- Broks

Thanks, that's useful info!
I did this:

make -DDB_FROM_SRC -DNO_ROOT installkernel DESTDIR=/tmp/test4
make -DDB_FROM_SRC -DNO_ROOT installworld DESTDIR=/tmp/test4
make -DDB_FROM_SRC -DNO_ROOT distribution DESTDIR=/tmp/test4

/tmp/test4/METALOG was created, but it did not seem to have
/boot/kernel/kernel or
any kernel modules.  Is that expected?

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

Re: make installworld commands used to generate manifest for makefs?

[Craig Rodrigues]

On Mon, Aug 25, 2014 at 9:55 AM, Brooks Davis bro...@freebsd.org wrote:
 On Sun, Aug 24, 2014 at 04:10:21PM -0700, Craig Rodrigues wrote:
 Hi,

 Is there an easy way to take most of the commands performed
 during make installworld and create a manifest file
 which is compatible with makefs?

 make -DNO_ROOT -DDB_FROM_SRC DESTDIR=foo installworld

 should result in a foo/METALOG file suitable for passing to makefs.
 You may also want the distribution target if you want a populated /etc.

 -- Broks

Hi,

I got this:


# make -DNO_ROOT -DDB_FROM_SRC DESTDIR=/tmp installworld
mkdir -p /tmp/install.hEJfJDhM
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown  date echo
egrep find grep id install   ln lockf make mkdir mtree mv pwd_mkdb  rm
sed services_mkdb sh sysctl test true uname wc zic tzsetup  ; do  if
progpath=`which $prog`; then  echo $progpath;  else  echo Required
tool $prog not found in PATH. 2;  exit 1;  fi;  done);  libs=$(ldd
-f %o %p\n -f %o %p\n $progs 2/dev/null | sort -u |  while read
line; do  set -- $line;  if [ $2 $3 != not found ]; then  echo $2;
 else  echo Required library $1 not found. 2;  exit 1;  fi;
done);  cp $libs $progs /tmp/install.hEJfJDhM
cp -R ${PATH_LOCALE:-/usr/share/locale} /tmp/install.hEJfJDhM/locale
echo #mtree 2.0  /tmp//METALOG
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64
MACHINE=amd64 CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.hEJfJDhM
 LD_LIBRARY_PATH=/tmp/install.hEJfJDhM
PATH_LOCALE=/tmp/install.hEJfJDhM/locale make -DWITH_ATF -f
Makefile.inc1  INSTALL=install -N /usr/src/etc -U -M /tmp//METALOG -D
/tmp MTREE_CMD=mtree -N /usr/src/etc -W
__MAKE_SHELL=/tmp/install.hEJfJDhM/sh -DNO_ROOT METALOG=/tmp//METALOG
reinstall;  MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.hEJfJDhM
 LD_LIBRARY_PATH=/tmp/install.hEJfJDhM
PATH_LOCALE=/tmp/install.hEJfJDhM/locale rm -rf /tmp/install.hEJfJDhM
make[2]: /usr/src/share/mk/bsd.compiler.mk line 37: Unable to
determine compiler type for cc.  Consider setting COMPILER_TYPE.
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org