discuss: Thread: Return of the Prodigal HOWTO: Linux Complete Backup and Recovery HOWTO

I am the original author and maintainer of the Linux Complete Backup
and Recovery HOWTO. The last version on the LDP web site is 2.1. I am
now up to 2.10. Do you want the most recent version?

It is in Docbook 4.1 in SGML, with some includes.

I had a cvs account, but I seem to recall that that went away. Is there
a git replacement? What's the preferred way to maintain?

-- 

The right of the people to be secure in their persons, houses, papers,
and effects, against unreasonable searches and seizures, shall not be
violated, and no Warrants shall issue, but upon probable cause,
supported by Oath or affirmation, and particularly describing the
place to be searched, and the persons or things to be seized.
-- U.S. Const. Amendment IV

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB

Charles, that would be fantastic. The group has talked about a Wiki that
holds all the current documents, perhaps that's a start for you! I cannot
wait to read it, great work!

On Wed, Jul 12, 2017 at 1:58 PM, Charles Curley <
####@####.#### wrote:

> I am the original author and maintainer of the Linux Complete Backup
> and Recovery HOWTO. The last version on the LDP web site is 2.1. I am
> now up to 2.10. Do you want the most recent version?
>
> It is in Docbook 4.1 in SGML, with some includes.
>
> I had a cvs account, but I seem to recall that that went away. Is there
> a git replacement? What's the preferred way to maintain?
>
> --
>
> The right of the people to be secure in their persons, houses, papers,
> and effects, against unreasonable searches and seizures, shall not be
> violated, and no Warrants shall issue, but upon probable cause,
> supported by Oath or affirmation, and particularly describing the
> place to be searched, and the persons or things to be seized.
> -- U.S. Const. Amendment IV
>
> Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB
>
> ______________________
> http://lists.tldp.org/
>
>


-- 
Thanks,

Paul Hendricksen

Hello and welcome back,

I read a great deal of the mailing list archive about a year ago and 
I saw your name often, Charles Curley.

>I am the original author and maintainer of the Linux Complete 
>Backup and Recovery HOWTO. The last version on the LDP web site is 
>2.1. I am now up to 2.10. Do you want the most recent version?

Certainly.

>It is in Docbook 4.1 in SGML, with some includes.

The earlier release of your document is in our repository as a 
DocBook V4.1 document -- should work just fine.

I did make a small change to your tooling [0] [1] to generate your 
included files and commit them to the repository so that our 
automatic publishing could read the derived files from checkout 
(rather than executing a script that was checked out of the 
repository itself).  If this is not unduly offensive to you, I'd 
happily adjust what we have committed to reflect your updated 
content.  (I.e. essentially, I'd reapply my small patch just so that 
we could safely, automatically, rebuild at will straight from the 
checkout.)

>I had a cvs account, but I seem to recall that that went away. Is 
>there a git replacement? What's the preferred way to maintain?

For source control, there is a git replacement for the (now defunct) 
CVS repository.  Here's the TLDP canonical repository:

  https://github.com/tLDP/LDP

We use a fork and PR model like many other organizations who have 
elected to use github.

We also have tooling to automatically generate text, PDF, HTML 
(single-page and chapter) outputs for each of the source documents 
in the source repository.  This job runs under a continuous 
integration model (thanks to Serge) and produces a single merged 
output directory with a single directory for each output type.  For 
example, for your document, you can see:

  http://www.tldp.org/en/Linux-Complete-Backup-and-Recovery-HOWTO/
  http://www.tldp.org/en/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO-single.html
  http://www.tldp.org/en/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO.txt
  http://www.tldp.org/en/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO.pdf

There's one Achilles heel in that these generated documents and 
their structure are not reflected through the "front door" of TLDP 
yet.

If anybody is interested in taking on some responsibility for 
helping re-organize and manage the content, I have notes (some of 
which I shared on this mailing list) from my own efforts of about a 
year ago to sift through the 20 years of links, archives, magazine 
articles and so forth.

Anyway, that's the current state of things over here and we'd be 
happy for the updates.

Thank you very much for your contributions over the years!

-Martin

 [0] https://github.com/tLDP/LDP/commit/d51e1970c49ee15593a3ec2bf5a0ef6078f40058
 [1] https://github.com/tLDP/LDP/commits/master/LDP/howto/docbook/Linux-Complete-Backup-and-Recovery-HOWTO

-- 
Martin A. Brown
http://linux-ip.net/

On Wed, 12 Jul 2017 18:17:57 -0700
"Martin A. Brown" ####@####.#### wrote:

