Re: [RFC] remove GNU rcs from FreeBSD 12

2016-11-05 Thread Mark Linimon
On Thu, Nov 03, 2016 at 10:17:23AM +0800, Julian Elischer wrote:
> why should we remove it?

IIUC the plan for several years has been to remove all GPLed software
from base.

But in any case the conversation is moot.  It was removed from head
on 20161015 by bapt:

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

UPDATING contains notes about how to install it on your system.

mcl
___
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: Use of env SRC_ENV_CONF=. . . for buildworld does not override/avoid use of /etc/src.conf : Intentional?

2016-11-05 Thread Mark Millard
On 2016-Nov-4, at 9:40 AM, Bryan Drewery  wrote:

> On 11/3/2016 5:28 PM, Mark Millard wrote:
>> 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.
> 
> SRC_ENV_CONF is kind of a special hack to allow setting some specific
> values that feasibly can't be set later.  Just stick to src.conf unless
> you need to set one of the options that requires src-env.conf.
> 
> -- 
> Regards,
> Bryan Drewery

Understood (now): intentional for sure. Thanks to Renato Botelho and you for
making clear that I'd read something into the description that just was not
written into the description.

For now I've adopted using an explicit env SRCCONF="/dev/null" in the scripts as
the means of avoiding an unexpected contribution and I still have env 
SRC_ENV_CONF=
use for picking out the file: I then do not have to worry about if I reference
any of the special values in the file referenced or not, nor about what
/etc/src-env.conf or /etc/src.conf might have in them.

I may change this at some point and follow your suggestion to just use SRCCONF=
to find the file because as time goes on it looks more like I'm unlikely to
experiment with any "special values" in the files.

===
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: [RFC] remove GNU rcs from FreeBSD 12

2016-11-05 Thread Mark Heily
On Sat, Nov 5, 2016 at 9:07 AM, Ronald Klop  wrote:

> On Thu, 03 Nov 2016 03:17:23 +0100, 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?
>>
>
It should be removed from base because the license was changed to GPLv3+
about six years ago. The obsolete GPLv2 version currently in base is no
longer maintained. I agree with the sentiment that RCS should be an
optional component available from ports.
___
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: was: CURRENT [r308087] still crashing: Backtrace provided

2016-11-05 Thread O. Hartmann
Am Sun, 30 Oct 2016 11:25:09 -0700
Mark Johnston  schrieb:

