Use of env SRC_ENV_CONF=. . . for buildworld does not override/avoid use of /etc/src.conf : Intentional?

2016-11-03 Thread Mark Millard 
I just had a case of "odd" command text in a buildworld that was based on (in 
part) env SRC_ENV_CONF=. . .

env __MAKE_CONF=. . . does not get the kind of behavior reported below for 
/etc/src.conf .

Overall this means that even with an explicit env SRC_ENV_CONF=. . . one must 
separately prevent /etc/src.conf from contributing if the SRC_ENV_CONF file is 
intended to cover everything.

Looking in the log from a failure that resulted shows that .MAKE.MAKEFILES 
shows both the SRC_ENV_CONF expansion and also a /etc/src.conf as well 
(formatted to make the /etc/src.conf and such stand out: separate lines wiht 
whitespace before and after and with just one path on the line for such file 
paths):

> Script started on Thu Nov  3 16:37:26 2016
> Command: env __MAKE_CONF=/root/src.configs/make.conf 
> SRC_ENV_CONF=/root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host 
> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/powerpc64vtsc_xtoolchain make -j 
> 5 buildworld buildkernel
. . .
> .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
> /usr/src/share/mk/src.sys.env.mk

> /root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host

> /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk

> /root/src.configs/make.conf

> /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk

> /etc/src.conf

> /usr/src/include/rpcsvc/Makefile /usr/src/share/mk/bsd.prog.mk 
> /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
> /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
> /usr/src/share/mk/src.init
> .mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk 
> /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk 
> /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk 
> /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share
> /mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk 
> /usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk 
> /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk 
> /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk'
> .PATH='. /usr/src/include/rpcsvc'

Note:

> # grep src.conf /root/src.configs/src.conf.powerpc64-xtoolchain.amd64-host
> #


The context I was under was:

> # uname -apKU
> FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r308247M: Thu Nov  3 
> 04:05:55 PDT 2016 
> markmi@FreeBSDx64:/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC-NODBG  
> amd64 amd64 1200014 1200014

I'd just cloned and switched from a stable/11 context to head (12-CURRENT).

If this is intentional then I think the man src.conf references and such should 
be explicit about the /etc/make.conf vs. /etc/src.conf distinction for 
__MAKE_CONF= vs. SRC_ENV_CONF= .

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

___
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: how to reduce the size of /usr/share/i18n data?

2016-11-03 Thread Jordan Hubbard 

> On Nov 3, 2016, at 1:56 PM, David Chisnall  wrote:
> 
> Is the depressing thing here that even something as recent as 386BSD 0.1 
> assumed that ASCII was enough for the whole world?

“Recent??” :-D

___
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: how to reduce the size of /usr/share/i18n data?

2016-11-03 Thread David Chisnall 
On 3 Nov 2016, at 19:34, Rodney W. Grimes  
wrote:
> 
> Depressing fact:  The i18n directory alone is larger than
> a full 386BSD 0.1+sources+patchkit install.

Is the depressing thing here that even something as recent as 386BSD 0.1 
assumed that ASCII was enough for the whole world?

David



smime.p7s
Description: S/MIME cryptographic signature

Re: Fwd: Re: how to reduce the size of /usr/share/i18n data?

2016-11-03 Thread Rodney W. Grimes 
[ Charset UTF-8 unsupported, converting... ]
> 
> So I am to take it that no-one has any idea how this stuff works and 
> how to stub it out?

I would be rather tempted to rm -r /usr/share/i18n and see what
fails.  Anything that fails should be patched to deal with the
fact locale date is missing.

Then the stub out would be a simple mater of making
src/share/i18n a SUBDIR += in the src/share Makefile
inside an .ifdef WITH_LOCALE or WITH_I18N.

Further stubbing out should be pursued if we want to get back
some of our embeded-friendly needs by making all of the locale
related code conditionally compiled during a make world.

