On Sun, Feb 07, 2016 at 05:18:27PM +0000, Ken Moffat wrote: > On Sun, Feb 07, 2016 at 12:03:18AM -0600, Bruce Dubbs wrote: > > > May I suggest that you wait a week for a lot of your efforts as we will be > > going into a package freeze next weekend and will need to build everything > > in both books. I don't ask you to do that, of course, but anything you can > > do to help is appreciated. > > > > -- Bruce > > > At the moment, my current run is still a shakedown, and then I'll > look again at adding distros and using my SSD. So, continuing is > meaningful for me, even if things change this week. > Well, I completed that run - now posting from urxvt under plasma5 fro m sddm. Apart from the issues mentioned in my other posts, I had to rethink how I plan to use git (for my sources) with multiple test machines : people who have no interest in using git should look away now! And for everybody else, this may be more detail than you want - but it might be helpful to somebody.
It turns out that, with my scripts in /sources/some/path I have to use my working branch for everythign before I reboot. Until now, I have only updated my master branch at an LFS release, I think in future I'll do all general updates in master. For the test machines, I think what I need to do (after updating my scripts) is to create a boxname-version branch (or perhaps boxname-version-purpose - I do not mix e.g. kde4 and kde5 in the same build). Normally, the version will be the date. And then checkout that branch, and from their create a -fixes branch but do not check it out. On the test machine, in /home/ken/local (/home/ken is not accessible during the LFS build, which I had initially overlooked until I came to try my first attempt) : git clone -b boxname-date [ or boxname-date-purpose ] \ myserver:/path/to/scripts boxname-version [ or boxname-version-purpose ] and from there: git branch boxname-version-fixes [ or boxname-version-purpose-fixes ] Please note that some of the changes I commit turn out to be "not wanted on voyage", e.g. in this build I built itstool earlier than normal, so that I could build gtk-doc to autoreconf gtkimageview for the gold linker, and added a test at itstool's normal position to see if I had already built it. At the end, or at a convenient point along the way, I then look at my git log, make a note of the commits that I want to put into my ongoing scripts, then change to the fixes branch and cherry-pick them (in reverse order). The first time I do that, when I push to my server I have to use git push --set-upstream myserver:/path/to/scripts boxname-version-fixes [ or -purpose-fixes ] - That sets the -fixes branch on the server as upstream. After pushing, I have to go back to the main scripts (for me, they are in my nfs mount of /sources) and merge the fixes branch to boxname-version and/or my main branch. This time, the first merge was fine - I did it as above. But after that I had a lot more fixes for my kde5 scripts and did it wrong - in the -fixes branch on the local machine I merged the local working branch "because I had already got up to date yesterday, and all new commits were needed". Bad mistake - the unwanted commits from Saturday showed up in git log, but at the date and time when I committed them, so far down git log. Fortunately I spotted that and was able to revert them before pushing - but my main git log now shows those reverts :-( I'm mentioning this as a public service: using git is good, but like all flexible and powerful tools it sometimes does what you told it, not what you intended. ;-) ĸen -- This email was written using 100% recycled letters. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
