NanoBSD install phase failing for releng/11

[Guido Falsi]

Hi,

While building a NanoBSD image using releng/11 sources I got this error
message:

===> lib/libc++ (install)
install  -C -o root -g wheel -m 444   libc++.a
/usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/
install  -s -o root -g wheel -m 444 libc++.so.1
/usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/
install  -S -C -o root -g wheel -m 444   libc++.ld
/usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libc++.so
===> lib/libcxxrt (install)
install  -C -o root -g wheel -m 444   libcxxrt.a
/usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/
install  -s -o root -g wheel -m 444 libcxxrt.so.1
/usr/local/nanobsd/rr-trunk/obj/_.w/lib/
install -l rs  /usr/local/nanobsd/rr-trunk/obj/_.w/lib/libcxxrt.so.1
/usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libcxxrt.so
install: symlink ../../lib/libcxxrt.so.1 ->
/usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib: File exists
*** Error code 71

Stop.

I'm not sure what's happening, I already tried reverting locally
r301880, thinking it could be related, but this changed nothing.

Anyone has some insight? It was working fine up to August 4th.

Thanks in advance to anyone giving me some hint!

-- 
Guido Falsi 
___
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: rpi-b leds

[Andrey Fesenko]

On Mon, Aug 22, 2016 at 1:29 PM, Daniel Braniss  wrote:
> Hi,
> I see that now both leds on the rpi-2 are operational,
> any chance it can happen on the rpi-b too?
>

A year or two ago, rpi-b had operational leds, it's make not working
after rework fdt/std layer
___
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] New version of webcamd, now v4.8.0.2

[Oleg Nauman]

On Fri, Aug 19, 2016 at 4:01 PM, Hans Petter Selasky 
wrote:

> Hi,
>
> If you are using webcamd, please help test the latest version which
> includes the most recent Linux v4.8-rc1 media tree sources.
>

Works fine with USB2.0 HD UVC WebCam Chicony Electronics Co. Ltd webcam,
tested as video device in skype.
Hardware is ASUS X552C laptop

Thank you.



>
> The latest webcamd port is available from here:
>
> svn --username anonsvn --password anonsvn \
>   checkout svn://svn.turbocat.net/i4b/trunk/ports/multimedia/webcamd
>
> Please test and report any regression issues to me or
> freebsd-multime...@freebsd.org
>
> Changes:
> - updated all Linux kernel sources to the latest Linux' Torvalds
> - fixed some minor bugs in the webcamd Linux kernel emulation
> - improved Linux kernel emulation support
> - added support for the coming evdev kernel module (GSOC project)
>
> Related work:
> https://reviews.freebsd.org/D6998
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678
>
> --HPS
> ___
> 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"
>
___
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: NanoBSD install phase failing for releng/11

[Shawn Webb]

On Mon, Aug 22, 2016 at 01:08:11PM +0200, Guido Falsi wrote:
> Hi,
> 
> While building a NanoBSD image using releng/11 sources I got this error
> message:
> 
> ===> lib/libc++ (install)
> install  -C -o root -g wheel -m 444   libc++.a
> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/
> install  -s -o root -g wheel -m 444 libc++.so.1
> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/
> install  -S -C -o root -g wheel -m 444   libc++.ld
> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libc++.so
> ===> lib/libcxxrt (install)
> install  -C -o root -g wheel -m 444   libcxxrt.a
> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/
> install  -s -o root -g wheel -m 444 libcxxrt.so.1
> /usr/local/nanobsd/rr-trunk/obj/_.w/lib/
> install -l rs  /usr/local/nanobsd/rr-trunk/obj/_.w/lib/libcxxrt.so.1
> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libcxxrt.so
> install: symlink ../../lib/libcxxrt.so.1 ->
> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib: File exists
> *** Error code 71
> 
> Stop.
> 
> I'm not sure what's happening, I already tried reverting locally
> r301880, thinking it could be related, but this changed nothing.
> 
> Anyone has some insight? It was working fine up to August 4th.
> 
> Thanks in advance to anyone giving me some hint!

I've been getting this simply in installworld outside the context of
nanobsd. I've got a 12-CURRENT host doing an installworld of an
11-STABLE src tree to a chroot directory.

Here's the log (granted, -s was added to make): http://ix.io/1fN3

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: NanoBSD install phase failing for releng/11

[Warner Losh]