> On Sun, Oct 30, 2016 at 06:55:00PM +0100, O. Hartmann wrote:
> > Am Sun, 30 Oct 2016 09:39:34 -0700
> > Mark Johnston  schrieb:
> >   
> > > On Sun, Oct 30, 2016 at 08:25:25AM +0100, O. Hartmann wrote:  
> > > > Am Sat, 29 Oct 2016 18:33:45 -0700
> > > > Mark Johnston  schrieb:
> > > > 
> > > > > On Sat, Oct 29, 2016 at 04:33:36PM +0200, O. Hartmann wrote:
> > > > > > Am Sun, 23 Oct 2016 15:18:57 -0400 (EDT)
> > > > > > Benjamin Kaduk  schrieb:
> > > > > >   
> > > > > > > On Sun, 23 Oct 2016, O. Hartmann wrote:
> > > > > > >   
> > > > > > > > How can I track a memory leak?
> > > > > > > 
> > > > > > > I think I did not read enough of the context, but vmstat and top 
> > > > > > > can track
> > > > > > > memory usage as a general thing.
> > > > > > >   
> > > > > > > > How can I write to disk the backtrace given by the debugger when
> > > > > > > > crashing? My box I can freely test is using the nVidia BLOB and 
> > > > > > > > vt(), so
> > > > > > > > I can not see the backtrace. I got a very bad screenshot on one 
> > > > > > > > of my
> > > > > > > > laptops, but its so ugly/unreadable, I think it is unsuable to 
> > > > > > > > be
> > > > > > > > presented within this list at a reasonable size (200 kB max ist 
> > > > > > > > too
> > > > > > > > small).
> > > > > > > 
> > > > > > > The backtrace should be part of the crash dump that is written to 
> > > > > > > the
> > > > > > > (directly connected, non-encrypted, non-USB) swap device.  "call 
> > > > > > > doadump"
> > > > > > > at the debugger prompt (even typing blind) is supposed to make 
> > > > > > > sure
> > > > > > > there's a dump taken.
> > > > > > > 
> > > > > > > With respect to the screenshot, you should be able to post the 
> > > > > > > image on an
> > > > > > > external site and send a link to the list, at least.
> > > > > > > 
> > > > > > > -Ben
> > > > > > > ___
> > > > > > > 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"  
> > > > > > 
> > > > > > Hello Benjamin,
> > > > > > 
> > > > > > thank you for your response. Attached, you'll find the backtrace 
> > > > > > developers
> > > > > > seem to have requested for. It was a bit hard, since FreeBSD, vt() 
> > > > > > and nVidia
> > > > > > is broken (black or distorted console, on UEFI it is black/locked 
> > > > > > as long as
> > > > > > the nvidia-modeset,ko module is loaded). I figured out that I could 
> > > > > > blindly
> > > > > > type "dump" when the box has crashed and resided at the debugger 
> > > > > > promt.
> > > > > > 
> > > > > > I hope this time I could provide the help to fix this really nasty 
> > > > > > problem. On
> > > > > > more recent hardware, Haswell and beyond, I was able to run CURRENT 
> > > > > > even with
> > > > > > ZFS and poudriere on a hard memory pressure without crash within 
> > > > > > three days.
> > > > > > On older machines, one older Fujitsu dual socket Core2Duo XEON (2x 
> > > > > > 4 core, 2x
> > > > > > 16 GB RAM banks) as well as two of my private boxes (1x IvyBridge 
> > > > > > XEON, one
> > > > > > i3-3220, both wit a non-UEFI-working ASROCK Z77 Pro4 board) crash, 
> > > > > > if FreeBSD
> > > > > > is > r307157. Staying on those systems with r307157 leaves the 
> > > > > > machine
> > > > > > "rock-solid" - the XEON box last now for a week uptime.   
> > > > > 
> > > > > In kgdb, could you execute:
> > > > > 
> > > > > (kgdb) frame 12
> > > > > (kgdb) p *ifp
> > > > > (kgdb) p *ro
> > > > > 
> > > > > and reply with the output?
> > > > 
> > > > Besides, is there any way to investigate the crashed vmcore.X files?
> > > 
> > > Besides examining the state contained in the vmcore? Not really.  
> > 
> > Juts not to misunderstand you (I'm not familiar with debugging!): I can 
> > investigate
> > the saved corefiles (vmcore.X) with kgdb? My first attempts failed by 
> > simply refering
> > via option -n 0 to the specific vmcore.0 and typing the commands as 
> > requested above -
> > the output looked like an error to me.  
> 
> Oh, sorry. Indeed, you should be able to execute
> 
> # kgdb $(sysctl kern.bootfile) vmcore.0
> 
> to open the core with kgdb.
> 
> > 
> > 
> >   
> > > 
> > > Based on the stack trace and affected range of revisions, it may be that
> > > reverting r307887 or r307234 helps, but I have no specific evidence for
> > > this without the requested output.  
> > 
> > I had the crashing also with > r307300 until now, so that leaves me with 
> > r307233 ... I
> > will go further with that revision and report so far.   
> 
> Hm, I don't see why this excludes r307887? In any case, r307234 looks to
> be the more likely culprit.

Here 

Re: [RFC] remove GNU rcs from FreeBSD 12

2016-11-05 Thread Ronald Klop
On Thu, 03 Nov 2016 03:17:23 +0100, 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.


Firefox/perl/java is also an integral part of many people's system. But it  
is not in base.



Is there a non gnu RCS with the same features?


There is the exact same version in pkg/ports.

Ronald.





Whatever the outcome may be and for whatever my opinion is worth, I hope
rcs will stay in base. I don't care about the licensing. I don't
care if a switch to openrcs happens either, as long as it works.

For years, one has been able to rely upon this operating system having
certain pieces of software available. Losing that makes it a worse  
choice

than before.

I've already had to readd cvs to my freebsd tree since that was removed,
but if it keeps getting worse and worse and there's soon a
freebsd kernel and some random bits of freebsd userland available
through ports, there's not much reason to keep using it as an operating
system, because then it is not an operating system anymore, rather an
emulation of another "system" built around that concept.



Eivind N. E.
___
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"

___
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-05 Thread Julian Elischer

On 3/11/2016 7:46 PM, Tomoaki AOKI wrote:

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.

there are some 3rd party apps that want them so I'd rather just know 
how to make a really small subset.


there is a database that is describes the data there but I have no 
clue how to generate a new db.





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