IRC channel logs


back to list of logs

***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>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>there's a bug report for that.
<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>and cached..
<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
<rekado>AFAIK it's a sqlite db.
<rekado>maybe /var/guix/db/db.sqlite
<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"
<fps>um, ok..
<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 :)
<rekado>bug tracker?
<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?
<keverets>ssh -L local_socket:remote_socket
<davexunit>keverets: the server has to support that though
<davexunit>lsh does not support this
<davexunit>keverets: also, I am using libssh via guile-ssh
<davexunit>not the ssh CLI
<davexunit>wingo: it's needed for 'guix deploy'
<davexunit>to remotely manage guixsd clusters
<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>bavier: from sqlite
<fps>hole on
<fps>*hold on
<fps>fps@raksha ~$ sqlite3 /var/guix/db/db.sqlite
<fps>SQLite version 2015-07-29 20:00:57
<fps>Enter ".help" for usage hints.
<fps>sqlite> .databases
<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>sqlite> .databases
<avoine>seq name file
<avoine>--- --------------- ----------------------------------------------------------
<avoine>0 main /var/guix/db/db.sqlite
<fps>maybe cause it's busy atm..
<fps>avoine: thanks. it works on a copy
<fps>sqlite> .tables
<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
<davexunit>and employee of CoreOS
<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.
<rekado>will send this tomorrow.
<piyo>is there a guideline for app authors to avoid this state problem?