Yea, this isn't nanobsd specific. Adrian was complaining about it as well
causing multiple entries in METALOG.

Does this happen with any of the embedded images we have in the tree
now as examples? I imagine it would..

Warner

On Mon, Aug 22, 2016 at 7:35 AM, Shawn Webb  wrote:
> On Mon, Aug 22, 2016 at 01:08:11PM +0200, Guido Falsi wrote:
>> Hi,
>>
>> While building a NanoBSD image using releng/11 sources I got this error
>> message:
>>
>> ===> lib/libc++ (install)
>> install  -C -o root -g wheel -m 444   libc++.a
>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/
>> install  -s -o root -g wheel -m 444 libc++.so.1
>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/
>> install  -S -C -o root -g wheel -m 444   libc++.ld
>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libc++.so
>> ===> lib/libcxxrt (install)
>> install  -C -o root -g wheel -m 444   libcxxrt.a
>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/
>> install  -s -o root -g wheel -m 444 libcxxrt.so.1
>> /usr/local/nanobsd/rr-trunk/obj/_.w/lib/
>> install -l rs  /usr/local/nanobsd/rr-trunk/obj/_.w/lib/libcxxrt.so.1
>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libcxxrt.so
>> install: symlink ../../lib/libcxxrt.so.1 ->
>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib: File exists
>> *** Error code 71
>>
>> Stop.
>>
>> I'm not sure what's happening, I already tried reverting locally
>> r301880, thinking it could be related, but this changed nothing.
>>
>> Anyone has some insight? It was working fine up to August 4th.
>>
>> Thanks in advance to anyone giving me some hint!
>
> I've been getting this simply in installworld outside the context of
> nanobsd. I've got a 12-CURRENT host doing an installworld of an
> 11-STABLE src tree to a chroot directory.
>
> Here's the log (granted, -s was added to make): http://ix.io/1fN3
>
> Thanks,
>
> --
> Shawn Webb
> Cofounder and Security Engineer
> HardenedBSD
>
> GPG Key ID:  0x6A84658F52456EEE
> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
___
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: NanoBSD install phase failing for releng/11

[Guido Falsi]

On 08/22/16 16:28, Warner Losh wrote:
> Yea, this isn't nanobsd specific. Adrian was complaining about it as well
> causing multiple entries in METALOG.

Outside of NanoBSD i did a "make packages" on a machine without problems
at head r304521.

Don't know if make packages would be affected as make install, but maybe
this information can help narrow things down.

-- 
Guido Falsi 
___
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: Somethign missing in my environment?

[Willem Jan Withagen]

On 22-8-2016 00:43, Ben Woods wrote:
> On Monday, 22 August 2016, Willem Jan Withagen  > wrote:
> 
> Tried an old trick:
> Build on another system (10.3) and then mount
> /usr/src
> /usr/obj
> on the system to install on.
> But that generates things like:
> ERROR-tried-to-rebuild-during-make-install
> So I guess that doesn't work any longer.
> 
> --WjW
> 
> 
> That trick still works for me, but you have to make sure the build
> environment and the install environment are the same. Namely that
> /etc/make.conf and /etc/src.conf are the same on both machines, and that
> they have the same architecture... Otherwise it will try and rebuild the
> differences during the install process.

Yup, that's how I knew it should work.

ATM I seem to be able to run into just about all possible problems to
upgrade this box.
But now it is claiming it is:
ERROR-tried-to-rebuild-during-make-install
whatever that may be.

I have found the definition, and it is to prevent building during
install on ReadOnly obj-dirs. But it does not really test for that, it
just blocks any builds.
But tinkering in the build system is asking for trouble, so I'm getting
closer and closer to reinstalling. Which is bad IMHO, since this it the
first time ever that I cannot escape for this type of catch-22.

Giving it a last retry building over NFS mounts.

Which sort of worked after I exclude some boot code that nagged me about
things growing to big. Which I attributed to "-g -O0".
But then I was able to complete buildword and buildkernel.

So sort of happy. Now I need to find out why the reboot did not work.
But that requires me next to the box.

--WjW

___
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: Error building 11.0-RC1 from 10.2

[Nenhum_de_Nos]

