IRC channel logs


back to list of logs

<mla>is guixsd supported on aarch64? says guixsd should work on aarch64 but there's no download link?
<atw>anon987321: could you get more info by launching emacs with --debug-init?
***jonsger1 is now known as jonsger
<ScaredyS1uirrel>hi guys
<ScaredyS1uirrel>why can't I have my config.scm file work?
<ScaredyS1uirrel>hi tech supporters
<bandali>hey ScaredyS1uirrel
<bandali>it's pretty quiet here right now
<bandali>if you don't get a reply, try asking again later, tomorrow through the day
<ScaredyS1uirrel>ok computer burn up
<ScaredyS1uirrel>you are so much a toy
<ScaredyS1uirrel>the brain can do all that you do and we could just grow different programmed one
<ScaredyS1uirrel>they just do that with ai programs in C
<ScaredyS1uirrel>genetical method alternate method
<elais[m]>Here I was thinking guix would drive *me* crazy
<Gamayun>Hey guix!
<wingo>jonsger: regarding guile and libgc8 -- i will try to put it on my to-do list
<PurpleSym>Is there any authentication of users built into guix’ TCP protocol?
<sneek>PurpleSym, you have 1 message.
<sneek>PurpleSym, leoprikler says: I'm not sure.
<leoprikler>sneek: botsnack
<ng0>do I save computing steps for guix when in an autotools project I make "/bin/sh" get detected via substitution instead of hardcoded /bin/sh?
<ng0>thinking about how we replace the python and perl interpreter line but not the /bin/sh one..
<leoprikler>Python and perl are necessary, because there's no /usr/bin/python or /usr/bin/perl
<ng0>i know
<leoprikler>iirc, we also replace /bin/sh in some places
<ng0>but it's more like, I don't have to care for my system, but should I care for constrained environments like guix for sh(1)?
<ng0>right now there are maybe 40 or so sh scripts in this
<leoprikler>using /bin/sh plainly?
<ng0>and where bash is used as a language, /usr/bin/env bash
<ng0>there are 2 or 3 bash scripts left because they use parts of bash which are more difficult to move to sh
<leoprikler>are you talking about shebangs or parts of guix packages?
<leoprikler>because shebangs are written like that for compatibility with other systems
<leoprikler>and guix patches them
<ng0>" when in an autotools project I make "
<ng0>ie upstream developer
<leoprikler>ahh, now i understand
<leoprikler>so your upstream patch would be something like /bin/sh -> @SHELL@?
<ng0>so what we have as SHalines right now is /bin/sh and /usr/bin/env bash, which was already done as a compromise to use as most systems
<ng0>i'm not exactly sure. @SHELL@ can be wrong
<ng0>iirc it takes the value of the build shell
<leoprikler>okay -> @BIN_SH@
<ng0>when someone builds with debian's broken fork of our sh, you get a couple of not working scripts including the bootstrap script
<ng0>is BIN_SH an autotools value? I would've just detected it in configure and substituted accoridngly
<ng0>that's what i do for perl and python
<leoprikler>you can name the value whatever you like it to be
<leoprikler>you probably use @PERL@ and @PYTHON@ right?
<ng0>hm. I'll just build my own logic, so that I can be sure a value is picked of a shell which is supported, and allow --with-shell= or something
<leoprikler>sounds like you're shifting a lot of work from other places into your configure script
<leoprikler>Guix will automatically patch your shebangs regardless of what you're doing
<ng0>not really
<ng0>i mena autotools
<ng0>but to come back to the question, it's probably not necessary
<leoprikler>Yep, if you're concerned about Guix compatibility, /bin/sh should be fine.
<ng0>speaking of which, can someone build gnunet from git (not from guix git, but gnunet git) and send me the testsuite log, configure log, and build log? I'm doing a similar thing with Nix ( as I think there are a couple of intersections of Nix and Guix with our tests
<anon987321>hi guix
<efraim>ng0: using the gnunet in contrib/guix/gnu/packages/gnunet?
<efraim>i might clean it up the file a bit
<ng0>i mean, you can
<ng0>basically no one is using it
<ng0>the question was more about simply from git. but then again it's probably easier for you in an guix environment first
<ng0>you can clean up and add to the file and send patches, it would be very good if it won't bitrot :)
<ng0>i think the section about dependencies in README should be mostly complete, to see if anything is missing from the guix package
<Franciman>I got back on a guix system
<Franciman>I am a bit dubious about the locales situation
<Franciman>I think that I should set GUIX_LOCPATH to my profile
<Franciman>so I can do guix pull and nothing breaks
<Franciman>right now I need to also do a guix system reconfigure
<Franciman>what do you think? How do you solve this for you?
<leoprikler>tbh I haven't encountered this problem in a while and I don't remember using any specific fix
<Franciman>on one side I think: whey I do a guix pull, it's natural to also update the whole system
<Franciman>on the other side: man! i forget it :P
<Franciman>another question. When I exit from hexchat it asks me for confirmation, and there is a checkbox where I can say: don't ask for confirmation anymore
<stikonas>Hi, I'm new to scheme, are there any example of how to delete a file from unpacked tarball?
<stikonas>I want to make java bootstrap blob free
<Franciman>if I enable the option, I expect the confirmation to not be asked anymore. But the next time I open hexchat and close it it asks for confirmation again
<efraim>ng0: gnunet-git forgot to check for jpeg, just got an ld error about missing -ljpeg
<ng0>yes, we have a couple of missing checks for the zbar thing
<stikonas>ok, I think I might have found my answer (delete-file)
<pkill9>stikonas: you want (delete file)
<ng0>so for guix we probably need to add those checks to not error out
<ng0>it's more than jpeg:;a=blob;f=gnunet/;h=f50b520d4c04a6152848922f8648a7512405fd11;hb=HEAD#l143
<ng0>thanks :)
<pkill9>I'm trying to compile the wayfire wayland compositor which uses wlroots - just to note, i'm using wlroots 0.8.1 which is newer than the wlroots packaged in guix - but it fails at the linking phase and spits out a tonne of undefined references to wlr_*. The build system it uses is meson/ninja, and looking at the command used to link with the libraries, it doesn't have any reference to wlroots, particularly in the list of
<pkill9>.so files after the `ldl` flag: , yet it finds wlroots in the configure phase. Does anyone have any idea how to fix this?
<roptat>Franciman, it should save the confirmation to your settings
<Franciman>i'm afraid this is the issue
<roptat>is there anything that prevents it from doing so? is ~/.config/hexchat somehow not accessible?
<roptat>I use hexchat too and don't have this issue
<Franciman>let me see
<Franciman>it should be unproblematic
<roptat>well, actually if it were not accessible, you would get a big warning at the start of hexchat
<Franciman>drwx------ 6 francesco users 4096 21 nov 14.43 hexchat/
<Franciman>seems ok
<roptat>maybe I actually never got this message
<roptat>I don't remember about a warning when I quit
<roptat>maybe try to run hexchat from a terminal, quit it and see if there's anything on the terminal?
<roptat>it could give us a hint of what's going wrong
<roptat>otherwise, I guess if you /quit properly you won't get that warning ^^
<Franciman>I get no error
<Franciman>just this: Fatal Python error: PyInterpreterState_Delete: remaining subinterpreters
<Franciman>when closing
<Franciman>but it doesn't seem useful
<Franciman>(hexchat:1481): libnotify-WARNING **: 15:03:51.189: Failed to connect to proxy
<Franciman>also this one, not useful, either
<Franciman>i'll try to modify the config by hand
<Franciman>roptat, ah the config changes, if I change the font
<Franciman>anyways I manually changed the config, now it works
<roptat>looks like you should set gui_quit_dialog = 0 in ~/.config/hexchat/hexchat.conf
<Franciman>yup that's what I did
<roptat>fwiw I don't have any error or warning on my foreign distro (hexchat from the other distro, not guix)
<roptat>so maybe they are related?
<roptat>let me try guix's hexchat on a foreign distro
<roptat>mh... building...
<ng0>efraim: I'll fix that in a minute or os, I'm currently trying to fix gnunet-bugreport
<roptat>ok, guix's hexchat failed to change the config
<roptat>nothing about libnotify, but lots of warning about the theme engine
<roptat>and Fatal Python error: PyInterpreterState_Delete: remaining subinterpreters
<roptat>as well as Abandon (core dumped)
<Franciman>ah so you mean it doesn't make it to change the config, it aborts earlier
<Franciman>makes sense
<Franciman>thanks roptat
<roptat>right, now we have to understand why and fix it
<roptat>seems to be in python
<roptat>#6 0x00007f42a39f805e hexchat_plugin_deinit (
<roptat>and here's a patch:
<roptat>do you want to work on a fix for this? it should be quite easy, as you already have the patch :)
<roptat>otherwise, please send a bug report to, with a link to that patch, so I'm reminded about it :)
<jgibbons[m]>Does anyone know if GuixSD works on Pinebook or Pinebook Pro? In particular, I'm interested in if their wifi and/or bluetooth require blobby drivers.
<ng0>efraim: do you also need a way to set the x11, libjpeg etc location or is automagic detection enough?
<fps>i'm trying to write a build.scm to derive some computed files
<fps>i fail to get the simplest thing to work though :)
<fps>this errors out with
<fps>if i `guile build.scm` this file though it seems to run without error. so a derivation is produced, right?
<roptat>fps, is guix build able to build something other than a package objet though?
<roptat>or maybe it's able to build a computed-file instead?
<fps>roptat: the help says it is able to build a PACKAGE-OR-DERIVATION
<fps>so i try to assemble a derivation :)
<ScaredySquirrel>hi guys
<fps>roptat: i'm looking at the documentation of gexps in the manual..
<ScaredySquirrel>how do i install a package system wide?
<fps>ScaredySquirrel: add it to the packages field of the operating system specification
<ScaredySquirrel>I try and use the guix package -i command to do it but it doesn't go about installing system wide instead the package not there
<zig>hey people, how do I run a container as part of my system wide configuration?
<str1ngs>ScaredySquirrel: on guis system you add it to your system config.scm
<ScaredySquirrel>str1ngs: ah
<ScaredySquirrel>but then, my config.scm wont compile
<str1ngs>what error do you get?
<str1ngs>zig: you'd need some server to start the container
<str1ngs>ScaredySquirrel: what error do you get
<ScaredySquirrel>there will be weston compile issue
<str1ngs>are you using substitutes?
<jonsger>jgibbons[m]: according to its an AMPAK AP6256 WLAN/Bluetooth chip. Which seems to be broadcom based. I assume that it won't work without firmware blobs :(
<ScaredySquirrel>that's the backtrace right there
<str1ngs>ScaredySquirrel: (service gnome-desktop-service-type) is not needed it should be in %base-services already
<ScaredySquirrel>another issue please
<ScaredySquirrel>and lol I can get rid of all my verbose font listing right aye?
<jonsger>jgibbons[m]: if it's a broadcom one, the mainline (FOSS) broadcom driver should work :)
<ScaredySquirrel>I add wm suckless fonts to use-service-modules
<str1ngs>ScaredySquirrel: not sure, you can always use a package manifest to install those.
<str1ngs>ScaredySquirrel: in that case you probably want suckless in use-package-modules
<str1ngs>ScaredySquirrel: like so maybe (use-package-modules bootloaders certs suckless gtk xdisorg
<str1ngs> wm xfce bash gnome messaging version-control
<str1ngs> ssh linux xorg glib)
<str1ngs>that's mine use what package modules you need for your packages
<str1ngs>also you probably don't need specification->package this way.
<str1ngs>both are kinda syntactic sugar
<fps>roptat: yeah, a computed-file seems to work better :)
<ScaredySquirrel>um wm isn't there
<ScaredySquirrel>wm.scm isn't a package service file
<str1ngs>if you want i3 wm the package is i3-wm
<str1ngs>and the modules is wm
<Franciman>roptat, sorry, here I am
<Franciman>I would be happy to contribute, not sure what I should do, tho
<fps>you could also probably do (map specification->package '("openbox" ....)) or something similar to avoid the repetition
<fps>the nice thing about specification->package is that you don't need the explicit use-modules, iirc
<str1ngs>fps: yes
<str1ngs>though because it's macro, I couldn't figure out how to use it dynamically. that's probably due to my scheme skills though :P
<fps>scheme@(guile-user) [1]> (map specification->package '("openbox" "vim"))
<fps>$2 = (#<package openbox@3.6.1 gnu/packages/openbox.scm:38 7fa79de3d0b0> #<package vim@8.1.0644 gnu/packages/vim.scm:68 7fa79f68f0b0>)
<str1ngs>fps: I had something like that but I used a for-each instead
<str1ngs>I think anyways
<Franciman>today is REALLY SLOW
<Franciman>is it only for me?
<bandali>seems okay for me?
<Franciman>guix pull takes AGES
<Franciman>and I tried to git clone guix source code, it takes ages as well
<str1ngs>ScaredySquirrel: you need to move %base-services into the append parentheses
<efraim>ng0: sorry I ad to run out. automagic detection worked. 'check before 'install failed as expected, trying it again with 'check after 'install
<str1ngs>ScaredySquirrel: like so (list (append (list (service type-a) (service type-b)) %base-services))
<ng0>I'm adding checks for the dependencies now
<ng0>because i need them here myself
<str1ngs>ScaredySquirrel: err first list should be services
<ng0>check after install is the way we do it now, but I also have ideas to change that
<efraim>i need to fix the current-directory thing I changed in guix.scm, right now it tries to build whatever git repo i'm sitting in instead of gnunet
<ng0>(see the Nix ticket)
<efraim>i might just add a note at the top saying to run 'guix build -f contrib/guix.scm' from the root of the git repo
<ng0>we have basically stopped maintaining the guix package there to my best knowledge, so if you fix it and it works, or just document how it works, that's welcome :)
<ng0>hm, the header file for libx11 is X11/X.h right?
<efraim>there's a fair amount of headers in %out/lib/X11/
<ng0>i think I'll just test it on Debian once I'm done writing this with my system as a starting point
<Franciman>I remember there were some rust crates already packaged in guix
<Franciman>I can't find where they are defined, tho
<roptat>Franciman, if you don't know how to do it, just send a mail to bug-guix, I'll work on it (but I need that email)
<ng0>efraim: the linking is odd. no matter what I do i end up with extra (double) missing libraries which are already satisfied.. but that's my problem
<ng0>or maybe i should clean up. adding -ljpeg worked at least
<efraim>ng0: I just pulled your latest 5 commits and now it's missing X, so I guess I was building it before without it
<ng0>same here, trying to fix it
<ng0>it takes a couple of moments, no ccache here
<Franciman>roptat, done!
<ng0>do you end up with `ldd $out/bin/gnunet-qr` displaying double entries for lSM.7 as well?
<efraim>i can check in a bit, it's still building. i stopped and started it a few times
<ng0>i hope we can provide a guix and nix build machine in automated builds next year
<ng0>ok, never mind, this was stupid
<ng0>i think you have the same issue as I have
<ng0>guix handle (or doesn't, therefore) ldd.conf in the same way NetBSD does, as in that it discourages the file to the absence of it
<ng0>when you objumd -x $out/bin/gnunet-qr you should see that the rpath for the x11 stuff is missing
<Franciman>I tried running cargo build in a project of mine
<Franciman>but i get an error regarding the SSL validity of
<Franciman>error: failed to download from ``
<Franciman>Caused by:
<Franciman> [60] SSL peer certificate or SSH remote key was not OK (server certificate verification failed. CAfile: none CRLfile: none)
<Franciman>do you also have these problems?
<Franciman>I thought that nss-certs package contained everything I needed
<ng0>efraim: setting rpath on the file sounds like too much of a hack, but I guess that's how it's handled unless there's something I find in autotools
<ng0>in pkgsrc this is handled by pkgsrc for me, so i hope this kind of issue exists only on systems without
<str1ngs>ng0: rpath is not really a hack in the context of guix. it's quite explicit and necessary for foreign distro's and to provided functional dependency. hopefully I have the right context here
<ng0>not really the right context, and i know this
<fps>hmm, does it make sense to ask "how to find all gc roots" in guix?
<fps>i.e. to find possibly old profiles, etc?
<bavier>fps: `guix gc --list-roots`
<pkill9>how can i set an environment variable for meson?
<fps>bavier: ty
<pkill9>oh nevermind, i remembered i can add it as a phase
<brettgilio>Are any of you Haskell developers in here getting completions in emacs on Guix? If so, what is your method?
<leoprikler>brettgilio: Do you have emacs-haskell-mode?
<brettgilio>leoprikler: i do.
<leoprikler>And M-x haskell-mode works or does not work?
<brettgilio>leoprikler: iirc haskell-mode alone doesn't provide completion contexts.
<leoprikler>sure, but neither do other major modes
<brettgilio>Right. I was asking about completion specifically tho :)
<leoprikler>this is implemented in other packages, such as yasnippet, company, etc.
<brettgilio>I understand that.
<leoprikler>But for those to work you first have to have haskell-mode :)
<leoprikler>Either way, what's your current setup?
<leoprikler>Haskell mode + ???
<leoprikler>Which company backends exactly?
<brettgilio>That's what I'm unsure of. Idk which backend to use for Haskell.
<leoprikler>Well, I mostly use dabbrev-code, capf and yasnippet, which should also work for Haskell.
<leoprikler>I'm not aware of anything Haskell-specific though, if that's what you want.
<anon987321>hi guix, how can i get geiser to provide completion for guix?
<brettgilio>anon987321: check the docs for loading modules into geiser
<anon987321>i tried geiser-repl-import-module, but i can't see anything guix there, and i tried setting up geiser to look up on my local checkout
<pkill9>I have a problem with compiling a package - i can compile it manually, i.e. in a guix environment and manually setting the LDFLAGS environment variable as shown in the package definition, but if I run `guix build -f <path-to-package-definition>` it fails to link to wlroots:
<pkill9>meson shows in the output that it's added the LDFLAGS when running `guix build`, so I'm not sure what's wrong
***sneek_ is now known as sneek
<leoprikler>pkill9: what's the build failure?
<pkill9>leoprikler: a bunch of undefined references to wlroots, so it's failing to link with
<pkill9>i can hack around it manually by setting LDFLAGS to "-ldl /path/to/", but it still fails to link when building the package definition, even though meson says it adds that flag, though it doesn't looking at the output
<leoprikler>this is very weird
<leoprikler>digging into the, wlroots should not even need your hack
<leoprikler>brb rebooting
<ng0>efraim: I think some the changes I made were incorrect for this, as we only use libzbar. dependencies of libzbar should be made available by the build environment, not gnunet itself
<efraim>ng0: right now i'm targeting commit 1713968e45e227b2c874824c9c9ad4e15abdc00d, although I took a slight break to work on the actual gnunet package in guix
<ng0>oh, cool :)
<efraim>test_transport_api_manipulation_cfg is the only test that consistently fails for me
<efraim>yeah it became easier to fix the guix package and then work on the build-from-git package after
<efraim>i also found some wether/whether typos in and src/cadet/gnunet-service-cadet_tunnels.c
<pkill9>leoprikler: any idea what the issue could be?
<leoprikler>sadly no
<ng0>ok, I'll replace them
<leoprikler>I tried building the packages, but I couldn't even download the sources.
<leoprikler>Could you fix those references?
<ng0>maybe i should add wether to make lint :)
<efraim>I spent the last week looking at some guix services and the manual puzzling out mailman and nagios and found a couple of typos and misconfigurations there
<efraim>unfortunately turning on spellcheck in vim gives way too many false positives
<pkill9>leoprikler: sure:
<leoprikler>pkill9: It appears your setenv does exactly nothing
<leoprikler>but the real error is probably inside meson itself
<pkill9>leoprikler: i don't think so, meson says "appending LDFLAGS from environment`:
<leoprikler>it still does nothing in the actual build
<pkill9>yea :/
<leoprikler>but the actual error appears to be in meson
<leoprikler>adding wlroots as dependency should set up those flags accordingly
<leoprikler>or maybe...
<leoprikler>Why is -ldl even used in the first place here?
<leoprikler>or rather, why does the linker target the shared objects individually instead of using $LIBS?
<pkill9>in <wayfire-source>/src/ it sets `link_args: '-ldl'`, not sure why
<pkill9>i don't know much about this sort of thing
<rockandska>Hi zimoun`, just to let you know i just update my post with reproducible behavior
<rockandska>and hi all
***apteryx_ is now known as apteryx
<pkill9>leoprikler: I got it compiling with the package definition by using a command line flag to add that linker argument \o/ `#:configure-flags `(,(string-append "-Dcpp_link_args=-ldl " (assoc-ref %build-inputs "wlroots") "/lib/"))`
<leoprikler>pkill9: nice
<leoprikler>Now you only have to make those uris git-references
<pkill9>heh yea
<dutchie>why is postgresql an input to qt