On 6/1/2016 12:56 AM, Bruce Dubbs wrote:
DJ Lucas wrote:
On 05/31/2016 07:53 PM, Bruce Dubbs wrote:
Those there packages are all in LFS too.
:-) So, that does open the door for the next question, however. What is
the path to merge BLFS books? Is everybody comfortable with how the LFS
merge went and how it is working after the fact? IMO, it was a complete
success! I've still got a bit more to do in chapter 7 device naming to
bring it up to par with SysV, being side by side brings those
omissions to
the forefront, but if BLFS is to be done in similar fashion, might
want to
get started on it sooner rather than later in the release cycle.
Well, it was a fair amount of work for me. I am happy with the results
though. I want to wait for a couple of weeks to start things though. I
need to do a full kde update first and plasma 5.6.5 is due June 14. kf5
5.11 on June 6th, kf5 apps also on June 14th.
I need to get GNOME updated and KF5/Plasma5 updated before we start on
this as well. What I am hoping is that when I get KF5/Plasma5 sorted
out, I can just merge your changes over... or I could just wait until
the merged book.
The advantage of the 2nd book is that we have already gone up the
learning curve. The drawback is that BLFS is 10x the size of LFS.
I suspect most of the changes are for services like mail servers, etc.
However there are numerous packages that are only in systemd. What I
did for LFS was to do a diff for each package to decide if a different
file was needed. After a while we were able to consolidate a lot of
those files.
I suppose I can create a merge branch any time. The only problem is
that updates need to be made in multiple places unless we just stop
updating trunk. That would be a lot like a package freeze before
release and a ton of upstream packages tend to accumulate.
That would be a huge issue, at least at this current time. A couple
weeks and we should be fine. While it would be helpful for me to do that
GOLD testing, doing a ton of updates right before yet another package
freeze (assuming it takes that long) doesn't make too much sense to me.
Given the size and scope of BLFS, I had thought it might be smoother to
get trunk ready to handle sysv/systemd without any additional content,
and
continue development as usual. I believe this will actually be less
disruptive WRT jhalfs than it was for LFS since we already do a profiled
build (still have to handle the menu, can it be reused?). Then, gradually
pull in the necessary systemd changes. It'll make the timeframe larger to
be sure, but I think it would be a smoother overall transition.
Probably a
bit more tedious than a long freeze, but we'll get there. Might also give
a bit of breathing room to Jean-Phillipe and the French translation team
if they are tracking BLFS.
I'm not sure what you mean here. Do you just want to fix trunk's
Makefile to support the revision= attributes and stop updating the
systemd branch? That would certainly be easier from my point of view.
That would be certainly be easier for doing the merging, but if anything
happens with GNOME-related stuffs during that time, I would like to be
on top of that. I hate trying to update GNOME sometimes up to 4 major
releases like I am doing right now, it becomes incredibly tedious.
What I will do while I am updating GNOME/Plasma5 is specify in the XML
file what exactly requires logind or any systemd service for that
matter. That might help out as well. I can keep a list of
systemd-specific tweaks and packages going too, so we have a list of
that stuff.
OT: Speaking of which, I love the side-bar navigation in the French
translation here:
http://www.fr.linuxfromscratch.org/view/lfs-stable/index.html
Excellent work guys! I have exactly two nit-picks, to my taste. I'd
freeze
the indent after the large icons show up in the TOCs, and left justify if
using the small icons (there are some big gaps with only 4-6 words per
line in full justification). If it is all or nothing, still left. But
even
with those minor points, this is an excellent change! It scales to
everything I've thrown at it.
That's their css3 work. We looked at it some time ago. I liked it, but
there was some resistance from some editors. That may be something to
incorporate after the BLFS merge.
I was just reminded that this came up before 2015/08/07 (I wasn't active
at that time). I vaguely remember looking at some of Ken's screenshots
and
having a "meh" response, so I didn't on list.
http://anduin.linuxfromscratch.org/~bdubbs/lfs-book-test/prologue/foreword.html
There have obviously been some changes since, but I'm kind of liking most
of it after seeing it tonight. The font is nicer on the French page, and
the nav icons are evenly spaced on the French page. Bruce's version
doesn't have the indent or large header that I didn't like, and is left
justified. There is an issue with the header being indented in portrait
mode on Android Chrome when viewing Bruce's render as well. I think this
was pretty close when Bruce and Ken last left off. I'd like to revisit
the
css3 changes. Too much at once I know, but that presentation is really
nice!
We can keep it in mind. Depending on how the BLFS merge goes, we might
want to do it before the next release. The scheduled package freeze for
that is in about 10 weeks (mid August), but the exact day will depend on
what packages are pending from upstream.
-- Bruce
On another note, we need to finish tagging in systemd before I feel
confident on the merge as well. Can someone (Bruce) run a grep for
"&lfs77_checked", "&lfs77_built", "&lfs78_checked", "&lfs78_built" for
me? Portable workstation is building GCC right now, still about a
half-day or more out, and I would much rather not rush that machine at
the moment.
--
Douglas R. Reno
--LFS/BLFS systemd maintainer
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
