<apteryx>pkill9: I've now built it in a container of the same environment; found the problem; I was clearing the files of the client but there's this lrc middle ware that is not supposed to use GNOME/GTK+ stuff but somehow it was keeping references to it and polluting the build of the client
<raghavgururajan>> apteryx: raghavgururajan: as a GNOME package maintainer I think this is an important detail that you should know: anything that propagates gdk-pixbuf should propagate gdk-pixbuf+svg to stay in harmony with gtk+'s own propagated libs.
<jmarciano>I have this problem http://ix.io/2Swb guix pull: error: got unexpected path `Backtrace:' from substituter, so what can I do to make guix package manager work again? It works on GNU Hyperbola/Linux-libre OS
<lle-bout>jmarciano: I that error once it was due to glibc-locales not being installed in the root profile
<jmarciano>I cannot install glibc-locales as the same error coes
<jmarciano>as guix pull never finished due to error, I cannot do guix package -u or install anything
<jmarciano>if Backtrace: comes from substituter, maybe I could change substituter, I understand it is server with packages
<lle-bout>marusich: it built but fails with checks
<lle-bout>marusich: running a build of it again now
<jmarciano>the install script should not IMHO try to download new archive if it was interrupted, archive should be kept. It spends data in those countries where it is very expensive
<i1l>emm.. i saw some Nix packages. they are not written like "use modules a b c, code", but like "lambda (func_a, func_b, func_c, ...), code". this means that package manager searches for dependencies itself (as i understood).. can it be so in Guix? looks interesting and "automated".
<i1l>i remember Guix has something like spec->package already. takes strings, returns packages it found.
<lle-bout>marusich: any idea how to access unpacked source directory path from within a phase?
<jmarciano>install scripts REQUIRES that /gnu does not exist
<lle-bout>marusich: are you sure the unpacked source dir isnt named after the tarball..?
<marusich>If the source comes from a tarball, the unpack phase will extract it and then invoke (first-subdirectory ".") to go to it.
<lle-bout>marusich: ohh that's a useful function, I also saw NIX_BUILD_TOP env variable
<marusich>the phase chdirs to it, so usually you don't need to chdir]
<lle-bout>so I could actually use both to find the unpacked source dir
<lle-bout>marusich: basically I need that dir before I have a package (zig) that can only run tests after 'install phase
<marusich>yes, but since the phases are deterministic, I don't think it's that bad to use with-directory-excursion to temporarily go somewhere else for your phase, if you aren't already where you need to be, or if you can't get the directory via some other method
<lle-bout>jmarciano: for the expensive data thing.. GNU Guix really isnt optimizing for that use case at all.. so I am afraid you will be better served with some other distro for that. However (when you don't have broken GNU Guix installs..) there's a feature to publish your store to your LAN (guix publish --advertise), so that creates some sort of cache, but downloaded things will still be larger than they really need to be. For size
<lle-bout>minimization, some other distros are just better, not GNU Guix right now.
<lle-bout>but you can certainly contribute on that aspect to GNU Guix (size minimization that is)
<jmarciano>lle-bout: right now, just Guix offers me straight access to some software
<jmarciano>other issue at hand is that my system sets LD_LIBRARY_PATH, such as /root/GNUstep/Library/Libraries:/usr/lib which conflicts with guix, then I need to $ unset LD_LIBRARY_PATH before running guix, is there way to keep both in alignment?
<marusich>hey lle-bout , do you have a guix with a version later than 7e9d9f28e997e7faad28cdd1c416be174d6986e7 ? can you run "guix repl", then ",use (guix build syscalls)", and then ",pp (mounts)" and share the result with me? I don't have a recent version built on an x86_64-linux system and I'm curious to see what the output looks like there.
<lle-bout>jmarciano: what kind of distro are you on..?
<marusich>I'm building it but if you have one offhand that is up to date it would be convenient.
<lle-bout>jmarciano: I don't know the answer to your question, but just piece of advice if you want to run GNU Guix on another distro without running into weird problems all the time, keep your environment within the norm.
<marusich>i1l, my understanding is that you can set LD_LIBRARY_PATH to override where theings are loaded from, but in Guix we use embedded runpaths to find libraries in /gnu/store, I don't think we use LD_LIBRARY_PATH for stuff like that. you can confirm by doing 'git grep LD_LIBRARY_PATH' to see how it's being used in the source, if you are curious.
<lle-bout>jmarciano: distros people most commonly run GNU Guix (or any other software) on, since that's what users test the most often
<lle-bout>default environments provided by those distros *
<donotshake[m]>I'm trying to package something in go and am wondering how, if at all, to have two `#:import-path`s ?
<jmarciano>lle-bout: yes, this LD_LIBRARY_PATH is not set by user, rather by OS
<i1l>marusich: so jmarciano have no chance to get an conflict due to that e-var?
<jmarciano>those LD_LIBRARY_PATH are installed from /etc/profile.d/ I have found here
<lle-bout>jmarciano: Trisquel or any other Debian/Ubuntu-based are the most tested environments for GNU Guix on other distros AFAICT
<marusich>I think if you set LD_LIBRARY_PATH it might conflict, since the linker will honor your request to search those locations for libraries.
<jmarciano>I use Guix because I do not change OS, I need some software beyond it, that it is in Guix
<jmarciano>maybe there is something that I can add to LD_LIBRARY_PATH so that Guix does not complain?
<marusich>Generally speaking, on any given non-Guix distro, you need to be careful about how the environment interacts with Guix-installed stuff. Usually it isn't too bad, but you have to take care not to have environment variables set that will interfere with things. If LD_LIBRARY_PATH is set, then perhaps you can do start an environment in which that is not set, to see if it fixes your issue? E.g. "env -u LD_LIBRARY_PATH some-cool-tool-from-guix"?
<lle-bout>jmarciano: on my GNU Guix System installation I do not use user profiles, I install everything I need into my system then I use 'guix environment --ad-hoc <pkg> -- <bin>' if I need something once
<i1l>lle-bout: just browsers not always already substitute ready.
<lle-bout>i1l: then I can wait a bit for them to be ready, I also have offloading set up to another powerful server for development so that helps.
<marusich>jmarciano, when using guix, I suggest unsetting environment variables that would cause system stuff to be used, like LD_LIBRARY_PATH. Try it out in a shell via "env -u LD_LIBRARY_PATH bash" or whatever.
<jmarciano>can I pay $5 for somebody to make recipe for Leo editor?
<marusich>I use a script like this in fedora to "activate" my guix environments, i.e. set the environment variables. I don't keep the guix environment variables active in all my shells.
<jmarciano>marusich: thanks, I made now alias guix='env -u LD_LIBRARY_PATH guix'
<marusich>They are all unique snowflakes, and the way in which they might interfere, and the solution you might take, depends entirely on the distro and sometimes even on how you are starting your environment.
<lle-bout>jmarciano: make a donation to GNU Guix as a whole then! I'll be happy about that!
<jmarciano>sponsoring need not influence development, it may or may not be
<marusich>e.g. when you ssh in, it's a different environment usually than if you log in via a graphical desktop
<sss2>lle-bout, i have tried to install qt4, pyqt "meta" package and sip separately, but it does not helped
<marusich>i have encountered similar issues, and usually the easiest path to a fix is to search guix-devel and the guix bug reports for keywords that help me figure out if someone has encountered the same problem before - sometimes a work-around for that specific distro has been shared on the list.
<lle-bout>sss2: I will modernize and fix the pybitmessage package since it seems it still depends on python2 right now, not sure if upstream supports python3
<lle-bout>jmarciano: I am really confused by all these errors you are getting, they never happened to me. I am afraid I can't be of much help here, your installation of GNU Guix looks severely corrupted in some way.
<marusich>i1l, whatever profile you run guix-daemon from, you should upate that one.
<marusich>the guix installer script that most people will probably use chooses to install guix-daemon in root's profile. so that's the one you need to update, probably.
<marusich>to know for sure, you can check whatever it is that is invoking guix-daemon. If it's systemd, look at the unit file. what is it execing? it'll be guix-daemon, from some profile. That's the profile you need to update, to update guix-daemon.
<marusich>lle-bout, i resolved the tests/syscalls.scm problem. seems like a bug in recent syscalls.scm code...i'll submit a patch when i respond to the email thread about wip-ppc64le-for-maseter
<lle-bout>marusich: on x86_64 I run GNU Guix System
<marusich>efraim, do you mind if i rebase wip-ppc64le-for-master? I want to drop commit 8f52ea2 because it is not necessary (and actually contributes to a test failure) because it solves a problem that is not present on master.
<i1l>lle-bout: .. due to some troubles on aarch64? (hi civodul.)
<efraim>marusich: I'm ok with that. I almost have a patch for lle-bout for sed and selinux for wip-ppc64le-for-master but I can wait to push it
<marusich>OK, efraim and civodul , I sent my email.
<marusich>efraim, if you can figure out what's up with commit 2712703474137310c2cf4f1a3530500188b37b9f and the last problem I mention, that'd be great. I'll check it out more tomorrow, but I gotta sleep now.
<lle-bout>abcdw: reading your guix home email, exciting!
<lle-bout>abcdw: it's really good you're creating videos of things
<abcdw>lle-bout: Thank you!) I find it a good way to spread the knowledge and ideas) Also, I learn myself preparing for streams and talks.
<lle-bout>abcdw: yes! we need more knowledge spreading across GNU Guix! :-D
<lle-bout>abcdw: can't wait until I can use some GNU Guix System and home configuration from some repo where everyone centralizes best practices, knowledge and then code so we can all improve our setups without redo-ing everything all the time
<efraim>marusich: looks like you ran into the same glibc-intermediate missing input that lle-bout ran into, that was fixed with the squash commit. I'm trying out make guix-binary.powerpc64le-linux.tar.xz now. I'll try to look at the test failures too but no promises :)
<zimoun>rekado: thanks. But I am not able to have anything defined in (guix scripts environment) in the REPL. It is annoying for testing one thing without going to Geiser or something like that. I mean “guix repl” then test some functions.
<zimoun>rekado: how do you generate this “guix-env-perf.svg” file?
<rekado>“perf timechart record <the-command>” and then “perf timechart -p guix -p guix-daemon”
<apteryx>raghavgururajan leoprikler by the way, I found the issue with the guix environment --pure and icons not being available in a locally built Jami; there was propagation of both gdk-pixbuf and gdk-pixbuf+svg; and somehow the earlier appear first in LIBRARY_PATH.
<apteryx>I've just push a fix for this (ensuring gdk-pixbuf+svg is the one used when propagated) on staging.
<apteryx>I'm trying to use --root with guix build -m manifest.scm --root=$HOME/.config/guix/profiles/name, and it produces two links rather than one, pointing to the debug output and normal output of coreutils. Hmm.
<apteryx>I would have expected the root to point to the profile
<apteryx>it seems to point to the first listed of the profile instead
<lfam>I noticed the issues when "ungrafting" on the wip-next-release branch.
<lfam>The derivations of the "ungrafted" packages should match the replacement packages, but they were not matching
<lfam>So, I poked around the derivations and the guile-builder files
<lfam>So, I just pushed a new revision of the wip-next-release branch. It's up to date for current master
***Noisytoot is now known as [[
***[[ is now known as [[Like
***[[Like is now known as [[
***[[ is now known as Noisytoot
<lambdanon>Hi, I'm trying to lock XFCE, but every time I do so, I get a constant "Authentication Failed". I tried adding xlock into the services declaration, but this doesn't seem to work
<leoprikler>lambdanon: that's because the relevant binaries also need the setuid bit
<lambdanon>I see. Is there a way to do this in config.scm, or will I have to manually chmod u+s?
<rekado>lambdanon: no, we don’t do things manually
<lambdanon>Looking at the manual, I see this section: "
<lambdanon>'"screen-locker-service package": Add package, whose command is program, to the set of setuid programs and add a PAM entry for it'
<lambdanon>Which I read as saying that this should already add the relevant binaries to setuid? Or will it only add them to the setuid if I append screen-locker-service to some other expression which sets the setuid programs?
<rekado>lambdanon: it extends the setuid-program-service-type
<lle-bout>should things required during tests be native-inputs?
<bone-baboon>i1l: apteryx: Thanks for your help with "nomodeset" appending that to the line about the kernel solved that issue of the system going unresponsive. I now have Guix installed on the computer.
<lambdanon>Got another problem. Tried removing the sddm service and add gdm, now gdm isn't launching
<bone-baboon>apteryx: Now when I start the computer I maualy edit that line. You said this can be added to the operating system configuration. This is what I have come up with from reading Bootloader configuration of the manual `(linux)`
<apteryx>is there something special in our handling of Qt? I built jami-qt in a Guix environment, and the QmlThread crashes with SIGSEGV, like so: Thread 7 "QQmlThread" received signal SIGSEGV, Segmentation fault.
<lfam>Can you try again with --no-grafts, apteryx?
<apteryx>I don't think there are grafts, I'm working off staging
<nckx>lle-bout: Ping? (I know, that's rich coming from me)
<lfam>I looked them up the handy Guile Procedure Index
<lfam>From the rnrs-lists page: "remove, remv, and remq are identical to the delete, delv, and delq procedures provided by Guile’s core library, (see List Modification). remp is identical to the alternate remove procedure provided by SRFI-1; See SRFI-1 Deleting. "
<bone-baboon>nckx: apteryx: Thanks for your comments. I now have it so it does not error on system reconfiguration. I am going to try a reboot and see if it eliminates the need for me to do manual edits.
<lfam>The lesson for me is, Guix System is better!
<nckx>lfam: The Guix manual, at least, should always mention SRFI-1 explicitly. If not that's a bug. You mentioned a snippet from the manual so I thought my message would be clear.
<bone-baboon>Just before I do that. What program do people use to poweroff from the command line? I am used to using poweroff but it looks like it is not in the base packages and when I search for poweroff I do not find it.
<nckx>I use ‘sudo halt’ the few times a year I switch off my laptop.
<lambdanon>How much of a guile background is necessary for making a well-engineered Guix SD config? I've gone through the first 3 chapters of SICP, and that's it
<lfam>I didn't realize there would be multiple implementations of remove from different libraries. It was just a lazy oversight
<lambdanon>lfam: cool. Since I can't really do any maintenance on my box, I'm just going to reinstall with a minimal config.scm, and go and make a modular manifest for everything else. Is that what you're supposed to do?
<lfam>There's not really a way you're supposed to do it
<nckx>lambdanon: It's recommended not to put all your day-to-day software in your system.scm, but only a small set of ‘system’ packages (e.g. %base-packages, or %desktop) and everything else in a per-user manifest. The logic is that you can then reconfigure without having to rebuild your world. It sounds like what you described.
<lfam>jackhill: And after that, try running the command again with --no-grafts. It's not safe to run your system without grafts, but I suspect the bug was introduced by a graft, and I want to test that hypothesis
<nckx>But it's not like any other way is ‘bad’ or ‘unsupported’. Freedom!
<lambdanon>nckx: That's exactly the problem I was having. I had a config.scm with around 50 emacs packages organized in a hierarchy. It worked, for a time, but it wasn't pretty
<leoprikler>yeah, you should keep those 50 hierarchied emacs packages inside a manifest.scm instead :P
<n1x_>when adding a package to the repos, is it generally preferable to get as many of its dependencies packaged as possible or is it preferable to try to get a minimal build? trying to package some fairly big golang stuff and I've noticed a lot of the time they'll build fine if don't pass in some dependencies that are being problematic (e.g. circular dependencies)
<leoprikler>we normally go for full features, but there's no problem if you package a minimal version and revise it later
<leoprikler>especially if there's circular dependencies and you'll need that minimal version for bootstrapping
<bone-baboon>When it booted it did not automatically use "nomodeset" and the system was unresponsive. So I rebooted and manually used "nomodeset". Here is the config that does not error when I do a system reconfigure but does not automatically use "nomodeset". https://termbin.com/o25qr