Depressing fact:  The i18n directory alone is larger than
a full 386BSD 0.1+sources+patchkit install.

> On 1/11/2016 7:11 PM, Julian Elischer wrote:
> >
> > 01.11.2016 17:53, Julian Elischer ?:
> >> there are a number of packages that want to link with or use that 
> >> data, and you can't always disable it, but it's very very big 
> >> (38MB?), especially in the context of an appliance that doesn't 
> >> really need it at all.
> >>
> >>
> >> If anyone has a procedure to follow to put that onto a diet, maybe 
> >> just as a stub then I'm all ears.
> >
> > +1
> >
> > Introduction of such large part of base system is kind of 
> > catastrophe for embedded systems
> > that need only ASCII and may be additionally one of "good old" 8-bit 
> > locales.
> >
> > FreeBSD 11 got pretty large and embedded-unfriendly without clear 
> > way to exclude such unneeded parts.
> >

-- 
Rod Grimes rgri...@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: CURRENT: re(4) crashing system

2016-11-03 Thread O. Hartmann 
Am Mon, 31 Oct 2016 11:12:22 +0900
YongHyeon PYUN  schrieb:

> On Fri, Oct 28, 2016 at 09:21:13PM +0200, Hartmann, O. wrote:
> > On Thu, 27 Oct 2016 10:00:04 +0900
> > YongHyeon PYUN  wrote:
> >   
> > > On Tue, Oct 25, 2016 at 07:03:38AM +0200, Hartmann, O. wrote:  
> > > > On Tue, 25 Oct 2016 11:05:38 +0900
> > > > YongHyeon PYUN  wrote:
> > > > 
> > > 
> > > [...]
> > >   
> > > > > I'm not sure but it's likely the issue is related with EEE/Green
> > > > > Ethernet handling. EEE is negotiated feature with link partner. If
> > > > > you directly connect your laptop to non-EEE capable link partner
> > > > > like other re(4) box without switches you may be able to tell
> > > > > whether the issue is EEE/Green Ethernet related one or not.
> > > > 
> > > > Me either since when I discovered a problem the first time with
> > > > CURRENT, that was the Friday before last week's Friday, there was a
> > > > unlucky coicidence: I got the new switch, FreeBSD introduced a
> > > > serious bug and I changed the NICs.
> > > > 
> > > > The laptop, the last in the row of re(4) equipted systems on which I
> > > > use the Realtek NIC, does well now with Green IT technology, but
> > > > crashes on plugging/unplugging - not on each event, but at least in
> > > > one of ten.
> > > 
> > > Hmm, it seems you know how to trigger the issue. When you unplug
> > > UTP cable was there active network traffic on re(4) device?
> > > It would be helpful to know which event triggers the crash(e.g.
> > > unplugging or plugging).  And would you show me backtrace of panic?
> > >   
> > > > I guess the Green IT issue is more a unlucky guess of mine and went
> > > > hand in hand with the problem I face with CURRENT right now on some
> > > > older, Non UEFI machines.
> > > > 
> > > 
> > > Ok.
> > > 
> > > [...]  
> > > > 
> > > > As requested the informations about re0 and rgephy0 on the laptop
> > > > (Lenovo E540) 
> > > > 
> > > > [...]
> > > > 
> > > > rgephy0:  PHY 1 on miibus0
> > > > rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
> > > > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX,
> > > > 1000baseT-FDX-master, 1000baseT-FDX-flow,
> > > > 1000baseT-FDX-flow-master, auto, auto-flow
> > > > 
> > > > re0: 
> > > > port 0x3000-0x30ff mem 0xf0d04000-0xf0d04fff,0xf0d0-0xf0d03fff
> > > > at device 0.0 on pci2 re0: Using 1 MSI-X message re0: ASPM disabled
> > > > re0: Chip rev. 0x5080
> > > > re0: MAC rev. 0x0010
> > > 
> > > This looks like 8168GU controller.
> > > 
> > > [...]
> > >   
> > > > I use options netmap in kernel config, but the problem is also
> > > > present without this option - just for the record.
> > > > 
> > > 
> > > Yup, netmap(4) has nothing to do with the crash.
> > > 
> > > Thanks.  
> > 
> > Attached, you'll find the backtrace of the crash. This time it was
> > really easy - just one pull of the LAN cabling - and we are happy :-/
> > 
> > Please let me know if you need something else. I will return to normal
> > operations (disabling debugging) due to CURRENT is very unstable at the
> > moment on other hosts beyond r307157.
> >   
> 
> It seems the attachment was stripped.

