Bug 97071 - stable keyword request for www-client/links-2.1_pre17-r1
|
Bug#:
97071
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Other
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: vanquirius@gentoo.org
|
Reported By: vanquirius@gentoo.org
|
|
Component: Applications
|
|
|
URL:
|
|
Summary: stable keyword request for www-client/links-2.1_pre17-r1
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2005-06-25 14:47 0000
|
Hello,
-r1 includes a new livecd flag. It forces graphic support to be built so that the version of links present in LiveCDs allows a better browsing experience. It would be nice if -r1 could be stabilized in arches for which LiveCDs are built and others too if there is time.
Thanks,
Marcelo
Does this fix properly take into account arches who have masked the graphics
useflags for links2? For those of us archs without VESA or VGA compatible
framebuffers, this might be a potential issue.
Good point and no, it does not. Here is the relevant part of the ebuild:
if use fbcon || use livecd; then
myconf="${myconf} --with-fb"
else
myconf="${myconf} --without-fb"
fi
An easy hack around it is to wrap this condition so that arches that do not have
framebuffer support do not pass --with-fb when the livecd flag is enabled. Other
ideas are welcome.
Just FYI, the livecd flag also forces the options --enable-graphics and
--with-libjpeg, although I don't think those should be a problem.
stable on ppc
This is going to look really nice on those live CDs...
Stable on sparc.
Weeve: it really doesn't matter, since links starts up as text-mode by default
unless you invoke it "links -driver fb" where it'll work if you have gpm working
and a framebuffer.
That being said, it works on sparc with fb. It should probably be handled in the
livecd with some alias to invoke it in fb mode, or just document the invocation
mode for that (though it'll require gpm running too).
Stable on alpha. Thanks to kloeri who keyworded it ten days ago =)
I'm happy enough, closing this bug :-).
