Re: RCS and $FreeBSD$ purge

[Warner Losh]

On Fri, Jan 26, 2024, 7:32 PM Steve Kargl 
wrote:

> I'm currently syncing src/lib/msun with my private libm
> repository where I do much of my hacking on libm issues.
> In looking at diffs, I see a few lingering RCS and
> $FreeBSD$ tags.  For example, lib/msun/amd64/s_scalbnl.S
> contains
>
> /* RCSID("$NetBSD: s_scalbnf.S,v 1.4 1999/01/02 05:15:40 kristerw Exp $")
> */
>
> Should this be cleaned up or ws intentional left in the
> source code?
>

The NetBSD and OpenBSD ones were intentional.

Warner

>

Re: RCS and $FreeBSD$ purge

[Gordon Bergling]

Hi Steve,

On Fri, Jan 26, 2024 at 06:32:26PM -0800, Steve Kargl wrote:
> I'm currently syncing src/lib/msun with my private libm 
> repository where I do much of my hacking on libm issues.
> In looking at diffs, I see a few lingering RCS and
> $FreeBSD$ tags.  For example, lib/msun/amd64/s_scalbnl.S
> contains
> 
> /* RCSID("$NetBSD: s_scalbnf.S,v 1.4 1999/01/02 05:15:40 kristerw Exp $") */
> 
> Should this be cleaned up or ws intentional left in the 
> source code?

the $FreeBSD$ tags can definitely be removed. I just did a grep through
my working tree and found a lot RCSIDs, so I would tend to keep them
as reference in the source files.

--Gordon


signature.asc
Description: PGP signature

RCS and $FreeBSD$ purge

[Steve Kargl]

I'm currently syncing src/lib/msun with my private libm 
repository where I do much of my hacking on libm issues.
In looking at diffs, I see a few lingering RCS and
$FreeBSD$ tags.  For example, lib/msun/amd64/s_scalbnl.S
contains

/* RCSID("$NetBSD: s_scalbnf.S,v 1.4 1999/01/02 05:15:40 kristerw Exp $") */

Should this be cleaned up or ws intentional left in the 
source code?


-- 
Steve

Re: i915: RCS timing out when being idled

[Kevin Oberman]

On Sat, Dec 31, 2022 at 9:58 AM obiwac  wrote:

> Hey,
>
> I didn't find a more appropriate mailing list to post to, so here it goes:
>
I'm afraid I can't really help with your problem, but issues with graphics
should be sent to FreeBSD graphics GitHub
. I think having this outside of the
standard FreeBSD support structure has bothered me since it was moved from
the Bugziila a few years ago. If you want a mailing list, x...@freebsd.org
would be most appropriate, though you need to subscribe first.
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

i915: RCS timing out when being idled

[obiwac]

Hey,

I didn't find a more appropriate mailing list to post to, so here it goes:

I'm running what is essentially FreeBSD-CURRENT on an Asus C300 Chromebook
(iGPU, gen 7).

Building branch 5.10-lts (or HEAD on main for that matter) of drm-kmod and
loading i915kms results in a wedged GPU, after a call to
intel_gt_wait_for_idle fails in __engines_record_defaults in
drivers/gpu/drm/i915/gt/intel_gt.c.

It fails waiting for the RCS0 engine; not loading a new context to it (i.e.
adding a few 'if (id == RCS0) continue;' lines to ignore it) allows the GPU
to continue initialisation without wedging. This isn't ideal though because
the RCS ends up unhappy after a bit of load and the GPU hangs (RCS engine
crashes) :P

I guess the issues (the wedging and the hang) could be unrelated but I have
a strong suspicion they are.

I've been trying to understand how the whole i915 stuff is architectured
for a couple days now (Intel's vocabulary is very confusing ngl), but there
are a few things I can't really wrap my head around, which leads me asking
for help debugging here 

Is there anything else I can try in terms of troubleshooting/anyone else I
can contact for help? If not I wouldn't really mind attempting to
understand everything through-and-through and fix the issue myself, if
there was someone I could ask for a couple short explanations on bits of
the driver ;)

Last I checked, everything was working well with drm-tip on Linux.

Kind regards and a happy new year,
Aymeric 壟

Re: [RFC] remove GNU rcs from FreeBSD 12

[Mark Linimon]

On Sun, Nov 06, 2016 at 12:09:30PM +0100, Eivind Nicolay Evensen wrote:
> I also thought that perl was a good example of another piece of software
> that once was provided and no longer is.

Yes, that's true, but somewhat different.

perl was removed because keeping it became incompatible with the concept
of the -stable branches.  perl development was simply moving faster than
FreeBSD major releases, leading to FreeBSD having to keep maintaining an
obsolete piece of software far past the time upstream had dropped support
for it.

Of course this is a problem with any software that FreeBSD imports, but
IIUC this may have been the most painful case.  (I was just starting to
use FreeBSD at the time, so was really just an observer.)

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

[Eivind Nicolay Evensen]

On Sat, Nov 05, 2016 at 05:31:47PM -0400, Mark Heily wrote:
> On Sat, Nov 5, 2016 at 9:07 AM, Ronald Klop <ronald-li...@klop.ws> wrote:
> 
> > On Thu, 03 Nov 2016 03:17:23 +0100, Julian Elischer <jul...@freebsd.org>
> > 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.

In my use of it, just plain keeping versions of files containing
only text in them, I haven't seen the need for a maintainer since
there has not been any problems. Is there a real problem I should be aware of?



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

[Eivind Nicolay Evensen]

On Sat, Nov 05, 2016 at 08:19:15PM -0500, Mark Linimon wrote:
> 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

It already being removed doesn't make me, and most likely nobody else
who also wanted it to stay, want it in base any less. Thanks though
for the headsup for us that doesn't use current.

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

Thanks for the tip, though I'll rather keep it in my own tree,
like I did with cvs when that was taken away.


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

[Eivind Nicolay Evensen]

On Sat, Nov 05, 2016 at 02:07:21PM +0100, Ronald Klop wrote:
> On Thu, 03 Nov 2016 03:17:23 +0100, Julian Elischer <jul...@freebsd.org>  
> 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.


I see a big difference between these two

First providing something people find useful enough that it affects their
decision about whether or not to use a system, then stopping providing it.

versus

Not including any and all available software packages.


I don't think I'm entirely along in that view.

I also thought that perl was a good example of another piece of software
that once was provided and no longer is.




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

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

[Mark Heily]

On Sat, Nov 5, 2016 at 9:07 AM, Ronald Klop <ronald-li...@klop.ws> wrote:

> On Thu, 03 Nov 2016 03:17:23 +0100, Julian Elischer <jul...@freebsd.org>
> 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: [RFC] remove GNU rcs from FreeBSD 12

[Ronald Klop]

On Thu, 03 Nov 2016 03:17:23 +0100, Julian Elischer <jul...@freebsd.org>  
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: [RFC] remove GNU rcs from FreeBSD 12

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

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

[Pete Wright]

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:


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.


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"

Re: [RFC] remove GNU rcs from FreeBSD 12

[Julian Elischer]

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?


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"

Re: [RFC] remove GNU rcs from FreeBSD 12

[Eivind Nicolay Evensen]

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.

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"

Re: [RFC] remove GNU rcs from FreeBSD 12

[Alfred Perlstein]

On 9/11/16 6:38 AM, 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.

GNU rcs is a GPLv2 software with newer version being GPLv3 preventing any
updates/fixes.

 From previous discussions there were issues that has been raised in previous
attempts:
- ident(1) is still useful given we still have Keywords in our sources. It has
   been replaced by a BSD Licensed version (enhanced to improve compatibility
   with Subversion Keyword) for FreeBSD 11. So that tool will remain in base
   after removal of GNU rcs.
- etc-update uses merge(1) from GNU rcs, this has been changed in head to use
   diff3 instead.
- rc.subr allows to use rcs for the backup file functionality. This
   functionality is off by default as such I plan to make a warning if rcs is 
not
   installed and recommand to install rcs from base (or if noone claim using the
   feature I will just remove the functionality and only keep the default
   behaviour aka keep one backup copy).
- people uses rcs to handle configuration files in /etc for example. for those
   multiple compatible alternatives are available in ports:
   * rcs57: a copy of the latest version of GNU rcs in base before removal
 (GPLv2)
   * rcs: latest GNU rcs version (GPLv3)

I haven't gone the direction of importing OpenRCS (BSD licensed version from
OpenBSD) as it needs way more work to be 100% compatible with latest version of
GNU rcs.

How to proceed:
- First turn off GNU rcs by default for a couple of month.
- Totally remove GNU rcs if no blockers has been raised.

Best regards,
Bapt

\o/

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

[Baptiste Daroussin]

On Sun, Sep 11, 2016 at 10:17:26AM -0600, Warner Losh wrote:
> On Sun, Sep 11, 2016 at 7:38 AM, Baptiste Daroussin <b...@freebsd.org> 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.
> >
> > GNU rcs is a GPLv2 software with newer version being GPLv3 preventing any
> > updates/fixes.
> >
> > From previous discussions there were issues that has been raised in previous
> > attempts:
> > - ident(1) is still useful given we still have Keywords in our sources. It 
> > has
> >   been replaced by a BSD Licensed version (enhanced to improve compatibility
> >   with Subversion Keyword) for FreeBSD 11. So that tool will remain in base
> >   after removal of GNU rcs.
> 
> So no affect.
> 
> > - etc-update uses merge(1) from GNU rcs, this has been changed in head to 
> > use
> >   diff3 instead.
> 
> Also no effect. Is our diff3 still the gpl'd one, or has bsd-diff
> finally grown that functionality?

Not yet bsd diff and bsd diff3 are very far from mature, however the sdiff(1)
part has landed as I have finished it. I still have plans for other diff
components.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [RFC] remove GNU rcs from FreeBSD 12

[Warner Losh]

On Sun, Sep 11, 2016 at 7:38 AM, Baptiste Daroussin <b...@freebsd.org> 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.
>
> GNU rcs is a GPLv2 software with newer version being GPLv3 preventing any
> updates/fixes.
>
> From previous discussions there were issues that has been raised in previous
> attempts:
> - ident(1) is still useful given we still have Keywords in our sources. It has
>   been replaced by a BSD Licensed version (enhanced to improve compatibility
>   with Subversion Keyword) for FreeBSD 11. So that tool will remain in base
>   after removal of GNU rcs.

So no affect.

> - etc-update uses merge(1) from GNU rcs, this has been changed in head to use
>   diff3 instead.

Also no effect. Is our diff3 still the gpl'd one, or has bsd-diff
finally grown that functionality?

> - rc.subr allows to use rcs for the backup file functionality. This
>   functionality is off by default as such I plan to make a warning if rcs is 
> not
>   installed and recommand to install rcs from base (or if noone claim using 
> the
>   feature I will just remove the functionality and only keep the default
>   behaviour aka keep one backup copy).

Works for me. I didn't even know this existed. From mall evidence I
can find, it looks like I stopped using RCS entirely in about 1999,
and that's 5 years after I moved to CVS for most things.

> - people uses rcs to handle configuration files in /etc for example. for those
>   multiple compatible alternatives are available in ports:
>   * rcs57: a copy of the latest version of GNU rcs in base before removal
> (GPLv2)
>   * rcs: latest GNU rcs version (GPLv3)

This is in line with what we've told people in the past. If I want to
play rogue, I have to install a port...

> I haven't gone the direction of importing OpenRCS (BSD licensed version from
> OpenBSD) as it needs way more work to be 100% compatible with latest version 
> of
> GNU rcs.

If people want it, they can make it a port...

> How to proceed:
> - First turn off GNU rcs by default for a couple of month.
> - Totally remove GNU rcs if no blockers has been raised.

Works for me.

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

[Pedro Giffuni]

+1 to removing GNU RCS.

FWIW;

I did bring OpenRCS to the vendor area:

https://svnweb.freebsd.org/base/vendor/OpenBSD/dist/usr.bin/rcs/

And I have a patch so that it builds on FreeBSD:

https://people.freebsd.org/~pfg/patches/openrcs.diff

It is known to NOT pass the GNU RCS testsuite and I lost interest in it.

Pedro.

___
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

[David Wolfskill]

On Sun, Sep 11, 2016 at 03:38:04PM +0200, Baptiste Daroussin wrote:
> ...
> 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.
> 
> GNU rcs is a GPLv2 software with newer version being GPLv3 preventing any
> updates/fixes.

Err... yeah. :-/  I was using RCS before it was GPLed :-(

> From previous discussions there were issues that has been raised in previous
> attempts:
> ...
> - people uses rcs to handle configuration files in /etc for example. for those
>   multiple compatible alternatives are available in ports:
>   * rcs57: a copy of the latest version of GNU rcs in base before removal
> (GPLv2)
>   * rcs: latest GNU rcs version (GPLv3)

Right; I'm one of those (folks who use RCS for local config files and
the like).  As well as Web pages, xfig files

> I haven't gone the direction of importing OpenRCS (BSD licensed version from
> OpenBSD) as it needs way more work to be 100% compatible with latest version 
> of
> GNU rcs.

Hmm  If there were a FreeBSD port for OpenRCS, I'd be interested in
poking at it  I'm not even at all sure that I need "100%
compatib[ility]" with any version of a GPLed RCS.  (Indeed; I may not
*want* such compatibility)

> How to proceed:
> - First turn off GNU rcs by default for a couple of month.
> - Totally remove GNU rcs if no blockers has been raised.
> 

OK; warning received. :-}  Thanks

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

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


signature.asc
Description: PGP signature

Re: [RFC] remove GNU rcs from FreeBSD 12

[Baptiste Daroussin]

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.
> 
> GNU rcs is a GPLv2 software with newer version being GPLv3 preventing any
> updates/fixes.
> 
> From previous discussions there were issues that has been raised in previous
> attempts:
> - ident(1) is still useful given we still have Keywords in our sources. It has
>   been replaced by a BSD Licensed version (enhanced to improve compatibility
>   with Subversion Keyword) for FreeBSD 11. So that tool will remain in base
>   after removal of GNU rcs.
> - etc-update uses merge(1) from GNU rcs, this has been changed in head to use
>   diff3 instead.
> - rc.subr allows to use rcs for the backup file functionality. This
>   functionality is off by default as such I plan to make a warning if rcs is 
> not
>   installed and recommand to install rcs from base (or if noone claim using 
> the
>   feature I will just remove the functionality and only keep the default
>   behaviour aka keep one backup copy).
> - people uses rcs to handle configuration files in /etc for example. for those
>   multiple compatible alternatives are available in ports:
>   * rcs57: a copy of the latest version of GNU rcs in base before removal
> (GPLv2)
>   * rcs: latest GNU rcs version (GPLv3)
> 
> I haven't gone the direction of importing OpenRCS (BSD licensed version from
> OpenBSD) as it needs way more work to be 100% compatible with latest version 
> of
> GNU rcs.
> 
> How to proceed:
> - First turn off GNU rcs by default for a couple of month.
> - Totally remove GNU rcs if no blockers has been raised.
> 
> Best regards,
> Bapt

I forgot to say freebsd-update uses merge(1) and which I will replaced with
diff3(1).

Best regards,
Bapt


signature.asc
Description: PGP signature

[RFC] remove GNU rcs from FreeBSD 12

[Baptiste Daroussin]

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.

GNU rcs is a GPLv2 software with newer version being GPLv3 preventing any
updates/fixes.

From previous discussions there were issues that has been raised in previous
attempts:
- ident(1) is still useful given we still have Keywords in our sources. It has
  been replaced by a BSD Licensed version (enhanced to improve compatibility
  with Subversion Keyword) for FreeBSD 11. So that tool will remain in base
  after removal of GNU rcs.