[...]

Sorry for the late reply.
Indeed, someone forgot to append the dump/core info and this someone seems to 
be me.

I have severe time constraints and I will prepare another crash/dump on this 
weekend with
a most recent CURRENT.

My apologizes for this,

kind regards,

Oliver


pgprRC6baT13b.pgp
Description: OpenPGP digital signature

Re: [RFC] remove GNU rcs from FreeBSD 12

2016-11-03 Thread Pete Wright 



On 11/03/2016 01:42, Julian Elischer wrote:

On 3/11/2016 10:45 AM, Pete Wright wrote:



On 11/02/2016 19:17, Julian Elischer wrote:

On 26/10/2016 2:27 AM, Eivind Nicolay Evensen wrote:

On Sun, Sep 11, 2016 at 03:38:04PM +0200, Baptiste Daroussin wrote:

hi,

For long we are planning to remove GNU rcs from base, after a 
failed attempt
before FreeBSD 10.0. Let see where we are to be able to remove it 
from FreeBSD

12.


why should we remove it?
What will replace it?  it's an integral part of many people's systems.

Is there a non gnu RCS with the same features?



surprised to hear so many people are dependent upon having rcs in 
their base system.  there are options though - for example OpenBSD 
uses OpenRCS in their base:

I don't see what is surprising about it.
It's been common "best practice" for decades to keep all your files in 
/etc under source control. RCS fits he bill well and many people have 
it in their muscle memory.


heh - not trying to start a bike shed, and I certainly have used RCS in 
that manner in the past, although I supplanted it for a configuration 
management engine quite a while ago as the industry moved towards more 
distributed environments where systems automation became more practical.


regardless - sounds like people still using rcs should be able to kick 
the tires on OpenRCS and see if it fits their needs.


-pete
___
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: Fwd: Re: how to reduce the size of /usr/share/i18n data?

2016-11-03 Thread Tomoaki AOKI 
On Thu, 3 Nov 2016 06:46:39 -0400
Mark Heily  wrote:

> On Nov 3, 2016 5:30 AM, "Kurt Jaeger"  wrote:
> >
> > Hi!
> >
> > > So I am to take it that no-one has any idea how this stuff works and
> > > how to stub it out?
> >
> > Or had time to write about it.
> >
> > --
> > p...@opsec.eu+49 171 3101372 4 years to
> go !
> >
> 
> Maybe you could use 'svn blame' to research who has commited those files,
> and contact them directly?

Not shure but maybe WITHOUT_ICONV knob would eliminate them from build.
Beware! It should completely eliminate iconv features.

See commit message for Revision 219019 below.

  https://svnweb.freebsd.org/base/head/share/i18n/Makefile?view=log

Sorry, I don't know how to safely delete some (not all) part of
conversions to shrink the contents there, keeping limited iconv
features to work.

-- 
Tomoaki AOKI
___
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: how to reduce the size of /usr/share/i18n data?

