<vagrantcish>i'm trying to add python-libusb1, but it uses ctypes.util.find_library to find libusb-1.0.so ... and fails to find it ... there doesn't appear to be a way to pass the library path to the find_library python function ... how is this sort of thing typically handled?
<vagrantcish>since libusb is passed as an input, a particular build should have that input hard-coded somehow?
<g_bor>Is there any way to ask guix build to retain the build directory if the build does not fail?
<g_bor>I'm trying to debug a build, and of course I can make the build fail, but if there is an easier way, that would be great.
<demotri>g_bor: I once had the same issue. Other than failing with #f/an exception, I'm not aware of a special flag like -K or something.
<janneke>g_bor: i'm not aware of that feature, would be nice to have
<janneke>apropos, it would be *so nice* if upon build failure, you could drop into a shell with the exact environment settings, and if all sources would have been put in a local .git archive after unpack
<demotri>janneke: But you know that you can do that manually: guix environment <package>; cd /tmp/guix-build-<package..>; source ./environment-variables.
<demotri>janneke: And the source code: ./pre-inst-env guix build -S. OK, it's a tarball, not git.
<g_bor>demotri, janneke: Thanks, I've ended up throwing an exception. It would be nice to have, as it would make debugging no fatal build failures easier.
<janneke>demotri: unless the package does `(setenv ...)...and adding the source to git is pretty difficult after stuff has been built
<janneke>demotri: hmm, a package could add a `populate-git' stage
<janneke>during development this could be a feature
<demotri>janneke: Why do you want to add to git anyway? I would expect the code to be checked in already somewhere.
<janneke>demotri: `want' is possibly a bit too strong, i'm brainstorming
<janneke>demotri: i'm working on GuixSD bootsrap build right now, and must somehow manage, write and rewrite patches for a number of versions and packages
<janneke>i find myself using a shadow build infrastructure, using a card-house of shell scripts
<janneke>it would be great if changes could be automagically handled by git, the environment by guix, and a couple of edits and rebuilds could be done in place
<demotri>This looks like a mes to me :-) I'm sometimes reading your announcements. Looks great, but hard to understand all the details for me.
<janneke>demotri: yeah, mes :-) I'm hoping that I find a way to make it easier to understand once the project starts to land in GuixSD
<brendyn>What's the default --cores value for guix pull
<efraim>It's hardcoded to build guix with just a single thread
<efraim>But all the other parts use all the threads allowed to guix-daemon
<brendyn>Ok it failed when i set --cores=9 and left some guile process using 100% of a thread. maybe i shouldnt try that again
<brendyn>is guix supposed to always be build with 1 thread?
<sahithi-ihtihas>I have added colorize-string procedure and soft port to guix/ui.scm earlier and i got colorized strings but when i try to do it now i am not getting colorful outputs and soft port is not being called
<mbakke>rekado: Can we also remove the six propagation from gtk-doc now?
<efraim>i'm up to "checking if the VM and compiler work together... configure: error: VM failed to run compiled class." for icedtea@1 for armhf-linux
<vagrantc>so, i'm trying to update python-trezor, and it requires adding python-libusb1 and python-pyblake2, which i've managed to get working, but i haven't yet gotten the test suite for python-trezor to work
<vagrantc>does it make sense to submit patches for python-pyblake2 and python-libusb1 if nothing else uses them, or should i wait till i have working patches to update python-trezor?
<vagrantc>oh, this is also sort of needed to upgrade electrum... which i forgot is where i started on this journey :)
<vagrantc>well, trezor support in newer versions of electrum is broken without an updated python-trezor
<g_bor>vagrantc: I guess it does make sense to submit the patches. They will be needed, when you manage to get trezor working, and if someone else is working on packages that need them can save some duplicate work.
<vagrantcish>ok, so i've got python-libusb1: https://paste.debian.net/1030572/ ... i've pretty much cargo-culted parts from python-pyusb, so if anyone sees anything obviously wrong or unecessary ... otherwise it seems ready for submission
<reepca>Hm, I'm in a bit of a pickle right now on my laptop... installed onto a fresh hard drive using the 0.14 installer, ended up with root having guix 972b87b14ae54bacf2457a4d538c5495bec37176 and now guix pull produces an error message about "./guix/build/compile.scm:132:21: ./guix/build/compile.scm:132:21: In procedure memq: Wrong type argument in position 2 (expecting list): (#<intset 6209> . #<intset 6410,6420,6430>)". And I'm still
<reepca>getting an error message when I try using "guix system" (guix: system: command not found), although I've tried installing guile-sqlite3 as someone recommended.
<apteryx`>did I read recently that our default database choice was mariadb? (over mysql or sqlite?)