Summary: | stable keyword request for www-client/links-2.1_pre17-r1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Marcelo Goes (RETIRED) <vanquirius> |
Component: | Current packages | Assignee: | Marcelo Goes (RETIRED) <vanquirius> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | mips |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Other | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Marcelo Goes (RETIRED)
2005-06-25 14:47:05 UTC
Stable ppc-macos 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 ppc64 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 amd64, Stable on hppa Stable on alpha. Thanks to kloeri who keyworded it ten days ago =) I'm happy enough, closing this bug :-). Closing it again. |