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