- etc-update uses merge(1) from GNU rcs, this has been changed in head to use
  diff3 instead.
- rc.subr allows to use rcs for the backup file functionality. This
  functionality is off by default as such I plan to make a warning if rcs is not
  installed and recommand to install rcs from base (or if noone claim using the
  feature I will just remove the functionality and only keep the default
  behaviour aka keep one backup copy).
- people uses rcs to handle configuration files in /etc for example. for those
  multiple compatible alternatives are available in ports:
  * rcs57: a copy of the latest version of GNU rcs in base before removal
(GPLv2)
  * rcs: latest GNU rcs version (GPLv3)

I haven't gone the direction of importing OpenRCS (BSD licensed version from
OpenBSD) as it needs way more work to be 100% compatible with latest version of
GNU rcs.

How to proceed:
- First turn off GNU rcs by default for a couple of month.
- Totally remove GNU rcs if no blockers has been raised.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: What to do about RCS/OpenRCS

[Lars Engels]

On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote:
 Maybe off-topic, but functionality-wise it might make much more sense to
 import Fossil. RCS has too many limitations this day and age when better
 tools are available. Of course, this would require people to learn
 something new, which I know can be a challenge.

I really like fossil. But it's still under development, so it would soon
be outdated. It's better installed from ports/packages.


pgpdrB812fhDT.pgp
Description: PGP signature

Re: What to do about RCS/OpenRCS

[Jos Backus]

On May 11, 2015 2:31 AM, Lars Engels lars.eng...@0x20.net wrote:

 On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote:
  Maybe off-topic, but functionality-wise it might make much more sense to
  import Fossil. RCS has too many limitations this day and age when better
  tools are available. Of course, this would require people to learn
  something new, which I know can be a challenge.

 I really like fossil. But it's still under development, so it would soon
 be outdated. It's better installed from ports/packages.

It seems OpenRCS is still under development ;-p It's better installed from
ports/packages, too.

It would give Fossil a recognition boost as a BSD-licensed DVCS.

Jos
___
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: What to do about RCS/OpenRCS

[Steve Kargl]

On Mon, May 11, 2015 at 09:12:57AM -0700, Jos Backus wrote:
On May 11, 2015 9:10 AM, Steve Kargl s...@troutmask.apl.washington.edu
 wrote:

 On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote:
 On May 11, 2015 2:31 AM, Lars Engels lars.eng...@0x20.net wrote:

 On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote:
 Maybe off-topic, but functionality-wise it might make
 much more sense to import Fossil. RCS has too many limitations
 this day and age when better
 tools are available. Of course, this would require people to learn
 something new, which I know can be a challenge.

 I really like fossil. But it's still under development, so it
 would soon be outdated. It's better installed from ports/packages.

 It seems OpenRCS is still under development ;-p It's better
 installed from ports/packages, too.

 It would give Fossil a recognition boost as a BSD-licensed DVCS.


 Please, just stop.  Thanks.
 
 Like I said, a challenge.
 

You've completely missed the point.  OpenRCS is intended
to replace ancient GNU RCS, which is already included in the
base system and used by a few scripts.  Fossil is not a 
drop-in replacement for the rcs utilities.  

So, please just stop.

PS: Please reply to the list not directly to me.  CC stored.

-- 
Steve
___
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: What to do about RCS/OpenRCS

[Ian Lepore]

On Mon, 2015-05-11 at 09:27 -0700, Jos Backus wrote:
 On May 11, 2015 9:21 AM, Steve Kargl s...@troutmask.apl.washington.edu
 wrote:
 
  On Mon, May 11, 2015 at 09:12:57AM -0700, Jos Backus wrote:
  On May 11, 2015 9:10 AM, Steve Kargl s...@troutmask.apl.washington.edu
   wrote:
  
   On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote:
   On May 11, 2015 2:31 AM, Lars Engels lars.eng...@0x20.net wrote:
  
   On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote:
   Maybe off-topic, but functionality-wise it might make
   much more sense to import Fossil. RCS has too many limitations
   this day and age when better
   tools are available. Of course, this would require people to learn
   something new, which I know can be a challenge.
  
   I really like fossil. But it's still under development, so it
   would soon be outdated. It's better installed from ports/packages.
  
   It seems OpenRCS is still under development ;-p It's better
   installed from ports/packages, too.
  
   It would give Fossil a recognition boost as a BSD-licensed DVCS.
  
  
   Please, just stop.  Thanks.
  
   Like I said, a challenge.
  
 
  You've completely missed the point.  OpenRCS is intended
  to replace ancient GNU RCS, which is already included in the
  base system and used by a few scripts.  Fossil is not a
  drop-in replacement for the rcs utilities.
 
 I didn't miss anything. My point is that debating to update one piece of
 obsolete software with another is silly, and that FreeBSD should try to
 move forward in this area. But that's hard, as your response indicates.
 
 This is the last I'll say about this, because it appears the community
 isn't ready. Have fun with your ancient version control while Linux
 continues to grow in market share. :-(

So you're saying that it's not that you're missing the point, it's just
that you're trolling the list.  That will be remembered.

(Of course, it's clear to those who've actually read the thread that you
are in fact completely missing the point.)

-- Ian


___
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: What to do about RCS/OpenRCS

[Jos Backus]

On May 11, 2015 9:21 AM, Steve Kargl s...@troutmask.apl.washington.edu
wrote:

 On Mon, May 11, 2015 at 09:12:57AM -0700, Jos Backus wrote:
 On May 11, 2015 9:10 AM, Steve Kargl s...@troutmask.apl.washington.edu
  wrote:
 
  On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote:
  On May 11, 2015 2:31 AM, Lars Engels lars.eng...@0x20.net wrote:
 
  On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote:
  Maybe off-topic, but functionality-wise it might make
  much more sense to import Fossil. RCS has too many limitations
  this day and age when better
  tools are available. Of course, this would require people to learn
  something new, which I know can be a challenge.
 
  I really like fossil. But it's still under development, so it
  would soon be outdated. It's better installed from ports/packages.
 
  It seems OpenRCS is still under development ;-p It's better
  installed from ports/packages, too.
 
  It would give Fossil a recognition boost as a BSD-licensed DVCS.
 
 
  Please, just stop.  Thanks.
 
  Like I said, a challenge.
 

 You've completely missed the point.  OpenRCS is intended
 to replace ancient GNU RCS, which is already included in the
 base system and used by a few scripts.  Fossil is not a
 drop-in replacement for the rcs utilities.

I didn't miss anything. My point is that debating to update one piece of
obsolete software with another is silly, and that FreeBSD should try to
move forward in this area. But that's hard, as your response indicates.

This is the last I'll say about this, because it appears the community
isn't ready. Have fun with your ancient version control while Linux
continues to grow in market share. :-(

Jos

 So, please just stop.

 PS: Please reply to the list not directly to me.  CC stored.

 --
 Steve
___
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: What to do about RCS/OpenRCS

[Steve Kargl]

On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote:
 On May 11, 2015 2:31 AM, Lars Engels lars.eng...@0x20.net wrote:
 
  On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote:
   Maybe off-topic, but functionality-wise it might make much more sense to
   import Fossil. RCS has too many limitations this day and age when better
   tools are available. Of course, this would require people to learn
   something new, which I know can be a challenge.
 
  I really like fossil. But it's still under development, so it would soon
  be outdated. It's better installed from ports/packages.
 
 It seems OpenRCS is still under development ;-p It's better installed from
 ports/packages, too.
 
 It would give Fossil a recognition boost as a BSD-licensed DVCS.
 

Please, just stop.  Thanks.

-- 
Steve
___
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: What to do about RCS/OpenRCS

[Jos Backus]

On May 11, 2015 9:33 AM, David Chisnall thera...@freebsd.org wrote:
[snip]

 And now you’re moving beyond missing the point and just trolling.

Thanks for the ad hominen, David. You continue to make my point.

Over and out,
Jos

 David

___
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: What to do about RCS/OpenRCS

[David Chisnall]

On 11 May 2015, at 17:27, Jos Backus j...@catnook.com wrote:
 
 I didn't miss anything. My point is that debating to update one piece of
 obsolete software with another is silly, and that FreeBSD should try to
 move forward in this area. But that's hard, as your response indicates.

Steve is correct, and you are missing the point.  Fossil, Git, Mercurial, and 
so on are all available as packages.  No one is suggesting using RCS in 
preference to any of them.  

Deleting RCS from the base system would be nice, but unfortunately we can’t 
because of scripts that depend on some components of RCS.  Replacing these with 
the OpenRCS equivalents (if they work) would allow us to remove a GPL’d piece 
of code from the base system.  As long as this doesn’t come with a 
functionality regression, this would be a nice thing to do.

Replacing RCS in the base system with Fossil solves no problems that actually 
exist.  It does not allow the scripts that rely on RCS to continue to work and 
it does not make Fossil easier to use (would you really want to stick with the 
one in the base system for the entire lifetime of a major release, rather than 
use the packaged one?).  It would only make sense if we were to move FreeBSD 
development to Fossil and currently there are a few showstoppers in Fossil that 
prevent this.

 This is the last I'll say about this, because it appears the community
 isn't ready. Have fun with your ancient version control while Linux
 continues to grow in market share. :-(

And now you’re moving beyond missing the point and just trolling.

David

___
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: What to do about RCS/OpenRCS

[Pedro Giffuni]

On 05/08/15 15:59, Davide Italiano wrote:

On Fri, May 8, 2015 at 1:34 PM, Pedro Giffuni p...@freebsd.org wrote:

Hi;



I guess I see the following options:

1) Just leave GNU RCS in the tree.

2) Improve OpenRCS so it can be swapped in.

3) Remove RCS dependencies from other parts of the tree (e.g.
etcupdate)
   and import just a /bin/ident binary (perhaps from OpenRCS).

Both 2) and 3) require some work.  I suspect 3) requires less. :)


I honestly don't see a real problem with (1): we do want to replace as much
GNU
software as we can but not at the cost of making our life unnecessarily
difficult.


To be honest I'm not entirely sure what's the real reason of this
crusade. FreeBSD can't import newer version of some components of the
toolchain (e.g. compiler, linker, debugger) and some of them are
slowly (or less slowly) bitrotting. I feel that in that case there's a
real goal which justifies all the headache derived from the
conversion.


Having a consistent license for all the OS has important
advantages. The main principle is that while we are fine
about sharing and having other people re-use our code
we don't really want to have to check with a lawyer before
taking any decision.

Some years ago, this was basically impossible due to the
toolchain, now it seems possible although it certainly
requires more work.


   For GNU RCS, I'm not completely sure there is. I've never
heard anybody complaining about lack of features for RCS or bugs.
My $0.02, I suspect very few people really rely on it and just
complain for the sake of doing it, but I'm not gonna argue on this
further.


I think there are legitimate reasons for having it in base.


That said, unfortunately there's a lot more than doing the conversion
and fixing the code so that the testsuite will pass.
You need to upstream the fixes and so deal with another layer and
other maintainers otherwise the code in base and the one upstream will
diverge.


We do that with GNU code anyways. The latest (GPLv3) version
of RCS has already diverged and is incompatible for some third
party software so we basically ran out of support from upstream.
OpenRCS has it's own share of problems but generally we can work
with the OpenBSD maintainers to get things to improve.

I think I found the issue at hand and the code has an

/* XXX: This is wrong ... */

Which doesn't really get me nearer to a solution but at least
upstream knows where to look. We can wait.


People rely from time to time on bugs of old software (e.g. single vs
double dash options) and are gonna complain.
The testsuite, even if comprehensive, unlikely will cover some corner
cases and suddenly software will start breaking. In other words, a lot
of (unneeded) work for you for a software that just worked fine(TM)
until yesterday.
I'm not gonna stop you from doing this, but I learned the hard way
that it's something that can/should be avoided unless really necessary
(and a better license doesn't seem to be a strong enough reason,
IMHO).



No one (or at least not me) is going to replace GNU RCS with
something of considerable less quality just for the license.

Pedro.
___
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: What to do about RCS/OpenRCS

[Lyndon Nerenberg]

On May 9, 2015, at 8:05 AM, Pedro Giffuni p...@freebsd.org wrote:

 We do that with GNU code anyways. The latest (GPLv3) version
 of RCS has already diverged and is incompatible for some third
 party software so we basically ran out of support from upstream.
 OpenRCS has it's own share of problems but generally we can work
 with the OpenBSD maintainers to get things to improve.

But really, how often does the RCS code change?  This is a piece of software 
you get running once, and then leave alone.  The last thing we want is for it 
to start growing features :-P

There seems to be an ever-increasing paranoia about adopting code in the base.  
Are we going to end up at the point where /usr/src/ is nothing but a bunch of 
Makefiles with VPATH pointed at /usr/src/contrib?  I get it for large outside 
components that are moving targets (e.g. llvm).  But RCS?  I think the paranoia 
might be a bit overdone in this case.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: What to do about RCS/OpenRCS

[Jos Backus]

Maybe off-topic, but functionality-wise it might make much more sense to
import Fossil. RCS has too many limitations this day and age when better
tools are available. Of course, this would require people to learn
something new, which I know can be a challenge.

Jos
___
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: What to do about RCS/OpenRCS

[Pedro Giffuni]

Hi;

On 08/05/2015 10:44 a.m., John Baldwin wrote:

On Thursday, May 07, 2015 04:18:38 PM NGie Cooper wrote:

On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni p...@freebsd.org wrote:

Hello;

On 05/07/15 14:56, Lyndon Nerenberg wrote:

On Thu, 7 May 2015, Pedro Giffuni wrote:


Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.


If we can have a build-knob to disable GNU RCS and enable the new one I
will happily twist up the new version and hammer on it.


Yes, that's usually the next step in the process. It is a little bit messy
because
there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
perhaps something else that we don't use).

I really want to check out first if there is some strong opinion against
OpenRCS. Perhaps someone that has used it before and thinks it is a
bad idea.

It looks like there are voices against it, so those have to be addressed
first.

Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs
bits); check with jhb first to make sure that OpenRCS works with
etcupdate.
Cheers!

I think this can be fixed by using diff3 instead of merge, I just haven't
sat down and figured out the correct incantation.

That said, I think that having a not-quite-working rcs (OpenRCS) in base
is worse than having no rcs.  If OpenRCS is improved as per Xin's notes
then just switching over is probably the path of least resistance.


To be honest, I just want to have options, and unfortunately OpenRCS is 
not one

at this time.


I guess I see the following options:

   1) Just leave GNU RCS in the tree.

   2) Improve OpenRCS so it can be swapped in.

   3) Remove RCS dependencies from other parts of the tree (e.g. etcupdate)
  and import just a /bin/ident binary (perhaps from OpenRCS).

Both 2) and 3) require some work.  I suspect 3) requires less. :)


I honestly don't see a real problem with (1): we do want to replace as 
much GNU
software as we can but not at the cost of making our life unnecessarily 
difficult.


No. 2 is something that has to be reported/submitted upstream before we can
adopt it. We do that with major components we take from other places and
it is the proven, safe way to do it.

No. 3 is something that seems necessary in any case: apparently the 
WITHOUT_RCS

option has been always broken.

I am currently reporting (2), but doing the /bin/ident part of (3) looks 
easy enough

that I may do it at a later time ;).

Pedro.

___
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: What to do about RCS/OpenRCS

[John Baldwin]

