make[3]: *** [../../../build/rules.make:122: do-test] Error 2 make[3]: Leaving directory '/var/tmp/portage/dev-lang/mono-basic-4.7/work/mono-basic-4.7/vbnc/vbnc/tests' make[2]: *** [../../build/rules.make:134: test-recursive] Error 1 make[2]: Leaving directory '/var/tmp/portage/dev-lang/mono-basic-4.7/work/mono-basic-4.7/vbnc/vbnc' make[1]: *** [../build/rules.make:134: test-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/dev-lang/mono-basic-4.7/work/mono-basic-4.7/vbnc' ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-desktop-gnome_test_20180508-174739 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.0 * Available Python interpreters, in order of preference: [1] python3.5 [2] python2.7 (fallback) [3] pypy3 (fallback) [4] pypy (fallback) java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.7.0 [icedtea-bin-8] 2) JamVM JDK 2.0.0 [jamvm] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm [2] jamvm emerge -qpv dev-lang/mono-basic [ebuild N ] dev-lang/mono-basic-4.7
Created attachment 531832 [details] emerge-info.txt
Created attachment 531834 [details] dev-lang:mono-basic-4.7:20180516-162411.log
Created attachment 531836 [details] emerge-history.txt
Created attachment 531838 [details] environment
Created attachment 531840 [details] etc.portage.tbz2
Created attachment 531842 [details] temp.tbz2
Why does the test case try to use a DLL ?!?
(In reply to Toralf Förster from comment #7) > Why does the test case try to use a DLL ?!? I don't think, this is a *.dll in the terms of a native win32 one. For example, when I do load libusb for a mono-basic project, it loads the *.so one, but internally it's still referred to a *.dll. Anyway, I don't have any clue, how to fix this tests. I can't even reproduce it here, where it fails for you. But I noticed, running tests with > -j1 seems to produce some strance problems. For me, running the test, it fails initially, because it wants to download some parts from the internet. Since this is not allowed in portage sandbox, it fails. When I do run with FEATURES="-network-sandbox", tests are executed, but at the end 6 tests fail. I can reproduce this also without portage, when just running locally. I don't have the knowledge to fix this. @Torlalf, @mgorny: Do you have an idea, what could be done to fix this? Or should be set RESTRICT="test" in this case as internet is needed for those tests?
Created attachment 543324 [details] build.log
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e8a8e22890881d806f95de192e5f79e6c708f584 commit e8a8e22890881d806f95de192e5f79e6c708f584 Author: Conrad Kostecki <conrad@kostecki.com> AuthorDate: 2018-10-07 11:02:20 +0000 Commit: Virgil Dupras <vdupras@gentoo.org> CommitDate: 2018-10-11 18:12:32 +0000 dev-lang/mono-basic: restrict tests and bump to EAPI=7 Tests do need internet access, so network-sandbox must be disabled. But tests also seems to fail. No response from upstream. Closes: https://bugs.gentoo.org/656682 Closes: https://bugs.gentoo.org/655900 Signed-off-by: Conrad Kostecki <conrad@kostecki.com> Package-Manager: Portage-2.3.50, Repoman-2.3.11 Closes: https://github.com/gentoo/gentoo/pull/10024 Signed-off-by: Virgil Dupras <vdupras@gentoo.org> dev-lang/mono-basic/mono-basic-4.6-r2.ebuild | 18 ++++++++++++++++++ dev-lang/mono-basic/mono-basic-4.7-r1.ebuild | 18 ++++++++++++++++++ 2 files changed, 36 insertions(+)
