On Thu, May 17, 2012 at 02:33:16PM -0700, Qrux wrote: > > On May 17, 2012, at 12:31 PM, Ken Moffat wrote: > > > > > Does this work for you ? > > Was resizecons a part of pre-7.1 LFS? If not...What is the rationale for > inclusion at this point? It sounds like a horrific thing. Here's a > description I've read: > I would hope that you can answer that question from your own build logs, but here's my response:
Resizecons has been in kbd since what it pleases me to call "time immemorial" (technically, that's an English legal phrase, and there is a year associated with, somewhere in the 1400s, I think, which is obviously an exaggeration for computing questions). My oldest remaining logs are from LFS-6.3 - I purged the older ones, and should probably purge some more - where resizecons was built and installed. Note: in those days, LFS was on i?86 only, those of us building on ppc or x86_64 had mostly moved to cross-lfs. After LFS became able to build on x86_64, I soon stopped building for i686 - the restricted registers just seemed so wrong! On *all* of my x86_64 builds, the resizecons program was not installed but its manpage was. Same on ppc/ppc64 (macs, so using framebuffers). But I never noticed until it was queried last week. I discovered that upstream (git) now *does* install resizecons on x86_64 as well as i?86, probably after someone raised a bug at SuSe, but it isn't useful without svgalib - and that was for linux-2.4, although some distros patch it to still build. > "The resizecons command tries to change the videomode of the console. There > are several aspects to this: (a) the kernel must know about it, (b) the > hardware must know about it, (c) user programs must know about it, (d) the > console font may have to be adapted." > > So, we have a program that has these complex interactions, and...provides > console size/font management? What is the use-case here? The edge case > where developers use the console for development? If it's just a case of "Oh > crap, I borked my network settings and I can't SSH in," or "Bummer, I screwed > up my X settings, and I can't start X", then I certainly can live for 20 > minutes debugging some conf file in vi in a 80x25 window. I'm perfectly > happy with the janky BIOS interface (unless newer kernels won't/can't do that > anymore). > I would hope that is true for everyone building LFS, although modern macs technically use the can of worms called EFI, not a BIOS. I've snipped the rest - on this occasion I agree with your sentiments, but you're answering the wrong question : it was noted that on x86_64 the manpage exists but the program doesn't. From there I determined that we *could* build it on x86_64, but it could not do anything without the obsolete svgalib. My preference is to get rid of it, but there were some alternatives in a mail I sent earlier this evening. Meanwhile, I'm waiting to see if xinglp has a problem - we've had this redundant program for years now, so best to wait a bit to find out if dropping it will expose a problem for someone. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
