In an vte-based terminal (likely only part that matters here is that it's not console), if a fetch happens during 'emerge -1', the output is along the lines of: 0% [ ] 0 --.-K/s 0% [ ] 30.116 106K/s 0%[ ] 66.316 117K/s 1%[ ] 118.444 139K/s 1%[ ] 170.572 150K/s 2%[ ] 225.596 159K/s 2%[> ] 297.996 175K/s 3%[> ] 386.324 194K/s 4%[> ] 471.756 212K/s 5%[=> ] 528.228 217K/s 6%[=> ] 616.556 227K/s a bit surprisingly, output of 'emerge -1f' is normal - only a single line for the fetch. [ebuild R ] dev-lang/python-2.7.2-r3 USE="doc examples gdbm ipv6 ncurses readline sqlite ssl threads (wide-unicode) xml -berkdb -build -tk -wininst" 0 kB [ebuild U ~] dev-lang/python-3.2.2-r1 [3.2.2] USE="doc examples gdbm ipv6 ncurses readline sqlite ssl threads (wide-unicode) xml -build -tk -wininst" 0 kB [ebuild R *] sys-apps/portage-2.2.0_alpha98 USE="doc (ipc) -build -epydoc (-pypy1_8) -python2 -python3 (-selinux) -xattr" LINGUAS="-pl" 0 kB
The EbuildFetcher class is supposed to create a pty device, which makes wget show a 1-line progress bar, if stdout is a tty. You can use this shell code to check if stdout is a tty in your terminal: [ -t 1 ] && echo yes || echo no You can adjust FETCHCOMMAND to use a progress bar even without a tty, by using the wget --progress=bar:force option.
Well, that line answers with "yes", also there's the part, that it's inconsistent between "emerge -1" and "emerge -1f".
(In reply to comment #2) > it's inconsistent between "emerge -1" and "emerge -1f". That's puzzling, since the EbuildFetcher class is used in both cases, so it should use the same logic for whether or not it chooses to create a pty device. The code is as follows: def _pipe(self, fd_pipes): """When appropriate, use a pty so that fetcher progress bars, like wget has, will work properly.""" if self.background or not sys.stdout.isatty(): # When the output only goes to a log file, # there's no point in creating a pty. return os.pipe() stdout_pipe = None if not self.background: stdout_pipe = fd_pipes.get(1) got_pty, master_fd, slave_fd = \ _create_pty_or_pipe(copy_term_size=stdout_pipe) return (master_fd, slave_fd)
Something is indeed odd. While the problem is not that recent, I've gone as far back as alpha86 (going even further would make me a bit twitchy, as I seem to recall there was a significant bug back then) and still see the problem. I'm not quite sure when I've seen the problem for the first time, as I usually fetch first, then emerge already fetched, so I might just missed the moment.
(In reply to comment #0) > a bit surprisingly, output of 'emerge -1f' is normal - only a single line > for the fetch. I guess this explained by the special fetchonly code in the EbuildBuild class, which forces background=False. I don't understand why background == True for your other command though, because that's only supposed to happen for --quiet-build=y or --jobs 1, when output is automatically redirected to a log file.
... Actually, I've got 'EMERGE_DEFAULT_OPTS="--quiet-build=n"' in make.conf...
Does it make any difference in the wget output if you remove --quiet-build=n from EMERGE_DEFAULT_OPTS?
(In reply to comment #7) > Does it make any difference in the wget output if you remove --quiet-build=n > from EMERGE_DEFAULT_OPTS? No, it does not.
Well, it seems that the reason is quite a funny thing: my terminal was less than 80 char wide. It was enough to use the mouse, for the output to become the expected form.
Now that you mention it, it seems obvious that the terminal is not wide enough for the output in comment #0. It's not the --progress=dot output that wget automatically produces when stdout is not a tty. Maybe it's a bug in wget, or maybe if portage exports the COLUMNS variable then wget will work correctly. Portage already uses stty to set the number of rows and columns on the pty device.
is this still an issue ? portage has been updated to export COLUMNS ...
(In reply to SpanKY from comment #11) > is this still an issue ? portage has been updated to export COLUMNS ... If the question is "does this still happen with portage 2.2.7 ?", the answer is "yes". Otherwise, please be more specific. (well, it might play a role here, that the terminal in question doesn't resize itself quite correctly...)
The bug definitely happens outside portage, even on wide terminals. My Konsole is 211x60, and attempting to wget http://distribution.bbb3d.renderfarming.net/audio/bbb3d_sunflower_soundtrack_surround.flac results in the same kind of corrupted progress-bar as in the original bug report.
Created attachment 390054 [details, diff] Upstream wget patch that fixes the issue
It turns out that the assertion is wrong and can be triggered. See https://lists.gnu.org/archive/html/bug-wget/2014-11/msg00135.html
Created attachment 390056 [details, diff] Updated patch
i get a segfault with current 1.17.1. whee!
added a fix from upstream for the segfault: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=885437bfa2b7d96e6aa6dc846f0123051496b5d3 so this should work fine w/1.17.1-r1+
