<jonsger>I try to package a small flashtool (0xFFFF). when I try to build it with ./pre-inst-env I'll became an error that libusb is missing http://sprunge.us/aFGU <jonsger>I declare libusb as native input and have it installed with guix <clacke[m]>Whether it's installed in your user profile or not doesn't matter, a package gets exactly its declared inputs, no more or less. <clacke[m]>that pkgconfig file there would tell a build system that uses pkgconfig that it should add a compiler flag to include .../libusb-1.0 <clacke[m]>but the header file is still called libusb.h rather than usb.h ***Apteryx_ is now known as Apteryx
<clacke[m]>so it looks like if you add libusb-compat instead of libusb your program should compile <Apteryx>Finally finishing to build IceCat after more than 12 hours ;) <lfam>Nice, I'm glad it didn't fail at the 11th hour :) <davexunit>awesome, ran 'guix pull' and now can't work on my project because guix wants to build automake which fails its test suite <davexunit>I haven't been very active in guix lately but I've been having pretty bad times every time I 'guix pull' lately <lfam>davexunit: `guix pull` with no arguments? <lfam>Ah, so later on some other command fails to build automake? <davexunit>but then I try to 'guix environent -l guix.scm' into my project that uses autotools and get a failure <davexunit>it took about an hour for the automake test suite to run <davexunit>it looked like I also needed to build mesa and other things from source <lfam>Probably the mesa build is just a graft. I can try building automake from latest master here, to see if it works <ZombieChicken>Is hydra.gnu.org slow for anyone else? It seems I'm only pulling at 90ish kb/s <lfam>ZombieChicken: For substitutes? <lfam>ZombieChicken: Please don't use hydra.gnu.org. Use mirror.hydra.gnu.org <davexunit>there are so many tests and I haven't found the failure yet <lfam>ZombieChicken: Ah, then it sounds like you got a cache miss. The mirror is fetching the file from hydra.gnu.org. Once the mirror has the file, it will be fast for every other user. Thanks for your patience :) <lfam>davexunit: I think we should have substitutes for automake. <davexunit>--no-grafts didn't change it, so I'll just disable the test suite for now. <lfam>Then you won't get *any* substitutes :) <lfam>Well, it's pretty bad if we garbage collected automake! <davexunit>not disabling test in the package that everything references <lfam>Sounds like you've done it before :) <ZombieChicken>lfam: Thanks for the information, thought output saying it's a cache miss would be nice. I might make a bugreport on that <lfam>ZombieChicken: Imagine what is was like before we created the mirror! <davexunit>even when I set #:tests? to #f it still runs the test <davexunit>oh well, looks like I'm not working on this project tonight <jmd`>davexunit: I have notices that mirror.hydra.gnu.org is very unreliable recently too. <davexunit>yeah not sure what's going on exactly. it's certainly not good that automake has a nondeterministic test suite <davexunit>well, it seems that tests fail on my machine that don't fail on others <lfam>It's still building on my end <jmd`>davexunit: Well I wonder if anyone else has had it fail unexplainedly? It *could* be a problem with your machine. <jmd`>lfam: To build or to test? <lfam>But, I can't reproduce the failure locally <jmd`>Same failure on both attempts or different ones? <davexunit>just saw 2 test failures go by when I retried <lfam>jmd`: It appears to be identical, based on the logs, although I didn't `diff` them <jmd`>I wonder if it's the same kind of problem as the one I just pushed a fix for? <jmd`>s/pushed a fix for/sent for review/ <jmd`>Which architecture is this? <lfam>davexunit: automake built for me from the latest master branch on x86_64-linux. The kernel is 4.9.16 and the filesystem is ext4 <lfam>Did you notice which tests they are? <jmd`>Do you know what test framework it's using? <jmd`>lfam: I was going to suggest a hardware problem on the build machine, but those two logs are identical so that seems unlikely. <jmd`>Could it be anything to do with the new guile version? <lfam>I'm stumped. It built for me <jmd`>davexunit: Does testsuite.log in the build directory tell you anything? <davexunit>I don't have any more time to debug this tonight <jmd`>I get a substitute when I guix build -K automake <marusich>Is anyone here using GNOME3 able to lock the screen? <marusich>I can't lock the screen and haven't ever figured out why. <ZombieChicken>guix gc: error: build failed: getting attributes of path '/some/long/path/in/store': No such file or directory <ZombieChicken>specifically it's refering to an icecat CVE patch that apparently no longer exist <Apteryx>Would I have more luck at finding substitutes if I stuck to an older linux-libre version? Say, linux-libre@4.9 instead of latest? My system is slow and rebuilding the kernel regularly is a drag for productivity. <ZombieChicken>Apteryx: I can't comment on most of that, but I can suggest trying to run everything through nice and ionice, which might help with it bogging down your system. At least, that works on Gentoo... <Apteryx>Has someone else noticed that "apropos" or "man -k" can't find squat? <Apteryx>ZombieChicken: Thanks for the suggestion. I'll try it when the system comes to a crawl. <ZombieChicken>Apteryx: I'm not sure what would need to be niced in this case, but if you can figure that out it should help. <rayline-x>Apteryx: is the man page for squat installed in the right place? <Apteryx>rayline-x: Ah, sorry, by "can't find squat" I meant "can't find anything at all" <buenouanq>I was totally confused too. `squat? i wonder what that program does...' <Apteryx>Must be some american slang that I somehow absorbed ;) <ZombieChicken>Which is weirder; that bit of slang, or that somewhere that is probably a name for a program that has nothing to do with weightlifting... <ryanwatkins>Does anybody know how to use Guix ontop of ArchLinux ARM? I am unable to install guile-ssh on armv7h <rekado>when I run apropos with “-d” I see this warning: warning: can't read the fallback whatis text database /home/rekado/.guix-profile/share/man/whatis <Apteryx>rekado: Interesting. I've never really read dig about how apropos works but that would suggest that it needs a database that we aren't generating. <Apteryx>Could it be that it cannot search through compressed manpages? <efraim>ryanwatkins: how so can you not install it? guile-ssh is an optional dependancy, but I believe it is like some other packages we have that can fail its tests on slower machines <efraim>I had to build it 2 or 3 times on my aarch64 board before it passed the tests <ryanwatkins>efraim: under yaourt and trying to install it from the AUR it is failing on my raspberry pi 3 model b board, should I clone it down and try to install seperately? <efraim>ryanwatkins: I don't know, I used the binary install method from the manual each time I installed it <roelj>So, when I run: export R_LIBS_SITE=""; guix environment --pure --ad-hoc r; echo $R_LIBS_SITE; It displays the site-library path of my profile. Does this mean `guix environment' looks for the environment variables, and then uses the values from the user's default profile? <roelj>When I add --search-paths to the `guix environment' command, it returns different profile directories.. <fps>hmm, i wonder.. i just did a quick experiment: modified the hello packages to be called "helo" and then guix built two variants: the original helo and one where i duplicated the gawk input <fps>this resulted in two different store items, which is what i kind of expected. inspecting the resulting binaries showed that the only difference is in a reference to the lib/ folder in the output.. <fps>so i wonder: is it generally possible to decouple this? i.e. sure, the package recipe changed, but the resulting store paths aside the resulting binaries are identical <fps>could another layer of indirection be introduced? such that there's a store item holding the binary is shared between the two but linked to two different store places to reflect the different derivations? <fps>i suppose it is obvious what i'm thinking about here. let's say package A depends on B. B changes, triggering a rebuild of A. Since the ABI of B didn't change, A is bit identical except for store paths.. <fps>this is an opportunity for optimization <fps>[i.e. while a build server would rebuild A, only the new store item linked to the old binary version would be handed out as substitute, saving traffic and disk memory] <rekado>fps: I’m not sure I follow, but we have two optimisations that seem relevant here: grafts and deduplication <rekado>we cannot know in advance if outputs are going to be identical. <rekado>but if we know that the only difference is going to be embedded references to other packages then we can use grafts instead of rebuilding a package. <rekado>a grafted package is the same package but with replaced references. <Apteryx>rekado: To generate the manpages db files one is supposed to run `mandb`, but this doesn't seem to help. <rekado>Apteryx: I have no problem with “man” itself, just with “man -k” and “apropos”. <rekado>once you have the file mandb created can you pass it to “apropos”? <rekado>Otherwise it would probably not be used. <civodul>ACTION wanted to add a profile hook to generate the man db <rekado>FYI: I’m trying to fix freeimage on core-updates <Apteryx>rekado: I think the problem is that it doesn't find the manpages. I'll keep reading. Maybe we should patch /gnu/store/spaz62a39nrgm274gvmwz529lhrrms4s-man-db-2.7.5/etc/man_db.conf. <rekado>Apteryx: that file is not used when MANPATH is set. <Apteryx>It seems that mandb does read MANPATH (getenv call)... hmm. <fps>rekado: maybe i'm confused, that's super possible. so i have some followup questions :) <fps>rekado: the output store key is a hash of all the inputs of a package, right? <fps>rekado: and the path where it gets built and the output path go into the binary (possibly) <fps>let's assume a package with no inputs first.. <fps>no, bad thinking. let me try to reformulate. <fps>ok, if there are two identical packages with just different names, then they get stored into two locations in the store, while they are really bit identical except for references to (in the case of hello) the lib/ directory in the store <thomasd>fps: often, absolute references to the package location are also encoded in the files (things like runtime paths) <fps>thomasd: yeah, that's the part i wonder about if there's a way around it.. <fps>the question if there's a way to canonicalize the part of the build that's different, so that the same build can be used for both packages, even though it's just found out after-the-fact. i.e. build those packages, their common core gets put in a store item who's key is just a result of the binary pattern of the output, then to instantiate the two store items that do depend on the output path, the references of <fps>the common core would need to be tweaked.. <roelj>I think I found a version of Maven that bootstraps with Ant! <fps>i.e. build both package with a canonicalized output path, on the second run, once the build is finished, the system would see "oh, it's bit identical!" and not store it twice in the store <roelj>Hidden somewhere in the (older) subversion repository of maven-1 <fps>it would just keep track of having to update references in the binary for the two "real" output paths... <fps>["real" as in the ones where the package name goes into it] <fps>i.e. links could be used as the pointees that point to the binary pattern adressed store location <thomasd>fps: I don't think I'm following. If you build the package twice anyway, what is the use? :) <fps>that's just a contrived example, where packages differing on the surface still result in the same binary if canonicalized <thomasd>You could split out a common “core” into a third package, and then defining a new build for the two packages that takes the common core and grafts it to generate a specialized version. <fps>now let's take a package depending on another package as the second example.. the dependency changes, but leaving all "cosmetics" aside the binary of the dependee would still be bit identical (as the ABI of the dependency didn't change) <fps>as of now grafts have to be done manually.. <fps>grafts make use of an invariant in the dependee which i hope to leverage automatically <Apteryx>I think the man-db index should be located at /run/current-system/profile/share/man/index.db. "man" attempts to read this but falls back to recurse all the manpaths instead. <fps>thomasd: here's the thing: if the dependency changes, but its output path didn't and the ABI is not changed, then the dependees binary would be bit identical <fps>[assuming its output path didn't change either] <fps>i'm arguing that the package inputs' hash and the output store location are useful information, but in a sense orthogonal and too strict thereby ruling out some optimizations like automatic "grafting" <fps>thomasd: and yes, automatically grafting the two output packages for the first example is along the lines of my thinking.. <thomasd>fps: it would require more complex handling of inputs. <fps>thomasd: there would be another layer of indirection. i.e. a "concrete" package in the store has links to its binary adressed "core". for the final output hash computation the concrete package's path is used, but for the binary build the resolved links to the core would be used <adfeno>During my work on packaging Ring, I tried building it, but the "libring" package is failing to build: make enters "src/client", builds things up to configurationmanager.cpp, but when it reaches it, fails saying: src/security/certstore.h:77:73: error: ‘RevocationList’ is not a member of ‘dht::crypto’ <thomasd>fps: you'd need to somehow distinguish ABI-breaking updates from ABI-compatible updates. <fps>so it's transitive along tree edges <adfeno>I'll share you the recipe I have so far. <fps>thomasd: you would see the ABI breakage in the different bit pattern <adfeno>(I also asked the same question at #ring) <fps>thomasd: ok, glad that it's not absolute madness.. i'm shaky on the details, but might be worth thining about a little ore.. <fps>ACTION is doing his laundry and needs to go to the bank.. bbiab <thomasd>fps: I think the issue is that Guix needs to be able to predict the build dependencies in advance. Which is not possible anymore if you need to build a package first to see if it's ABI-compatible with the previous version.... Maybe I misunderstand, maybe I should draw some diagrams :-) <fps>thomasd: i'm strictly talking about discovering the invariance the dependee after the fact. i.e. if A depends on B, B changes, but leaves A unchanged, then this could be discovered after the build of A after B changes.. <fps>s/the dependee/of the dependee/ <fps>thomasd: oh, i need to think about your comment more. need to go to the bank though now :) <rekado>nckx: I hope it will be again soon. <rekado>I’m using the rottlog service and got an error from sbin/rottlog: line 1596: /usr/sbin/sendmail: No such file or directory. <thomasd>nckx: oh, I just got the latest digest :-( <rekado>for those who read digests that don’t include my EOT message: please let this thread die now. <davexunit>whoa what the hell has been going on on guix-devel <davexunit>I see that someone quit the savannah project <nckx>davexunit: really? Oh. Good to know I was actually being *too* optimistic... -_- <paroneayea>it's unfortunate that someone left, though I feel at least the community worked things through pretty well on the thread as a whole <paroneayea>it sucks that it was such a painful thread for many <nckx>(Anyway, I feel a bit guilty for bringing it up here. That smiley was out before I knew it. Sorry.) <paroneayea>yes, I think everything that could be said has already been said on the thread <davexunit>okay, I just have no idea what happened. I'll read on my own and leave it be here. <Wapanese>Can I use make install for non-Guix packages in Guix? <bavier`>Wapanese: sure, you won't be able install into /gnu/store or use Guix to manage the package, but building and installing should be fine <adfeno>Also, `make install` must be done as root, if I'm not mistaken, <adfeno>However, be advised of what bavier said <adfeno>`make install` spits things to lots of places. Making it very difficult to remove afterwards, unless you are using something like GNU Stow. :) <davexunit>FHS is incompatible with functional package management <Wapanese>What is "functional package management"? <rekado>Wapanese: it means to treat the package build process as if it were a pure function in the mathematical sense. <Wapanese>How can I port non-Guix package for Guix? <bavier`>Wapanese: the guix package build-system's typically handle installing into the correct /gnu/store directory <bavier`>some more work needs to be done for LVM <civodul>Wapanese: the page above has links to 'guix hash' etc. <ZombieChicken>Okay, so apparently irssi in abduco in dvtm in abduco does /not/ play nicely. Plus my email is seeming a bit wonky. <efraim>Looks like I will have to fix mozjs17, its needed by polkit <thomassgn>I try to setup connman-service in my guixsd config, but keep getting 'Unbound variable: connman-service' though I have already 'use-service-module networking'. The connman service is in defined in /gnu/services/networking.scm... <bavier`>thomassgn: there is no "connman-service" exported by networking.scm <bavier`>bavier1: that seems to contradict the manual... <bavier`>thomassgn: you should be able to use "(service connman-service-type (connman-configuration))" instead <ZombieChicken>Okay, that seems fixed at least. No more weird scrollback buffers <joshuaBPMan_>Hello, dumb question. I have a guile script. Everytime I modify it and save it, I have to chmod to let the user run it again. <joshuaBPMan_>What is going on? Why is chmod being over-written by my changes? <rekado>joshuaBPMan_: is your editor changing the access to the file? <rekado>I can’t seem to get good error messages out of it. <amz3>héllo, I unziped the guile 2.2 pack file on my ubuntu (yaketty, 16.10) machine but I have an error regarding locales <amz3>$ /opt/guile-2.2.0/bin/guile <amz3>guile: warning: failed to install locale <amz3>warning: failed to install locale: Invalid argument <amz3>can some help me troubleshoot this issue? <lfam>Hmm, I'd expected those "packs" to be totally self-contained and not have this issue :) <davexunit>this was covered explicitly when the guile pack was released <efraim>it looks like ots has moved and taken their release tarballs with them <thomassgn>bavier`: Aha, Thanks. That makes guix complain about missing wpa-supplicant, which is a good step forward :) <janneke>joshuaBPMan_: it's a continuous build/integration system for Guix <janneke>minimalistic, intended to replace hydra <efraim>it fails to build on aarch64, but that's a technicality since the guix binary in core-updates doesn't support aarch64 yet :p <efraim>oh, I finally looked at openblas in maths.scm, didn't realize I'd have to tune it to make it build <gazon>joshuaBPMan_: are you running emacs as a different user from the one that runs the guile script? <joshuaBPMan_>Nope. And I just tried running (define 1-3 (let ...)) (1-3) <joshuaBPMan_>(define procedure (lambda)) or (define (procedure) procedure body) are the only forms of define that I know (minus variable assignment) <thomassgn>how do I add to the list of conf files in '/gnu/store/...-xorg.xonf.d/' ? Been trying the 'xorg-configuration-file #:extra-config' without success... <efraim>the store is immutable, you'd have to add files in a service <efraim>woah I didn't realize we had double-conversion pacakged <efraim>i'll have to try to toss that into whatever qt module bundles it <rekado>marble-mouse-settings holds the contents of a file <rekado>and that’s used later in #:extra-config <Walakea>how does guile work together with C++ code? <thomassgn>rekado: thanks. Makes sense. Realize I'm not yet keeping my head above water entirely in guile/guix world (: am happy guix makes itself so easy to work with... <rekado>thomassgn: some things aren’t documented well enough <rekado>thomassgn: it would be nice to have a tutorial as part of the manual, which currently is mostly reference. <thomassgn>rekado: ye, I get an error saying config is an unbound variable, that is config on line 118 in your example... Added all the 'use-...' from example. <rekado>thomassgn: could you post your configuration file? <wingo>"Subject: Re: Let?s freeze and build ?core-updates?!" <rekado>“config” is bound right here: (slim-service-type config => <rekado>and here again: (udev-service-type config => <lfam>wingo: I am doing lots of manual patch recreation to work around that! <rekado>thomassgn: you need to use modify-services <rekado>thomassgn: on line 176 you already have it <rekado>instead of modifying %base-services you can modify %desktop-services <rekado>and then match on slim-service-type <rekado>what you have on line 153 is incorrect syntax <rekado>the idea is that “(modify-services %desktop-services …)” contains match clauses <rekado>in my example configuration I match on two different services that are part of %desktop-services: <rekado>slim-service-type and udev-service-type <rekado>this tells “modify-services” to search through “%desktop-services” and match these two types. <rekado>when it matches a service with type “slim-service-type” it binds that service’s configuration to the variable “config” <rekado>I then tell it to return a new configuration that happens to inherit from the original service’s configuration <rekado>(so I don’t have to specify so many fields that I actually don’t want to change) <rekado>thomassgn: you’re doing something similar on line 179 <rekado>there you tell “modify-services” to pick out a service of type “guix-service-type” from the list of services in the “%base-services” variable <rekado>you bind its configuration to the variable “config” and then throw it away, replacing it with “%guix-daemon-config”, a value defined on line 27. <thomassgn>aa, do I need ro merge the modify-services of desktop-services and base-...? <rekado>%desktop-services contains all of the %base-services <rekado>so it’s enough to modify %desktop-services <rekado>all of the DBus services are already part of %desktop-services, too, so you don’t need to specify them. <lfam>I wonder how they do it? <methalo>hi, how can i set gcc-4.9 to CC?, by default guix set gcc-5.4.0 <paroneayea>guessing because that's what they have for the packages link <paroneayea>would be even cooler if they used Guix's scheme though :) <rekado>methalo: you could just add the GCC package to the native-inputs <methalo>rekado: Now works!, currently ustr package fails on core-updates, due guix use gcc-5.4.0 <rekado>methalo: it might be worth looking for upstream patches that fix compilation with newer GCC versions. <thomassgn>is there a way to remove a service from the %desktop-services var? <snape>thomassgn: yes, you can use (remove ) for this <snape>the first argument is a lambda expression that could be, for example: (lambda (service) <snape> (eq? (service-kind service) nscd-service-type)) <rekado>“remove” is from “(srfi srfi-1)” <lfam>It's dozens of packages across ~1 dozen files <rekado>I asked myself the same question, actually :) <lfam>I already made the commit, but I'll save it for after we merge core-updates -> master <rekado>it wouldn’t be the first commit with a nasty long changelog summary <paroneayea>lfam: I wonder if it qualifies under the "simple updates" changelog exception in the gnu standards manual <slyfox>what purpose do commit messages serve? Are they being postprocessed later? <paroneayea>slyfox: commit messages are being used to generate changelogs <lfam>slyfox: They make it easier to read the commit log and understand what was changed and what the intention was <paroneayea>lfam: rekado: I think civodul should be asked about it <paroneayea>if the "simple changes" exception is good enough <lfam>Sometimes they help catch mistakes. For example, a patch that accidentally includes a change can be caught in review if the change is not mentioned in the commit message <slyfox>lfam: it looks like intention is explicitly removed from the changelogs <slyfox>i'd expect changes to contain things like "here is the build failure and how i fixed it" <rekado>slyfox: we try to keep intention in comments near the code <slyfox>and instead it's usually "in this file in that function i changes that variable" <lfam>It's a different level of intent. Rekado is right, too :) <rekado>it’s better than having to dig in the history <lfam>The intent I'm referring to is something like, "I intend to change this function in this file". <slyfox>rekado: why have changelogs at all then? :) <slyfox>you just open the file and see both intent in the comment and code <lfam>It does help catch mistakes, and it reduces the cognitive load of review <lfam>People *do* accidentally add changes to commits, and requiring a changelog helps catch those mistakes <rekado>hmm, the python2-pysam test failure on core-updates is really confusing <rekado>there is no test log, even when running “nosetests -v -d” <rekado>so I don’t know why the test fails <lfam>In the Hydra log, the test suite appears to stop before it's done <lfam>testMDTagComplex (AlignedSegment_test.TestTags) ... phase `check' failed after 7.1 seconds <slyfox>if we take for example 7bc57e760ca22dd78be054ef6c9ba1adc2cfa5fc. is it worth stating twice the same thing in commit message? <lfam>Actually, a different thing is stated in the title and the changelog :) <lfam>The title refers to a package name whereas the changelog refers to a variable <lfam>So, the title is the "high-level" description of the change, and the changelog describes the changes to the code <slyfox>but code changes for some reason are done on per-file basis <slyfox>what i try to say is i rarely see a coherent more-that-one-line description of a change in guix <slyfox>like 56aef188a2a014e254d3c93c8a79cd1fb5a1ece6 <lfam>I don't disagree that we could do a better job of documenting our changes in many cases <slyfox>it looks like ChageLog format discourages to have free-form description of a change <lfam>Sometimes it's appropriate to do that in a code comment, sometimes in the commit message. But it's not a reason to stop writing the changelog entries <slyfox>i understand ChangeLog's value in CVS where it's a problem to find the whole change <slyfox>i'm not vehemently against it. just not used to. in my eves linux kernel has a good culture for commit messages. wondering what value guix gets ChangeLog format <thomassgn>don't think I'm doing this the right way, '(define tms-desktop-services (remove (lambda (service) (eq? (service-kind service) wicd-service)) %desktop-services))' and then use tms-desktop-services in the modify-services later. Still tells me there's more than one networking service provided. Could I run a REPL on the config somehow? <lfam>We try to explain things that aren't obvious in code comments, whereas Linux favors putting the explanation in the commit message (or in both places). We could do a better job of commenting <slyfox>but otherwise commit messages are not processed by any tool afterwards, right? or do they? (to produce a release notes or something like that) <rekado>thomassgn: don’t use “wicd-service” but use the type <rekado>thomassgn: you can try this in the REPL, actually <rekado>and then take a look at the value of tms-desktop-services <rekado>you are comparing the result of “(service-kind service)” with an actual service object <lfam>slyfox: They do get processed a bit to create some statistics when we make a release. But I think they are valuable aside from that. <rekado>“eq?” can be used to compare symbols such as “'hello” and “'something” <rekado>“wicd-service” is a more complicated value <lfam>slyfox: I think it's valuable to make oneself write down a standardized accounting of the changes they've made. It helps catch mistakes. <snape>thomassgn: and the type of wicd-service is wicd-service-type <thomassgn>rekado: allright, just have to figure out how to start this repl then (: <snape>thomassgn: do you use Emacs? <snape>then you should have a look at the Geiser documentation <thomassgn>ah, ofc. it's not a guix specific one. makes sense :) <snape>well, there is some Guix specific setting too, but it is written in the Guix documentation <thomassgn>mm, think I've been through that setup. Will check. Thanks a lot my system just built fine again. <amz3>so i have installed guix on both of my machines, hopefully no bug this time... <rekado>the pysam test failure is strange. Running “nosetests --processes 2” works, but without it the tests abort.