IRC channel logs


back to list of logs

<raingloom>heyo, how do i compile something *manually* for i686? i have the cross-gcc in my environment but it can't find the crt libs.
<the_tubular>Trying to make something like %system-defaults that would set locale, timezone and a few other settings
<the_tubular>But the settings don't really have nothing to do with each other
***rekado_ is now known as rekado
<jgart[m]>Is there ever a delay in the time when some commit is pushed to master and when users will receive that update via `guix pull`?
<AwesomeAdam54321>jgart[m]: I don't think so
<jgart[m]>looks like my guix describe says it is at commit 2fb4304ee7eb7d17d48bee345677ef1f288a0b86
<jgart[m]>but that is from Mar 18
<jgart[m]>March 18
<jgart[m]>gnu: bitlbee-purple: Use 'modify-inputs'.
<apteryx>perhaps you set a specific revision in ~/.config/guix/channels.scm
<jgart[m]>I tried running `guix pull` but it doesn't point to the tip of master
<jgart[m]>I just have %default-channels
<jgart[m]>and guixrus and nonguix
<jgart[m]>apteryx: Is there any other place that I might be pinning the above commit?
<civodul>Hello Guix!
<jpoiret>jgart[m]: note that commits may be committed on a different date than they are authored
<tschilptschilp23>I just pulled and got informed about the new ~guix home container~ feature. Great, just started to play with it!
<tschilptschilp23>mhm. might it be that the container does not play well with mcron-services (I'm actually happy about it, just wondering)?
<abrenon>hello guix
<tschilptschilp23>Does somebody have experience with the package network-manager-openvpn? I already can connect from bash by running ~sudo openvpn --config file.ovpn~. So I installed the mentioned package (both systemwide and then also into home) -- but I can not make out any difference in the options of the network-manager GUI in GNOME. If I go for 'import VPN connection from file' it tells me, that it cannot read the file. And if I manually type
<tschilptschilp23>~sudo nmcli connection import type openvpn file file.ovpn~ I receive a 'unknown vpn-extension »org.freedesktop.NetworkManager.openvpn«'. Any hints on what I'm missing to do?
<abrenon>tschilptschilp23: hi ! it was a while, but I remember struggling with that one
<abrenon>if I remember correctly, you have to modify the network-manager service to add the required "vpn-plugns" to it
<abrenon>that was with openconnect (a CISCO thing I think ?), but it may be similar with openvpn ?
<abrenon>maybe there's just a plugin to add ?
<tschilptschilp23>abrenon: thanks! I will look into the service, need to get into this anyway... I was hoping that just installing the plugin package is enough (always getting excited when I see guix acting on it during a reconfigure)
<abrenon>yeah, I had the same
<abrenon>maybe one of the most difficult aspect of guix at first for me was to understand how most "system" packages installed not for you but just for things to work need to be plugged at the right place
<abrenon>it's surprising when compared with most other system where you learn about a needed package, install it, and then just expect it to work, and if it doesn't you kind of tinker with everything, possibly going as far as rebooting, and you have no clue what really happens if it doesn't work (and even if it does)
<abrenon>if the openvpn plugin is anything like openconnect, you may like to see an example in my config
<tschilptschilp23>cool, thank you!
***toulene9 is now known as toulene
<abrenon>hope it helps !
<tschilptschilp23>abrenon: it does indeed ⌣! I would say this is just a small tweak off your config:
<tschilptschilp23>thanks again
<abrenon>ohh, that close ? ^^
<abrenon>that's really great ! you're welcome
<tschilptschilp23>abrenon: I feel very tempted to fill up this list...
<tschilptschilp23>but only have openvpn to connect to for now
<abrenon>that's understandable but you don't need to, it's so easy to change afterwards : )
<tschilptschilp23>you are totally right :)
<tschilptschilp23>abrenon: I have to admit that I actually rebooted, but I'm 99.9% sure that login/logout would have been enough to make the changes visible. My fingers were too fast though :)
<tschilptschilp23>Confirmed, this is a matter of login and logout only. And the packages do not even have to go into the system's package list, at least here on 24cbe07!
<fnstudio>hi, i was wondering if anyone had any suggestion for a browser extension for mouse-less browsing; e.g. if anything is available in guix already or if i should be looking into something that's not currently in guix but that could be packaged relatively easily
<fnstudio>i do love animals including mice, it's the ones that connect to a computer that i can't stand
<jpoiret>if you're familiar with emacs, you could try nyxt
<fnstudio>and browsing is probably the activity that's more taxing in terms of mouse use
<fnstudio>jpoiret: thanks, i've briefly looked into it in the past; i understand it makes use of popular web engines (i'm looking at its website right now)
<fnstudio>and as a matter of fact, it seems to adopt an agnostic approach to web engines
<fnstudio>in general, when considering alternative (i.e. not the popular 2 or 3 options) browsers, my main concern has been around security - i.e. the security implications of using a less popular web engine - but in the case of nyxt i suppose that's not a concern then?
<acrow>tschilptschilp23: I have precisely the same errors when I run guix home container. I also suspected mcron but guix home reconfigure does not complain and things appear to be doing as I intend. If you discover the cause I'll be interested to hear what you find.
<civodul>tschilptschilp23: i noticed that (harmless) backtrace about bind and EADDRINUSE; i think the problem is that a login script here is executed twice, so it tries to run shepherd even though it's already running
<civodul>i'll report a bug
<tschilptschilp23>acrow: for me the reconfigure itself also worked as expected -- the mcron job in my home-configuration just regularely copies files from one directory to another, and I honestly absolutely did not think about this job in my config when I issued guix home container! We recently had the situation on another machine with 'regular' cron, where we unpurposly let cron copy the same files to the same destination machine, yet once to a local and
<tschilptschilp23>once to a remote folder, at the same time, which resulted in the job never finishing. So I think it's actually good, that guix mcron somehow does not 'allow' this! As I wouldn't be happy about playing with ~guix home container~ would kill/interrupt my running mcron-job...
<civodul>tschilptschilp23: i've reported it now:
<tschilptschilp23>civodul: thank you for looking into this -- maybe a message like "just don't do that!" would just be fine for avoiding confusion!
<civodul>don't do what, though? :-)
<tschilptschilp23>TBC, I mean a message coming from ~guix home container~, in case one tries to start a job in a container, that's already running outside of it!
<civodul>tschilptschilp23: ah sorry, i didn't get it; why would it be a problem?
<tschilptschilp23>civodul: mhm, because thinking about what I'm asking my computer to do in this case makes my head swirl...
<civodul>"guix home container" starts a fully isolated environment
<civodul>the daemons in there do not interfere with those running outside
<tschilptschilp23>ahh -- does this mean, this also happens without mcron-jobs in the home-configuration? I haven't tried yet!
<jeo649>i dont want to have any login managers how do I setup my config.scm?
<civodul>tschilptschilp23: i haven't tried actually, but i think so
<civodul>jeo649: hi! you can follow the 1st example at
***the-porcupirate is now known as porcupirate
<peterpolidoro>what is the proper way to define a package that has a dependency  on udev rules?
<peterpolidoro>should that dependency just be ignored in the package definition and then separately set up using a Guix System service?
***the-porcupirate is now known as porcupirate
<jpoiret>peterpolidoro: yep
<peterpolidoro>if you look at the package "libsigrok"
<peterpolidoro>it seems to be doing some udev rules manipulations
<peterpolidoro>but that would seem to need root privileges
<tschilptschilp23>civodul: thanks for clarifying -- still difficult to think (but I'm certainly no computer). But this might somehow lead to quite some heavy io, if not used with care, wouldn't it? not in my local case, but generally...
<peterpolidoro>(add-after 'install-doc 'install-udev-rules
<peterpolidoro>             (lambda* (#:key outputs #:allow-other-keys)
<peterpolidoro>               (let* ((out (assoc-ref outputs "out"))
<peterpolidoro>                      (rules (string-append out "/lib/udev/rules.d/")))
<peterpolidoro>                 (for-each (lambda (file)
<peterpolidoro>                             (install-file file rules))
<peterpolidoro>                           (find-files "contrib" "\\.rules$")))))
<jpoiret>oh yeah, that's just moving the udev rules from the source to the store output
<peterpolidoro>so should we be doing something like that in our package definition?
<peterpolidoro>and then use a Guix System service to actually enable the rules?
<jpoiret>yes, you'd want the output to contain the udev rules you want to use (if they're a standard part of the package)
<jpoiret>yes, exactly
<peterpolidoro>or the other option might be to define a second package that only contains the udev rules needed for the first package?
<jpoiret>you could, if it makes sense to only have the udev rules without the first package
<jpoiret>99% of the time it doesn't but there are some edge cases
<peterpolidoro>ok that makes sense, thanks!
<gnucode>morning guix!
<civodul>tschilptschilp23: no no, what "guix home container" sets up is pretty lightweight, a regular but confined process
<jgart[m]>jpoiret: is you guix revision updated to `297a5b74c37fd11b4b73e353ae9ab1b7cb2ae7ac`?
<jgart[m]>s/updated/updated to at least/
<jgart[m]>one other way to confirm is if sbcl-ningle only has disabled tests in the arguments
<jgart[m]>guix edit sbcl-ningle
<jpoiret>that was committed 31 hours ago
<jpoiret>so seems recent enough
<jpoiret>my guix is a bit behind :p
<jgart[m]>if sbcl-ningle has a lengthier arguments field with various custom phases then that commit has not ended up in master somehow
<jpoiret>it is in master
***the-porcupirate is now known as porcupirate
<apteryx>is it me or 'guix-set-emacs-environment' is borked again?
<apteryx>(from emacs-guix, run from Emacs)
<PotentialUser-82>I'm trying to package an R package called R-INLA that's not on CRAN that is mainly a frontend to several included binaries that are tricky to compile from source. I can get the R package installed but I when it calls out to the binaries it crashes as it claims they are not found in the directory when they are. I think maybe the Rpath is wrong but
<PotentialUser-82>I'm not sure how to fix this. Anybody have ideas? Help would be greatly appreciated.
<lfam>PotentialUser-82: "it claims they are not found in the directory"
<lfam>Are you sure it cannot find those binaries? Or could the error message be misleading?
<lfam>If they are precompiled, it's more likely that one of their runtime dependencies is missing
<PotentialUser-82>It lists the path to the store of the package correctly and when I go there they are there. I can't run them from there either
<lfam>Please copy and paste the error message to <> for further assistance
<PotentialUser-82>Unless you want more output
<lfam>It's almost certainly what I suggested: one of the runtime dependencies is missing
<lfam>If you run it with strace, you'll probably see that
<lfam>For example, `strace -f -e abbrev=none /path/to/binary`
<lfam>It's probably the loader that is missing
<PotentialUser-82>Ok I'll give that a shot and see what it says
<lfam>The OS that these binaries were compiled for had the loader in one place, but with Guix it's in another place
<lfam>I know people have created Guix System services to work around this, but I don't have a link handy
<PotentialUser-82>okay I was wondering if there was any examples of how to fix this
<lfam>Stick around for a while. I'm sure that somebody can help you write a simple service to make the loader available in the expected location
<PotentialUser-82>ok thanks
***the-porcupirate is now known as porcupirate
<unmatched-paren>hello guix :)
<unmatched-paren>i've nearly migrated everything to guix home, but i'm having some issues with one nvim plugin
<unmatched-paren>it depends on various python things, but it tries to download them and stuff them in a venv...
<unmatched-paren>you need to run `:COQDeps` to download a few things from pypi and it puts them in a venv
<Aurora_v_kosmose>So yeah, the kaldi + openfst 1.7.3 patch should be about ready.
***rekado_ is now known as rekado
***sneek_ is now known as sneek
<jab>Hey guix! I did some more work on the opensmtpd-configuration today. It's still a long ways from where I can submit it...
<civodul>jab: hey, good!
<civodul>feel free to ask here if you need guidance
<jab>civodul: try to keep your hopes low...I've been working on this for a year...
<jab>but thanks for the offer of help
<jab>also obligatory link:
<civodul>woow, that's a long file already!
<jab>civodul: thanks for the encouragment!
<acrow>sneek: later tell PotentialUser-82 After installing your new R library did you try uninstalling and then reinstalling the main R package? I'm just guessing after thinking about your problem for awhile. I'm guessing that this will rebuild your RPATH and enable that new library.
<sneek>Will do.
<civodul>apteryx: hey! was 4a828263791ebb8ed8f8104e015a8f467008fc76 intended? looks fishy
<civodul>ngz followed up in 9a31942cabb5c73174aee96ecd873fcf89955a9d, but the ".post1" version string looks weird to me
<lfam>That project's release process looks disorganized
<ngz>The ".postN" suffix is not unseen in this project. They released a 7.0.0.post3 some time ago.
***the-porcupirate is now known as porcupirate
<civodul>ngz, lfam: oh well, maybe it's ok after all