https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-ruby/tty-screen-0.8.2 fails tests. Discovered on: amd64 (internal ref: lto_tinderbox) System: LTO-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#LTO) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0015
Created attachment 886346 [details] build.log build log and emerge --info
Error(s) that match a know pattern in addition to what has been reported in the summary: Failure/Error: expect(File).to have_received(:exist?).with(path) NameError:
I saw this test failure when the package was built as part of a standard "emerge -auND @world" run, with output not going to the terminal, but when I tried building just this package with output not hidden, the test passed. The other difference between the two builds was that the first was inside of an app-misc/screen session, with TERM=screen, while the second was outside that session and had TERM=xterm-color (though I don't know if the Portage ebuild environment may have reset $TERM). So my guess is that this test is somehow sensitive to the actual terminal attached, or not, to its stdout?
(In reply to Jonathan Lovelace from comment #3) > So my guess is that this test is somehow sensitive to the actual terminal > attached, or not, to its stdout? I think it might be related to the location of the stty command. For me on a split-usr system that is located at /bin/stty. Do you happen to have a merged-usr system (with /usr/bin/stty also being present)?
No, this is a split-usr system; "which -a stty" returns only /bin/stty. At that time it was still on the 17.1 profile (and it hasn't hit this package in the final "emerge --emptytree @world" step of the 23.0 profile migration yet). And (speaking of /bin/stty) while I do have =sys-apps/coreutils-9.5 in package.accept_keywords, it was installed before either the failed or the successful build of this package. I finally took the time to look at the log of the failed build: ------------------------------ Failures: 1) TTY::Screen.size_from_tput doesn't detect size when the tput command is missing Failure/Error: expect(File).to have_received(:exist?).with(path) NameError: uninitialized constant RSpec::Support::Differ # ./spec/unit/screen_spec.rb:378:in `block (3 levels) in <top (required)>' Top 2 slowest examples (0.01197 seconds, 19.1% of total time): TTY::Screen.size_from_tput detects size 0.00816 seconds ./spec/unit/screen_spec.rb:420 TTY::Screen.size_from_tput doesn't detect size when the tput command raises an IO error 0.00381 seconds ./spec/unit/screen_spec.rb:382 Finished in 0.06263 seconds (files took 0.1418 seconds to load) 57 examples, 1 failure Failed examples: rspec ./spec/unit/screen_spec.rb:366 # TTY::Screen.size_from_tput doesn't detect size when the tput command is missing Randomized with seed 30762 ------------------------------ And I noticed that the specific "NameError" is "uninitialized constant RSpec::Support::Differ". So maybe the difference may have something to do with dev-ruby/rspec-support? On this machine =dev-ruby/rspec-support-1.13.1 was merged only shortly before the failed tty-screen build (in /var/log/portage, the rspec-support build log is timestamped only 6 minutes before the tty-screen build log showing the failure), and I notice rspec-support is not mentioned in *DEPEND for dev-ruby/tty-screen. (I don't *think* the @world update that ended with the test failure for this package used any "emerge -j" option, but it might have ...)
(In reply to Jonathan Lovelace from comment #5) > No, this is a split-usr system; "which -a stty" returns only /bin/stty. So much for that theory then :-) > And I noticed that the specific "NameError" is "uninitialized constant > RSpec::Support::Differ". Yes, but this is a bug in RSpec where the actual error is hidden by this Differ one. I think this is related to where exactly a bug triggers but I'm not sure. It does make it harder to track down the actual issue. Perhaps it would help to run the tests manually with the "-b" option for rspec to see if anything useful comes out of the backtrace.
