Created attachment 494436 [details] build.log This dependency is of course not in tree yet, and I'll get onto that ASAP. And as I said in https://bugs.gentoo.org/624754#c2 I have my doubts about needing Module::Install in the test suites. Module::Install typically is only needed for "authors", as its release process results in a bundled, frozen version of Module::Install There's also a bunch of problems with having Module::Install installed in that it makes an entire class of related bugs invisible ( see: https://wiki.gentoo.org/wiki/Project:Perl/Dot-In-INC-Removal ), and for this reason Perl herd is trying to whittle it out of existence. FAIL: testcases/complete-run.pl =============================== Can't locate X11/XCB/Connection.pm in @INC (you may need to install the X11::XCB::Connection module) (@INC contains: /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/testcases/lib /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/lib /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/AnyEvent-I3/blib/lib /etc/perl /usr/local/lib64/perl5/5.26.0/x86_64-linux /usr/local/lib64/perl5/5.26.0 /usr/lib64/perl5/vendor_perl/5.26.0/x86_64-linux /usr/lib64/perl5/vendor_perl/5.26.0 /usr/local/lib64/perl5 /usr/lib64/perl5/vendor_perl/5.26.0-RC1 /usr/lib64/perl5/vendor_perl/5.25.12 /usr/lib64/perl5/vendor_perl/5.25.11 /usr/lib64/perl5/vendor_perl/5.22.3 /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/5.26.0/x86_64-linux /usr/lib64/perl5/5.26.0) at ./testcases/complete-run.pl line 31. BEGIN failed--compilation aborted at ./testcases/complete-run.pl line 31.
After satisfying the X11-XCB dep, it seems to need Xephyr built into xorg FAIL: testcases/complete-run.pl =============================== Xephyr was not found in your path. Please install Xephyr (xserver-xephyr on Debian). at ./testcases/complete-run.pl line 113. FAIL testcases/complete-run.pl (exit status: 2)
Ugh. This test suite is just terrible. After you install xorg-server[xephyr], the test hangs indefinately. Of course it does, xephyr instances need a display to run on. So you throw virtualx into the mix, and you spawn a display on your display so you can test while you test. And the next error is: FAIL: testcases/complete-run.pl =============================== Starting 4 Xephyr instances, starting at :6... fatal: Not a git repository (or any of the parent directories): .git Use of uninitialized value $timingsjson in numeric gt (>) at ./testcases/complete-run.pl line 170. Writing logfile to 'testsuite-2017-09-14-04-30-30-/complete-run.log'... test /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/t/000-load-deps.t bailed out: The Perl module "Inline" could not be loaded. Please see http://build.i3wm.org/docs/testsuite.html#_installing_the_dependencies FAIL testcases/complete-run.pl (exit status: 1) Getting the impression upstream never considered people other than them would run tests.
Ok, I know how to get it to this stage now where the first real bug appears, I'll send you a PR with a bunch of fixes. =============================== i3 4.14: ./test-suite.log =============================== # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: testcases/complete-run.pl =============================== Starting 4 Xephyr instances, starting at :6... fatal: Not a git repository (or any of the parent directories): .git Use of uninitialized value $timingsjson in numeric gt (>) at ./testcases/complete-run.pl line 170. Writing logfile to 'testsuite-2017-09-14-04-44-08-/complete-run.log'... # Failed test 'human readable version contains branch name' # at /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/t/193-ipc-version.t line 35. # '4.14 (2017-09-04)' # doesn't match '(?^:branch)' # Failed test 'first tiled border width 2' # at /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/t/263-edge-borders.t line 153. # got: '1280' # expected: '636' Test Summary Report ------------------- Use of uninitialized value in subtraction (-) at /usr/lib64/perl5/5.26.0/TAP/Formatter/Base.pm line 386. Negative repeat count does nothing at /usr/lib64/perl5/5.26.0/TAP/Formatter/Base.pm line 386. /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/t/193-ipc-version.t (Wstat: 0 Tests: 5 Failed: 1) Failed test: 5 Use of uninitialized value in subtraction (-) at /usr/lib64/perl5/5.26.0/TAP/Formatter/Base.pm line 386. Negative repeat count does nothing at /usr/lib64/perl5/5.26.0/TAP/Formatter/Base.pm line 386. /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/t/263-edge-borders.t (Wstat: 0 Tests: 23 Failed: 1) Failed test: 21 Files=219, Tests=2747, 37 wallclock secs ( 0.81 usr + 0.06 sys = 0.87 CPU) Result: FAIL The slowest tests are: /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/t/165-for_window.t with 13.16 seconds /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/t/262-root-window-mouse-binding.t with 10.43 seconds /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/t/264-keypress-numlock.t with 7.67 seconds /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/t/265-swap.t with 6.45 seconds /var/tmp/portage/x11-wm/i3-4.14/work/i3-4.14/x86_64-pc-linux-gnu/../../i3-4.14/testcases/t/529-net-wm-desktop.t with 5.01 seconds FAIL testcases/complete-run.pl (exit status: 1)
Ugh. Gosh. I see why you added the Module::Install dependency now :/ Its a result of AnyEvent-I3 not shipping its own like its supposed to.
Thanks for you work on this Kent, I haven't followed the test failures since AnyEvent-I3 is new in the tree and we still have dev-perl/AnyEvent-I3. I wanted to follow up with the perl project to see how we'll proceed with AnyEvent-I3 now being part of the i3 tree. Looking at the changelog of dev-perl/AnyEvent-I3 you actually fixed the missing Module-Install dependency: https://bugs.gentoo.org/614694 Unless AnyEvent-I3 has dependencies other than i3 I'd suggest to remove the AnyEvent-I3 package. The package doesn't make much sense without i3 anyhow. If we keep going with AnyEvent-I3 as a separate package it should be removed from the tarball and build system in i3's src_prepare - however I'd rather not make invasive changes to the build system.
Ah, the most recent comment on the gh issue[1] makes it clearer. We'll keep going as it is, then. It is weird though to move a "separate" projects' tree into another project while keeping to distribute different dists. I'll see if I can easily and reliably patch out the AnyEvent-I3 tests from the test suite. But I'm pretty sure I remember that even building i3 fails, when AnyEvent-I3 can't find Module-Install. I'll follow up on that tonight. For reference of other readers: [1]: https://github.com/i3/i3/issues/2905
(In reply to Nelo-T. Wallus (ntnn) from comment #5) > Thanks for you work on this Kent, I haven't followed the test failures since > AnyEvent-I3 is new in the tree and we still have dev-perl/AnyEvent-I3. > > Looking at the changelog of dev-perl/AnyEvent-I3 you actually fixed the > missing Module-Install dependency: https://bugs.gentoo.org/614694 Yeah, that's kinda different. The AnyEvent-I3 that ships to CPAN ships with Module::Install embedded: https://metacpan.org/source/MSTPLBG/AnyEvent-I3-0.17/inc But the archive that you fetch from github does not. The Issue above only *looks* similar, but happens for a different reason: Perl 5.26 changes its @INC path and the `use inc::Module::Install` statement simply stops being able to find the bundled files. ( https://wiki.gentoo.org/wiki/Project:Perl/Dot-In-INC-Removal ) The archive you fetch from github however lacks these, and so is either designed for *upstream* use ( upstream's that use Module::Install don't keep copies in their repo, Module::Install is auto-bundled during the release), or they're doing something wrong. > I wanted to follow up with the perl project to see how we'll proceed with > AnyEvent-I3 now being part of the i3 tree. > > Unless AnyEvent-I3 has dependencies other than i3 I'd suggest to remove the > AnyEvent-I3 package. The package doesn't make much sense without i3 anyhow. > > If we keep going with AnyEvent-I3 as a separate package it should be removed > from the tarball and build system in i3's src_prepare - however I'd rather > not make invasive changes to the build system. This is really a different concern as far as I can tell at present. It looks to me like upstream are bundling it *exclusively* for testing, as their install process doesn't deploy AnyEvent-I3 to the system. To the extent that one viable way of getting around the Module::Install problem above is using *2* SRC URI's, specifically: AEVER=0.16 SRC_URI="https://i3wm.org/downloads/${P}.tar.bz2 test? ( mirror://cpan/authors/M/MS/MSTPLBG/AnyEvent-I3-${AEVER}.tar.gz )" Note: the first of those is the one lacking AnyEvent-I3 you reported And the second of those is the CPAN copy. And you can then move the unpacked dir into the right place, and have it (mostly) work ( at least, its as equally broken as the github copy with a system Module::Install ) So basically I'd say unless upstream provide credible evidence that they're trying to push the bundled AnyEvent-I3 for use by end users, ( as opposed to strictly testing as it is now ), we should stick to what we're doing until they shake that up.
Created attachment 494440 [details, diff] ebuild.patch This is just where I'm at atm, hopefully patch notes and changes are some kind of interesting. :)
Thanks for your work and help on this, kent. Dependencies for tests are now packaged by kent and the test stage has been fixed. Since i3's test suite is broken if note executed below $HOME of the executing user tests have been restricted. Upstream issue: https://github.com/i3/i3/issues/3013
