IRC channel logs


back to list of logs

***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>hello guix!
<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.
<boskovits>What approach shoul be taken here?
<brendyn>Anyone else find the guile repl really laggy in emacs?
<efraim>boskovits: perhaps packaged as asm-for-semme
<rekado_>my emails to any address are being delayed a lot.
<rekado_>I also haven’t received confirmation from after sending mail to
<boskovits>Hello, rekado!
<boskovits>I have a question
<boskovits>I'm trying to package xbean-reflect.
<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>What should I do now?
<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.
<rekado_>what is a “shaded” version?
<rekado_>ACTION goes afk
<civodul>Hello Guix!
<civodul>rekado: thanks a lot for going through the list of pending patches!
<civodul>really a relief to see old patches get in :-)
<civodul>heya roelj!
<roelj>Hi civodul!
<mekeor>hi guix :)
<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>roelj: maybe yes
<civodul>longer-term we should probably have a generic version thereof
<civodul>one that can be customized for HPC etc.
<civodul>ACTION goes for lunch
<roelj>civodul: I agree.
<roelj>civodul: Alright, see you!
<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
<civodul>arrrgh, typing is hard
<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>quigonjinn: yes indeed
<civodul>either that, or close over 'gcc-toolchain', which includes everything
<civodul>i think clisp does that
<civodul>which program do you have in mind?
<quigonjinn>civodul: i'm fixing the issues of my patches for freehdl and qucs
<civodul>oh excellent
<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
<quigonjinn>i thought it only compiled VHDL to C
<civodul>right, so that's a good reason to close over gcc
<civodul>well, gcc-toolchain in this case
<quigonjinn>good. thanks for the input :-)
<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!
<civodul>they seemed to like the idea ;-)
<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>hmm yeah
<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?
<civodul>i think it would
<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>oh wait i realised im an idiot
<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>hello guix
<civodul>heya bavier!
<mekeor>hello bavier :)
<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
<mekeor>how does it feel?
<bavier>mekeor: about 20C cooler :)
<mekeor>nice :3
***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?
<thomassgn>derp, I think it was obvious...
***Steap__ is now known as Steap
<civodul>woow, relatively few people here
<bavier>yeah, kinda quiet
<civodul>looks like 30-40 people disappeared since earlier today
<OrangeShark>a bunch of people disconnected at the same time
<OrangeShark>looks like all matrix, so an irc bridge went down or something?
<civodul>too much centralization!
<jackhill>Has there been any more thinking about done about Maven? A quick internet search turned up this thread from last year:
<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.
<jackhill>found another thread:
<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>I think that is very understandable.
<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.
<jackhill>OriansJ: okay that sounds good to me.
<OriansJ>jackhill: everyone is here because they care
<jackhill>join #lucene
<caffe>so, i hear this is the place to go re: shepherd?
<jackhill>OriansJ: that's really cool!
<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.
<jackhill>argh, sorry for the noise