On Thursday, May 07, 2015 04:18:38 PM NGie Cooper wrote:
 On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni p...@freebsd.org wrote:
  Hello;
 
  On 05/07/15 14:56, Lyndon Nerenberg wrote:
 
  On Thu, 7 May 2015, Pedro Giffuni wrote:
 
  Unfortunately I don't use RCS enough (it looks like I should though) so
  I am not in a good position to take the next step and deal with any
  fallout it may produce.
 
 
  If we can have a build-knob to disable GNU RCS and enable the new one I
  will happily twist up the new version and hammer on it.
 
 
  Yes, that's usually the next step in the process. It is a little bit messy
  because
  there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
  perhaps something else that we don't use).
 
  I really want to check out first if there is some strong opinion against
  OpenRCS. Perhaps someone that has used it before and thinks it is a
  bad idea.
 
  It looks like there are voices against it, so those have to be addressed
  first.
 
 Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs
 bits); check with jhb first to make sure that OpenRCS works with
 etcupdate.
 Cheers!

I think this can be fixed by using diff3 instead of merge, I just haven't
sat down and figured out the correct incantation.

That said, I think that having a not-quite-working rcs (OpenRCS) in base
is worse than having no rcs.  If OpenRCS is improved as per Xin's notes
then just switching over is probably the path of least resistance.

I guess I see the following options:

  1) Just leave GNU RCS in the tree.

  2) Improve OpenRCS so it can be swapped in.

  3) Remove RCS dependencies from other parts of the tree (e.g. etcupdate)
 and import just a /bin/ident binary (perhaps from OpenRCS).

Both 2) and 3) require some work.  I suspect 3) requires less. :)

-- 
John Baldwin
___
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: What to do about RCS/OpenRCS

[Davide Italiano]

On Fri, May 8, 2015 at 1:34 PM, Pedro Giffuni p...@freebsd.org wrote:
 Hi;


 I guess I see the following options:

1) Just leave GNU RCS in the tree.

2) Improve OpenRCS so it can be swapped in.

3) Remove RCS dependencies from other parts of the tree (e.g.
 etcupdate)
   and import just a /bin/ident binary (perhaps from OpenRCS).

 Both 2) and 3) require some work.  I suspect 3) requires less. :)


 I honestly don't see a real problem with (1): we do want to replace as much
 GNU
 software as we can but not at the cost of making our life unnecessarily
 difficult.


To be honest I'm not entirely sure what's the real reason of this
crusade. FreeBSD can't import newer version of some components of the
toolchain (e.g. compiler, linker, debugger) and some of them are
slowly (or less slowly) bitrotting. I feel that in that case there's a
real goal which justifies all the headache derived from the
conversion.  For GNU RCS, I'm not completely sure there is. I've never
heard anybody complaining about lack of features for RCS or bugs.
My $0.02, I suspect very few people really rely on it and just
complain for the sake of doing it, but I'm not gonna argue on this
further.

That said, unfortunately there's a lot more than doing the conversion
and fixing the code so that the testsuite will pass.
You need to upstream the fixes and so deal with another layer and
other maintainers otherwise the code in base and the one upstream will
diverge.
People rely from time to time on bugs of old software (e.g. single vs
double dash options) and are gonna complain.
The testsuite, even if comprehensive, unlikely will cover some corner
cases and suddenly software will start breaking. In other words, a lot
of (unneeded) work for you for a software that just worked fine(TM)
until yesterday.
I'm not gonna stop you from doing this, but I learned the hard way
that it's something that can/should be avoided unless really necessary
(and a better license doesn't seem to be a strong enough reason,
IMHO).

-- 
Davide

There are no solved problems; there are only problems that are more
or less solved -- Henri Poincare
___
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

What to do about RCS/OpenRCS

[Pedro Giffuni]

Hello;

Some of you might recall that right before 10.0-Release there was
a painful attempt to remove GNU RCS from the base system.

From my point of view, the lessons learned from that were:

-A lot more people than you might think find it useful to have
a small version control system for thing like the files in /etc.
-Just removing features without a discussion is not wise.
-IMHO, people wondering about the bloat in the OS should
focus on other bigger VCS we carry, namely svn.

For all I know, it looks like OpenRCS is the most viable option and can
completely replace the old RCS we have in base.

