***MightyJoe is now known as cyraxjoe
<efraim>Anyone have experience adding to the firmware field for the os config? <efraim>Hmm, looks like b43-open is included by default there <brendyn>I'm packaging goldendict, which uses qmake. when make is running, i get the error `...qtbase-5.9.2/bin/lrelease: Command not found.` When I search /gnu, I find lrelease is actually in the qt, and qttools package, not qtbase. I'm not sure how to fix it, is qmake making some kind of mistake? <brendyn>looks like i may have found the solution in another package definition <boskovits>I'd like some advice in packaging java-xbean-reflect. <boskovits>I have all the dependencies packaged, but it semme, that a shaded version of asm-3.1 is used. <boskovits>I have the original, but the shaded version exports symbols under a different package. <brendyn>Anyone else find the guile repl really laggy in emacs? <efraim>boskovits: perhaps packaged as asm-for-semme <rekado_>my emails to any gnu.org address are being delayed a lot. <rekado_>I also haven’t received confirmation from debbugs.gnu.org after sending mail to guix-patches@gnu.org. <boskovits>I have packaged java-asm-3.1, based on java-asm. <boskovits>However xbean uses a shaded version, where symbols are exported under a different package name. <boskovits>Do we have an approach for that, or should I patch sources? <boskovits>If a patch is needed, which source should be patched? <boskovits>I used version 3.1 of asm, because of namespace changes since then. <civodul>rekado: thanks a lot for going through the list of pending patches! <civodul>really a relief to see old patches get in :-) <civodul>roelj: i'm sorry if i messed up by modifying hpcguix-web in the guix-hpc "fork"! <civodul>hopefully we'll manage to reconcile these <civodul>i'll look into it this afternoon anyway <roelj>civodul: Oh, I think it's fine, no? Only the width of the table might be a little small now. <roelj>civodul: rekado made sure they also got back in the original "hpcguix-web" repository as well. Would it help if I just give you and rekado push access to the original hpcguix-web repository (on Github..)? Then we can maybe keep things in sync. <civodul>longer-term we should probably have a generic version thereof <civodul>one that can be customized for HPC etc. <quigonjinn>is it preferred that packages do not depend uppon linux-libre-headers? <civodul>quigonjinn: linux-libre-headers is an "implicit" dependency: it's always there, even if you don't explicitly add it as an input <civodul>(more specifically, it's provided by gnu-build-system) <civodul>so in general you don't need to add it as an inpu <quigonjinn>civodul: and what about the case when a program/script needs the headers in C_INCLUDE_PATH because it calls on gcc at runtime? I guess I should just wrap the executable, right? <civodul>either that, or close over 'gcc-toolchain', which includes everything <quigonjinn>civodul: i'm fixing the issues of my patches for freehdl and qucs <civodul>i hadn't made the connection with your real name :-) <civodul>yeah so maybe after all depending on gcc-toolchain is the right thing to do <civodul>i hadn't thought about C_INCLUDE_PATH and all <quigonjinn>right. also, i had missed thay freehdl has a script that calls the compiler itself <civodul>right, so that's a good reason to close over gcc <civodul>i'm sorry it took this long to land this patch series <civodul>hopefully discussions have helped improve it <civodul>rekado: a couple of days ago i advertise your JSON importer at work :-) <civodul>somebody was complaining about the parentheses <civodul>i said: look, you can have braces instead if you want! <quigonjinn>civodul: yes, the delay was for the better. many issues were found and fixed <brendyn>Weird. my keyboard layout, xmodmap and xset settings mysteriously reset themselves randomly after a few horus <divansantana>why would =guix offload test= work on a non guixsd system, yet when I do =guix package -i ruby@2.4.1= it compiles locally instead of on the build machine? <civodul>brendyn: could it be GNOME or something interfering with that? <civodul>divansantana: do the machines declared in /etc/guix/machines.scm have the right system type? <brendyn>I logged in to i3 tiling window manager from slim so im not sure what could be doing it <civodul>divansantana: also, tiny derivations such as those that build the profile are marked as "non-offloadable" <divansantana>civodul: good answers. The system type is right. Think it's perhaps your latter answer. I'll see. Also would you know if the =guix pull= command would be offloaded? <brendyn>civodul: Since you said you use guix pull instead of symlinking latest to your git repo, how do you go about testing changes you've made, since the guix command wont see any of your changes <civodul>brendyn: for testing purposes i use ./pre-inst-env <brendyn>ok odd, ./pre-inst-env tries to call a version of guile that doesn't exist in my /gnu/store <brendyn>I actually typed the command............... on the wrong computer ;< <brendyn>I have two keyboards, two mice, and three monitors infront of me. It's a source of perpetual frustration as a keep finding myself typing on the wrong keyboard ***jonsger1 is now known as jonsger
<bavier>I replaced the thermal paste on my laptop's cpu last night <bavier>so I should be able to build guix packages with more than --cores=1 again ***jonsger1 is now known as jonsger
<thomassgn>is it possible to use guix environment with only a local .scm file that is missing e.g. the source fields? ***Steap__ is now known as Steap
<civodul>looks like 30-40 people disappeared since earlier today <OrangeShark>looks like all matrix, so an irc bridge went down or something? <jackhill>Hmm, I guess the latest mailing list traffic about the Java devroom is relevant. <civodul>jackhill: one way to help would be to give rekado feedback on that proposal <civodul>perhaps you can email the list sharing your thoughts on this topic? <jackhill>civodul: noted. Unfortunately, I don't really know that much about Java build magic. <OriansJ>jackhill: we don't need magic, only people willing to think and do the logical next steps <OriansJ>for example, mechanically check to see what are the absolute build dependencies and their supported versions <jackhill>OriansJ: oh cool. I can certinally do thinking after I come up to speed on the current state :) <OriansJ>jackhill: we <3 people who are willing to put forth the effort to help us fix these sorts of problems. <OriansJ>We sadly are usually short on time and tend to have to set priorities for the things we work on. <jackhill>(at least to me) everyone here seems really nice, so I would like to help, but am fearful about responding too enthusiastically to calls for help in case I'm not able to follow through. <OriansJ>jackhill: we all sometimes fail just be honest and share what you learned so that others may build upon your work <OriansJ>I've had numerous failures in stage0 FORTH that reepca helped me with because I didn't know FORTH as well as reepca does. <OriansJ>jackhill: everyone is here because they care <caffe>so, i hear this is the place to go re: shepherd? <caffe>how does guixsd get around shepherd's lack of runlevels? <OriansJ>caffe: by understanding what runlevels are <OriansJ>runlevels are just an abstractions about what services should be running and in what order they need to be started. <caffe>okay, so the basic functionality can be reimplemented (in scheme, i'm guessing)? <jackhill>Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format version is not supported (resource: MMapIndexInput(path="/srv/perkins/dspace/solr/statistics/data/index/_obuu.fdx")): 1 (needs to be between 2 and 3). This version of Lucene only supports indexes created with release 3.0 and later.