***HeisenbergsDog is now known as Guest88875
<fps>hmm, what package is test_atomic.exe from? <fps>g++ -o test_concurrent_queue_whitebox.o -c -MMD -DTBB_USE_DEBUG -DDO_ITT_NOTIFY -g -O0 -DUSE_PTHREAD -m64 -mrtm -Wall -Wno-parentheses -Wno-non-virtual-dtor -I../../src -I../../src/rml/include -I../../include -I. ../../src/test/test_concurrent_queue_whitebox.cpp <fps>g++ -o test_concurrent_queue_whitebox.exe -DTBB_USE_DEBUG -DDO_ITT_NOTIFY -g -O0 -DUSE_PTHREAD -m64 -mrtm -Wall -Wno-parentheses -Wno-non-virtual-dtor test_concurrent_queue_whitebox.o tbb_misc.o -lpthread -lrt -ldl -Wl,-rpath-link=. -rdynamic -Wl,-rpath=/gnu/store/d9pjzxvf69b137hbap00b37b1sslwdzn-tbb-4.3.2/lib <fps>./test_assembly_compiler_builtins.exe <fps>./test_aligned_space.exe <fps>it runs for like 40 minutes already <fps>doesn't buld on my system. seems to timeout on the tests every time <rekado>tbb test failures don't fail the check phase <rekado>that's something I still want to fix. <rekado>I don't know if 40 minutes is normal for this test. <fps>it's now at 58 minutes <fps>it will get killed by the silent-max-time default of 3600 seconds <fps>on hydra the whole build took 17 minutes <fps>building of `/gnu/store/a7qd4mgcqjb8ad12snqix6pwwczjfjas-tbb-4.3.2.drv' timed out after 3600 seconds of silence <fps>@ build-failed /gnu/store/a7qd4mgcqjb8ad12snqix6pwwczjfjas-tbb-4.3.2.drv - timeout <fps>i'll blacklist it :) <fps>on my local machine.. <fps>soooo, someone should write a test suite for their testsuite <fps>build time went up from 20 to around 50 minutes <fps>coincidence that it succeeded then? ***Guest88875 is now known as HeisenbergsDog
<fps>rekado: also it seems that the fail due to the exceeding of max-silent-time doesn't get registered in the db <fps>since it failed again.. hmm. or maybe some dependency changed and it was thusly tried to be built again <fps>oh, it's at it again. <fps>seems more than one package depends on it <fps>rekado: how can i inspect the build-daemons db manually? <fps>hmm, i wonder where it lives and what its format is. searching through the manual, guix-daemon's manpage and its texinfo page gave me nothing <fps>rekado: thanks.. taking a look <fps>btw: how about adding a package field "pure" or "detereministic" which is boolean? <fps>and which can be set to true once a package build is considered deterministic.. it would inherit indeterminism from any dependency thoug <fps>this way we could be able to treat deterministic builds differently from non-deterministic ones <fps>hmm, .tables shows nothing for the db.sqlite <fps>.databases tells me"Error: unable to open database file" <rekado>fps: ultimately, we want all builds to be deterministic. <rekado>non-determinism is indicated by guix challenge. <fps>ok, and then that information is lost <fps>and not made explicit <fps>consider a package marked as "non-deterministic" as a TODO then :) <fps>or make guix challenge file a bug report automatically if it's considered a bug ***HeisenbergsDog is now known as Guest70533
***Guest70533 is now known as HeisenbergsDog
<davexunit>I really want to figure out how to create a tunnel from my computer to a remote guix daemon <davexunit>a straight-forward tunnel isn't enough because I need to forward traffic to a UNIX domain socket <keverets>ssh -L works with Unix sockets as well as TCP <wingo>why would you want to do that? to manage software on a remote machine? <davexunit>keverets: the server has to support that though <davexunit>keverets: also, I am using libssh via guile-ssh <davexunit>I want to start with my bare metal guixsd machines by writing something that can import system closures into remote guixsd systems. <davexunit>and then use guile-ssh's remote Guile REPL support to instantiate that new system <davexunit>maybe it's not possible to do all of the plumbing that I need to do without explicit support from the ssh server. <wingo>might be less work to create openssh-service, dunno <davexunit>wingo: sure, but I'd like it if users could use any ol' ssh server <davexunit>openssh-service would still be good, though. <fps>can someone give me a tip or two on how to inspect the guix-daemon's database manually with e.g. sqlite3? <fps>all i get is errors about not being able to open the db file, even if it's world readable <bavier>fps: is the error from guix-daemon or guix? <fps>fps@raksha ~$ sqlite3 /var/guix/db/db.sqlite <fps>SQLite version 3.8.11.1 2015-07-29 20:00:57 <fps>Enter ".help" for usage hints. <fps>Error: unable to open database file <fps>but i'm an sqlite noobie, too <fps>i want to inspect whether some package builds who's derivations timed out due to exceeding the max-silent-time got marked as failed or no <fps>cause they get rebuilt [or tried to] every time i redo the build <fps>[and i run the daemon with --cache-failures] <avoine>sqlite3 /var/guix/db/db.sqlite works on my machine <fps>avoine: can you do .databases? <avoine>--- --------------- ---------------------------------------------------------- <fps>maybe cause it's busy atm.. <fps>avoine: thanks. it works on a copy <fps>DerivationOutputs FailedPaths Refs ValidPaths <fps>ok, tbb is not in the FailedPaths table <davexunit>CoreOS's new secure container stuff, featuring Matthew Garret, FSF board member <rekado>annoying: ibus caches some state in the user's directory, so when you upgrade an input method it will continue to use the old one. <rekado>until it's garbage collected. Then things just break without an error message. <rekado>I found an error with our ibus-libpinyin package. It only worked by accident because some other package propagated gtk+. <rekado>I also wrote patches for gtk+ to respect GUIX_GTK2_PATH and GUIX_GTK3_PATH environment variables, which should be set when input methods or GTK themes are installed. <piyo>is there a guideline for app authors to avoid this state problem?