In order to avoid painful surprises late in the release cycle, I started
the process to consider OpenRCS by bringing it to the vendor area
(OpenBSD/usr.bin/rcs/*). I also have an initial patch[1] so that it builds
on FreeBSD.

Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.

All in all, it looks like whatever is done about RCS it may be controversial
so I am opening the discussion in the hope that someone else will
take the lead and do something about it much ahead of 11-Release.

Regards,

Pedro.

[1] Follow the link in:
https://wiki.freebsd.org/GPLinBase
___
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: What to do about RCS/OpenRCS

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/07/15 12:09, Pedro Giffuni wrote:
 Hello;
 
 Some of you might recall that right before 10.0-Release there was a
 painful attempt to remove GNU RCS from the base system.
 
 From my point of view, the lessons learned from that were:
 
 -A lot more people than you might think find it useful to have a
 small version control system for thing like the files in /etc. 
 -Just removing features without a discussion is not wise. -IMHO,
 people wondering about the bloat in the OS should focus on other
 bigger VCS we carry, namely svn.
 
 For all I know, it looks like OpenRCS is the most viable option and
 can completely replace the old RCS we have in base.

I have objected this in 2013 because OpenRCS did not pass GNU RCS's
test suite:

https://lists.freebsd.org/pipermail/freebsd-current/2013-October/045185.
html

More specifically:

+ : -Dhas_conf_h
+ : cc
+ : diff
+ CL='cc -Dhas_conf_h  -o a.out'
+ L=''
+ RCSINIT=-x
+ export RCSINIT
+ SLASH=/
+ RCSfile=RCS/a.c
+ RCS_alt=RCS/a.d
+ lockfile=RCS/a._
+ q=-q
+ test -d RCS
+ rmdir=rmdir
+ mkdir RCS
+ rm -f 'a.*' RCS/a.c RCS/a.d RCS/a._
+ echo 1.1
+ echo 1.1.1.1
+ echo 1.2
+ diff -c a.11 a.3x1
+ diff='diff -c'
+ rcs -i -L -ta.11 -q a.c
+ test -r RCS/a.c
+ rlog a.c
+ rm -f RCS/a.c
+ cp a.11 a.c
+ ci -ta.11 -mm -q a.c
+ test -r RCS/a.c
+ rcs -L -q a.c
+ test ! -f a.c
+ co -q a.c
+ test -f a.c
+ diff -c a.11 a.c
+ co -l -q a.c
+ test -f a.c
+ diff -c a.11 a.c
+ cp a.12 a.c
+ ci -mm -q a.c
+ co -q a.c
+ diff -c a.12 a.c
+ rm -f a.c
+ co -r1.1 -q a.c
+ diff -c a.11 a.c
+ rm -f a.c
+ cp a.3x1 a.c
+ ci -r1.1.1 -mm -q a.c
ci: RCS/a.c: no lock set by delphij
+ echo '#branches failed'
#branches failed
+ exit 1

The checkout as of today ported to FreeBSD still does not pass the
test cases, so I still object the replacement unless the issues have
been taken care of.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVS8j7AAoJEJW2GBstM+nsUR4P/1X9hvotuBLzjgY1S6389HJP
3FXoT0+xjJqW0L6Ke5wGJy01Q3awJBGG6OUgSYufZhg32uIwPbLmKKouUuscPj/p
77e+EdonjkNcKIDYurtL8ifLm6bhPUvuWX4JSPcy8SBZtehqXUF0s4WdLqISGXpM
t8iJ56AoGAffQAHEAeHzJDxf41+7Jdb8aw314aFyAAcrcH2Q3giuo6QH75psGoSy
0X3BLu7Wi0eADcTgvLps6eJ6Uwwt+FbCKFySqkNeiXy9+LRnNg8lGUyzHp1gwSJW
5KQ9l+8vFabnAkwVZWkwnZ0mFZRRu24Ui97nwfLOrv0fDYflZIcmfEQQUHTZNp5Z
zsZEulU9MZDA10LgNvIAr4rsDDa41HOY3KA89rGuWXQpxZUOwzibWNnNfHOJIW9c
b4rGJ+femjr5wllvjG3vURGS6mkPvtLt7e/nO4pAZ+ev06KBLQAp+qd3RCjFPMRw
+cFpFXwSN+O2e6aQbYLduk18UAJFLkZf/1tH1AaO4pnjxyM3liZeE5oeIVoqUVMu
2iNNyb15Vk7dJL2DIam1MSX4UA+mCLgsJ6m+SIbigB6zYusUm2vPbDkx+e82fnhu
QlXml8k+ZQjZm6nZl45l2yaRmhRyIVq2b4GgiC6zG/WUfn4mSju83gI2hEfuGqhj
VgaTuJMDK6pjCpTKfA/B
=di1X
-END PGP SIGNATURE-
___
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: What to do about RCS/OpenRCS

[Lyndon Nerenberg]

On Thu, 7 May 2015, Pedro Giffuni wrote:


Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.


If we can have a build-knob to disable GNU RCS and enable the new one I 
will happily twist up the new version and hammer on it.


___
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: What to do about RCS/OpenRCS

[NGie Cooper]

On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni p...@freebsd.org wrote:
 Hello;

 On 05/07/15 14:56, Lyndon Nerenberg wrote:

 On Thu, 7 May 2015, Pedro Giffuni wrote:

 Unfortunately I don't use RCS enough (it looks like I should though) so
 I am not in a good position to take the next step and deal with any
 fallout it may produce.


 If we can have a build-knob to disable GNU RCS and enable the new one I
 will happily twist up the new version and hammer on it.


 Yes, that's usually the next step in the process. It is a little bit messy
 because
 there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
 perhaps something else that we don't use).

 I really want to check out first if there is some strong opinion against
 OpenRCS. Perhaps someone that has used it before and thinks it is a
 bad idea.

 It looks like there are voices against it, so those have to be addressed
 first.

Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs
bits); check with jhb first to make sure that OpenRCS works with
etcupdate.
Cheers!
___
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: What to do about RCS/OpenRCS

[Pedro Giffuni]

 Il giorno 08/mag/2015, alle ore 00:26, Doug Brewer brewer.d...@gmail.com ha 
 scritto:
 
 On Thu, May 07, 2015 at 04:18:38PM -0700, NGie Cooper wrote: 
  
  On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni p...@freebsd.org 
  mailto:p...@freebsd.org wrote: 
   Hello; 
   
   On 05/07/15 14:56, Lyndon Nerenberg wrote: 
   
   On Thu, 7 May 2015, Pedro Giffuni wrote: 
   
   Unfortunately I don't use RCS enough (it looks like I should though) so 
   I am not in a good position to take the next step and deal with any 
   fallout it may produce. 
   
   
   If we can have a build-knob to disable GNU RCS and enable the new one I 
   will happily twist up the new version and hammer on it. 
   
   
   Yes, that's usually the next step in the process. It is a little bit 
   messy 
   because 
   there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and 
   perhaps something else that we don't use). 
  
   I really want to check out first if there is some strong opinion against 
   OpenRCS. Perhaps someone that has used it before and thinks it is a 
   bad idea. 
   
   It looks like there are voices against it, so those have to be addressed 
   first. 
  
  Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs 
  bits); check with jhb first to make sure that OpenRCS works with 
  etcupdate. 
 
 Confirmed.  Pedro, are you also willing to fix fallout as Xin Li pointed out? 
 If not, please revert, thanks.


I haven’t committed anything to base so there’s nothing to revert (?).

Pedro.
 

___
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: What to do about RCS/OpenRCS

[Doug Brewer]

 On Thu, May 07, 2015 at 04:18:38PM -0700, NGie Cooper wrote:

 On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni p...@freebsd.org wrote:
  Hello;
 
  On 05/07/15 14:56, Lyndon Nerenberg wrote:
 
  On Thu, 7 May 2015, Pedro Giffuni wrote:
 
  Unfortunately I don't use RCS enough (it looks like I should though)
so
  I am not in a good position to take the next step and deal with any
  fallout it may produce.
 
 
  If we can have a build-knob to disable GNU RCS and enable the new one
I
  will happily twist up the new version and hammer on it.
 
 
  Yes, that's usually the next step in the process. It is a little bit
messy
  because
  there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
  perhaps something else that we don't use).
 
  I really want to check out first if there is some strong opinion
against
  OpenRCS. Perhaps someone that has used it before and thinks it is a
  bad idea.
 
  It looks like there are voices against it, so those have to be
addressed
  first.

 Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs
 bits); check with jhb first to make sure that OpenRCS works with
 etcupdate.

Confirmed.  Pedro, are you also willing to fix fallout as Xin Li pointed
out?
If not, please revert, thanks.
___
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: What to do about RCS/OpenRCS

[Pedro Giffuni]

Hello;

On 05/07/15 14:56, Lyndon Nerenberg wrote:

On Thu, 7 May 2015, Pedro Giffuni wrote:


Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.


If we can have a build-knob to disable GNU RCS and enable the new one 
I will happily twist up the new version and hammer on it.




Yes, that's usually the next step in the process. It is a little bit 
messy because

there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
perhaps something else that we don't use).

I really want to check out first if there is some strong opinion against
OpenRCS. Perhaps someone that has used it before and thinks it is a
bad idea.

It looks like there are voices against it, so those have to be addressed 
first.


Pedro.

___
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: BE Loader Menu (was Re: rcs)

[Kris Moore]

On 10/20/2013 20:58, Julian Elischer wrote:
 Kris.  exactly what features need to be added to the boot process to
 allow
 what you want to do, but without using grub?


Here's a list of the features we are using from grub:

For install medium:

* Hybrid DVD ISO/USB image in same file
* BIOS / UEFI loaders on same image
* Graphics support

For installed system:

* Script-able ZFS BE menus
* Options for setting default timeouts / default BEs to load, etc
* Script-able menu to boot other OS's, such as Windows / Linux
* Loads before kernel
* Graphics support (I.E. countdown indicator, wallpapers, arrow-key
support, etc)

If the native loader is able to handle the ZFS BE stuff, then I don't
see a reason why I can't make it an option in the installer, even
without graphics and the other niceties that grub brings. Is this
working in the stable/10 branch now?

-- 
Kris Moore
PC-BSD Software
iXsystems

___
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: BE Loader Menu (was Re: rcs)

[Teske, Devin]

On Oct 21, 2013, at 6:32 AM, Kris Moore wrote:

 On 10/20/2013 20:58, Julian Elischer wrote:
 Kris.  exactly what features need to be added to the boot process to
 allow
 what you want to do, but without using grub?
 
 
 Here's a list of the features we are using from grub:
 
 For install medium:
 
 * Hybrid DVD ISO/USB image in same file

I've been using ISOLINUX for that functionality since 2006.
My DRUID installer is shipped as a hybrid ISO using ISOLINUX.


 * BIOS / UEFI loaders on same image

Haven't played with UEFI yet.


 * Graphics support

ISOLINUX has that. Can we compare screens?

I really like the way ISOLINUX's vesamenu.c32 module allows
you to even go so far as to customize the scrollbar coloring (e.g.,
in the below image, notice how I've given the scrollbar a blue
color so it completes the theme).

http://twitpic.com/17z5yi

Compare that to the same menu, but previously themed in blue:
http://twitpic.com/17xas6

I wonder if grub lets you do that (scrollbar color, hilite color, and
color of header/footer text as well).


 For installed system:
 
 * Script-able ZFS BE menus

This can be achieved in loader(8) with some basic work, building
upon what we already have. Around this time last year, I actually
added code to allow scripting of the loader(8) menu, but said
functionality is still unused (waiting for some userland tool or some
C code integrated directly into loader(8) to actually start scripting
the menu-system.

Until that happens... it's just my little secret that the Forth menus
are actually scriptable from a higher language. (been trying for
years it seems to find someone whom cares to sit down and show
them how it works -- maybe at vBSDcon).


 * Options for setting default timeouts / default BEs to load, etc

I don't see why this too couldn't be done with loader(8). We already
have a timeout system for booting with defaults... and I gather that
whatever scripting there is to change the loaded defaults would take
place prior to reboot (some tool munges loader.conf and then
reboots; current defaults are displayed and after the configured
timeout, it boots with the displayed configuration).



 * Script-able menu to boot other OS's, such as Windows / Linux

Well, I use SYSLINUX for that. SYSLINUX is the same product as the
aforementioned ISOLINUX, except that it's focused on system versus
install media.

Of course... in your case, grub loads FreeBSD directly. When I use
syslinux as a bootloader, I get the FreeBSD Forth beastie menu after
selecting FreeBSD from the syslinux vesamenu.


 * Loads before kernel

Yeah, I got patches for our menu to follow suit.
http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/

(thinking abut committing it already)




 * Graphics support (I.E. countdown indicator, wallpapers, arrow-key
 support, etc)
 

Well, I don't think the countdown indicator is going to get anyone all
too excited (I believe we've had that for years).

The wallpapers of course... can't do those as a default, but I think there's
a graphical loader project -- but of course that won't service serial boot.

I've thought about using arrow keys to navigate before...

It involves implementing a whole new layer on top of the menu. One that
would use some static character (e.g., ) to show you which item you
are over (or in the case of color... we could *maybe* use ANSI reverse).
Definitely not easy. New state machine would be required. New rendering
code would be required as well. The good news though is that it would get
rid of the number prefixes).



 If the native loader is able to handle the ZFS BE stuff, then I don't
 see a reason why I can't make it an option in the installer, even
 without graphics and the other niceties that grub brings. Is this
 working in the stable/10 branch now?
 

No... just the patchset I pointed to...

http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/

Which produces the following:

http://twitpic.com/dhv2b6

Which achieves:

a. Don't load kernel before menu
b. Scripting of selections can be done via $kernels in loader.conf

What we are lacking at the moment is...

Root Device selection menu.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
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: BE Loader Menu (was Re: rcs)

[Julian Elischer]

Kris.  exactly what features need to be added to the boot process to allow
what you want to do, but without using grub?

On 10/19/13 3:39 AM, Teske, Devin wrote:

On Oct 10, 2013, at 9:42 AM, Julian Elischer wrote:


On 10/11/13 12:39 AM, Teske, Devin wrote:

On Oct 10, 2013, at 9:06 AM, Julian Elischer wrote:


On 10/10/13 1:05 AM, Teske, Devin wrote:

I'm late to the party again ;D (didn't realize the rcs thread had turned BE)

Both problems can be solved.
The loading of the kernel *after* choosing your boot device is trivial.
We've been doing it at $work for *years* (almost a decade?)

I can put that in, whenever. Probably at the same time as implementing
the live/dynamic BE menus for selecting the root device.

yeah it always pisses me of when the menu comes up after the kernel is loaded 
because 99% of the time, I'm in the menu because I want to boot a DIFFERENT 
kernel..


Same thought I had about 7 years ago. After hearing that others
(especially you, Julian) think the same thoughts...

I'm happily ready to merge a patch from VICOR to achieve this.

PLEASE!..   put it up for review somewhere...


Done...

http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/

All new code. Had to make it programmable:

http://twitpic.com/dhv2b6

See that the patch adds documentation for loader.conf(5).
It also clarifies a horrible description of start versus initialize in 
loader.4th(8).



I wonder if we can we get a reviewboard instance for the project some time?


Do let me know what you think. I went all-out on this one.


___
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: BE Loader Menu (was Re: rcs)

[Teske, Devin]

On Oct 10, 2013, at 9:42 AM, Julian Elischer wrote:

 On 10/11/13 12:39 AM, Teske, Devin wrote:
 On Oct 10, 2013, at 9:06 AM, Julian Elischer wrote:
 
 On 10/10/13 1:05 AM, Teske, Devin wrote:
 I'm late to the party again ;D (didn't realize the rcs thread had turned 
 BE)
 
 Both problems can be solved.
 The loading of the kernel *after* choosing your boot device is trivial.
 We've been doing it at $work for *years* (almost a decade?)
 
 I can put that in, whenever. Probably at the same time as implementing
 the live/dynamic BE menus for selecting the root device.
 yeah it always pisses me of when the menu comes up after the kernel is 
 loaded because 99% of the time, I'm in the menu because I want to boot a 
 DIFFERENT kernel..
 
 Same thought I had about 7 years ago. After hearing that others
 (especially you, Julian) think the same thoughts...
 
 I'm happily ready to merge a patch from VICOR to achieve this.
 PLEASE!..   put it up for review somewhere...
 

Done...

http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/

All new code. Had to make it programmable:

http://twitpic.com/dhv2b6

See that the patch adds documentation for loader.conf(5).
It also clarifies a horrible description of start versus initialize in 
loader.4th(8).


 I wonder if we can we get a reviewboard instance for the project some time?
 

Do let me know what you think. I went all-out on this one.
-- 
Devin

P.S. I probably hadn't have put so much thought into this one if it hadn't been
specifically you asking ;D but I think you know that.

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
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: BE Loader Menu (was Re: rcs)

[Juergen Lock]

In article 59.81.16944.C6136525@cdptpa-oedge02 you write:
Sorry for previous typo in From: line, missing right angle bracket at end.
Then, in a finger error, I resent that message just before finding the error 
and making the needed correction.

from Devin Teske:

 I'm late to the party again ;D (didn't realize the rcs thread had turned BE)

 Both problems can be solved.
 The loading of the kernel *after* choosing your boot device is trivial.
 We've been doing it at $work for *years* (almost a decade?)

 I can put that in, whenever. Probably at the same time as implementing
 the live/dynamic BE menus for selecting the root device.

I'd like to know how to boot FreeBSD = 9.1 with grub2.

Following the instructions under $PORTSDIR/sysutils/grub2

insmod ufs2
set root=(hd0,gpt3)
kfreebsd /boot/loader
boot

stopped working around FreeBSD 9.1-stable.

If you mean it loads the kernel but then crashes instead of booting it
then your grub2 version is missing this fix:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699002

I used Super Grub2 Disk image on the System Rescue CD written to USB stick.

 A super grub disk beta version with the mentioned fix is here:

https://forja.cenatic.es/frs/?group_id=204

(2.00s1b6, it also has fixed autodetection of FreeBSD installs.)

Recently, I built sysutils/grub2, ran mkrescue, wrote that image to the System 
Rescue USB stick and made the entry in /syslinux/syslinux.cfg, but haven't 
tested that yet.

What is the method you or PC-BSD uses?

 PC-BSD uses (more or less?) the sysutils/grub2 port that has the above
fix. (as well as zfs patches etc.)

I want to use it on FreeBSD 9.2 and 10-current.

I tried visiting pcbsd.org website but couldn't find any details.

Tom

 HTH, :)
Juergen
___
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: BE Loader Menu (was Re: rcs)

[Thomas Mueller]

from Juergen Lock:

 If you mean it loads the kernel but then crashes instead of booting it
 then your grub2 version is missing this fix:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699002

 I used Super Grub2 Disk image on the System Rescue CD written to USB stick.

  A super grub disk beta version with the mentioned fix is here:

 https://forja.cenatic.es/frs/?group_id=204

 (2.00s1b6, it also has fixed autodetection of FreeBSD installs.)

I did the download, now will copy it to the System Rescue CD USB stick and make 
the appropriate entry in syslinux.cfg .

I don't think the Super Grub2 Disk was able to load the kernel.

It led to a prompt like what I get when I escape from the boot menu to loader 
prompt.

My image resulting from mkrescue in sysutils/grub2 built from FreeBSD ports 
worked on FreeBSD 10-head, now 10-stable.

But I got the same failure on FreeBSD 9.2.

I copied /boot/kernel/kernel from the hard-drive installation to 
/boot/kernel/kernel92 on the USB-stick installation.

Then I was able to boot the USB stick, escape to loader prompt, then

unload
boot /boot/kernel/kernel92 -a -s

(or without -s for regular boot, but I was upgrading from 9.2-prerelease).

Now uname -a shows

FreeBSD amelia2 9.2-STABLE FreeBSD 9.2-STABLE #19 r256095M: Tue Oct  8 08:57:11 
UTC 2013 root@amelia2:/usr/obj/usr/src/sys/SANDY  amd64

Tom

___
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: rcs

[Outback Dingo]

On Thu, Oct 10, 2013 at 6:42 PM, Jakub Lach jakub_l...@mailplus.pl wrote:

 I have similar views. There is abundance of be-everything-for-everybody
 Linuxes
 and not enough lean and mean Unix-style kits...




however did we neglect to realize that even some ports need rcs


= clog-1.6.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
= Attempting to fetch
http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/obrien/clog-1.6.tar.gz
clog-1.6.tar.gz   100% of   17 kB   59 kBps
00m00s
=== Fetching all distfiles required by clog-1.6 for building
===  Extracting for clog-1.6
= SHA256 Checksum OK for clog-1.6.tar.gz.
===  Patching for clog-1.6
===  Applying FreeBSD patches for clog-1.6
rcsdiff: not found
patch:  can't check out file clog.c: differs from default RCS version
= Patch patch-clog.c failed to apply cleanly.
*** Error code 1

Stop.
uname -a
FreeBSD zfsroot.xxx.com 10.0-ALPHA5 FreeBSD 10.0-ALPHA5 #0: Fri Oct 11
22:41:25 EDT 2013 m...@zfsroot.xxx.com:/usr/obj/usr/src/sys/GENERIC
 amd64






 --
 View this message in context:
 http://freebsd.1045724.n5.nabble.com/rcs-tp5850096p5850951.html
 Sent from the freebsd-current mailing list archive at Nabble.com.
 ___
 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

Re: rcs

[Glen Barber]

On Fri, Oct 11, 2013 at 11:49:15PM -0400, Outback Dingo wrote:
 On Thu, Oct 10, 2013 at 6:42 PM, Jakub Lach jakub_l...@mailplus.pl wrote:
 
  I have similar views. There is abundance of be-everything-for-everybody
  Linuxes
  and not enough lean and mean Unix-style kits...
 
 
 
 
 however did we neglect to realize that even some ports need rcs
 
 
 = clog-1.6.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
 = Attempting to fetch
 http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/obrien/clog-1.6.tar.gz
 clog-1.6.tar.gz   100% of   17 kB   59 kBps
 00m00s
 === Fetching all distfiles required by clog-1.6 for building
 ===  Extracting for clog-1.6
 = SHA256 Checksum OK for clog-1.6.tar.gz.
 ===  Patching for clog-1.6
 ===  Applying FreeBSD patches for clog-1.6
 rcsdiff: not found

gjb@nucleus:~ % make -C /usr/ports/net-mgmt/clog -V PATCH_DEPENDS
rcsdiff:/usr/ports/devel/rcs

Glen



pgphfl_vpZEa1.pgp
Description: PGP signature

Re: rcs

[Outback Dingo]

On Fri, Oct 11, 2013 at 11:52 PM, Glen Barber g...@freebsd.org wrote:

 On Fri, Oct 11, 2013 at 11:49:15PM -0400, Outback Dingo wrote:
  On Thu, Oct 10, 2013 at 6:42 PM, Jakub Lach jakub_l...@mailplus.pl
 wrote:
 
   I have similar views. There is abundance of be-everything-for-everybody
   Linuxes
   and not enough lean and mean Unix-style kits...
  
  
  
  
  however did we neglect to realize that even some ports need rcs
 
 
  = clog-1.6.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
  = Attempting to fetch
 
 http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/obrien/clog-1.6.tar.gz
  clog-1.6.tar.gz   100% of   17 kB   59 kBps
  00m00s
  === Fetching all distfiles required by clog-1.6 for building
  ===  Extracting for clog-1.6
  = SHA256 Checksum OK for clog-1.6.tar.gz.
  ===  Patching for clog-1.6
  ===  Applying FreeBSD patches for clog-1.6
  rcsdiff: not found

 gjb@nucleus:~ % make -C /usr/ports/net-mgmt/clog -V PATCH_DEPENDS
 rcsdiff:/usr/ports/devel/rcs


Yupp just found it, i got it done, but thanks


 Glen


___
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: rcs

[C. P. Ghost]

On Tue, Oct 8, 2013 at 4:31 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote:

 Okay folks, can we make a call about keeping the RCS tools in the base?

 The proponents wanting to remove RCS need to speak up and make their
 technical case.


Still using RCS here and there, esp. managing /etc. Having to install
it separately on machines that are not or seldom connected would be a
pain.

On a more general note: *if* you absolutely have to kill functionality
and move it into ports, please do create a ports/freebsd category, and
move to it stuff like net/freebsd-uucp etc... This way, all code that was
previously in /usr/src would be availabel at one place.

Thanks,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
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: BE Loader Menu (was Re: rcs)

[Kris Moore]

On 10/10/2013 00:47, Thomas Mueller wrote:
 Sorry for previous typo in From: line, missing right angle bracket at end.
 Then, in a finger error, I resent that message just before finding the error 
 and making the needed correction.

 from Devin Teske:

 I'm late to the party again ;D (didn't realize the rcs thread had turned BE)
 Both problems can be solved.
 The loading of the kernel *after* choosing your boot device is trivial.
 We've been doing it at $work for *years* (almost a decade?)
 I can put that in, whenever. Probably at the same time as implementing
 the live/dynamic BE menus for selecting the root device.
 I'd like to know how to boot FreeBSD = 9.1 with grub2.

 Following the instructions under $PORTSDIR/sysutils/grub2

 insmod ufs2
 set root=(hd0,gpt3)
 kfreebsd /boot/loader
 boot

 stopped working around FreeBSD 9.1-stable.

 I used Super Grub2 Disk image on the System Rescue CD written to USB stick.

 Recently, I built sysutils/grub2, ran mkrescue, wrote that image to the 
 System Rescue USB stick and made the entry in /syslinux/syslinux.cfg, but 
 haven't tested that yet.

 What is the method you or PC-BSD uses?

 I want to use it on FreeBSD 9.2 and 10-current.

 I tried visiting pcbsd.org website but couldn't find any details.

 Tom

 ___
 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

We use the same port, but have some custom grub.d/ scripts which builds
our /boot/grub/grub.cfg files.

https://github.com/pcbsd/pcbsd/tree/master/src-sh/pc-extractoverlay/ports-overlay/usr/local/etc/grub.d

The scripts do basic stuff like parsing output of beadm and creating a
list of Boot-Environment menus to build. Along with parsing
/boot/loader.conf, /boot/device.hints and friends. Lastly it even has
code to mount each of your BEs and copy the resulting grub.cfg file into
each, so that you have a unified menu regardless of which BE you are
currently booting.

One thing that I really want to fix is detecting which kernel modules
have what depends. Currently I have to ensure that /boot/loader.conf has
both the target module + depends in order for GRUB to load them properly.

If anybody wants to help hack on these and make them more FreeBSD
generic I think it could eventually go into the ports tree for everybody.

When grub-mkconfig is run, it generates a ZFS / BE specific boot-script,
with entries that look like this:


---

submenu PC-BSD (default) - 2013-08-27 14:23 {
  menuentry Normal Bootup {
insmod zfs
search -s -l tank1
kfreebsd /ROOT/default/@/boot/kernel/kernel
kfreebsd_module /ROOT/default/@/boot/zfs/zpool.cache
type=/boot/zfs/zpool.cache
set kFreeBSD.vfs.root.mountfrom=zfs:tank1/ROOT/default
kfreebsd_module_elf /ROOT/default/@/boot/kernel/siis.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/sdhci.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/geom_journal.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/geom_mirror.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/geom_eli.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/aesni.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/zfs.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/tmpfs.ko
kfreebsd_module_elf /ROOT/default/@/boot/modules/nvidia.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/dummynet.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/ipfw_nat.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/ipdivert.ko
kfreebsd_module_elf /ROOT/default/@/boot/modules/vboxdrv.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/zlib.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/opensolaris.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/linux.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/crypto.ko
set kFreeBSD.hint.fdc.0.at=isa
set kFreeBSD.hint.fdc.0.port=0x3F0
set kFreeBSD.hint.fdc.0.irq=6
set kFreeBSD.hint.fdc.0.drq=2
set kFreeBSD.hint.fd.0.at=fdc0
set kFreeBSD.hint.fd.0.drive=0
set kFreeBSD.hint.fd.1.at=fdc0
set kFreeBSD.hint.fd.1.drive=1
set kFreeBSD.hint.atkbdc.0.at=isa
set kFreeBSD.hint.atkbdc.0.port=0x060
set kFreeBSD.hint.atkbd.0.at=atkbdc
set kFreeBSD.hint.atkbd.0.irq=1
set kFreeBSD.hint.psm.0.at=atkbdc
set kFreeBSD.hint.psm.0.irq=12
set kFreeBSD.hint.sc.0.at=isa
set kFreeBSD.hint.sc.0.flags=0x100
set kFreeBSD.hint.uart.0.at=isa
set kFreeBSD.hint.uart.0.port=0x3F8
set kFreeBSD.hint.uart.0.flags=0x10
set kFreeBSD.hint.uart.0.irq=4
set kFreeBSD.hint.uart.1.at=isa
set kFreeBSD.hint.uart.1.port=0x2F8
set kFreeBSD.hint.uart.1.irq=3
set kFreeBSD.hint.ppc.0.at=isa
set kFreeBSD.hint.ppc.0.irq=7
set kFreeBSD.hint.atrtc.0.at=isa
set kFreeBSD.hint.atrtc.0.port=0x70
set kFreeBSD.hint.atrtc.0

Re: BE Loader Menu (was Re: rcs)

[Julian Elischer]

On 10/10/13 1:05 AM, Teske, Devin wrote:


I'm late to the party again ;D (didn't realize the rcs thread had turned BE)

Both problems can be solved.
The loading of the kernel *after* choosing your boot device is trivial.
We've been doing it at $work for *years* (almost a decade?)

I can put that in, whenever. Probably at the same time as implementing
the live/dynamic BE menus for selecting the root device.


yeah it always pisses me of when the menu comes up after the kernel is 
loaded because 99% of the time, I'm in the menu because I want to boot 
a DIFFERENT kernel..








___
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: rcs

[Julian Elischer]

On 10/9/13 11:59 PM, Jos Backus wrote:

On Oct 9, 2013 5:39 AM, Kimmo Paasiala kpaas...@gmail.com wrote:

On Wed, Oct 9, 2013 at 2:03 PM, George Mitchell george+free...@m5p.com

wrote:

On 10/09/13 03:20, Hans Ottevanger wrote:

On 10/08/13 04:31, Lyndon Nerenberg wrote:

Okay folks, can we make a call about keeping the RCS tools in the

base?

The proponents wanting to remove RCS need to speak up and make their
technical case.


Technically it is quite simple: I need RCS to start versioning config
files, even before starting any customization. I know about several
others who do the same (and have not yet defected to Linux).

I would like to see RCS to be put back into the tree for 10.0. If it
really -has- to be victimized by the current anti-GPL crusade, it could
be replaced by OpenRCS in 11.

And as a long time hard-core user I would appreciate if this kind of
changes were  performed only after at least -some- public discussion.
The way this change was sneaked in (though apparently with approval of
core@),  reminds me more of a Secret Society than of an Open Source
project.

Regards,

Hans

___
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

+1, enthusiastically. -- George


+1 also to OpenRCS allthough I hate anything related to RCS/CVS with a
passion. I do however recognize the need for a simple revision control
system in the base, svnlite would fill the need maybe but it's good to
have other options too.

-Kimmo

OK, but please, can we replace RCS with Fossil in 11 then? That adds a real
improvement to FreeBSD while giving people plenty of time to prepare.

can fossil read rcs files? and how big is it compared to RCS?


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

Re: rcs

[Julian Elischer]

On 10/11/13 12:34 AM, Jos Backus wrote:
On Thu, Oct 10, 2013 at 9:10 AM, Julian Elischer jul...@freebsd.org 
mailto:jul...@freebsd.org wrote:


On 10/9/13 11:59 PM, Jos Backus wrote:

[snip]

OK, but please, can we replace RCS with Fossil in 11 then?
That adds a real
improvement to FreeBSD while giving people plenty of time to
prepare.

can fossil read rcs files? and how big is it compared to RCS?


It seems there's some thought on importing CVS repos but according 
to 'fossil help import', only the git fast-export format is supported.
In practice this means you'd loose history, yes. But it's not hard 
to keep the old RCS files somewhere else in case that history is needed.


http://www.fossil-scm.org/fossil/wiki?name=Import+CVS+Repositories

I just built devel/fossil and it yields a single binary, 
/usr/local/bin/fossil which clocks in at 1.8M. Given all the 
functionality it provides (plus it is in a similar class as git, see 
http://www.fossil-scm.org/index.html/doc/tip/www/fossil-v-git.wiki), 
I think that's a steal.


It was started by the author of SQlite. If we require some kind of 
version control system in the base that's powerful, well-maintained 
and BSD-licensed, this really seems like a no-brainer.


well since people expect RCS.. it is not a no brainer.
you are asking people to learn  a whole new tool  for functionality 
that is currently very simple..

edit file
ci -l file
add comment.




Jos
--
Jos Backus
jos at catnook.com http://catnook.com


___
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: BE Loader Menu (was Re: rcs)

[Teske, Devin]

On Oct 10, 2013, at 9:06 AM, Julian Elischer wrote:

 On 10/10/13 1:05 AM, Teske, Devin wrote:
 
 I'm late to the party again ;D (didn't realize the rcs thread had turned BE)
 
 Both problems can be solved.
 The loading of the kernel *after* choosing your boot device is trivial.
 We've been doing it at $work for *years* (almost a decade?)
 
 I can put that in, whenever. Probably at the same time as implementing
 the live/dynamic BE menus for selecting the root device.
 
 yeah it always pisses me of when the menu comes up after the kernel is loaded 
 because 99% of the time, I'm in the menu because I want to boot a DIFFERENT 
 kernel..
 

Same thought I had about 7 years ago. After hearing that others
(especially you, Julian) think the same thoughts...

I'm happily ready to merge a patch from VICOR to achieve this.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
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: BE Loader Menu (was Re: rcs)

[Julian Elischer]

On 10/11/13 12:39 AM, Teske, Devin wrote:

On Oct 10, 2013, at 9:06 AM, Julian Elischer wrote:


On 10/10/13 1:05 AM, Teske, Devin wrote:

I'm late to the party again ;D (didn't realize the rcs thread had turned BE)

Both problems can be solved.
The loading of the kernel *after* choosing your boot device is trivial.
We've been doing it at $work for *years* (almost a decade?)

I can put that in, whenever. Probably at the same time as implementing
the live/dynamic BE menus for selecting the root device.

yeah it always pisses me of when the menu comes up after the kernel is loaded 
because 99% of the time, I'm in the menu because I want to boot a DIFFERENT 
kernel..


Same thought I had about 7 years ago. After hearing that others
(especially you, Julian) think the same thoughts...

I'm happily ready to merge a patch from VICOR to achieve this.

PLEASE!..   put it up for review somewhere...

I wonder if we can we get a reviewboard instance for the project some 
time?


___
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: rcs

[Jos Backus]

On Thu, Oct 10, 2013 at 9:10 AM, Julian Elischer jul...@freebsd.org wrote:

 On 10/9/13 11:59 PM, Jos Backus wrote:

[snip]

 OK, but please, can we replace RCS with Fossil in 11 then? That adds a real
 improvement to FreeBSD while giving people plenty of time to prepare.

 can fossil read rcs files? and how big is it compared to RCS?


It seems there's some thought on importing CVS repos but according to
'fossil help import', only the git fast-export format is supported.
In practice this means you'd loose history, yes. But it's not hard to keep
the old RCS files somewhere else in case that history is needed.

http://www.fossil-scm.org/fossil/wiki?name=Import+CVS+Repositories

I just built devel/fossil and it yields a single binary,
/usr/local/bin/fossil which clocks in at 1.8M. Given all the functionality
it provides (plus it is in a similar class as git, see
http://www.fossil-scm.org/index.html/doc/tip/www/fossil-v-git.wiki), I
think that's a steal.

It was started by the author of SQlite. If we require some kind of version
control system in the base that's powerful, well-maintained and
BSD-licensed, this really seems like a no-brainer.

Jos
-- 
Jos Backus
jos at catnook.com
___
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: rcs

[Jos Backus]

On Oct 10, 2013 9:38 AM, Julian Elischer jul...@freebsd.org wrote:

 On 10/11/13 12:34 AM, Jos Backus wrote:

 On Thu, Oct 10, 2013 at 9:10 AM, Julian Elischer jul...@freebsd.org
wrote:

 On 10/9/13 11:59 PM, Jos Backus wrote:

 [snip]

 OK, but please, can we replace RCS with Fossil in 11 then? That adds a
real
 improvement to FreeBSD while giving people plenty of time to prepare.

 can fossil read rcs files? and how big is it compared to RCS?


 It seems there's some thought on importing CVS repos but according to
'fossil help import', only the git fast-export format is supported.
 In practice this means you'd loose history, yes. But it's not hard to
keep the old RCS files somewhere else in case that history is needed.

 http://www.fossil-scm.org/fossil/wiki?name=Import+CVS+Repositories

 I just built devel/fossil and it yields a single binary,
/usr/local/bin/fossil which clocks in at 1.8M. Given all the functionality
it provides (plus it is in a similar class as git, see
http://www.fossil-scm.org/index.html/doc/tip/www/fossil-v-git.wiki), I
think that's a steal.

 It was started by the author of SQlite. If we require some kind of
version control system in the base that's powerful, well-maintained and
BSD-licensed, this really seems like a no-brainer.


 well since people expect RCS.. it is not a no brainer.
 you are asking people to learn  a whole new tool  for functionality that
is currently very simple..
 edit file
 ci -l file
 add comment.

Such is the price of progress. I envy people who don't have to learn
anything new in order to stay employed  :-)

Jos





 Jos
 --
 Jos Backus
 jos at catnook.com


___
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: rcs

[Diane Bruce]

...
  OK, but please, can we replace RCS with Fossil in 11 then? That adds a
 real
  improvement to FreeBSD while giving people plenty of time to prepare.

Fossil was showing promise the last time I tried it. Quite frankly

  well since people expect RCS.. it is not a no brainer.
  you are asking people to learn  a whole new tool  for functionality that
 is currently very simple..
  edit file
  ci -l file
  add comment.

pfft as long as any SCS can read my old rcs files this old fart does
not mind.

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: rcs

[Igor Mozolevsky]

On 10 October 2013 19:15, Jos Backus j...@catnook.com wrote:

 On Oct 10, 2013 9:38 AM, Julian Elischer jul...@freebsd.org wrote:


[snip]


  well since people expect RCS.. it is not a no brainer.
   you are asking people to learn  a whole new tool  for functionality that
 is currently very simple..
  edit file
  ci -l file
  add comment.

 Such is the price of progress. I envy people who don't have to learn
 anything new in order to stay employed  :-)


So your definition of progress is doing more work to achieve the same
result?..

-- 
Igor M.
___
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: rcs

[Jos Backus]

On Oct 10, 2013 11:54 AM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:




 On 10 October 2013 19:15, Jos Backus j...@catnook.com wrote:

 On Oct 10, 2013 9:38 AM, Julian Elischer jul...@freebsd.org wrote:


 [snip]


  well since people expect RCS.. it is not a no brainer.
  you are asking people to learn  a whole new tool  for functionality
that
 is currently very simple..
  edit file
  ci -l file
  add comment.

 Such is the price of progress. I envy people who don't have to learn
 anything new in order to stay employed  :-)


 So your definition of progress is doing more work to achieve the same
result?..

That would only be true if they were equivalent, and we didn't care about
the extra features. You may not, but many people do, as the popularity of
git and other distributed version control systems proves.

Jos


 --
 Igor M.
___
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: rcs

[Igor Mozolevsky]

On 10 October 2013 20:36, Jos Backus j...@catnook.com wrote:


 On Oct 10, 2013 11:54 AM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:
 
  On 10 October 2013 19:15, Jos Backus j...@catnook.com wrote:
 
  On Oct 10, 2013 9:38 AM, Julian Elischer jul...@freebsd.org wrote:
 
 
  [snip]
 
 
   well since people expect RCS.. it is not a no brainer.
   you are asking people to learn  a whole new tool  for functionality
 that
  is currently very simple..
   edit file
   ci -l file
   add comment.
 
  Such is the price of progress. I envy people who don't have to learn
  anything new in order to stay employed  :-)
 
 
  So your definition of progress is doing more work to achieve the same
 result?..

 That would only be true if they were equivalent, and we didn't care about
 the extra features. You may not, but many people do, as the popularity of
 git and other distributed version control systems proves.


You're missing the point- the requirement is provide a way to keep track
of changes for file X not have many fancy and unnecessary features...


-- 
Igor M.
___
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: rcs

[Jos Backus]

On Oct 10, 2013 1:07 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:




 On 10 October 2013 20:36, Jos Backus j...@catnook.com wrote:


 On Oct 10, 2013 11:54 AM, Igor Mozolevsky i...@hybrid-lab.co.uk
wrote:
 
  On 10 October 2013 19:15, Jos Backus j...@catnook.com wrote:
 
  On Oct 10, 2013 9:38 AM, Julian Elischer jul...@freebsd.org wrote:
 
 
  [snip]
 
 
   well since people expect RCS.. it is not a no brainer.
   you are asking people to learn  a whole new tool  for functionality
that
  is currently very simple..
   edit file
   ci -l file
   add comment.
 
  Such is the price of progress. I envy people who don't have to learn
  anything new in order to stay employed  :-)
 
 
  So your definition of progress is doing more work to achieve the same
result?..

 That would only be true if they were equivalent, and we didn't care
about the extra features. You may not, but many people do, as the
popularity of git and other distributed version control systems proves.


 You're missing the point- the requirement is provide a way to keep track
of changes for file X not have many fancy and unnecessary features...

That may have been the requirement at the time of the RCS import but the
world has changed in my view. Feel free to use the old tools though, nobody
is saying you can't.

Anyway, why not change this for 11? Do we feel RCS is superior simply
because we are familiar with it? What about all the extra features modern
version control offers? Sounds like people think it's all a step backwards,
all we need is manage separate files. No need for changesets or any other
modern features.

I don't really understand the resistance. We're okay with importing
Subversion which has less functionally and more dependencies but a single
Fossil binary is too intrusive?

Jos


 --
 Igor M.
___
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: rcs

[C. P. Ghost]

On Thu, Oct 10, 2013 at 8:51 PM, Diane Bruce d...@db.net wrote:

 ...
   OK, but please, can we replace RCS with Fossil in 11 then? That
 adds a
  real
   improvement to FreeBSD while giving people plenty of time to
 prepare.

 Fossil was showing promise the last time I tried it. Quite frankly

   well since people expect RCS.. it is not a no brainer.
   you are asking people to learn  a whole new tool  for functionality
 that
  is currently very simple..
   edit file
   ci -l file
   add comment.

 pfft as long as any SCS can read my old rcs files this old fart does
 not mind.


Same here. Don't care about the tool, as long as it can provide backward
compatibility to the RCS format, and provides the familiar command interface
(ci, co, ...) somehow.

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
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: rcs

[Lyndon Nerenberg]

On 2013-10-10, at 1:06 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:

 You're missing the point- the requirement is provide a way to keep track
 of changes for file X not have many fancy and unnecessary features...

The point is to put back the specific RCS commands that were recently removed.

Those of us using RCS do so because it's in the base system.  If we 
wanted/needed another SCM, we would install it from ports.  But many of us use 
RCS specifically because installing a port is not an option.  *Why* it's not an 
option is not relevant.

RCS is not broken, and is very low maintenance code. /usr/src/gnu/usr.bin/rcs 
has been modified four times in the last decade.  Two of those changes were 
sweeping Makefile updates that affected much more than RCS.  Of the other two, 
only one update touched the actual code, and that was a one line change to a .h.

--lyndon

___
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: rcs

[Glen Barber]

On Thu, Oct 10, 2013 at 01:35:33PM -0700, Lyndon Nerenberg wrote:
 
 On 2013-10-10, at 1:06 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:
 
  You're missing the point- the requirement is provide a way to keep track
  of changes for file X not have many fancy and unnecessary features...
 
 The point is to put back the specific RCS commands that were recently removed.
 

http://lists.freebsd.org/pipermail/svn-src-head/2013-October/052106.html

Glen



pgpwrgyRT0jiY.pgp
Description: PGP signature

Re: rcs

[Igor Mozolevsky]

On 10 October 2013 21:18, Jos Backus j...@catnook.com wrote:


 On Oct 10, 2013 1:07 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:
 

[snip]

  You're missing the point- the requirement is provide a way to keep
 track of changes for file X not have many fancy and unnecessary
 features...

 That may have been the requirement at the time of the RCS import but the
 world has changed in my view. Feel free to use the old tools though, nobody
 is saying you can't.

 Anyway, why not change this for 11? Do we feel RCS is superior simply
 because we are familiar with it? What about all the extra features modern
 version control offers? Sounds like people think it's all a step backwards,
 all we need is manage separate files. No need for changesets or any other
 modern features.


RCS is a tool that does it's job. It's been in base since time immemoriam,
and is more likely than not to be found in other flavours of Unix(TM).
Moreover, RCS commands are integrated into a lot of scripts that sysadmins
use (it'd be naive to think otherwise), so in terms of $$$ not having RCS
in base (yup, I know the change's been reverted) has a real cost to
business!

I don't really understand the resistance. We're okay with importing
 Subversion which has less functionally and more dependencies but a single
 Fossil binary is too intrusive?


SVN is the necessary evil, the project uses it and until the project
switches to something else we're stuck with it. What's the case for
Fossil?..

-- 
Igor M.
___
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: rcs

[Jos Backus]

On Oct 10, 2013 2:20 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:




 On 10 October 2013 21:18, Jos Backus j...@catnook.com wrote:


 On Oct 10, 2013 1:07 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:
 

 [snip]

  You're missing the point- the requirement is provide a way to keep
track of changes for file X not have many fancy and unnecessary
features...

 That may have been the requirement at the time of the RCS import but the
world has changed in my view. Feel free to use the old tools though, nobody
is saying you can't.

 Anyway, why not change this for 11? Do we feel RCS is superior simply
because we are familiar with it? What about all the extra features modern
version control offers? Sounds like people think it's all a step backwards,
all we need is manage separate files. No need for changesets or any other
modern features.


 RCS is a tool that does it's job. It's been in base since time
immemoriam, and is more likely than not to be found in other flavours of
Unix(TM). Moreover, RCS commands are integrated into a lot of scripts that
sysadmins use (it'd be naive to think otherwise), so in terms of $$$ not
having RCS in base (yup, I know the change's been reverted) has a real cost
to business!

Like I said, change is hard. I'm not going to argue this any further, you
clearly have no interest in using better tools. Fine.

 I don't really understand the resistance. We're okay with importing
Subversion which has less functionally and more dependencies but a single
Fossil binary is too intrusive?


 SVN is the necessary evil, the project uses it and until the project
switches to something else we're stuck with it. What's the case for
Fossil?..

To replace RCS. But you're not interested, so I'll stop here. I have enough
trouble with Luddites at $work :-)

Jos

 --
 Igor M.
___
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: rcs

[Jakub Lach]

I have similar views. There is abundance of be-everything-for-everybody
Linuxes
and not enough lean and mean Unix-style kits...





--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/rcs-tp5850096p5850951.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
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: rcs

[Hans Ottevanger]

On 10/08/13 04:31, Lyndon Nerenberg wrote:
 Okay folks, can we make a call about keeping the RCS tools in the base?
 
 The proponents wanting to remove RCS need to speak up and make their 
 technical case.
 

Technically it is quite simple: I need RCS to start versioning config
files, even before starting any customization. I know about several
others who do the same (and have not yet defected to Linux).

I would like to see RCS to be put back into the tree for 10.0. If it
really -has- to be victimized by the current anti-GPL crusade, it could
be replaced by OpenRCS in 11.

And as a long time hard-core user I would appreciate if this kind of
changes were  performed only after at least -some- public discussion.
The way this change was sneaked in (though apparently with approval of
core@),  reminds me more of a Secret Society than of an Open Source project.

Regards,

Hans

___
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: rcs

[Daniel Nebdal]

On Tue, Oct 8, 2013 at 11:34 PM, Lev Serebryakov l...@freebsd.org wrote:
 Hello, Daniel.
 You wrote 8 октября 2013 г., 19:40:23:

 DN If they get the package repositories back up - which I assume will
 DN happen before any official releases from 10 - it should just be pkg
 DN install rcs. As challenges go, that doesn't seem too bad?
   Topic starter mentioned, that assumption that everybody has online
  connection is completely wrong! As far as I understand, it was his main
  objection -- they have a lot of offline computers at work (something
  related to Security Theatre by DHS, but who am I to judge them?).

   And you again says about pkg install rcs which needs internet
  connection!

 --
 // Black Lion AKA Lev Serebryakov l...@freebsd.org



I was answering Alfred Perlsteins claim that FreeBSD is a chore to
install packages into. I agree that it won't work without an internet
connection (or a local package repository), but that's hardly a
problem limited to FreeBSD.

Anyway, it seems likely that we'll get OpenRCS in base, hopefully
making everyone happy.

-- 
Daniel Nebdal
___
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: rcs

[George Mitchell]

On 10/09/13 03:20, Hans Ottevanger wrote:

On 10/08/13 04:31, Lyndon Nerenberg wrote:

Okay folks, can we make a call about keeping the RCS tools in the base?

The proponents wanting to remove RCS need to speak up and make their technical 
case.



Technically it is quite simple: I need RCS to start versioning config
files, even before starting any customization. I know about several
others who do the same (and have not yet defected to Linux).

I would like to see RCS to be put back into the tree for 10.0. If it
really -has- to be victimized by the current anti-GPL crusade, it could
be replaced by OpenRCS in 11.

And as a long time hard-core user I would appreciate if this kind of
changes were  performed only after at least -some- public discussion.
The way this change was sneaked in (though apparently with approval of
core@),  reminds me more of a Secret Society than of an Open Source project.

Regards,

Hans

___
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



+1, enthusiastically. -- George
___
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: rcs

[Kimmo Paasiala]

On Wed, Oct 9, 2013 at 2:03 PM, George Mitchell george+free...@m5p.com wrote:
 On 10/09/13 03:20, Hans Ottevanger wrote:

 On 10/08/13 04:31, Lyndon Nerenberg wrote:

 Okay folks, can we make a call about keeping the RCS tools in the base?

 The proponents wanting to remove RCS need to speak up and make their
 technical case.


 Technically it is quite simple: I need RCS to start versioning config
 files, even before starting any customization. I know about several
 others who do the same (and have not yet defected to Linux).

 I would like to see RCS to be put back into the tree for 10.0. If it
 really -has- to be victimized by the current anti-GPL crusade, it could
 be replaced by OpenRCS in 11.

 And as a long time hard-core user I would appreciate if this kind of
 changes were  performed only after at least -some- public discussion.
 The way this change was sneaked in (though apparently with approval of
 core@),  reminds me more of a Secret Society than of an Open Source
 project.

 Regards,

 Hans

 ___
 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


 +1, enthusiastically. -- George


+1 also to OpenRCS allthough I hate anything related to RCS/CVS with a
passion. I do however recognize the need for a simple revision control
system in the base, svnlite would fill the need maybe but it's good to
have other options too.

-Kimmo
___
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: rcs

[Julian Elischer]

On 10/8/13 11:20 PM, Alfred Perlstein wrote:

On 10/8/13 8:04 AM, sth...@nethelp.no wrote:

I think the fact is that most direct users of RCS use it in a very
simple way, and
it works just fine for that.  with no real need for any updates 
or any

change.
With all due respect Julian, The more we discuss this more this 
really
points to the problem that FreeBSD appears to be a challenge to 
install
packages into such that a package moving out of base is such a big 
deal.


Can we fix that instead?

I mean, this change should really not be a big deal, but yet it is 
and

this speaks to the core of FreeBSD utility.

Not commenting on RCS here, but on the concept of moving packages out
of the base:

- For some of us, the attraction of FreeBSD is that it is a tightly
integrated system, and the base contains enough useful functionality
that we don't *have* to add a lot of packages.

- Each package that is moved out of the base system means less useful
functionality in the base system - and for me: Less reason to use
FreeBSD instead of Linux.

I absolutely see the problem of maintaining out-of-date packages in
the base system, and the desirability of making the base system less
reliant on GPL. I'm mostly troubled by the fact that there seems to
be a rather strong tendency the last few years of having steadily
less functionality in the base system - and I'm not at all convinced
that the right balance has been found here.

This discussion is not new, and I don't expect to convince any new
persons...


I'm sure other devs will disagree, but with ~15 years of FreeBSD 
experience and ~13 years as a dev, my very strong opinion is that 
this tightly coupled system is actually a boat anchor sinking us.


you are right.. I disagree :-)


Just because no one else does it a certain way, does not mean that a 
unique way of doing something is correct and/or sustainable. Maybe 
in 1995, 1999, or 2005 even, but not today.  Especially in the 
context of add-on tools like rcs.


What we need to discuss is lowering the bar to making custom installs.

I personally find that installing FreeBSD is useless until I install 
screen, zsh, vim-lite, git why is that so manual for me?  Why 
can't I just register a package set somewhere so that all I have to 
type in is alfred.perlstein.devel into a box during the installer 
and I get all my packages by default?


I agree in part.. we should have several levels of packages.. where 
the highest level is pretty much indistinguishable from what we have 
now as base utilities..  we maintian the package, but we also maintain 
the source the package pulls from. it has hte same guarantee of being 
in sync as currently we have for base utils.
 under that we have 'highly used and trusted apps'   (X11, bind, 
apache, python etc), and after that there are the others.
but until then I consider rcs a bit like awk..  something I just 
expect to be there. and use like that...





___
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: rcs

[Julian Elischer]

On 10/9/13 4:38 AM, Graham Todd wrote:


On Tue, 8 Oct 2013, Adrian Chadd wrote:

I think that's great. But, as we are increasingly finding, theres 
no stable
ports snapshot, so unless we as a project change how packages are 
managed,

there may not really be a stable, predictable version of things once
they're moved from base to a package. A number of users and 
companies like
that there is a very strict definition of base and that it wont 
change as

the ports tree changes.

Eg, you install 10.0 and get the rcs package from that. You then do an
install of 10.0 a yeat later and install rcs. If it comes from the
10-stable pkgng set, itll pick up the latest version, not the 10.0 
version.

Thats the big ports vs base difference.


Perhaps a perl style dual life module set of core (errm BASE?) 
packages/ports will emerge. It could resolve some of the perennial 
what is BASE? debates - or at least make it possible to have those 
debates in a different way :-)


My understanding is that dealing with the GPLv3 issue for BASE is 
*necessary* for the project. Since the latest rcs releases are 
licensed using GPLv3, FreeBSD's BASE rcs (GPLv2) would have to be 
maintained exclusively by the FreeBSD project - which means more 
developer overhead (the same could be said for gcc I suppose). That 
seems to be a different type of issue than the size/completeness of 
BASE itself.


but RCS is not GPLv3 and what we have works fine... just leave it alone!



Since rcs is a small utility, it's hooked into a script or two via 
rc.subr, it's useful to a lot of folks, it doesn't face the network 
and there's a BSD licensed equivalent sort of available, then maybe 
the best way to go would be to import opencvs's rcs (which is not 
part in the ports version of opencvs) to replace the GNU version.


___
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

Re: rcs

[Julian Elischer]

On 10/9/13 2:35 AM, Freddie Cash wrote:

On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein bri...@mu.org wrote:


You're right on the money, to be honest this is one of the reasons why
I've switched to using OSX as my desktop OS.

zsh, vim, screen by default.  and upgrades work.  At the end of the day
I'm spending time doing work, not mucking about my workspace to make it
usable for development.

I think this was brought up at BSDCan in the discussion about making
FreeBSD a more featured development platform.

Speaking of... has anyone tried PCBSD?


PC-BSD isn't much different from FreeBSD.  The installer is GUI and support
ZFS, there are some GUI setup tools on first boot for X, there are some GUI
tools to select binary drivers for X, and there ​​are working pkgng repos
available.

I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do things
the FreeBSD way which broke a lot of things that were done the PC-BSD
way (aka don't manually edit config files used for booting).

​Switching to the rolling-release (aka PC-BSD 9-STABLE) and moving all my
config file edits into filename.conf.local fixed my issues.  Things have
been running smooth, and I finally understand the beauty and simplicity of
freebsd-update + pkg.  OS gets updated once per month, packages get updated
twice per month, no more compiling things from source.  It's like using
Ubuntu/Debian but with the power and features of FreeBSD.  :)
​


When they went to a ZFS-only system, using GRUB, with no alternative, then I'm 
afraid they lost me.
I want a root filesystem on UFS for reliabailty and simpleness.  I can debug 
it's media if needed.
Before then I really liked it (though ther eis not enough information on how it 
works interneally if you want to use it.
hopefully that will come.. and I LIKE PBIs  FreeBSD should adopt PBIs for sure.
With PBIs you could make even quite base items separately installable. 
versioning problems go away.


___
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: rcs

[Julian Elischer]

On 10/9/13 4:59 PM, Daniel Nebdal wrote:

On Tue, Oct 8, 2013 at 11:34 PM, Lev Serebryakov l...@freebsd.org wrote:

Hello, Daniel.
You wrote 8 октября 2013 г., 19:40:23:

DN If they get the package repositories back up - which I assume will
DN happen before any official releases from 10 - it should just be pkg
DN install rcs. As challenges go, that doesn't seem too bad?
   Topic starter mentioned, that assumption that everybody has online
  connection is completely wrong! As far as I understand, it was his main
  objection -- they have a lot of offline computers at work (something
  related to Security Theatre by DHS, but who am I to judge them?).

   And you again says about pkg install rcs which needs internet
  connection!

--
// Black Lion AKA Lev Serebryakov l...@freebsd.org



I was answering Alfred Perlsteins claim that FreeBSD is a chore to
install packages into. I agree that it won't work without an internet
connection (or a local package repository), but that's hardly a
problem limited to FreeBSD.

Anyway, it seems likely that we'll get OpenRCS in base, hopefully
making everyone happy.


if it doesn't make it then we need RCS back
and it should be back now waiting for OpenRCS... until then there is a 
hole..



___
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: rcs

[Julian Elischer]

On 10/9/13 3:20 PM, Hans Ottevanger wrote:

On 10/08/13 04:31, Lyndon Nerenberg wrote:

Okay folks, can we make a call about keeping the RCS tools in the base?

The proponents wanting to remove RCS need to speak up and make their technical 
case.


Technically it is quite simple: I need RCS to start versioning config
files, even before starting any customization. I know about several
others who do the same (and have not yet defected to Linux).

I would like to see RCS to be put back into the tree for 10.0. If it
really -has- to be victimized by the current anti-GPL crusade, it could
be replaced by OpenRCS in 11.

And as a long time hard-core user I would appreciate if this kind of
changes were  performed only after at least -some- public discussion.
The way this change was sneaked in (though apparently with approval of
core@),  reminds me more of a Secret Society than of an Open Source project.


no, with private  approval of a CORE MEMBER.. that is quite a 
different thing..
Core, AFAIK has not ruled on this sort of topic.. (and actually it's 
not really it's job to do so unless it's resolving a dispute.)




Regards,

Hans

___
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

Re: [Heads Up] RCS removed from base

[Julian Elischer]

On 10/9/13 7:22 AM, Diane Bruce wrote:

On Tue, Oct 08, 2013 at 04:56:46PM -0400, Kurt Lidl wrote:

On 10/8/13 4:33 PM, Cy Schubert wrote:

In message 52542687.7000...@pix.net, Kurt Lidl writes:

On 10/8/13, Julian Elischer wrote:

On 10/7/13 11:06 PM, Steve Kargl wrote:

On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote:

Hey all,

Did it this morning

http://people.FreeBSD.org/~db/rcs.tgz

Or

http://www.db.net/~db/rcs.tgz


It's up to core@ to decide what to do.


- Diane


I think everyone knows my opinion..
I think we need an in-base *file* versioning tool .. and since many of us have 
RCS'd our /etc files,
or have install scripts that use RCS it should be RCS..

 I don't care WHICH RCS it is but it needs to be back in place by 10.
and the easiest way of having it there in the mean while is jsut to revert the 
commit until
the new one is ready.




___
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: rcs

[Alfred Perlstein]

On 10/9/13 1:59 AM, Daniel Nebdal wrote:

On Tue, Oct 8, 2013 at 11:34 PM, Lev Serebryakov l...@freebsd.org wrote:

Hello, Daniel.
You wrote 8 октября 2013 г., 19:40:23:

DN If they get the package repositories back up - which I assume will
DN happen before any official releases from 10 - it should just be pkg
DN install rcs. As challenges go, that doesn't seem too bad?
   Topic starter mentioned, that assumption that everybody has online
  connection is completely wrong! As far as I understand, it was his main
  objection -- they have a lot of offline computers at work (something
  related to Security Theatre by DHS, but who am I to judge them?).

   And you again says about pkg install rcs which needs internet
  connection!

--
// Black Lion AKA Lev Serebryakov l...@freebsd.org



I was answering Alfred Perlsteins claim that FreeBSD is a chore to
install packages into. I agree that it won't work without an internet
connection (or a local package repository), but that's hardly a
problem limited to FreeBSD.

Anyway, it seems likely that we'll get OpenRCS in base, hopefully
making everyone happy.



Only a few years ago you could take a dvd or memstick of FreeBSD and 
have 1000s of packages to choose from during your install.  That is 
broken now?


Bummer.

--
Alfred Perlstein

___
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: rcs

[Glen Barber]

On Wed, Oct 09, 2013 at 07:17:11AM -0700, Alfred Perlstein wrote:
 Only a few years ago you could take a dvd or memstick of FreeBSD and
 have 1000s of packages to choose from during your install.  That is
 broken now?
 

memstick.img always had a minimal set of packages (mostly documentation
sets).

dvd1.iso has packages.

Glen



pgpTuiodQukdP.pgp
Description: PGP signature

Re: rcs

[Benjamin Kaduk]

Going off on a slight tangent...

On Tue, 8 Oct 2013, Lyndon Nerenberg wrote:



For this to work in a disconnected environment, you need a ports tree 
with a fully populated distfiles/ directory.  The hack we came up with 
was to put a FreeBSD host on the external network, on which we ran a 
script once a week or so that would do the something like 'portsnap 
fetch update; portsclean -DD; for in in /usr/ports/*/*; (cd $i  make 
fetch); done'.


I just reviewed a documentation patch which was noting that 'make fetch' 
can be done in a category directory or even in /usr/ports itself.  Maybe a 
little more reliable than the shell loop.


-Ben Kaduk

That would give us a (mostly) populated /usr/ports/distfiles. We would 
then rsync /usr/ports from the public machine onto a USB drive. That 
drive would then be disconnected from the public machine and attached to 
an internal file server, and its /usr/ports rsynced to the file server's 
/usr/ports.

___
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: rcs

[Alfred Perlstein]

On 10/9/13 7:20 AM, Glen Barber wrote:

On Wed, Oct 09, 2013 at 07:17:11AM -0700, Alfred Perlstein wrote:

Only a few years ago you could take a dvd or memstick of FreeBSD and
have 1000s of packages to choose from during your install.  That is
broken now?


memstick.img always had a minimal set of packages (mostly documentation
sets).

dvd1.iso has packages.

Glen


Thanks Glen!

I'm just confused as to why this is such a big deal if the packages are 
available.


Do we need a package memstick now that memsticks are typically 4 or 
even 8GB?


--
Alfred Perlstein

___
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: [Heads Up] RCS removed from base

[Kurt Lidl]

On Tue, Oct 08, 2013 at 04:56:46PM -0400, Kurt Lidl wrote:

On 10/8/13 4:33 PM, Cy Schubert wrote:
 In message 52542687.7000100 at pix.net, Kurt Lidl writes:
 On 10/8/13, Julian Elischer wrote:
 On 10/7/13 11:06 PM, Steve Kargl wrote:
 On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote:
 Hey all,


Did it this morning

http://people.FreeBSD.org/~db/rcs.tgz

Or

http://www.db.net/~db/rcs.tgz



I notice in diff'ing your work vs my work, that I started with
newer revisions of some of the files than the ones you have:

 .\   $OpenBSD: ci.1,v 1.37 2011/07/14 16:31:34 sobrado Exp $
---
 .\   $OpenBSD: ci.1,v 1.38 2013/08/12 14:19:53 jmc Exp $

 /* $OpenBSD: ci.c,v 1.214 2013/01/18 11:21:09 guenther Exp $   */
---
 /* $OpenBSD: ci.c,v 1.215 2013/04/17 00:20:52 deraadt Exp $*/

 /* $OpenBSD: co.c,v 1.116 2010/12/03 19:44:58 chl Exp $*/
---
 /* $OpenBSD: co.c,v 1.117 2013/04/16 20:24:45 deraadt Exp $*/

 /* $OpenBSD: date.y,v 1.10 2010/07/31 08:54:42 ray Exp $   */
---
 /* $OpenBSD: date.y,v 1.11 2013/04/19 17:28:07 deraadt Exp $   */

 /* $OpenBSD: diff.c,v 1.33 2011/04/20 19:34:16 nicm Exp $  */
---
 /* $OpenBSD: diff.c,v 1.34 2013/05/16 12:44:48 stsp Exp $  */

 .\   $OpenBSD: ident.1,v 1.11 2011/04/19 21:17:30 jmc Exp $
---
 .\   $OpenBSD: ident.1,v 1.12 2013/06/29 09:08:41 jmc Exp $

 /* $OpenBSD: rcs.h,v 1.15 2011/07/06 15:36:52 nicm Exp $   */
---
 /* $OpenBSD: rcs.h,v 1.16 2013/06/03 17:04:35 jcs Exp $*/

 /* $OpenBSD: rcsparse.c,v 1.8 2012/02/04 21:22:32 tobias Exp $ */
---
 /* $OpenBSD: rcsparse.c,v 1.9 2013/06/03 17:04:35 jcs Exp $*/

 /* $OpenBSD: rcsutil.c,v 1.38 2010/12/06 22:52:55 chl Exp $*/
---
 /* $OpenBSD: rcsutil.c,v 1.39 2013/04/16 20:24:45 deraadt Exp $*/

 /* $OpenBSD: rlog.c,v 1.65 2011/07/14 16:38:39 sobrado Exp $   */
---
 /* $OpenBSD: rlog.c,v 1.66 2013/06/03 17:04:35 jcs Exp $   */

-Kurt

___
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: rcs

[Jos Backus]

On Oct 9, 2013 5:39 AM, Kimmo Paasiala kpaas...@gmail.com wrote:

 On Wed, Oct 9, 2013 at 2:03 PM, George Mitchell george+free...@m5p.com
wrote:
  On 10/09/13 03:20, Hans Ottevanger wrote:
 
  On 10/08/13 04:31, Lyndon Nerenberg wrote:
 
  Okay folks, can we make a call about keeping the RCS tools in the
base?
 
  The proponents wanting to remove RCS need to speak up and make their
  technical case.
 
 
  Technically it is quite simple: I need RCS to start versioning config
  files, even before starting any customization. I know about several
  others who do the same (and have not yet defected to Linux).
 
  I would like to see RCS to be put back into the tree for 10.0. If it
  really -has- to be victimized by the current anti-GPL crusade, it could
  be replaced by OpenRCS in 11.
 
  And as a long time hard-core user I would appreciate if this kind of
  changes were  performed only after at least -some- public discussion.
  The way this change was sneaked in (though apparently with approval of
  core@),  reminds me more of a Secret Society than of an Open Source
  project.
 
  Regards,
 
  Hans
 
  ___
  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
 
 
  +1, enthusiastically. -- George
 

 +1 also to OpenRCS allthough I hate anything related to RCS/CVS with a
 passion. I do however recognize the need for a simple revision control
 system in the base, svnlite would fill the need maybe but it's good to
 have other options too.

 -Kimmo

OK, but please, can we replace RCS with Fossil in 11 then? That adds a real
improvement to FreeBSD while giving people plenty of time to prepare.

Jos
___
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: rcs

[Freddie Cash]

On Wed, Oct 9, 2013 at 6:41 AM, Julian Elischer jul...@freebsd.org wrote:

 On 10/9/13 2:35 AM, Freddie Cash wrote:

 On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein bri...@mu.org wrote:

  You're right on the money, to be honest this is one of the reasons why
 I've switched to using OSX as my desktop OS.

 zsh, vim, screen by default.  and upgrades work.  At the end of the day
 I'm spending time doing work, not mucking about my workspace to make it
 usable for development.

 I think this was brought up at BSDCan in the discussion about making
 FreeBSD a more featured development platform.

 Speaking of... has anyone tried PCBSD?


 PC-BSD isn't much different from FreeBSD.  The installer is GUI and
 support
 ZFS, there are some GUI setup tools on first boot for X, there are some
 GUI
 tools to select binary drivers for X, and there ​​are working pkgng repos
 available.

 I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do things
 the FreeBSD way which broke a lot of things that were done the PC-BSD
 way (aka don't manually edit config files used for booting).

 ​Switching to the rolling-release (aka PC-BSD 9-STABLE) and moving all
 my
 config file edits into filename.conf.local fixed my issues.  Things have
 been running smooth, and I finally understand the beauty and simplicity of
 freebsd-update + pkg.  OS gets updated once per month, packages get
 updated
 twice per month, no more compiling things from source.  It's like using
 Ubuntu/Debian but with the power and features of FreeBSD.  :)
 ​


 When they went to a ZFS-only system, using GRUB, with no alternative, then
 I'm afraid they lost me.
 I want a root filesystem on UFS for reliabailty and simpleness.  I can
 debug it's media if needed.
 Before then I really liked it (though ther eis not enough information on
 how it works interneally if you want to use it.
 hopefully that will come.. and I LIKE PBIs  FreeBSD should adopt PBIs for
 sure.
 With PBIs you could make even quite base items separately installable.
 versioning problems go away.


There's no GRUB in a default install of PC-BSD 9.0, 9.1, or 9.2.  Even on a
ZFS-only setup (which is what I run).  It's using the FreeBSD loader, with
custom artwork and menus.

There's also nothing stopping you from installing / onto UFS.  At least, I
didn't see anything that would prevent it when I installed it originally.
 Granted, that was with 9.1, so the installer may be different in 9.2.

I tried to use PBIs, but really messed up the system doing so.  /usr was
just a directory on /, on a USB stick, and ran out of room.  Tried various
things to get it off / and b0rked the system.  Even after moving to
ZFS-on-root and getting away from filesystem limits, I still couldn't get
PBIs to upgrade properly.

Since moving away from PBIs, away from ports, away from pkg_* tools, and
sticking strictly with pkg, everything has been running smoothly.  The
experience with pkg on PC-BSD gives me hope for FreeBSD again (too many
issues in the past with ports and pkg_* tools, even when using only
portmaster).

For desktops, a binary-only system using freebsd-update and pkg is so much
nicer.  For servers, implementing your own freebsd-update server and pkg
repo (via poudriere) is so much nicer.  If I never have to compile a port
on a remote system again, I will be a happy man.  :)  To each their own, of
course.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: rcs

[Freddie Cash]

On Wed, Oct 9, 2013 at 9:12 AM, Freddie Cash fjwc...@gmail.com wrote:

 On Wed, Oct 9, 2013 at 6:41 AM, Julian Elischer jul...@freebsd.orgwrote:

 On 10/9/13 2:35 AM, Freddie Cash wrote:

 On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein bri...@mu.org wrote:

  You're right on the money, to be honest this is one of the reasons why
 I've switched to using OSX as my desktop OS.

 zsh, vim, screen by default.  and upgrades work.  At the end of the day
 I'm spending time doing work, not mucking about my workspace to make it
 usable for development.

 I think this was brought up at BSDCan in the discussion about making
 FreeBSD a more featured development platform.

 Speaking of... has anyone tried PCBSD?


 PC-BSD isn't much different from FreeBSD.  The installer is GUI and
 support
 ZFS, there are some GUI setup tools on first boot for X, there are some
 GUI
 tools to select binary drivers for X, and there ​​are working pkgng repos
 available.

 I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do
 things
 the FreeBSD way which broke a lot of things that were done the PC-BSD
 way (aka don't manually edit config files used for booting).

 ​Switching to the rolling-release (aka PC-BSD 9-STABLE) and moving all
 my
 config file edits into filename.conf.local fixed my issues.  Things
 have
 been running smooth, and I finally understand the beauty and simplicity
 of
 freebsd-update + pkg.  OS gets updated once per month, packages get
 updated
 twice per month, no more compiling things from source.  It's like using
 Ubuntu/Debian but with the power and features of FreeBSD.  :)
 ​


 When they went to a ZFS-only system, using GRUB, with no alternative,
 then I'm afraid they lost me.
 I want a root filesystem on UFS for reliabailty and simpleness.  I can
 debug it's media if needed.
 Before then I really liked it (though ther eis not enough information on
 how it works interneally if you want to use it.
 hopefully that will come.. and I LIKE PBIs  FreeBSD should adopt PBIs for
 sure.
 With PBIs you could make even quite base items separately installable.
 versioning problems go away.


 There's no GRUB in a default install of PC-BSD 9.0, 9.1, or 9.2.  Even on
 a ZFS-only setup (which is what I run).  It's using the FreeBSD loader,
 with custom artwork and menus.


​Hrm, it seems they've changed things with the 9.2 installer.  It does use
GRUB2 (e!) for the boot loader, and integrates support for ZFS boot
environments (via beadm) into it.  :(  Shame they didn't use the BE support
in the FreeBSD loader for this.  Wonder if my 9-STABLE-based PC-BSD install
will get upgraded to GRUB?

-- 
Freddie Cash
fjwc...@gmail.com
___
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: rcs

[Allan Jude]

On 2013-10-09 12:23, Freddie Cash wrote:
 On Wed, Oct 9, 2013 at 9:12 AM, Freddie Cash fjwc...@gmail.com wrote:

 On Wed, Oct 9, 2013 at 6:41 AM, Julian Elischer jul...@freebsd.orgwrote:

 On 10/9/13 2:35 AM, Freddie Cash wrote:

 On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein bri...@mu.org wrote:

  You're right on the money, to be honest this is one of the reasons why
 I've switched to using OSX as my desktop OS.

 zsh, vim, screen by default.  and upgrades work.  At the end of the day
 I'm spending time doing work, not mucking about my workspace to make it
 usable for development.

 I think this was brought up at BSDCan in the discussion about making
 FreeBSD a more featured development platform.

 Speaking of... has anyone tried PCBSD?

 PC-BSD isn't much different from FreeBSD.  The installer is GUI and
 support
 ZFS, there are some GUI setup tools on first boot for X, there are some
 GUI
 tools to select binary drivers for X, and there ​​are working pkgng repos
 available.

 I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do
 things
 the FreeBSD way which broke a lot of things that were done the PC-BSD
 way (aka don't manually edit config files used for booting).

 ​Switching to the rolling-release (aka PC-BSD 9-STABLE) and moving all
 my
 config file edits into filename.conf.local fixed my issues.  Things
 have
 been running smooth, and I finally understand the beauty and simplicity
 of
 freebsd-update + pkg.  OS gets updated once per month, packages get
 updated
 twice per month, no more compiling things from source.  It's like using
 Ubuntu/Debian but with the power and features of FreeBSD.  :)
 ​

 When they went to a ZFS-only system, using GRUB, with no alternative,
 then I'm afraid they lost me.
 I want a root filesystem on UFS for reliabailty and simpleness.  I can
 debug it's media if needed.
 Before then I really liked it (though ther eis not enough information on
 how it works interneally if you want to use it.
 hopefully that will come.. and I LIKE PBIs  FreeBSD should adopt PBIs for
 sure.
 With PBIs you could make even quite base items separately installable.
 versioning problems go away.

 There's no GRUB in a default install of PC-BSD 9.0, 9.1, or 9.2.  Even on
 a ZFS-only setup (which is what I run).  It's using the FreeBSD loader,
 with custom artwork and menus.

 ​Hrm, it seems they've changed things with the 9.2 installer.  It does use
 GRUB2 (e!) for the boot loader, and integrates support for ZFS boot
 environments (via beadm) into it.  :(  Shame they didn't use the BE support
 in the FreeBSD loader for this.  Wonder if my 9-STABLE-based PC-BSD install
 will get upgraded to GRUB?

The reason they went to grub2, is that the way the freebsd loader menus
work, it loads the kernel before it draws the menu. This means if there
is a problem with your kernel (probably the most valuable time to have
boot environments) then the menu never comes up, and you cannot select
which BE to boot from. Grub doesn't rely on a FreeBSD kernel until after
you select which BE to boot from.

Kris and I discussed it at length with Devin Teske, and while he has
demonstrated being able to populate a lower menu with the ZFS datasets,
I am not sure if the other issue can be resolved.

-- 
Allan Jude

___
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: rcs

[Hans Ottevanger]

On 10/09/13 15:47, Julian Elischer wrote:
 On 10/9/13 3:20 PM, Hans Ottevanger wrote:
 On 10/08/13 04:31, Lyndon Nerenberg wrote:
 Okay folks, can we make a call about keeping the RCS tools in the base?

 The proponents wanting to remove RCS need to speak up and make their
 technical case.

 Technically it is quite simple: I need RCS to start versioning config
 files, even before starting any customization. I know about several
 others who do the same (and have not yet defected to Linux).

 I would like to see RCS to be put back into the tree for 10.0. If it
 really -has- to be victimized by the current anti-GPL crusade, it could
 be replaced by OpenRCS in 11.

 And as a long time hard-core user I would appreciate if this kind of
 changes were  performed only after at least -some- public discussion.
 The way this change was sneaked in (though apparently with approval of
 core@),  reminds me more of a Secret Society than of an Open Source
 project.
 
 no, with private  approval of a CORE MEMBER.. that is quite a different
 thing..
 Core, AFAIK has not ruled on this sort of topic.. (and actually it's not
 really it's job to do so unless it's resolving a dispute.)
 

You are probably right, but as a relative outsider I only saw this in
the commit message:

Log:
  Good bye RCS.  You will be missed.

  (devel/rcs and devel/rcs57 are available as alternatives)

  Approved by:  core
  Approved by:  re (hrs)

which led me to my possibly wrong conclusion about the approval of core@.

Kind regards,

Hans


___
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: rcs

[Kris Moore]

On 10/09/2013 12:33, Allan Jude wrote:
 On 2013-10-09 12:23, Freddie Cash wrote:
 On Wed, Oct 9, 2013 at 9:12 AM, Freddie Cash fjwc...@gmail.com wrote:

 On Wed, Oct 9, 2013 at 6:41 AM, Julian Elischer jul...@freebsd.orgwrote:

 On 10/9/13 2:35 AM, Freddie Cash wrote:

 On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein bri...@mu.org wrote:

  You're right on the money, to be honest this is one of the reasons why
 I've switched to using OSX as my desktop OS.

 zsh, vim, screen by default.  and upgrades work.  At the end of the day
 I'm spending time doing work, not mucking about my workspace to make it
 usable for development.

 I think this was brought up at BSDCan in the discussion about making
 FreeBSD a more featured development platform.

 Speaking of... has anyone tried PCBSD?

 PC-BSD isn't much different from FreeBSD.  The installer is GUI and
 support
 ZFS, there are some GUI setup tools on first boot for X, there are some
 GUI
 tools to select binary drivers for X, and there ​​are working pkgng repos
 available.

 I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do
 things
 the FreeBSD way which broke a lot of things that were done the PC-BSD
 way (aka don't manually edit config files used for booting).

 ​Switching to the rolling-release (aka PC-BSD 9-STABLE) and moving all
 my
 config file edits into filename.conf.local fixed my issues.  Things
 have
 been running smooth, and I finally understand the beauty and simplicity
 of
 freebsd-update + pkg.  OS gets updated once per month, packages get
 updated
 twice per month, no more compiling things from source.  It's like using
 Ubuntu/Debian but with the power and features of FreeBSD.  :)
 ​

 When they went to a ZFS-only system, using GRUB, with no alternative,
 then I'm afraid they lost me.
 I want a root filesystem on UFS for reliabailty and simpleness.  I can
 debug it's media if needed.
 Before then I really liked it (though ther eis not enough information on
 how it works interneally if you want to use it.
 hopefully that will come.. and I LIKE PBIs  FreeBSD should adopt PBIs for
 sure.
 With PBIs you could make even quite base items separately installable.
 versioning problems go away.

 There's no GRUB in a default install of PC-BSD 9.0, 9.1, or 9.2.  Even on
 a ZFS-only setup (which is what I run).  It's using the FreeBSD loader,
 with custom artwork and menus.

 ​Hrm, it seems they've changed things with the 9.2 installer.  It does use
 GRUB2 (e!) for the boot loader, and integrates support for ZFS boot
 environments (via beadm) into it.  :(  Shame they didn't use the BE support
 in the FreeBSD loader for this.  Wonder if my 9-STABLE-based PC-BSD install
 will get upgraded to GRUB?

 The reason they went to grub2, is that the way the freebsd loader menus
 work, it loads the kernel before it draws the menu. This means if there
 is a problem with your kernel (probably the most valuable time to have
 boot environments) then the menu never comes up, and you cannot select
 which BE to boot from. Grub doesn't rely on a FreeBSD kernel until after
 you select which BE to boot from.

 Kris and I discussed it at length with Devin Teske, and while he has
 demonstrated being able to populate a lower menu with the ZFS datasets,
 I am not sure if the other issue can be resolved.


Yea, GRUB is not my first choice, but ATM this is the cleanest way we
can do ZFS BE's. However if you don't like ZFS / GRUB, you can always
use regular FreeBSD and just grab our toolchain from
sysutils/pcbsd-utils* in ports or use our PKGNG repo:

http://wiki.pcbsd.org/index.php/Turn_FreeBSD_into_PC-BSD%C2%AE

I'm planning on using GRUB to do UEFI booting for 10.0 as well. But when
the FreeBSD loader matures to the point of having support for all these
features, I'll gladly move us back.

-- 
Kris Moore
PC-BSD Software
iXsystems

___
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: [Heads Up] RCS removed from base

[Diane Bruce]

...
 
 I notice in diff'ing your work vs my work, that I started with
 newer revisions of some of the files than the ones you have:

I was well aware of that. There is no point doing much more until
there is a decision from core.

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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

BE Loader Menu (was Re: rcs)

[Teske, Devin]

On Oct 9, 2013, at 9:42 AM, Kris Moore wrote:

 On 10/09/2013 12:33, Allan Jude wrote:
 On 2013-10-09 12:23, Freddie Cash wrote:
 On Wed, Oct 9, 2013 at 9:12 AM, Freddie Cash fjwc...@gmail.com wrote:
 
 On Wed, Oct 9, 2013 at 6:41 AM, Julian Elischer jul...@freebsd.orgwrote:
 
 On 10/9/13 2:35 AM, Freddie Cash wrote:
 
 On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein bri...@mu.org wrote:
 
 You're right on the money, to be honest this is one of the reasons why
 I've switched to using OSX as my desktop OS.
 
 zsh, vim, screen by default.  and upgrades work.  At the end of the day
 I'm spending time doing work, not mucking about my workspace to make it
 usable for development.
 
 I think this was brought up at BSDCan in the discussion about making
 FreeBSD a more featured development platform.
 
 Speaking of... has anyone tried PCBSD?
 
 PC-BSD isn't much different from FreeBSD.  The installer is GUI and
 support
 ZFS, there are some GUI setup tools on first boot for X, there are some
 GUI
 tools to select binary drivers for X, and there ​​are working pkgng repos
 available.
 
 I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do
 things
 the FreeBSD way which broke a lot of things that were done the PC-BSD
 way (aka don't manually edit config files used for booting).
 
 ​Switching to the rolling-release (aka PC-BSD 9-STABLE) and moving all
 my
 config file edits into filename.conf.local fixed my issues.  Things
 have
 been running smooth, and I finally understand the beauty and simplicity
 of
 freebsd-update + pkg.  OS gets updated once per month, packages get
 updated
 twice per month, no more compiling things from source.  It's like using
 Ubuntu/Debian but with the power and features of FreeBSD.  :)
 ​
 
 When they went to a ZFS-only system, using GRUB, with no alternative,
 then I'm afraid they lost me.
 I want a root filesystem on UFS for reliabailty and simpleness.  I can
 debug it's media if needed.
 Before then I really liked it (though ther eis not enough information on
 how it works interneally if you want to use it.
 hopefully that will come.. and I LIKE PBIs  FreeBSD should adopt PBIs for
 sure.
 With PBIs you could make even quite base items separately installable.
 versioning problems go away.
 
 There's no GRUB in a default install of PC-BSD 9.0, 9.1, or 9.2.  Even on
 a ZFS-only setup (which is what I run).  It's using the FreeBSD loader,
 with custom artwork and menus.
 
 ​Hrm, it seems they've changed things with the 9.2 installer.  It does use
 GRUB2 (e!) for the boot loader, and integrates support for ZFS boot
 environments (via beadm) into it.  :(  Shame they didn't use the BE support
 in the FreeBSD loader for this.  Wonder if my 9-STABLE-based PC-BSD install
 will get upgraded to GRUB?
 
 The reason they went to grub2, is that the way the freebsd loader menus
 work, it loads the kernel before it draws the menu. This means if there
 is a problem with your kernel (probably the most valuable time to have
 boot environments) then the menu never comes up, and you cannot select
 which BE to boot from. Grub doesn't rely on a FreeBSD kernel until after
 you select which BE to boot from.
 
 Kris and I discussed it at length with Devin Teske, and while he has
 demonstrated being able to populate a lower menu with the ZFS datasets,
 I am not sure if the other issue can be resolved.
 
 

I'm late to the party again ;D (didn't realize the rcs thread had turned BE)

Both problems can be solved.
The loading of the kernel *after* choosing your boot device is trivial.
We've been doing it at $work for *years* (almost a decade?)

I can put that in, whenever. Probably at the same time as implementing
the live/dynamic BE menus for selecting the root device.



 Yea, GRUB is not my first choice, but ATM this is the cleanest way we
 can do ZFS BE's. However if you don't like ZFS / GRUB, you can always
 use regular FreeBSD and just grab our toolchain from
 sysutils/pcbsd-utils* in ports or use our PKGNG repo:
 
 http://wiki.pcbsd.org/index.php/Turn_FreeBSD_into_PC-BSD%C2%AE
 
 I'm planning on using GRUB to do UEFI booting for 10.0 as well. But when
 the FreeBSD loader matures to the point of having support for all these
 features, I'll gladly move us back.
 

I had not been pushing hard on finishing the BE Forth because I knew that
it would be a greater value add if we actually had Boot from ZFS finished
first. Would be easier to test, that is, if I actually had a system booting from
ZFS -- which is what Allan, jmg, and myself are hopefully working toward
for FreeBSD 10.0-R. (smiles)
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review

Re: rcs

[Bruce Cran]

On 10/9/2013 3:17 PM, Alfred Perlstein wrote:
Only a few years ago you could take a dvd or memstick of FreeBSD and 
have 1000s of packages to choose from during your install.  That is 
broken now?


At some point it was decided that the installer should be as simple as 
possible and package installation was a post-install task, for once the 
system was up and running. I think that might be changing with 
bsdinstall getting pkgng support, but it did seem like a fairly major 
regression at the time.


--
Bruce Cran
___
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: rcs

[Adrian Chadd]

On 9 October 2013 11:28, Bruce Cran br...@cran.org.uk wrote:

 On 10/9/2013 3:17 PM, Alfred Perlstein wrote:

 Only a few years ago you could take a dvd or memstick of FreeBSD and have
 1000s of packages to choose from during your install.  That is broken now?


 At some point it was decided that the installer should be as simple as
 possible and package installation was a post-install task, for once the
 system was up and running. I think that might be changing with bsdinstall
 getting pkgng support, but it did seem like a fairly major regression at
 the time.


I think it was more a this is a stepping stone to a bigger change.. ..
and that didn't happen soon after.

The other thing here is the introduction of the uhm, livefs. It's big and
it took up the space once occupied by the first set of packages. Honestly,
I'm kinda surprised how big base is these days, but I have other fights to
fight right now.



-adrian
___
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: rcs

[Teske, Devin]

On Oct 9, 2013, at 2:48 PM, Adrian Chadd wrote:

 On 9 October 2013 11:28, Bruce Cran br...@cran.org.uk wrote:
 
 On 10/9/2013 3:17 PM, Alfred Perlstein wrote:
 
 Only a few years ago you could take a dvd or memstick of FreeBSD and have
 1000s of packages to choose from during your install.  That is broken now?
 
 
 At some point it was decided that the installer should be as simple as
 possible and package installation was a post-install task, for once the
 system was up and running. I think that might be changing with bsdinstall
 getting pkgng support, but it did seem like a fairly major regression at
 the time.
 

That wasn't the rationale. sysinstall was broken and more people wanted a
replacement than wanted to see it fixed.

bsdinstall is simply coming of age still (sysinstall had a 15 year run).


 
 I think it was more a this is a stepping stone to a bigger change.. ..
 and that didn't happen soon after.
 

Adrian is right. It was a first step (nobody intended to see functionality
get dropped -- it's a matter of finding the time to replace a 15-year code
line -- sysinstall).

Only a very small handful of us are actively working on it. It's further along
than you think. You can always help out by testing.



 The other thing here is the introduction of the uhm, livefs. It's big and
 it took up the space once occupied by the first set of packages. Honestly,
 I'm kinda surprised how big base is these days, but I have other fights to
 fight right now.
 

The livefs is a bee in my bonnet too. But as you say... more pressing things
to worry about right now than break something that is working currently.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
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