On Sat, August 20, 2016 22:54, Dimitry Andric wrote:
> On 21 Aug 2016, at 03:07, Nenhum_de_Nos  wrote:
>>
>> I tried to build 11.0-RC1 from two machines here, my home server and a
>> vm I installed and updated to 10.2 just to test for the real deal on
>> that server. Both failed on the same spot:
> ...
>> 3.  Running pass 'Function Pass Manager' on module
>> '/usr/src-11.0/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGBlocks.cpp'.
>> 4.  Running pass 'X86 DAG->DAG Instruction Selection' on function
>> '@_ZN5clang7CodeGen15CodeGenFunction12EmitCallArgsINS_17FunctionProtoTypeEEEvRNS0_11CallArgListEPKT_N4llvm14iterator_rangeINS_4Stmt17ConstExprIteratorEEEPKNS_12FunctionDeclEj'
>> c++: error: unable to execute command: Segmentation fault (core dumped)
>
> If you are using 10.2-RELEASE, you will not have this fix, which most
> likely solves the crash you are seeing:
>
> https://svnweb.freebsd.org/changeset/base/286033
>
> Please try to apply this to your 10.2 source tree, recompile clang, and
> then try to build 11.0 again.
>
> Alternatively, first upgrade to the latest stable/10, which should also
> fix it.  This costs more time, but is easier to execute.
>
> -Dimitry

Thanks,

I updated to 10.3 then the build process got past that issue.

Problem solved.

thanks again,

matheus


-- 
"We will call you Cygnus,
the God of balance you shall be."

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

make universe and /etc/src.conf

[Eric van Gyzen]

I just tried a "make universe", and all the kernels failed because they couldn't
find the config files.  I had forgotten that I have this in /etc/src.conf:

KERNCONF=NUMA
KERNCONFDIR=/etc

Since "make universe" is primarily used for build-testing changes in src,
shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
following?  Or is "make universe" used for other purposes for which it really
should read /etc/src*.conf?

--- Makefile(revision 304226)
+++ Makefile(working copy)
@@ -479,6 +479,7 @@
 universe_${target}_${target_arch}: universe_${target}_prologue .MAKE .PHONY
