<Gooberpatrol66>I'm getting a permission error trying to connect to libvirtd. Is it supposed to be run by an unprivileged user?
<mroh>Gooberpatrol66: the user has to be in the "libvirt" group ala: `(user-account (supplementary-groups '("libvirt")))` or you can set another group for the service: `(service libvirt-service-type (libvirt-configuration (unix-sock-group "yourgroup")))`
<ryanprior>If you know the answer, please provide it instead of redirecting. I can tell it to use somewhere other than $HOME, but in that case I still need to know what the build path is.
<lle-bout>ryanprior: I mean that it should not require any $HOME directory, not during a build - I am guessing there's some function to get the build directory but I don't know it. It seems like an easier and more maintainable route to me to fix that build system to not require $HOME
<ryanprior>I looked deeper in response to your suggestion and soon found that it does not require any $HOME, that's simply a default. So now I know how to provide an alternate directory without setting $HOME, and I'm trying to figure out what to provide.
<iyzsong-w>`getcwd` will return the current directory, usually add "(setenv "HOME" "/tmp")" should make it work
<ryanprior>How do I specify that a package should set a certain environment variable when installed in a profile? Like how installing a Python package will modify your PYTHONPATH
<iyzsong-w>ryanprior: Add the 'native-search-paths' field.
<ryanprior>Thank you iyzsong-w for those pointers and lle-bout for challenging my assumptions
<ryanprior>Yes very exciting if you use experimental :)
<ryanprior>How do I create a file using guile, a la touch?
<apteryx>perhaps using 'open' with write access, and not actually writing anything to it?
<ryanprior>Does Guix perhaps set umask 222 during build?
<ryanprior>I'm getting errors from a test that tries to open a file in write mode repeatedly to overwrite it. After the first time, it's failing. When I look at the file, it's set as read-only for everyone.
<ryanprior>I thought "maybe if I create the file ahead of time it'll work" but it doesn't.
<philipper905>Is there to have both guile2 and guile3 installed and accessible a la python?
<mizukota[m]>i've tried to boot official qcow2 image using qemu with uefi-only emulated system
<mizukota[m]>and bootloader told me it cant find partition with Guix_image label
<mizukota[m]>while same qcow2 image can be loaded with bios emulated system
<mizukota[m]>Also this autumn i've tried to build and install my guix image a lot and I experienced some problems.
<mizukota[m]>- grub-efi-bootlader can only be installed using `guix system init` from host system that was booted in uefi mode
<mizukota[m]>- i've managed to build image, i've managed to guix system init to external usb drive with bios setup, but when i tried to install system to laptop... It was success but when I boot I get booloader errors i think about not being able to find some partition too
<civodul>i think the qcow2 VM image expects a "BIOS" setup
<roptat>hi guix! has anyone managed to make ibus-anthy work?
<roptat>if that helps, I get this kind of errors: org.freedesktop.IBus.Config.SetValue: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._dconf_5ferror.Code2: The operation attempted to modify one or more non-writable keys
<jas4711>i have a guix machine that was installed around 5 years ago, but /gnu/store contains lots of old stuff despite running guix gc daily. how can i find out why a particular file there exists, and how to clean it out safely? for someone who grew up on lisp it somehow feels comforting that nothing has changed and garbage collection still leaves garbage around :)
<pineapples>Whoops. I just accidentally sent a HTML e-mail. Will it hurt?
<civodul>jas4711: hi! "guix package --list-profiles" and "guix gc --list-roots" can give you a good idea
<pineapples>I hope it won't be a garbled mess, and will get auto-converted if possible
<jas4711>is it possible to find out from where a particular file under /gnu/store is referenced? for example, i have a bunch of 'bash44-???.drv' files that probably should have been cleared out when i upgraded to bash 5
<rekado_>civodul: there’s a chance a post like that would become the new anchor, never to be nudged by consecutive blog posts and release announcements, so it would have to be comprehensive and really good.
<morgansmith>I'm currently having issues with the mpd service. I've set it up to run as my user but the /var/run/mpd/my_user folder is owned by root so mpd can't create its pid file there.
<mbakke>PotentialUser-14: I expect LVM-on-root will be supported "soon", the main issue is that GRUB does not currently have the LVM module. You would also need a newer installer image (but you can grab that from the CI when it's available).
<morgansmith>so the activation script creates a .mpd folder in the /var/run/mpd/my_user dir. the .mpd folder has the correct permissions. but the pid file is trying to be made in the /var/run/mpd/my_user dir that has root permissions
<morgansmith>I guess I should go read the manual. I was avoiding it but it'd likely help
<morgansmith>does anyone here use arm-none-eabi? It's really broken. I submitted a patch, but now I don't think that patch is correct :/
<morgansmith>stdlib.h was the one giving me greif. it has an include next stdlib.h line that fails since we put it ontop of the stdlib.h it wants to include next
<morgansmith>in bug # 44750 i made it install into a c++ folder which allows my c code to compile but c++ code wont compile since it can't see the c includes anymore
<mizukota[m]>but none-eabi which is embedded application binary interface with no operating system installed means there is no stdlib, you cant use malloc untill you define it
<morgansmith>libstdc++-arm-none-eabi defines the c++ stdlib.h. maybe newlib defines the c stdlib.h? regardless we are installing those headers.
<tatsumaru>Hey guys, I just installed Guix SD. Then I proceeded to install icecat via guix install icecat and the installed pulled icecat 78.4.0, but then on the guix website I read that icecat 78 doesn't yet meet privacy requirements. does that mean that the guix installed can pull non privacy packages?
<morgansmith>mizukota[m]: I do hope you belive me about the stdlib.h thing. If you do edit "~/.guix-profile/arm-none-eabi/include/stdlib.h" you should see that it's a c++ file. It always fails at line 30 since there are no other stdlib.h files to include
<mizukota[m]>so you need another stdlib for arm-none-eabi I guess.
<morgansmith>mbakke: I didn't want to just add a random chown in the activation service since the mpd user works just fine. I think it's because the mpd user is in the account-service-type. So I think I need to add the user to that
<morgansmith>mizukota[m]: When you tell libstdc++-arm-none-eabi to install in a different directory (like "/arm-none-eabi/include/c++") then you'll see that the original c stdlib.h is preserved.
<morgansmith>if you download the arm-none-eabi zip you'll see they put those c++ things in arm-none-eabi/include/c++/9.3.1
<mizukota[m]>so it is a bug in libstdc++-arm-none-eabi package...?
<morgansmith>guix-vits: learning C is a very big thing to do. chances are you only want a small subset of c. why do you want c? to build embedded device firmware? to write fast programs? there are many different ways to do it
<morgansmith>nckx: I think the bug you found is really similar to mine but it might be harder. Also it has not been fixed yet. In my case the c++ headers where installed into include instead of the common include/c++. In this case glibc is installed in include (either ontop of gcc or below, I'm not sure) but I'm not sure where it is traditionally installed. But ya, it's basically the same issue
<morgansmith>don't we use gcc to build a ton of other programs? How has this issue not caused more problems?
<mizukota[m]>well generally we dont install gcc and build tools into profile, we just write package definitions an they use gcc-toolchain and other things from various places of /gnu/store i think
<morgansmith>That makes a ton of sense. profiles honestly seem a little funky to me. Why don't we just not install this stuff to the profile and only access it via environment variables? It's not like it's currently in the standard include directory
<dannym>civodul: If you have the time and want to, can you show up in https://osfw.slack.com/ #heads (it's slack) ? That would be a communication channel to the Heads people. tlaurion in there is the lead.
<dannym>civodul: I think they are very serious in using Guix for their Heads builds in the future, but right now we are planning to use some weird heads-on-guix-on-docker contraption to do it. They are also doing a lot of manual source checksumming and whatever, which would not really be necessary when they use Guix
<dannym>civodul: I've been trying to explain to them that a lot of stuff they have been doing is superseded by normal guix tools, but they (obviously) mostly care of solving the immediate problem of Heads' builds not being reproducible
<morgansmith>also I'd like to throw out there that currently openocd doesn't build but it we add "LIBS=-lutil" to the configure flags than magically it works. I'd submit it as a patch, but I don't understand why that would be needed
<morgansmith>guix for embedded development currently sucks :P but it should only be a few commits to make it rock I think
<mizukota[m]>well you try to put compiler and other development packages into profile and build your project manually. Guix way is to write a package definition and build it using `guix build`
<morgansmith>ya well probably. You're not wrong. but when a buddy throws a repo at me I just want to run make :P
<morgansmith>I don't see any reason why we couldn't fix it up to make that possible
<mizukota[m]>you can do your make if you truly manage to get proper set of development packages in profile, also they should not have overlapping files so those that do have overlapping files are not compatible for installing into profile
<morgansmith>ok but in this case arm-none-eabi-toolchain was overlaping with itself
<mizukota[m]>but when writing a package recipe in guile.... there is target, there are package transformation options like --with-c-toolchain, --target, --with-source
<mizukota[m]>i think toolchain packages are for guix recipes, and you need bunch of other packages to get same thing in profile
<morgansmith>I'm not sure what your point is here? That we don't need to fix arm-none-eabi cuz people should only use them in guix package?
<mizukota[m]>do fix it if you can, my point is using the whole power of guix if you were so powerful that you managed to install it
<mizukota[m]>those "just run configure/make/make install" things work everywhere else, on debian or fedora, which is much easier to have installed on hardware on in docker or somewhere else
<mizukota[m]>again the point of guix is to prevent such overlapping when you use things in /gnu/store instead of merging them into profile
<morgansmith>ok I've sent an updated patch which fixes some arm-none-eabi problems. I still need to look into the c++config.h issue. I guess I should also send in to openocd patch. Even if I don't understand it, it building is better than it not building
<nckx>Imagine parsing that with a regex or whatever vim uses.
<lfam>Vim paredit is rough enough that I don't recommend it to anyone that's not already stuck on vi
<Gooberpatrol66>I'm kind of curious about Android in Guix. So Anbox runs Android apps in a container. A lot of the need for this, I guess, is that Android apps try to search for files at certain paths that conflict with the GNU/Linux directory structure. But that's not really a problem if you package Android components for Guix. So it makes me wonder if you could run Android apps "natively" on Guix without using a
<GNUtoo>morgansmith: hi, that package supports only arm 32bit right?
<bonz060>morgansmith: thanks for the pointer. Let me have a look...
<GNUtoo>like you can't use it to cross compile an arm64 bit kernel?
<morgansmith>dunno. I just did: grep -r --exclude-dir=doc --exclude-dir=po --exclude-dir=tests --exclude-dir=.git "arm-none-eabi" .
<morgansmith>and then made sure everything that showed up still worked
<morgansmith>it supports armv6-m armv7-m armv7e-m according to the configure flags
<morgansmith>anyways, if I'm going to get any work done today I probably need to leave the IRC :P take care guys
<bonz060>morgansmith: I've had a look at the file you shared. That doesn't exactly help. What I'd like to do is to get /all/ the propagated inputs from the package, and then write to a file static file somewhere. Sth like this: https://paste.debian.net/1175001/ <-- that doesn't work though :(
<mbakke>bonz060: package->specification may return a different package than what was actually given as an input name, you should unquote the entire (map (lambda (input) ...) ...) block, and refer to (package-propagated-inputs this-package) instead
<efraim>My vim config doesn't do the indentation actually correctly, more of close enough
<efraim>I intend at some point to get the indentation into vim-guix-vim, just have to actually learn more vimscript first
<nckx>civodul: I'd like to close <http://issues.guix.gnu.org/21992>. You've added download size reporting when available, and after writing a similar ‘nar-size’ (decompressed) size I've decided it's not something I want. People care about the total additional space use, which we can't estimate due to local builds, not about some random substitutable subset. Make sense?
<nixin72>Hi, I'm looking to try out GNU Guix since the idea of having an entirely reproducible OS sounds amazing to me cause I like playing around with configs. However, there are a number of pieces of non-free software I want, like drivers for my hardware Discord, Spotify and some other stuff. I could use NixOS, but I also love the idea of my entire system being configured in Lisp. I love Emacs for this
<nixin72>reason, and I'd rather configure in Scheme over Nix any day. That being said, is getting non-free software going to be an issue in Guix? Of course I can be compiling from source and installing from zips, but who wants to do that for everything?
<lle-bout>civodul: FYI current core-updates introduces other problems with powerpc64le-linux-gnu but I'm still investigating
<joshuaBPMan>nixin72 It will be a bit tedious getting non-free software in guix. It is not officially supported. Nor is it considered proper to talk about it in the guix channel. I'm not bullying you, or saying you should not have asked that question. I am just saying, that if there exists ways to use non-free software in guix, then I cannot tell you how
<lle-bout>civodul: It can't compile Glibc 2.32 due to: configure: error: *** The compiler must support -mabi=ieeelongdouble and -mlongdouble simultaneously.
<nixin72>Okay, so sorry about that. I know GNU doesn't support or endorse it, but wasn't sure if it was okay to ask about here. I'll ask elsewhere. Thank you
<joshuaBPMan>nixin72 No worries. Best of luck! I personally use a thinkpad T400. It's a bit old, but works for most tasks that I have. THought I am not a gamer.
<nckx>nixin72: It's one of the trade-offs of using GNU Guix, if you assign non-free software a value greater than 0 (most of us don't, so it's not even an issue). That said Guix will not artificially limit what you do with it. You can write package definitions for whatever you like. We simply won't provide updates or any kind of support.
<nixin72>Honestly, 95% of what I use is free software already - I pratically use Emacs as my OS atm. Unfortunately having less tech-savvy friends makes it tougher to get them to communicate using open-source alternatives hahah
<lle-bout>nixin72: Signal and Matrix with Element have been pretty good with my non tech-savvy friends and they are Free Software, also GNU Guix packages Flatpak and there's some flatpaks somewhere for those. GNU Guix hasnt yet handled the npm eco-system with Electron onto which those two are based.
<joshuaBPMan>lle-bout My understanding is that npm software is really really hard to build from source. Lots of circular dependencies.
<cbaines>Flatpak indeed, the free software non-free software distribution platform (if that makes sense)
<lle-bout>joshuaBPMan: I would rather say the packaging practices of the eco-system really work against reproducible builds and happily download binaries from remote places without attaching any origin source code
<joshuaBPMan>lle-bout If you aren't already, then you should consider a job as a technical writer. I think you'd be good at it. :)
<civodul>bavier[m]: the UI looks quite nice though
<cbaines>bavier[m], maybe Guix can include the necessary hooks so you could install the guix-emoji package, and get output like that
<lle-bout>cbaines: It is unfortunate that some flatpak repos are distributing non-free software and I already argued against it to them but nothing to do I guess, nonetheless Element and Signal are Free Software and available as flatpaks :-)
<bavier[m]>cbaines: ooo, yes, that'd also open the doors for `guix-nyan` :)
<cbaines>lle-bout, well, for free software distribution, I'm not sure Flatpak has a great featureset, like I'm not sure how you build from source for example
<lle-bout>cbaines: There's many ways, Flatpak also supports OCI images so GNU Guix can be used for it too.
<cbaines>bavier[m], I was thinking one could maybe (ab)use translations to have an emoji locale or something, but I'm not sure how well that would work
<lle-bout>cbaines: Fedora builds OCI images for their Free Software only Flatpak repo
<cbaines>lle-bout, I quite like Guix's one way of building things, I'm not sure Flatpak makes building something from source as easy
<cbaines>(also, Guix doesn't yet produce OCI images, just Docker V1 images)
<lle-bout>cbaines: Flatpak's focus is not on a packaging/build tool, so that's normal I think :-)
<cbaines>lle-bout, I agree, but what I'm getting at is that lack of focus on providing users a way to effect change in the software they're using, is relevant when you consider distributing free software through it
<lle-bout>cbaines: I thought GNU Guix supported OCI, good to know it's only Docker V1 images.
<lle-bout>cbaines: I agree it comes off a little limited in thinking, they certainly consider with the distribution mechanism commonly used that users don't need to change the software - but what I am interested in with Flatpak is the sandboxing capabilities and those can be used without using the distribution mechanism as there can be "local" remotes from which you can install packages. GNU Guix could manage that local remote and allow us to
<lle-bout> launch sandboxed desktop apps with Flatpak (on a Wayland-only environment with the app using only xdg-portals and all for proper sandboxing)
<civodul>nckx: ah yes, mostly fixed by --cache-bypass-threshold \o/
<cbaines>lle-bout, yes, it would be really good to use the runtime isolation stuff.
<lle-bout>cbaines: I think that Flatpak when the eco-system has evolved towards it (Wayland, Portals, Pipewire, etc..) is the future for Linux secure desktop
<cbaines>lle-bout, you might be interested to know that thumbnail generation for nautilus (Gnome Files) happens in an ioslated manor, through bubblewrap
<nckx>civodul: ‘Mostly’? (I don't use the --cache... functionality myself.)
<mbakke>lle-bout: there is a mythical 'guix run' command (and patch) floating about which gives flatpak-like isolation for GUI applications
<mbakke>lately I've been considering the possibility of baking a container runtime into a guix profile
<lle-bout>native eco-systems in Rust and Go, what pleased me is that the Rust eco-system was growing under the AGPL license but I think it isnt for the good reasons.
<mbakke>nckx: thanks for the libreoffice reproducibility patch
<lle-bout>mbakke: that's cool! I am not sure what this will give, I have a feeling that this might have limitations but maybe not.
<lle-bout>mbakke: What I am interested in also is the ability to run two instances of the same applications with different runtime parameters, so I could install a "work-icecat" and a "personal-icecat" where both don't have access to the same data but still connect to the same Wayland server (when Icecat supports Wayland if not already).
<lfam>jonsger: No, I'm not using radicale. It was a test-suite dependency of vdirsyncer, which I am using. IIRC the vdirsyncer author was not very happy with the correctness of radicale, or of dav implementations in general
<mbakke>lle-bout: I also want that, and currently use a wrapper script for IceCat to achive a similar effect (without the isolation, of course)
<lfam>sneek: later tell jonsger: No, I'm not using radicale. It was a test-suite dependency of vdirsyncer, which I am using. IIRC the vdirsyncer author was not very happy with the correctness of radicale, or of dav implementations in general
<lle-bout>civodul: * powerpc64le supports IEEE128 long double libm/libc redirects when using the -mabi=ieeelongdouble to compile C code on supported GCC toolchains. It is recommended to use GCC 8 or newer when testing this option.
<lle-bout>mbakke: I think we should hardcode versions for all the tools used in bootstrap
<lle-bout>Right now it's "hardcoded" because we build bootstrap binaries once and never again but when you port new platforms it still uses latest versions which is not always good
<mbakke>lle-bout: will creating ppc64le bootstrap tarballs with GCC 10 do the job?
<lle-bout>mbakke: It will work better if these use Glibc 2.32 but that's only part of the problem - when we grow GNU Guix using gcc 5.5 (like current master), on powerpc64le-linux-gnu it can't build Glibc 2.32 using gcc 5.5
<lle-bout>Minimum version for powerpc64le-linux-gnu is gcc 6.2+ and even then, glibc 2.32 might require gcc 8, though they only recommend it so have to find correct build options.
<mbakke>lle-bout: but that is "just" a concern for an eventual Mes-based PPC bootstrap, right?
<lle-bout>With Glibc 2.31 and a single patch (--with-long-double-128 on bootstrap GCC and also during commencement) it worked OK, but I am afraid it will break again with Glibc 2.32 on core-updates
<lle-bout>mbakke: no, it's not using Mes at all now
<lle-bout>It works without GNU Mes, bootstrap binaries are just bigger
<mbakke>lle-bout: I mean that if we create new bootstrap tarballs on core-updates after the GCC 10 switch, then ppc64le-linux-gnu will "start" at glibc 2.32 and GCC 10, and not have to worry about other versions in the graph?
<mbakke>but admittedly you probably know better how the bootstrap works than me :P
<lle-bout>mbakke: currently make-bootstrap.scm creates gcc 5.5 tarballs, not gcc 10, it always starts at gcc 5.5