> Hello and welcome back,
> 
> I read a great deal of the mailing list archive about a year ago and 
> I saw your name often, Charles Curley.
> 
> >I am the original author and maintainer of the Linux Complete 
> >Backup and Recovery HOWTO. The last version on the LDP web site is 
> >2.1. I am now up to 2.10. Do you want the most recent version?  
> 
> Certainly.
> 
> >It is in Docbook 4.1 in SGML, with some includes.  
> 
> The earlier release of your document is in our repository as a 
> DocBook V4.1 document -- should work just fine.

OK.

> 
> I did make a small change to your tooling [0] [1] to generate your 
> included files and commit them to the repository so that our 
> automatic publishing could read the derived files from checkout 
> (rather than executing a script that was checked out of the 
> repository itself).  If this is not unduly offensive to you, I'd 
> happily adjust what we have committed to reflect your updated 
> content.  (I.e. essentially, I'd reapply my small patch just so that 
> we could safely, automatically, rebuild at will straight from the 
> checkout.)

I took a quick look at them. The two grammatical fixes I can apply
easily enough, or we can leave those until I get the newer stuff
checked in and they merge.

The other one is problematic. I have been re-working the build process
to get rid of the awkward handling of the scripts. The whole
buildscript script goes away, finally. Let me see if I can incorporate
some of your changes (like putting cooked under another directory).

Can your build scripts test for a make file, and if it is present, call
it? That might be the best of two worlds.

I wanted to make the scripts themselves pristine so that the user could
execute them directly. I also want this so I can edit a script on a
target machine, then simply copy it back into place and check that in.

However, in order to get rid of the hacks I had in the make file, I now
have three versions of each script:

* The source, in directory src, with the extension .s, with 0600
  permissions.

* The cooked version, in directory cooked, with no extension, and 0600,
  ready for pulling into the .sgml file with no changes to that.

* The executable versions, ready for installation, in scripts. These
  have no extension and permissions of 0700. These are ready for the
  script install. (I have also changed the make file to call that
  script.)

I have no problem re-arranging things to suit your existing build
structure, as long as we retain the goal of allowing the user to install
the scripts, whether by tarball, .deb or .rpm.

I am not wedded to any of the details here. For example, it might work
out better for your build tools if the install script strips the .s
extension and applies the executable bit where appropriate.

> 
> >I had a cvs account, but I seem to recall that that went away. Is 
> >there a git replacement? What's the preferred way to maintain?  
> 
> For source control, there is a git replacement for the (now defunct) 
> CVS repository.  Here's the TLDP canonical repository:
> 
>   https://github.com/tLDP/LDP
> 
> We use a fork and PR model like many other organizations who have 
> elected to use github.

I'm going to have to look up "fork and PR". Meanwhile, I currently have
a git repo at home for my projects and a github account. I can certainly
add another git repo to the home repos.

One of my goals is to re-automate putting tarballs where folks can find
them, probably on charlescurley.com. Once I have that, you can play
with it to see what changes I need to make to work with the build
tools. That way I can just check in the changes and they will work
(Murphy willing) from day one.

> 
> We also have tooling to automatically generate text, PDF, HTML 
> (single-page and chapter) outputs for each of the source documents 
> in the source repository.  This job runs under a continuous 
> integration model (thanks to Serge) and produces a single merged 
> output directory with a single directory for each output type.  For 
> example, for your document, you can see:
> 
>   http://www.tldp.org/en/Linux-Complete-Backup-and-Recovery-HOWTO/
>   http://www.tldp.org/en/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO-single.html
>   http://www.tldp.org/en/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO.txt
>   http://www.tldp.org/en/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO.pdf

I should probably re-name my output files to agree with your naming
scheme. Single rather than smooth, e.g. But that's another project.

> 
> Anyway, that's the current state of things over here and we'd be 
> happy for the updates.

Let's see what we can do.

> 
> Thank you very much for your contributions over the years!

You are very welcome. I see your name on a lot of more recent stuff.
Thank you.

> 
> -Martin
> 
>  [0]
> https://github.com/tLDP/LDP/commit/d51e1970c49ee15593a3ec2bf5a0ef6078f40058
> [1]
> https://github.com/tLDP/LDP/commits/master/LDP/howto/docbook/Linux-Complete-Backup-and-Recovery-HOWTO
> 



-- 

The right of the people to be secure in their persons, houses, papers,
and effects, against unreasonable searches and seizures, shall not be
violated, and no Warrants shall issue, but upon probable cause,
supported by Oath or affirmation, and particularly describing the
place to be searched, and the persons or things to be seized.
-- U.S. Const. Amendment IV

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB