<OriansJ>calcal: being limited to a single computer isn't a problem, because virtual machines can be utilized. Install virtualbox, qemu or even VMware if that is your preference.
<calcal>See? I use a lot of weird apps. I like to know I can use them if I ever need them. I hate making a commitment to a system and then finding out later "oh shit, I can't use that program because I'd have to build so many dependencies from source first"
<calcal>OriansJ, >virtual machines on libreboot x200
<calcal>If I were to get the ultimate boot CD, I would have to (1) figure out how to put it on my multiboot and give it a working grub entry OR (2) get rid of the multiboot and have no live system to use when i have no system on disk
<calcal>making grub entries is hard. not having a working system to go back to is really hard.
<OriansJ>calcal: My recommendation is to first get seabios, so that you never have to worry about booting CD/DVDs again then use exclusively Tails and encrypted partitions for everything.
<OriansJ>calcal: I strongly recommend you find a local linux users group and go to the meetings. As the assistance you require appears to be more than should take place in a IRC conversation.
<muck>finally ! all lua-lgi tests succeed ... we may have a proper awesome version soon :)
<muck>turns out $LG_LIBRARY_PATH is not set, neither in the builder sandbox nor within guix environment .. instead its called $LIBRARY_PATH .. im not sure whats the meaning of this and if i should patch the lgi makefile within the guix package accordingly or if that issue is better fixed elsewhere
<ng0_>in case anyone tries to review some of the packages I might've send in hosted on *.psyced.org and wonders why it does not succeed downloading, there's currently an outage which is being investigated.
<ng0>else I would try to come up with another version, I want to attempt another temporary package for pybitmessage because everthing sucks, but being able to temporary use it sucks less... writing the setup.py takes time when you don't know the project.
<ng0>correction, the psyced.org files are available.
<joolean>@mark_weaver: Hey Mark! Sorry again about those build failures. What do the Cool Kids do these days for cross-arch compatibility testing? I don’t have access to Hydra and I’m having a hard time finding a CI service that offers a 32-bit build environment. Should I just run a VM locally?
<muck>mh .. is there a way to use a local extracted (and modified) copy as sources for a build ? i.e. something like (source (origin (method local) [...] ? I've got a package tests successfully within a guix-environment, but same tests do a segfault when using guix build
<muck>i'd like to debug those tests within the context of guix build so i want to use the modified sources without having to upload them somewhere
<bavier>muck: you could define another package with a modified origin that includes one or more patches to apply
<muck>right so no quick&dirty source uri=~/testme ..
<bavier>retroj: yes, unless it's also needed at runtime, in which case in 'inputs'
<retroj>i had it in inputs when i received those warnings
<retroj>i'm not entirely sure whether it's needed at runtime.. it may be for certain features of this program
<bavier>retroj: you could try using the python-wrapper package instead
<bavier>the python package has no "python" interpreter, only "python3"
<ng0>because PyBitmessage Makefile still sucks, I need to call part of the build-system-python in the build-system-gnu in a phase... how do I manage this if at all possible? I need it for wrapping correctly
<bavier>ng0: you could (assoc-ref (@ (guix build python-build-system) %standard-phases) 'phase) or something similar
<rekado_>naming these things confused me, because upstream names are “luasocket”, “luaexpat”, “luasec”, etc but our package names start with “lua5.1-” …
<lfam>Yeah... I don't know what the best solution is. We don't have much Lua software yet, so I think this is fine. Maybe we'll revisit it if we end up needing, for example, a lua-5.2 version of luasec
<lfam>Speaking of which, I find it weird that Prosody depends on this old version of Lua. Does the Lua project still support 5.1?
<lfam>rekado_: Speaking of Guix talks, I would *love* a talk about using GuixSD for a music workstation. I think a lot of computer musicians live in terror that their "instrument" will break due to updates and things like that
<jmd>What is the correct way to set my domainname ?
<retroj>when i add certain inputs to the package i'm building, i get a "match error" like: guix/packages.scm:833:12: Throw to key `match-error' with args `("match" "not matching pattern" ())'
<retroj>inputs that have produced this error include ("libftdi" ,libftdi) and ("libmicrohttpd" ,libmicrohttpd)
<retroj>i also received this error when i added ("python-numpy" ,python-numpy) to native-inputs. it and python-protobuf are used for a certain build option (--enable-rdm-tests, which is commented out in the code i shared above)
<retroj>; makes a line comment, but in some schemes, #; makes a sexp comment. i didn't check whether guile did, but it didn't complain
<retroj>anyway, i can just use a line comment there instead and put the close paren on the next line. the error persists
<retroj>and i still get the same error with avrdude, which also uses libftdi
<lfam>retroj: I don't understand line 66. What are you trying to do there?
<lfam>Are you trying to pass some flags to the configure script?
<lfam>If so, the following should work: #:configure-flags (list "--enable-rdm-tests" "CXXFLAGS=-ftrack-macro-expansion=0")
<ng0>lfam: it seems like my email server is stuck somehow... or at least I suppose so. I added the mirror for font-un because I feel like there should be a safe way to get the file. but if it's unnecessary because the noted hash is enough, than this new patch is not necessary