On Saturday 11 May 2019 01:28:15 pm Chris Hassell wrote: > Boy... Gene... I've been at configuration management since my early > days in the late 90s and you are an *excellent* destructive tester for > the 'standard' configuration path! [In the neverending circle-of-life > the thrill of testers' victory is the agony of the developers defeat > :-]. > > As for one thing you really should know: Git is *made made made* for > changes-that-don't-need-a-new-download. Git can get the latest any > time you like, but the pattern is really like this: > > % git clone <url-here> > % git checkout -b <my-branch> origin/<source-branch> > > % git log # see what's the latest thing and its function... > > [ magic, edits and @#$@# happens here ] > > % git diff --stat # summarized changes... > > % git diff # full changes... > > [ review the sanity you added to all the madness that came in ] > > % git checkout ./packaging/deb/rules # a file restored back to > original state, readied for a commit > > % git checkout ./autogen # a file restored back to > original state, readied for a commit ... > > [ consider a retry for the build with your few changes ] > > % git clean -d -f # remove only extra/temp files it > detects [none from the clone/repo] > > [ magic, edits and final versions happen here ] > > % git commit -a -m "wise and ingenious edits beyond question were... > blah blah blah" > > [ changes are integrated into your branch, only on the local machine, > btw ] > > <time passes> > > % git pull origin <orig-branch> > > [ magic remains with new versions of crazy integrated. ] > > % git log --oneline # to see all the things piled on yet again... > > Any changes upstream then are copied in and *automatically* merged > into place over the top of yours, as long as you've committed them > into place locally. It's not fun if there's a conflict but them's the > breaks if you and the remote disagree at times. It allows you to > keep up a highly modified build over time if you like and, if you > dare, you can use a 'rebase' to try and yank your changes on top over > and over. > > In any case ... I didn't think I'd need to overhaul the build on the > community side, before. Still, it looks like more may need to be done > to config the user and to *at least* get the README in order! > There's far too many cobwebs in this setup and I *must* say you do > seem to be working late at night also! I may need a bit of time to > catch up to your plans here. I'll get some more by Sunday night > probably. > > -- CH > > p.s. > > Side notes: YES it does take a little bit of heavy-hit-NUDGING to > convince Out-The-Window-10/10 that you mean what you say. [sigh] > Welding the hood shut is their idea of fun. > > And also, SSHFS is a pretty neat scheme and it's awesome that it can > sit there as a directory like any other. We're considering Ansible > for some new work here and SSH-only is great for interactive links, as > opposed to HTTPS-and-friends for every thing under the sun. > > ASIDE ABOUT GIT > > Git is a very very bizarre set of concepts, but its main function is > simple: maintain a winding 'tree' of 'undo' changes that were layered > (across many separate files) for every small shift or growth in a > design that devs write. As folks cooperate it attempts to tape-record > *only* the deltas, the diffs, the patches since the beginning of a > project. Keeping them precisely a small as the original writer wanted > them to be. It then precisely knows how to un-lay every brick and > un-nail every joist and stud all the way back to a bare slab of > concrete. It does this so each intention for each change is pretty > clear. (They can be joined into a bigger change later on if needed). > > NOTE: It does not maintain a 'video' in slow-mo of images of your > files, like Subversion does. It maintains a change-tree... so your > own 'undo' chain can go backward and (if you like) jump back forward > ... but it's not required to be a single timeline at all. > > Why is this good to know things backwards? Because that's where > variations or mistakes are removed and better ways are tried: in > reverse! Forward has disagreements or variation but backward is > always pretty clear. > > Then you have a clear way to jump backwards a ways from one design > (mistake) to an earlier one (success). Even more you can yank better > parts from one developer branch over to another and 'replay them' on > top of your own. It's the undo key for programmers and *also* the way > to tightly track any set of local changes and re-add them on top of > any solid version of anything anywhere [i.e. rebase]. > > If reshuffling with a rebase (which can be messy) you can still track > things by stacking (but tracking) remote changes on your local changes > and intermingle them like a huge huge dagwood sandwich. Linear > history be damned.. cuz coding rarely goes linearly. > > I have no apology for the bizarre set of names and terms and invisible > states it maintains. It is not easy to learn and an easier GUI > version like "gitg" or something is far better, if you can because > it's very hard to visualize in the first two years of use. Even so, > things like local changes are good to make and easy to stow away. > > Restarting from a "reset --hard <orig-branch>" or a nicer "checkout -b > mineno2 ..." is always possible... but beware as some changes you make > can be lost. > > On 5/11/19 9:32 AM, Gene Heskett wrote: > > Despite changing the name in the rules file, its hard coded to be > amanda-backup in the .dsc files. GRRRRRRR > > Without fixing this, how the hell do we get rid of the older version > trash when updateing it? Seems like a heck of a good question to me. > Do we expect the users to wear out find in cleaning house file by > file? I think not. > > This was amanda for 2 decades before some marketing type decreed a > name change. What was this person thinking? > > Anyway, I blew that whole /home/amanda/amanda directory away an > started with becoming amanda, then a fresh git clone from github. > Then did exactly as said. It builds 5 packages. so I attempt to > install the amanda-backup-server since this machine is the server. > > And its stuck, just like the previous attempt. No cpu used, no > progress. pstree does show but one process, but htop shows 5, with the > highest pid being from gnupg getting a no-permissions from > /var/lib/amanda. An ls -l of that dir is: > > amanda@coyote:..$<mailto:amanda@coyote:..$> ls -l /var/lib/amanda > total 16 > -rw-r--r-- 1 root root 34 May 11 09:59 amanda-release > -rw-r--r-- 1 backup backup 0 May 6 10:51 amandates > drwxr-xr-x 3 amandabackup disk 4096 May 11 11:01 example > drwxrwx--- 2 amandabackup disk 4096 May 11 09:59 gnutar-lists > drwxr-xr-x 2 amandabackup disk 4096 May 11 11:01 template.d > No comment of this?
> And that directory is owned by backup. And I'm lost, and I need to go > convince a winders 10 home edition that I am indeed boss. I can't even > get it online. Need a manpage for netfs. > > Thanks Chris, but its Your turn. > > Cheers, Gene Heskett Copyright 2019 by Maurice E. Heskett Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
