Re: gcc-ddc
Aside from these libtool files we can now say, that this ddc project succeeded. I've contacted the libtool developers if we can extend the wrapper approach to the .la files. It seems, that in some older version of libtool those were just sourced as shell script, but I don't know if now they do something more fancy with it or not... Anyways, if it's just shell script, then the environment variable approach can also work out there. The only problem seems, that I should do the substitution before checksumming the compiler. I think I can inject something into the makefile, or use a patched vesion of libtool. A patched libtool could be a better option, so other ddc projects can use it. I guess I can do something like add an environment variable GUIX_INSTALL_DIRECTORY, or something like that... Any maybe name this version libtool-for-ddc. It should be noted in the package documentation, that this package is not recommended for general use. WDYT? 2017-11-30 15:32 GMT+01:00 Gábor Boskovits : > It seems, that the libtool file differences leak into the checksum. > I will try to contact developers on how to bypass that issue. > > > 2017-11-29 16:57 GMT+01:00 Jan Nieuwenhuizen : > >> Gábor Boskovits writes: >> >> > It seems, that I can make really good progress here. >> > Now the only things that remain: >> >> Great! >> >> > The libtool .la files record the installation directory, these are >> textfile wrappers anyways, so I don't know if >> > we should care about this. >> >> How about asking the libtool developers? >> >> > The mkheaders shell srcipt in install-tools record the installation >> directory, this is in source form by the >> > way, so I don't know if we should care about this. >> >> In a way similar to the libtool wrappers: the build is still >> reproducible in a way; just harder to check with Guix. Having >> everything below /gnu/store/deadbeef-gcc-4.7.4 identical could be a >> feature, but possibly something left for later. >> >> > The only remainig problem is that the symbol executable_checksum in cc1 >> and cc1plus still differ. No other >> > differences remained. >> >> OK! >> >> > I'm now investigating the checksum issue. >> >> Great to hear your progress >> janneke >> -- >> Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org >> Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com >> > >
Re: MIME database
Andy Wingo skribis: > Specifically we should add to this package from gnome.scm to include the > PDF -> evince association: I’ve just done that: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8ad4f0aa315d69ff6b2df50e21ef01a60b0d2aec Ludo’.
Re: boot the Hurd with Guix
Hi rennes, ren...@openmailbox.org skribis: > This is the demo generated with Guix: > > https://github.com/methalo/boot-hurd > > The binary files were generated in Debian/Hurd and placed in an 'img' file. > > The command used to generate the binaries is: > > './pre-inst-env guix system init ~/light.scm /guix' > > To test Hurd, execute: > > 'sudo qemu-system-i386 -enable-kvm -m 1G -hda guixsdhurd.img -curses' [...] > https://ombx.io/ipoWt9uK I just gave it a try, and woow! :-) It’s really nice to see that in action. It lacks a couple of things such as the console server and client and the pipe server, but tweaking this will be the funny part. ;-) Also, in GRUB, you currently load ext2fs.static and exec explicitly. There’s now a /hurd/startup server that takes care of launching /hurd/proc, /hurd/auth, and then passes control to /libexec/runsystem. I suppose this is the preferred method, but hurd.texi doesn’t give the exact GRUB commands. Can anyone shed some light? BTW, the image you posted is in “raw” format. You would get a smaller file by using the qcow2 format, which you can create with “qemu-img create -f qcow2”. Anyway, kudos, and keep up the good work! Thank you, Ludo’.
fcgiwrap doesn't see gzip
strace log from my previous message, apologies.
I guess, the issue is because fcgiwrap process environment PATH only
contains /gnu/store/…-shadow-4.5/sbin which doesn't include gzip.
--8<---cut here---start->8---
$ sudo strace -s 128 -p 457
strace: Process 457 attached
accept(0, {sa_family=AF_INET, sin_port=htons(57088),
sin_addr=inet_addr("127.0.0.1")}, [112->16]) = 3
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
read(3,
"\1\1\0\1\0\10\0\0\0\1\0\0\0\0\0\0\1\4\0\1\1!\7\0\17FSCRIPT_FILENAME/gnu/store/27ki0l76vn23698caynfknbcnqf5jag0-cgit-1.1/lib/cgit/cgit.cgi\t&PATH_INFO/guix/"...,
8192) = 336
pipe([4, 5])= 0
pipe([6, 7])= 0
pipe([8, 9])= 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7ff3f0dc4e10) = 12762
close(4)= 0
close(7)= 0
close(9)= 0
close(5)= 0
select(9, [6 8], NULL, NULL, NULL) = 1 (in [8])
read(8, "[cgit] Unable to lock slot /var/cache/cgit/8a30.lock: Permission
denied (13)\n", 4096) = 81
write(2, "[cgit] Unable to lock slot /var/cache/cgit/8a30.lock: Permission
denied (13)\n", 81) = 81
select(9, [6 8], NULL, NULL, NULL) = 1 (in [6])
read(6, "Content-Type: application/x-gzip; charset=UTF-8\nContent-Disposition:
inline; filename=\"guix-0.13.0.tar.gz\"\n", 4096) = 107
select(9, [6 8], NULL, NULL, NULL) = 1 (in [6])
read(6, "Last-Modified: Fri, 01 Dec 2017 11:42:10 GMT\nExpires: Fri, 01 Dec
2017 11:47:10 GMT\nETag: \"99d1ec5989eae66719fb968f41560f2879707"..., 4096) =
134
select(9, [6 8], NULL, NULL, NULL) = 1 (in [8])
read(8, "fatal: Unable to exec subprocess gzip: No such file or directory\n",
4096) = 65
write(2, "fatal: Unable to exec subprocess gzip: No such file or directory\n",
65) = 65
select(9, [6 8], NULL, NULL, NULL) = 2 (in [6 8])
read(6, "", 4096) = 0
close(6)= 0
read(8, "", 4096) = 0
close(8)= 0
write(3, "\1\6\0\1\0\367\1\0Content-Type: application/x-gzip;
charset=UTF-8\r\nContent-Disposition: inline;
filename=\"guix-0.13.0.tar.gz\"\r\nLast-Modifi"..., 280) = 280
shutdown(3, SHUT_WR)= 0
poll([{fd=3, events=POLLIN}], 1, 2000) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
read(3, "", 1024) = 0
close(3)= 0
accept(0, C-c C-cstrace: Process 457 detached
--8<---cut here---end--->8---
--8<---cut here---start->8---
/proc/457$ sudo cat environ
HOME=/
TERM=linux
BOOT_IMAGE=/gnu/store/nrhx7jf33zqxmbw832bpxyrnc0k3lrnq-linux-libre-4.14.2/bzImage
--root=magnolia-root
--system=/gnu/store/mqwc1vmlnx076aka7gn8bi89hmj6v3pq-system
--load=/gnu/store/mqwc1vmlnx076aka7gn8bi89hmj6v3pq-system/boot
PATH=/gnu/store/a8arlhcrf70113zw7b3qrwqbqfq2hgj6-shadow-4.5/sbin
--8<---cut here---end--->8---
Thanks,
Oleg.
signature.asc
Description: PGP signature
Re: 01/01: gnu: glusterfs: Replace hardcoded FHS references.
rek...@elephly.net (Ricardo Wurmus) skribis:
> commit b9fb70ca65f2f76919a093cb73150082466f4203
> Author: Ricardo Wurmus
> Date: Fri Dec 1 16:39:08 2017 +0100
>
> gnu: glusterfs: Replace hardcoded FHS references.
>
> * gnu/packages/patches/glusterfs-use-PATH-instead-of-hardcodes.patch: New
> file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/file-systems.scm (glusterfs)[source]: Use it.
[...]
> +--- a/contrib/fuse-lib/mount-common.c
> b/contrib/fuse-lib/mount-common.c
> +@@ -255,16 +255,16 @@ fuse_mnt_umount (const char *progname, const char
> *abs_mnt,
> + exit (1);
> + }
> + #ifdef GF_LINUX_HOST_OS
> +-execl ("/bin/umount", "/bin/umount", "-i", rel_mnt,
> ++execl ("umount", "umount", "-i", rel_mnt,
Should it be ‘execlp’? Otherwise it’s going to try to execute “umount”
from $PWD, no?
Ludo’.
Re: boot the Hurd with Guix
Hello, Congrats on the achievement :D Ludovic Courtès, on ven. 01 déc. 2017 14:17:48 +0100, wrote: > Also, in GRUB, you currently load ext2fs.static and exec explicitly. That's the normal way, yes. exec does the rest (including running startup). > BTW, the image you posted is in “raw” format. You would get a smaller > file by using the qcow2 format, which you can create with “qemu-img > create -f qcow2”. Well, using sparse files can work as well: create the image with dd if=/dev/zero of=file.img bs=1M count=1 seek=1000 and pass -S to tar so that on decompression it gets sparse too. The advantage is that standard tools (fdisk, etc.) will work on it. Samuel
Re: java: switch to icedtea-8 as default JDK
On Wed, Nov 29, 2017 at 10:58:48PM -0800, Chris Marusich wrote: > Chris Marusich writes: > > >> 1) Confirm that these packages build before making changes. If any > >> fail, fix them first if possible. > >> > >> ... > >> > >> I'm going to try step (1) tonight on my laptop. Is there a way to check > >> their build status on Hydra, I wonder? I'm planning to just do it in a > >> simple shell one-liner like the following: > >> > >> for pkg in $( >> success: $pkg >> /tmp/log; else echo failure: $pkg >> /tmp/log; fi; done > > I tried something like this, and GuixSD crashed while it was building > the packages... Specifically, the following morning, I checked my > computer and found that the screen remained blank, the HDD I/O LED was > constantly on (as if tons of disk access was taking place), and not even > pressing the capslock key would turn on the capslock key LED. I decided > to let the computer sit for the day, but when I got home 8 hours later, > nothing had changed. I power cycled my machine, and after it booted, I > found that during the night, my kernel had logged an Oops along with a > BUG in /var/log/messages, but I don't really know why it occurred. > > So, I don't know if any of the packages built successfully or not. I'll > try again tonight, and this time I'll store the results somewhere where > I'll (hopefully) be able to see how far it got before crashing. > Hopefully it won't crash this time... If you know of an easier way to > check the build status of packages that will be impacted by an icedtea > change, please let me know. > > -- > Chris my build script is a little different: guix package -A | cut -f1,2 | sed -e 's/\t/@/' | parallel --bar --shuf --jobs 1 guix build --no-grafts --fallback and you could have "guix refresh -l -e '(@ (gnu packages java) icedtea-7)'" in place of 'guix package -A'. Mine doesn't take into account packages that are already built or dependencies which have already failed, but it could be loading all the packages into memory at once is too much. If it isn't then perhaps: guix build --no-grafts --keep-going < $(guix refresh ... | cut -f1,2 | sed -e 's/\t/@/' ) would also work. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Release!
Hi!
l...@gnu.org (Ludovic Courtès) writes:
[...]
>>
>> I guess we’ll be using berlin.guixsd.org instead of bayfront, no?
>
> Yes. Questions:
>
> 1. Do we pre-register berlin’s key on GuixSD?
Isn't this already the case?
[...]
>
> The main GuixSD annoying messages that I think we should address by
> Tuesday are:
[...]
>
> 2. “udevd[304]: RUN{builtin}: 'uaccess' unknown
> /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
>
I had researched about that error a bit and it seems that it caused by
eudev lacking support for 'uaccess'[0]; so not something to fix in Guix
proper.
[0] https://github.com/gentoo/eudev/issues/145
Maxim
New French PO file for 'guix' (version 0.14.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/guix/fr.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/guix/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/guix.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
fcgiwrap doesn't see gzip
Hello Guix, cgit service through fcgiwrap doesn't see gzip. /run/current-system/profile/bin/gzip exists. fcgiwrap strace: http://paste.debian.net/998501
Re: boot the Hurd with Guix
On Fri, Dec 1, 2017 at 5:16 PM, Samuel Thibault wrote: > Hello, > > Congrats on the achievement :D > > Ludovic Courtès, on ven. 01 déc. 2017 14:17:48 +0100, wrote: >> Also, in GRUB, you currently load ext2fs.static and exec explicitly. > > That's the normal way, yes. exec does the rest (including running > startup). > >> BTW, the image you posted is in “raw” format. You would get a smaller >> file by using the qcow2 format, which you can create with “qemu-img >> create -f qcow2”. > > Well, using sparse files can work as well: create the image with > > dd if=/dev/zero of=file.img bs=1M count=1 seek=1000 Or you can use truncate from gnu coreutils: $ du -sh file.img 0file.img vince@dell:~$ ls -l file.img -rw--- 1 vince vince 1073741824 déc. 1 19:43 file.img vince@dell:~$ ls -lh file.img -rw--- 1 vince vince 1,0G déc. 1 19:43 file.img -- Vincent Legoll
Re: Release!
On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
> 1. Do we pre-register berlin’s key on GuixSD?
I vote yes.
> 2. Do we add berlin.guixsd.org to the list of substitute servers on
> GuixSD? On Guix? The drawback is that ‘guix’ sometimes talks to
> both servers when retrieve substitute lists, which can be slightly
> slower/annoying, but otherwise I think it’s a win.
I think it's worth the extra source of substitutes. Since adding
berlin.guixsd.org to my list of substitute URLs, it seems like I need to
build less often.
In my experience, it's annoying to query multiple servers when my
network connection is slow or unreliable. But, it's also annoying in
that situation to need to download source files from a variety of
upstream sites.
> The main GuixSD annoying messages that I think we should address by
> Tuesday are:
>
> 1. “Error in finalization thread: Bad file descriptor” coming from the
> Shepherd;
I'm not sure how to start debugging this :/ If I get some advice, I
could try to fix it on Sunday and Monday.
> 2. “udevd[304]: RUN{builtin}: 'uaccess' unknown
> /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
I haven't seen this one before.
signature.asc
Description: PGP signature
Re: boot the Hurd with Guix
Sorry, the mail was sent too early >> Well, using sparse files can work as well: create the image with >> >> dd if=/dev/zero of=file.img bs=1M count=1 seek=1000 > > Or you can use truncate from gnu coreutils: $ truncate -s 1G file.img $ du -sh file.img 0file.img $ ls -lh file.img -rw--- 1 vince vince 1,0G déc. 1 19:43 file.img -- Vincent Legoll
Re: Release!
Leo Famulari writes:
> On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
>> 1. Do we pre-register berlin’s key on GuixSD?
>
> I vote yes.
>
>> 2. Do we add berlin.guixsd.org to the list of substitute servers on
>> GuixSD? On Guix? The drawback is that ‘guix’ sometimes talks to
>> both servers when retrieve substitute lists, which can be slightly
>> slower/annoying, but otherwise I think it’s a win.
>
> I think it's worth the extra source of substitutes. Since adding
> berlin.guixsd.org to my list of substitute URLs, it seems like I need to
> build less often.
>
> In my experience, it's annoying to query multiple servers when my
> network connection is slow or unreliable. But, it's also annoying in
> that situation to need to download source files from a variety of
> upstream sites.
I’d like to add berlin.guix.org to the list of default substitute
servers, but before I can allow this with a good conscience I need to
increase space on the head node. We were very busy, so the new head
node and storage aren’t ready yet, and the old node that’s currently
coordinating builds on berlin.guix.org has very limited storage.
I’ll try to get the new storage ready on Monday.
>> 2. “udevd[304]: RUN{builtin}: 'uaccess' unknown
>> /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
>
> I haven't seen this one before.
I have seen it, but only when checking the output of dmesg. I guess we
could just remove that rule.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
Re: java: switch to icedtea-8 as default JDK
Hello!
I've just checked the current build status of packages on hyrda. I could
filter out a few that currently seems not to build anyway, we might try to
fix those first.
I'll send a quick list:
*java-htsjdk@1.129 -> newer version (2.3.0) in master, does not build;
java-testng@6.12
*java-plexus-container-default@1.7.1 -> does not build; java-testng@6.12
*kodi@18.0_alpha-6-f22d62d -> does not build; unbound 1.6.7
*java-eclipse-jetty-servlet@9.4.6 -> does not build;
java-eclipse-jetty-security-9.2.22
*java-eclipse-jetty-servlet@9.2.22 -> does not build;
java-eclipse-jetty-security-9.4.6
The first one with the specific version does build, to be clear, but the
newer version does not.
I've extracted the log segment of those failures:
java-testng@6.12 - log extract:
TestNG
Total tests run: 1517, Failures: 1, Skips: 0
===
Failures in :TestNG, :Parallelization
test.thread.parallelization.ParallelByMethodsTestCase4Scenario1.verifyThatTestMethodsRunInParallelThreads()
StackTrace:
java.lang.AssertionError: Expected 6 test method start event logs to be in
a block of methods executing in parallel. Found an event log of a different
type in the block being processed: [EventLog{Event:
LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodB, Time of
event: 1511159025654, Thread ID: 5556}, EventLog{Event:
TEST_METHOD_EXECUTION, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodB, Data
provider param: paramThree, Time of event: 1511159026154, Thread ID: 5556},
EventLog{Event: LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodA, Time of
event: 1511159026244, Thread ID: 5550}, EventLog{Event:
LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodF, Time of
event: 1511159026244, Thread ID: 5560}, EventLog{Event:
LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodC, Time of
event: 1511159026244, Thread ID: 5552}, EventLog{Event:
LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodE, Time of
event: 1511159026244, Thread ID: 5558}] expected [true] but found [false]
at
test.thread.parallelization.BaseParallelizationTest.verifyEventTypeForEventsLogs(Unknown
Source)
at
test.thread.parallelization.BaseParallelizationTest.verifySimultaneousTestMethodListenerStartEvents(Unknown
Source)
at
test.thread.parallelization.BaseParallelizationTest.verifySimultaneousTestMethodListenerStartEvents(Unknown
Source)
at
test.thread.parallelization.BaseParallelizationTest.verifyParallelTestMethodsWithNonParallelDataProvider(Unknown
Source)
at
test.thread.parallelization.ParallelByMethodsTestCase4Scenario1.verifyThatTestMethodsRunInParallelThreads(Unknown
Source)
... Removed 27 stack frames
phase `check' failed after 282.9 seconds
Requires further investigation.
-
unbound@1.6.7 - log extract
libtool: link: gcc -I.
-I/gnu/store/ks27x0mf95gir0cdgb9h573xbava6v1k-python-3.5.3/include/python3.5m
-I/gnu/store/m0m6bwzi8lx7kv8zbn3hjrim6flmgnf4-openssl-1.0.2l/include
-I/gnu/store/ldkwm8hwhknpx6651yjgc1231nh8234d-libevent-2.1.8/include
-I/gnu/store/wdlhrg370gm42s7ggyhnvnb4xrzpls1x-expat-2.2.1/include -g -O2
-flto -pthread -o testbound .libs/testbound.o .libs/replay.o
.libs/fake_event.o .libs/testpkts.o .libs/worker.o .libs/acl_list.o
.libs/daemon.o .libs/stats.o .libs/shm_main.o .libs/dns.o .libs/infra.o
.libs/rrset.o .libs/dname.o .libs/msgencode.o .libs/as112.o
.libs/msgparse.o .libs/msgreply.o .libs/packed_rrset.o .libs/iterat
Re: java: switch to icedtea-8 as default JDK
Gábor Boskovits writes:
> Hello!
>
> I've just checked the current build status of packages on hyrda. I could
> filter out a few that currently seems not to build anyway, we might try to
> fix those first.
>
> I'll send a quick list:
>
> *java-htsjdk@1.129 -> newer version (2.3.0) in master, does not build;
> java-testng@6.12
> *java-plexus-container-default@1.7.1 -> does not build; java-testng@6.12
> *kodi@18.0_alpha-6-f22d62d -> does not build; unbound 1.6.7
> *java-eclipse-jetty-servlet@9.4.6 -> does not build;
> java-eclipse-jetty-security-9.2.22
> *java-eclipse-jetty-servlet@9.2.22 -> does not build;
> java-eclipse-jetty-security-9.4.6
>
> The first one with the specific version does build, to be clear, but the
> newer version does not.
> I've extracted the log segment of those failures:
>
>
> java-testng@6.12 - log extract:
> TestNG
> Total tests run: 1517, Failures: 1, Skips: 0
> ===
>
> Failures in :TestNG, :Parallelization
> test.thread.parallelization.ParallelByMethodsTestCase4Scenario1.verifyThatTestMethodsRunInParallelThreads()
> StackTrace:
> java.lang.AssertionError: Expected 6 test method start event logs to be in
> a block of methods executing in parallel. Found an event log of a different
> type in the block being processed: [EventLog{Event:
> LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodB, Time of
> event: 1511159025654, Thread ID: 5556}, EventLog{Event:
> TEST_METHOD_EXECUTION, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodB, Data
> provider param: paramThree, Time of event: 1511159026154, Thread ID: 5556},
> EventLog{Event: LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodA, Time of
> event: 1511159026244, Thread ID: 5550}, EventLog{Event:
> LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodF, Time of
> event: 1511159026244, Thread ID: 5560}, EventLog{Event:
> LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodC, Time of
> event: 1511159026244, Thread ID: 5552}, EventLog{Event:
> LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodE, Time of
> event: 1511159026244, Thread ID: 5558}] expected [true] but found [false]
> at
> test.thread.parallelization.BaseParallelizationTest.verifyEventTypeForEventsLogs(Unknown
> Source)
> at
> test.thread.parallelization.BaseParallelizationTest.verifySimultaneousTestMethodListenerStartEvents(Unknown
> Source)
> at
> test.thread.parallelization.BaseParallelizationTest.verifySimultaneousTestMethodListenerStartEvents(Unknown
> Source)
> at
> test.thread.parallelization.BaseParallelizationTest.verifyParallelTestMethodsWithNonParallelDataProvider(Unknown
> Source)
> at
> test.thread.parallelization.ParallelByMethodsTestCase4Scenario1.verifyThatTestMethodsRunInParallelThreads(Unknown
> Source)
> ... Removed 27 stack frames
>
> phase `check' failed after 282.9 seconds
>
> Requires further investigation.
>
> -
>
> unbound@1.6.7 - log extract
> libtool: link: gcc -I.
> -I/gnu/store/ks27x0mf95gir0cdgb9h573xbava6v1k-python-3.5.3/include/python3.5m
> -I/gnu/store/m0m6bwzi8lx7kv8zbn3hjrim6flmgnf4-openssl-1.0.2l/include
> -I/gnu/store/ldkwm8hwhknpx6651yjgc1231nh8234d-libevent-2.1.8/include
> -I/gnu/store/wdlhrg370gm42s7ggyhnvnb4xrzpls1x-expat-2.2.1/include -g -O2
> -flto -pthread -o testbound .libs/testbound.o .libs/replay.o
> .libs/fake_event.o .libs/testpkts.o .libs/worker.o .libs/acl_li
