| Summary: | "emerge something" resets terminal size to 80x25 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Thomas Eckert <eckert.thomas> |
| Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bevdv, daniel, folke.lemaitre, jared, matthiasbernges, radek |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Diff-file to workaround | ||
|
Description
Thomas Eckert
2003-11-01 03:16:14 UTC
addendum: same behaviour if you "ebuild some.ebuild unpack" instead of doing a full "emerge some". (2 different profiles tested: default-1.0 and default-x86-1.4) Strange -- I'd expected more people having this problem ... The resizing occurs on 4 different machines here (indepently installed, different versions of xfree running). Workaround: eval $(resize) to get the correct size back after each emerge. I can't confirm that here, terminal size as reported by `stty size` stays the same, tested with both xterm and multi-gnome-terminal. I have a machine not showing the "resize-effect" -- but I couldn't pinpoint the reason yet. Biggest difference between working<->non-working is gcc-3.2.3<->gcc-2.95.3. The first guess was "notitles" in FEATURES -- but does not seem to be the prob. I'll try to figure it out here -- any hints welcome. Closing this until someone can confirm this bug. Finally I found a way to reproduce it: the reason is NOCOLOR="yes" in make.conf (or make.globals). If color-support is disabled the terminal is resized to 80x25 -- if you use "ebuild xx.ebuild unpack" you should take care to do a "ebuild xx.ebuild clean" to remove the save environment from PORTAGE_TMPDIR! (the terminal-size is preserved there and you may not see an effect when changing the value of NOCOLOR). Thomas ... it does not happen with portage-2.0.48-r5 and NOCOLOR="yes" (tested on an old installation). Update baselayout on the old box and see if the problem starts. Portage shouldn't be doing anything regarding terminal info. This is not portage related. NOCOLOR isn't used for anything other than removing ANSI codes form the print strings. Happy christmas to you all.
Unfortunately my present is not a "baselayout was to old"-message:
baselayout is up-to-date on the old box (as it is on the new ones).
old-box # epm -q baselayout
baselayout-1.7.8-r1
baselayout-1.8.6.10-r1
The problem is _real_ here and NOCOLOR="yes" is the key. I tested different
terms (vanilla console, xterm, rxvt, screen).
As it does not happen with portage-2.0.48-r5 -- verified by downgrading on a
testmachine from portage-2.0.49-r15 to portage-2.0.48-r5 -- I seriously doubt
that it is _not_ portage related. The testmachine is up to date ("emerge -u
world" yesterday).
Happens for me too; fully up-to-date box, NOCOLOR="true", multi-gnome-terminal. Confirmed that turning off NOCOLOR="true" fixes the problem. While "NOCOLOR isn't used for anything other than removing ANSI codes form the print strings", it's pretty clear it's doing it the wrong way. Offhanded guess is that it is using an ANSI escape code which resets the terminal, instead of just the colors. A prowl through the exact ANSI codes used and an ANSI color reference manual would probably find it. Probably line 11 of /usr/lib/portage/pym/output.py. Created attachment 40521 [details, diff]
Diff-file to workaround
The problem is in /etc/init.d/functions.sh about line 800
I added a diff file to workaround this but I maybe it will break the ouput in
other cases.
dont use baselayout 1.11.x, ive made it worse in that version :) i need to break out a serial console so we can fix this properly ... i'll try to do so this weekend ... I tested the fix from comment #12 and it works fine for me so far, thanks Matthias for digging into this. I patched this one: # $Header: /home/cvsroot/gentoo-src/rc-scripts/sbin/functions.sh,v 1.52 # 2004/05/21 15:22:12 agriffis Exp $ it's not a fix, it's a workaround i'm investigating a real fix anyway, i'm happy this is now recognized as a bug (that should be fixed) -- it wasn't tooo easy to make that happen, thanks to all commenters. with a bit of "luck" i'll be able to celebrate the first birthday of this one soon ;) (no offense meant) *** Bug 22428 has been marked as a duplicate of this bug. *** ok, i've fixed this in cvs and tested it on some serial and non-serial consoles the end result is that the stty code works for some serial consoles, but not all, so i've just removed it ... your workaround should work fine for users until the next version of baselayout is released thanks :) *** Bug 67279 has been marked as a duplicate of this bug. *** *** Bug 67518 has been marked as a duplicate of this bug. *** |