@echo ">> ${target}.${target_arch} ${UNIVERSE_TARGET} started on 
`LC_ALL=C date`"
@(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \
+   SRCCONF=/dev/null SRC_ENV_CONF=/dev/null \
${SUB_MAKE} ${JFLAG} ${UNIVERSE_TARGET} \
TARGET=${target} \
TARGET_ARCH=${target_arch} \

Thanks,

Eric
___
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 universe and /etc/src.conf

[Glen Barber]

On Mon, Aug 22, 2016 at 10:24:25AM -0500, Eric van Gyzen wrote:
> I just tried a "make universe", and all the kernels failed because they 
> couldn't
> find the config files.  I had forgotten that I have this in /etc/src.conf:
> 
>   KERNCONF=NUMA
>   KERNCONFDIR=/etc
> 
> Since "make universe" is primarily used for build-testing changes in src,
> shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
> following?  Or is "make universe" used for other purposes for which it really
> should read /etc/src*.conf?
> 
> --- Makefile  (revision 304226)
> +++ Makefile  (working copy)
> @@ -479,6 +479,7 @@
>  universe_${target}_${target_arch}: universe_${target}_prologue .MAKE .PHONY
>   @echo ">> ${target}.${target_arch} ${UNIVERSE_TARGET} started on 
> `LC_ALL=C date`"
>   @(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \
> + SRCCONF=/dev/null SRC_ENV_CONF=/dev/null \
>   ${SUB_MAKE} ${JFLAG} ${UNIVERSE_TARGET} \
>   TARGET=${target} \
>   TARGET_ARCH=${target_arch} \
> 

I'm CC-ing bdrewery@ who did a bunch of /etc/src-env.conf work.  I don't
*think* it was supposed to be required.  I might be wrong, though.

Glen



signature.asc
Description: PGP signature

Re: make universe and /etc/src.conf

[Bryan Drewery]

On 8/22/2016 8:27 AM, Glen Barber wrote:
> On Mon, Aug 22, 2016 at 10:24:25AM -0500, Eric van Gyzen wrote:
>> I just tried a "make universe", and all the kernels failed because they 
>> couldn't
>> find the config files.  I had forgotten that I have this in /etc/src.conf:
>>
>>  KERNCONF=NUMA
>>  KERNCONFDIR=/etc
>>
>> Since "make universe" is primarily used for build-testing changes in src,
>> shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
>> following?  Or is "make universe" used for other purposes for which it really
>> should read /etc/src*.conf?

I disagree. Universe has read src.conf for a long time, and not
make.conf which is more system-specific.  Perhaps you should move your
KERNCONF* to make.conf.

>>
>> --- Makefile (revision 304226)
>> +++ Makefile (working copy)
>> @@ -479,6 +479,7 @@
>>  universe_${target}_${target_arch}: universe_${target}_prologue .MAKE .PHONY
>>  @echo ">> ${target}.${target_arch} ${UNIVERSE_TARGET} started on 
>> `LC_ALL=C date`"
>>  @(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \
>> +SRCCONF=/dev/null SRC_ENV_CONF=/dev/null \
>>  ${SUB_MAKE} ${JFLAG} ${UNIVERSE_TARGET} \
>>  TARGET=${target} \
>>  TARGET_ARCH=${target_arch} \
>>
> 
> I'm CC-ing bdrewery@ who did a bunch of /etc/src-env.conf work.  I don't
> *think* it was supposed to be required.  I might be wrong, though.
> 

This isn't src-env-specific though.

> Glen
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: make universe and /etc/src.conf

[Glen Barber]

On Mon, Aug 22, 2016 at 08:47:06AM -0700, Bryan Drewery wrote:
> On 8/22/2016 8:27 AM, Glen Barber wrote:
> > On Mon, Aug 22, 2016 at 10:24:25AM -0500, Eric van Gyzen wrote:
> >> I just tried a "make universe", and all the kernels failed because they 
> >> couldn't
> >> find the config files.  I had forgotten that I have this in /etc/src.conf:
> >>
> >>KERNCONF=NUMA
> >>KERNCONFDIR=/etc
> >>
> >> Since "make universe" is primarily used for build-testing changes in src,
> >> shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like 
> >> the
> >> following?  Or is "make universe" used for other purposes for which it 
> >> really
> >> should read /etc/src*.conf?
> 
> I disagree. Universe has read src.conf for a long time, and not
> make.conf which is more system-specific.  Perhaps you should move your
> KERNCONF* to make.conf.
> 

Ah, thank you, I missed the configuration file mentioned above.

> >>
> >> --- Makefile   (revision 304226)
> >> +++ Makefile   (working copy)
> >> @@ -479,6 +479,7 @@
> >>  universe_${target}_${target_arch}: universe_${target}_prologue .MAKE 
> >> .PHONY
> >>@echo ">> ${target}.${target_arch} ${UNIVERSE_TARGET} started on 
> >> `LC_ALL=C date`"
> >>@(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \
> >> +  SRCCONF=/dev/null SRC_ENV_CONF=/dev/null \
> >>${SUB_MAKE} ${JFLAG} ${UNIVERSE_TARGET} \
> >>TARGET=${target} \
> >>TARGET_ARCH=${target_arch} \
> >>
> > 
> > I'm CC-ing bdrewery@ who did a bunch of /etc/src-env.conf work.  I don't
> > *think* it was supposed to be required.  I might be wrong, though.
> > 
> 
> This isn't src-env-specific though.
> 

Indeed, thank you for the prompt reply.

Glen



signature.asc
Description: PGP signature

Re: make universe and /etc/src.conf

[Ngie Cooper]

> On Aug 22, 2016, at 08:24, Eric van Gyzen  wrote:
> 
> I just tried a "make universe", and all the kernels failed because they 
> couldn't
> find the config files.  I had forgotten that I have this in /etc/src.conf:
> 
>KERNCONF=NUMA
>KERNCONFDIR=/etc

Alternatively, use KERNCONF?= and KERNCONFDIR?=..

A conditional will be needed to deal with MODULES_OVERRIDE, but it's trivial.. 
I'll dig up my old src.conf a bit later on today if needed. It's how I dealt 
with that caveat before I switched to GENERIC*.

> Since "make universe" is primarily used for build-testing changes in src,
> shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
> following?  Or is "make universe" used for other purposes for which it really
> should read /etc/src*.conf?
> 
> --- Makefile(revision 304226)
> +++ Makefile(working copy)
> @@ -479,6 +479,7 @@
> universe_${target}_${target_arch}: universe_${target}_prologue .MAKE .PHONY
>@echo ">> ${target}.${target_arch} ${UNIVERSE_TARGET} started on `LC_ALL=C 
> date`"
>@(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \
> +SRCCONF=/dev/null SRC_ENV_CONF=/dev/null \
>${SUB_MAKE} ${JFLAG} ${UNIVERSE_TARGET} \
>TARGET=${target} \
>TARGET_ARCH=${target_arch} \
> 
> Thanks,
> 
> Eric
> ___
> 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"
___
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 universe and /etc/src.conf

[Eric van Gyzen]

On 08/22/2016 10:47, Bryan Drewery wrote:
> On 8/22/2016 8:27 AM, Glen Barber wrote:
>> On Mon, Aug 22, 2016 at 10:24:25AM -0500, Eric van Gyzen wrote:
>>> I just tried a "make universe", and all the kernels failed because they 
>>> couldn't
>>> find the config files.  I had forgotten that I have this in /etc/src.conf:
>>>
>>> KERNCONF=NUMA
>>> KERNCONFDIR=/etc
>>>
>>> Since "make universe" is primarily used for build-testing changes in src,
>>> shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
>>> following?  Or is "make universe" used for other purposes for which it 
>>> really
>>> should read /etc/src*.conf?
> 
> I disagree. Universe has read src.conf for a long time, and not
> make.conf which is more system-specific.  Perhaps you should move your
> KERNCONF* to make.conf.

I'm okay with that.  Thanks for the help.

Eric
___
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 universe and /etc/src.conf

[Eric van Gyzen]

On 08/22/2016 11:00, Ngie Cooper wrote:
> 
>> On Aug 22, 2016, at 08:24, Eric van Gyzen  wrote:
>> 
>> I just tried a "make universe", and all the kernels failed because they
>> couldn't find the config files.  I had forgotten that I have this in
>> /etc/src.conf:
>> 
>> KERNCONF=NUMA KERNCONFDIR=/etc
> 
> Alternatively, use KERNCONF?= and KERNCONFDIR?=..
> 
> A conditional will be needed to deal with MODULES_OVERRIDE, but it's
> trivial.. I'll dig up my old src.conf a bit later on today if needed. It's
> how I dealt with that caveat before I switched to GENERIC*.

Thanks for the suggestion.  Moving these to /etc/make.conf seems easiest, so
I'll just do that.

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

10.03 to -current software removal

[Joshua Rogers]

Hi everybody,

I've come across a problem when upgrading from 10.03 to -current, which
I needed to do since my graphics driver isn't supported in 10.03, after
upgrading.

When I built the world and kernel, and did `make installkernel',
everything was perfect; I rebooted, and xorg ran, my wm was perfect,
software worked, and I could even change the backlight of my screen
using redshift.

However, when I went to the next step, `make installworld', and `yes |
make delete-old ; yes | make delete-old-libs', and I rebooted, xorg had
been uninstalled, along with many other things such as firefox, etc. It
was an easy fix to just reinstall them, however.

The problem is, after booting and starting xorg and everything, I've
come across a few errors when running software:

libreoffice and transmission-gtk no longer run(and probably other software):
/usr/local/lib/libreoffice/program/oosplash: Undefined symbol "dirname"
/usr/local/bin/transmission-gtk: Undefined symbol "dirname"
and redshift no longer can change the backlight color at all(manually
using xgamma doesn't work, either.)

vlc is also very laggy when fullscreen.

I suspect a library has been uninstalled or something along those lines
when I ran the last step as mentioned.

Does anybody know the best course of action to either: work out which
software was uninstalled so I can reinstall it, or to debug the specific
issues I'm having?


Cheers,
Josh
___
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: 10.03 to -current software removal

[Alan Somers]

Sounds like you have ports that are linked against the old base
system.  Did you do a "pkg upgrade" after the installworld?

On Mon, Aug 22, 2016 at 12:55 PM, Joshua Rogers  wrote:
> Hi everybody,
>
> I've come across a problem when upgrading from 10.03 to -current, which
> I needed to do since my graphics driver isn't supported in 10.03, after
> upgrading.
>
> When I built the world and kernel, and did `make installkernel',
> everything was perfect; I rebooted, and xorg ran, my wm was perfect,
> software worked, and I could even change the backlight of my screen
> using redshift.
>
> However, when I went to the next step, `make installworld', and `yes |
> make delete-old ; yes | make delete-old-libs', and I rebooted, xorg had
> been uninstalled, along with many other things such as firefox, etc. It
> was an easy fix to just reinstall them, however.
>
> The problem is, after booting and starting xorg and everything, I've
> come across a few errors when running software:
>
> libreoffice and transmission-gtk no longer run(and probably other software):
> /usr/local/lib/libreoffice/program/oosplash: Undefined symbol "dirname"
> /usr/local/bin/transmission-gtk: Undefined symbol "dirname"
> and redshift no longer can change the backlight color at all(manually
> using xgamma doesn't work, either.)
>
> vlc is also very laggy when fullscreen.
>
> I suspect a library has been uninstalled or something along those lines
> when I ran the last step as mentioned.
>
> Does anybody know the best course of action to either: work out which
> software was uninstalled so I can reinstall it, or to debug the specific
> issues I'm having?
>
>
> Cheers,
> Josh
> ___
> 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"
___
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: 10.03 to -current software removal

[Joshua Rogers]

Sending again to the list since I misclicked and sent an email only to Alan:

Indeed I did, and many new programs got installed when I did it.
However, now:

~$ sudo pkg update && sudo pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (23 candidates): 100%
Processing candidates (23 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.

Thanks,



On Tue, Aug 23, 2016 at 4:59 AM, Alan Somers  wrote:

> Sounds like you have ports that are linked against the old base
> system.  Did you do a "pkg upgrade" after the installworld?
>
> On Mon, Aug 22, 2016 at 12:55 PM, Joshua Rogers 
> wrote:
> > Hi everybody,
> >
> > I've come across a problem when upgrading from 10.03 to -current, which
> > I needed to do since my graphics driver isn't supported in 10.03, after
> > upgrading.
> >
> > When I built the world and kernel, and did `make installkernel',
> > everything was perfect; I rebooted, and xorg ran, my wm was perfect,
> > software worked, and I could even change the backlight of my screen
> > using redshift.
> >
> > However, when I went to the next step, `make installworld', and `yes |
> > make delete-old ; yes | make delete-old-libs', and I rebooted, xorg had
> > been uninstalled, along with many other things such as firefox, etc. It
> > was an easy fix to just reinstall them, however.
> >
> > The problem is, after booting and starting xorg and everything, I've
> > come across a few errors when running software:
> >
> > libreoffice and transmission-gtk no longer run(and probably other
> software):
> > /usr/local/lib/libreoffice/program/oosplash: Undefined symbol "dirname"
> > /usr/local/bin/transmission-gtk: Undefined symbol "dirname"
> > and redshift no longer can change the backlight color at all(manually
> > using xgamma doesn't work, either.)
> >
> > vlc is also very laggy when fullscreen.
> >
> > I suspect a library has been uninstalled or something along those lines
> > when I ran the last step as mentioned.
> >
> > Does anybody know the best course of action to either: work out which
> > software was uninstalled so I can reinstall it, or to debug the specific
> > issues I'm having?
> >
> >
> > Cheers,
> > Josh
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
>
___
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"

10.03 to -current software removal?

[Joshua Rogers]

Hi everybody,

I've come across a problem when upgrading from 10.03 to -current, which
I needed to do since my graphics driver isn't supported in 10.03, after
upgrading.

When I built the world and kernel, and did `make installkernel',
everything was perfect; I rebooted, and xorg ran, my wm was perfect,
software worked, and I could even change the backlight of my screen
using redshift.

However, when I went to the next step, `make installworld', and `yes |
make delete-old ; yes | make delete-old-libs', and I rebooted, xorg had
been uninstalled, along with many other things such as firefox, etc. It
was an easy fix to just reinstall them, however.

The problem is, after booting and starting xorg and everything, I've
come across a few errors when running software:

libreoffice and transmission-gtk no longer run(and probably other software):
/usr/local/lib/libreoffice/program/oosplash: Undefined symbol "dirname"
/usr/local/bin/transmission-gtk: Undefined symbol "dirname"
and redshift no longer can change the backlight color at all(manually
using xgamma doesn't work, either.)

vlc is also very laggy when fullscreen.

I suspect a library has been uninstalled or something along those lines
when I ran the last step as mentioned.

Does anybody know the best course of action to either: work out which
software was uninstalled so I can reinstall it, or to debug the specific
issues I'm having?


Cheers,
Josh
___
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: 10.03 to -current software removal?

[Ed Schouten]

Hi Joshua,

2016-08-22 20:54 GMT+02:00 Joshua Rogers :
> /usr/local/lib/libreoffice/program/oosplash: Undefined symbol "dirname"
> /usr/local/bin/transmission-gtk: Undefined symbol "dirname"

This specific issue interests me, for the reason that I recently
imported a new implementation of dirname(3) into libc. This error
message is probably related to this work.

Question: how recent is the version of FreeBSD -CURRENT to which you
upgraded? Could it be the case that you installed a version that is
not-so-new, but installed precompiled binary packages for 11.0 on top
that depend on a newer version?

Best regards,
-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
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: rpi-b leds

[Luiz Otavio O Souza]

On 22 August 2016 at 08:55, Andrey Fesenko wrote:
> On Mon, Aug 22, 2016 at 1:29 PM, Daniel Braniss wrote:
>> Hi,
>> I see that now both leds on the rpi-2 are operational,
>> any chance it can happen on the rpi-b too?
>>
>
> A year or two ago, rpi-b had operational leds, it's make not working
> after rework fdt/std layer

I tested the leds on two different rpi-b and the leds are working.
Maybe you are talking about the b+ model ?

The ACT or OK led for the old boards (< b+) are wired to gpio 16. The
b+ has two leds, they are wired to pins 47 and 35.

For a quick fix, edit your dts and the leds will work.

Can you check the board revision for your rpi ? (sysctl hw.board.revision)

These are the ones I tested:

hw.board.revision: 3
hw.board.revision: 14

Tested with r301978.

Luiz
___
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 universe and /etc/src.conf

[Poul-Henning Kamp]

In message , Eric van Gyzen w
rites:
>I just tried a "make universe", and all the kernels failed because they 
>couldn't
>find the config files.  I had forgotten that I have this in /etc/src.conf:
>
>   KERNCONF=NUMA
>   KERNCONFDIR=/etc
>
>Since "make universe" is primarily used for build-testing changes in src,
>shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
>following?  Or is "make universe" used for other purposes for which it really
>should read /etc/src*.conf?

I frankly don't remember why universe ignores make.conf but not src.conf,
but I do remeber it was a deliberate decision.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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 universe and /etc/src.conf

[Eric van Gyzen]

On 08/22/2016 17:15, Poul-Henning Kamp wrote:
> 
> In message , Eric van Gyzen 
> w
> rites:
>> I just tried a "make universe", and all the kernels failed because they 
>> couldn't
>> find the config files.  I had forgotten that I have this in /etc/src.conf:
>>
>>  KERNCONF=NUMA
>>  KERNCONFDIR=/etc
>>
>> Since "make universe" is primarily used for build-testing changes in src,
>> shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
>> following?  Or is "make universe" used for other purposes for which it really
>> should read /etc/src*.conf?
> 
> I frankly don't remember why universe ignores make.conf but not src.conf,
> but I do remeber it was a deliberate decision.

Okay, good to know.  Thanks for the input.

Eric
___
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 universe and /etc/src.conf

[Ngie Cooper (yaneurabeya)]

> On Aug 22, 2016, at 09:25, Eric van Gyzen  wrote:
> 
> On 08/22/2016 11:00, Ngie Cooper wrote:
>> 
>>> On Aug 22, 2016, at 08:24, Eric van Gyzen  wrote:
>>> 
>>> I just tried a "make universe", and all the kernels failed because they
>>> couldn't find the config files.  I had forgotten that I have this in
>>> /etc/src.conf:
>>> 
>>> KERNCONF=NUMA KERNCONFDIR=/etc
>> 
>> Alternatively, use KERNCONF?= and KERNCONFDIR?=..
>> 
>> A conditional will be needed to deal with MODULES_OVERRIDE, but it's
>> trivial.. I'll dig up my old src.conf a bit later on today if needed. It's
>> how I dealt with that caveat before I switched to GENERIC*.
> 
> Thanks for the suggestion.  Moving these to /etc/make.conf seems easiest, so
> I'll just do that.

The problem with using make.conf is that it pollutes all uses of make, whereas 
src.conf just pollutes compilation of the source tree.

Here’s what I used: 
https://github.com/yaneurabeya/scratch/blob/master/bayonetta/etc/src.conf-local#L39
 — I used some additional magic because of the reasons I mentioned in my 
previous email. Now, I just set KERNCONF= GENERIC GENERIC-NODEBUG (but I should 
use `?=` if I cared about running make universe on my VM on my laptop — heh).

Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Delay with 11.0-RC2 builds

[Glen Barber]

On Thu, Aug 18, 2016 at 11:30:24PM +, Glen Barber wrote:
> Two issues have been brought to our attention, and as a result, 11.0-RC2
> builds will be delayed a day or two while these are investigated.
> 
>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211872
>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211926
> 
> An update will be sent if the delay is longer than anticipated.
> 

Just an update, the 11.0-RC2 will be delayed at least two days.  One of
the issues mentioned in the above PR URLs does not affect releng/11.0,
and is a non-issue, but we are awaiting one more change to the stable/11
and releng/11.0 branches that we hope will be the final major changes to
11.0.

If this is the case, we may be able to eliminate 11.0-RC3 entirely, and
still release on time (or, on time as the current schedule suggests).

However, as you know, FreeBSD releases prioritize quality over schedule,
so we may still need to adjust the schedule appropriately.

So, help with testing 11.0-RC1 (or the latest releng/11.0 from svn) is
greatly appreciated.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

Re: rpi-b leds

[Daniel Braniss]

> On 23 Aug 2016, at 01:00, Luiz Otavio O Souza  wrote:
> 
> On 22 August 2016 at 08:55, Andrey Fesenko wrote:
>> On Mon, Aug 22, 2016 at 1:29 PM, Daniel Braniss wrote:
>>> Hi,
>>> I see that now both leds on the rpi-2 are operational,
>>> any chance it can happen on the rpi-b too?
>>> 
>> 
>> A year or two ago, rpi-b had operational leds, it's make not working
>> after rework fdt/std layer
> 
> I tested the leds on two different rpi-b and the leds are working.
> Maybe you are talking about the b+ model ?
> 
> The ACT or OK led for the old boards (< b+) are wired to gpio 16. The
> b+ has two leds, they are wired to pins 47 and 35.
> 
> For a quick fix, edit your dts and the leds will work.
> 
> Can you check the board revision for your rpi ? (sysctl hw.board.revision)
> 
> These are the ones I tested:
> 
> hw.board.revision: 3
> hw.board.revision: 14
> 
> Tested with r301978.
tested with revision 303422:
hw.board.revision: 16

and it’s a b+

managed to get pin 35 to work, but not 47.
50% success!
thanks,
danny

> 
> 
> Luiz

___
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: rpi-b leds

[Daniel Braniss]

> On 23 Aug 2016, at 09:00, Daniel Braniss  wrote:
> 
>> 
>> On 23 Aug 2016, at 01:00, Luiz Otavio O Souza  wrote:
>> 
>> On 22 August 2016 at 08:55, Andrey Fesenko wrote:
>>> On Mon, Aug 22, 2016 at 1:29 PM, Daniel Braniss wrote:
 Hi,
 I see that now both leds on the rpi-2 are operational,
 any chance it can happen on the rpi-b too?
 
>>> 
>>> A year or two ago, rpi-b had operational leds, it's make not working
>>> after rework fdt/std layer
>> 
>> I tested the leds on two different rpi-b and the leds are working.
>> Maybe you are talking about the b+ model ?
>> 
>> The ACT or OK led for the old boards (< b+) are wired to gpio 16. The
>> b+ has two leds, they are wired to pins 47 and 35.
>> 
>> For a quick fix, edit your dts and the leds will work.
>> 
>> Can you check the board revision for your rpi ? (sysctl hw.board.revision)
>> 
>> These are the ones I tested:
>> 
>> hw.board.revision: 3
>> hw.board.revision: 14
>> 
>> Tested with r301978.
> tested with revision 303422:
> hw.board.revision: 16
> 
> and it’s a b+
> 
> managed to get pin 35 to work, but not 47.
> 50% success!
> thanks,
>   danny
> 

maybe this can shed some light:

gpio0:  mem 0x20-0x2000af on simplebus0
gpio0: read-only pins: 46-53.
gpio0: reserved pins: 48-53.
gpiobus0:  on gpio0
gpioled0:  at pin 16 on gpiobus0
gpioled1:  at pin 47 on gpiobus0
gpioled2:  at pin 35 on gpiobus0
gpioled3:  at pin 6 on gpiobus0
gpioled4:  at pin 12 on gpiobus0
gpioled5:  at pin 13 on gpiobus0
gpiobus0: warning: pin 16 is already mapped
gpioled6:  at pin 22 on gpiobus0
gpioled7:  at pin 23 on gpiobus0
gpioled8:  at pin 24 on gpiobus0
gpioled9:  at pin 5 on gpiobus0
gpioc0:  on gpio0

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

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