Re: [lfs-dev] Patching LFS XML sources: SVN insight required
Am 2019-03-31 18:25, schrieb DJ Lucas via lfs-dev: On 3/30/2019 9:04 PM, Kevin Buckley via lfs-dev wrote: What's not been clear to me in trying to store changes within my local SVN repo is how to seperate things out so that for example, i could apply a "PkgUser" SVN diff to a vanilla LFS XML source tree if it hadn't had Thomas's Multilib patch already applied. Since Thomas's patch set can produce all four books, I'd just use that as a base. Hopefully it'll wind up in a branch that you could use for 'upstream' soon. Yes it will, I'm just about to create the branch - just a question of a few days, depending on this lovely job here i need to spend my time on currently. Hopefully I'll get it done... -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Patching LFS XML sources: SVN insight required
On 3/30/2019 9:04 PM, Kevin Buckley via lfs-dev wrote: What's not been clear to me in trying to store changes within my local SVN repo is how to seperate things out so that for example, i could apply a "PkgUser" SVN diff to a vanilla LFS XML source tree if it hadn't had Thomas's Multilib patch already applied. Since Thomas's patch set can produce all four books, I'd just use that as a base. Hopefully it'll wind up in a branch that you could use for 'upstream' soon. --DJ -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Patching LFS XML sources: SVN insight required
On 3/31/2019 2:38 AM, Thomas Trepl via lfs-dev wrote:
Next step will be to make a branch in the original repository for the
ML part.
This should probably be done sooner rather than later, there is enough
of a demand that it is useful outside of the core group of developers,
and I'm not really comfortable with this being managed outside of some
SCM tool (I had previously thought it was in SVN on Thomas's server).
I'd offer, but I'm already stretched really thin right now. The workflow
isn't that difficult, just use standardized commit messages, and you can
automate the merges. I've been using the format "Merged to HEAD r#."
for commits, and manually using 'svn log | grep -N1 "Merged" | grep -o
r{0-9}.*\.$' to get the previous merge (double check syntax, from memory).
Strictly my opinion, even though I am a consumer, and while there is
some educational value here, I don't currently think this is appropriate
for inclusion in HEAD. It would take considerably more community
interest, and multilib/default would need to use real arch values (i686,
x86_64, x86_64-multilib (?), etc.) and ditch the 'case $(uname -m)'
statements. Additionally, the i686 binaries produced on x86_64 should be
able to be copied onto an i686 LFS build without modification (this was
possible at last check in qemu/kvm). The consumers that I am aware of
are WINE, QEMU, AOSP, and some binary only applications used by devs
here. I would encourage the existing devs who use it to assist in
keeping the branch up to date as additions are made to LFS proper. Most
of that can be automated, but merge failures would require notifications
for manual intervention.
Pierre, could you take a look at the patch for jhalfs as well? Obviously
it would need to be adapted for the new branch location.
http://www.linuxfromscratch.org/~dj/Multilib/jhalfs-multilib-20180909.patch
--DJ
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Patching LFS XML sources: SVN insight required
Am Sonntag, den 31.03.2019, 10:04 +0800 schrieb Kevin Buckley via lfs- dev: > Hi there, > > I'd be interested in some feedback, should anyone have a chance to > look at things, as to how best to leverage SVN to add "mutiple > rendering pathways", so let me expand on that. > > The build system for the vanilla LFS book already has the ability to > branch on SysV or SysD. > > Thomas's patch adds multilib capability to either of those pathways. > > I am looking to apply a "PkgUser" (the More Control hint) approach > on top of that. > > My local (file-backed) SVN repo contains a mix of direct PkgUser > modifications, along with things such as > > 2>&1 | tee ../make.out > > being added into (hopefully) all of the various make commands, so including > the "make check/test" and "make install" stuff. > > I also make a few changes to blocks so as to remove some > things from the output generated by the book's Makefile's dump-commands > target. As you surly have seen, the ML stuff is controlled via 'arch="multilib"' or 'arch="default"' profiling attributes in the books sources. Using them made it possible to switch on/off the ML modifications at rendering time by setting a parameter to 'make'. So if set to "default", the rendering output should be exactly the output you get when using the original book and not using ML at all. You may use such a profiling attribute for your modifications as well but unfortunatly, docbook in the used version has only a limited set of those attrs while its possible to introduce own ones. > > What's not been clear to me in trying to store changes within my local > SVN repo is how to seperate things out so that for example, i could > apply a "PkgUser" SVN diff to a vanilla LFS XML source tree if it > hadn't had Thomas's Multilib patch already applied. > > Another one along the same lines is the make redirection stuff that > I add into my own books. That is what kept me busy for a while to get things done like you described. Goal was to minimze the impact on the "infrastructure" of the book (modifying the Makefile etc), simply be as much "compatible" as possible. Even jhalfs (with a few modifications DJ made) runs on the ML-variant. Finally, I end up with: Create a local copy of the LFS repository (svn checkout). This repo can be updated simply via "svn up". Than, i created a copy of the book (directory BOOK) and made my modifications there. A diff between this directory and the original repo is what is known as the multilib- patch. Same procedure is made for the so-called "belfs extensions" which are modifications i like to have in the book but which are surly nothing to ever go to the original book. For example, in this variant i use the base kernel sources and a patch to get them uptodate (linux- 5.0.tar.xz + patch-5.0.4.xz) simply to save diskspace and download time... To keep things uptodate, i run a script which does: - diff the ML working dir and the upstream repo and store the patch in a temporary location - diff the BELFS working dir and the upstream repo and store the patch in a temporary location - update the upstream repository (never to that before the first two steps has been made) - duplicate the original sources into the ML working dir (via rsync -- delete) - apply the temp-patch to it - create the ML-patch (now this patch is against the most recent original sources) - duplicate the original sources into the BELFS working dir - apply the temp-patch to it - create the BELFS-patch - duplicate the original sources into the "merged" working dir - apply the BELFS-patch to it - apply the ML-patch to it - copy the BELFS- and the ML-patch to my website This process runs every day at 04:45. I use the interdiff utils to see whether there are differences between the previous and the newly created patches. If none, the new patches are thrown away. The description sounds a bit complicated but usually the process runs well, from time to time some .rej are created. That happens if there are modifications made in the original repo which are in conflict with my modifications. Then i have to fix that manually. I use the "merged" book for building my machines. Problem in this approach is that i cannot track my modifications in a SVN repository since the BELFS and the ML copies are simple file copies and are not under SVN control. The only history i have is that i keep the previously created patches. Next step will be to make a branch in the original repository for the ML part. > > Whilst that's not realy PkgUser specific, i could see that a standlone > SVN diff that applied just that might be useful to some folk, but again > it's not clear how to seperate things out when using SVN across the > two "regimes" I am adding stuff on top off, namely, the vanilla LFS and > the Multilib additional source. > > Any pointers/insight welcome. > Kevin > > PS > I have a rendering of my current book but am yet to stick it up on > the internet in case anyone wnats to take a look.:
[lfs-dev] Patching LFS XML sources: SVN insight required
Hi there, I'd be interested in some feedback, should anyone have a chance to look at things, as to how best to leverage SVN to add "mutiple rendering pathways", so let me expand on that. The build system for the vanilla LFS book already has the ability to branch on SysV or SysD. Thomas's patch adds multilib capability to either of those pathways. I am looking to apply a "PkgUser" (the More Control hint) approach on top of that. My local (file-backed) SVN repo contains a mix of direct PkgUser modifications, along with things such as 2>&1 | tee ../make.out being added into (hopefully) all of the various make commands, so including the "make check/test" and "make install" stuff. I also make a few changes to blocks so as to remove some things from the output generated by the book's Makefile's dump-commands target. What's not been clear to me in trying to store changes within my local SVN repo is how to seperate things out so that for example, i could apply a "PkgUser" SVN diff to a vanilla LFS XML source tree if it hadn't had Thomas's Multilib patch already applied. Another one along the same lines is the make redirection stuff that I add into my own books. Whilst that's not realy PkgUser specific, i could see that a standlone SVN diff that applied just that might be useful to some folk, but again it's not clear how to seperate things out when using SVN across the two "regimes" I am adding stuff on top off, namely, the vanilla LFS and the Multilib additional source. Any pointers/insight welcome. Kevin PS I have a rendering of my current book but am yet to stick it up on the internet in case anyone wnats to take a look.: RSN. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