2016-11-03 Thread Tijl Coosemans 
On Thu, 3 Nov 2016 15:48:09 +0800 Julian Elischer  wrote:
> On 1/11/2016 7:11 PM, Julian Elischer wrote:
>> 01.11.2016 17:53, Julian Elischer пишет:  
>>> there are a number of packages that want to link with or use that 
>>> data, and you can't always disable it, but it's very very big 
>>> (38MB?), especially in the context of an appliance that doesn't 
>>> really need it at all.
>>>
>>>
>>> If anyone has a procedure to follow to put that onto a diet, maybe 
>>> just as a stub then I'm all ears.  
>
> So I am to take it that no-one has any idea how this stuff works and 
> how to stub it out?

/usr/share/i18n is only used by iconv(3).  If you don't need that
function just add WITHOUT_ICONV to src.conf.  If you do need it then you
can remove all the subdirectories of character sets you never convert
to/from.  The easiest is probably to modify the SUBDIR variable in
src/share/i18n/csmapper/Makefile and src/share/i18n/esdb/Makefile.
___
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: Fwd: Re: how to reduce the size of /usr/share/i18n data?

2016-11-03 Thread Mark Heily 
On Nov 3, 2016 5:30 AM, "Kurt Jaeger"  wrote:
>
> Hi!
>
> > So I am to take it that no-one has any idea how this stuff works and
> > how to stub it out?
>
> Or had time to write about it.
>
> --
> p...@opsec.eu+49 171 3101372 4 years to
go !
>

Maybe you could use 'svn blame' to research who has commited those files,
and contact them directly?

___
> 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: Fwd: Re: how to reduce the size of /usr/share/i18n data?

2016-11-03 Thread Kurt Jaeger 
Hi!

> So I am to take it that no-one has any idea how this stuff works and 
> how to stub it out?

Or had time to write about it.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: [RFC] remove GNU rcs from FreeBSD 12

2016-11-03 Thread Julian Elischer 

On 3/11/2016 10:45 AM, Pete Wright wrote:



On 11/02/2016 19:17, Julian Elischer wrote:

On 26/10/2016 2:27 AM, Eivind Nicolay Evensen wrote:

On Sun, Sep 11, 2016 at 03:38:04PM +0200, Baptiste Daroussin wrote:

hi,

For long we are planning to remove GNU rcs from base, after a 
failed attempt
before FreeBSD 10.0. Let see where we are to be able to remove it 
from FreeBSD

12.


why should we remove it?
What will replace it?  it's an integral part of many people's systems.

Is there a non gnu RCS with the same features?



surprised to hear so many people are dependent upon having rcs in 
their base system.  there are options though - for example OpenBSD 
uses OpenRCS in their base:

I don't see what is surprising about it.
It's been common "best practice" for decades to keep all your files in 
/etc under source control. RCS fits he bill well and many people have 
it in their muscle memory.




http://man.openbsd.org/rcs.1

its not strictly GNU compliant as I believe it adheres to the 
original implementation (which frankly is probably a good thing 
imho).  GNU RCS is also available via ports/pkgs as well.


If people are adamant about preserving a rcs binary in base though 
this seems like a great opportunity to step up and help 
import/support OpenRCS.


that's ok by me as long as:
1/ it can continue to read all the old data
2/ it works the same (for scripts etc)



just my two bits - hope it helps.

-pete


___
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: Fwd: Re: how to reduce the size of /usr/share/i18n data?

2016-11-03 Thread Julian Elischer 


So I am to take it that no-one has any idea how this stuff works and 
how to stub it out?


On 1/11/2016 7:11 PM, Julian Elischer wrote:


01.11.2016 17:53, Julian Elischer пишет:
there are a number of packages that want to link with or use that 
data, and you can't always disable it, but it's very very big 
(38MB?), especially in the context of an appliance that doesn't 
really need it at all.



If anyone has a procedure to follow to put that onto a diet, maybe 
just as a stub then I'm all ears.


+1

Introduction of such large part of base system is kind of 
catastrophe for embedded systems
that need only ASCII and may be additionally one of "good old" 8-bit 
locales.


FreeBSD 11 got pretty large and embedded-unfriendly without clear 
way to exclude such unneeded parts.



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