<Kolev>rekado: I'm not sure. It might be building Telegram Desktop, yes.
<Kolev>rekado: Does "building ... drv" mean actual building, as in compiling source?
<ulfvonbelow>What's the Proper Way to simply ensure a directory exists on the root file system in my system configuration? I happen to need a directory that's guaranteed to be empty for something (so something like /empty).
<rekado_>Kolev: I totally understand the frustration. Perhaps it would be less frustrating if Guix had a way to tell us why it’s doing something unexpected.
<Ribby>Anyone know about (free) firmware. It appears that I need this after installing the driver.
<atomizedalex>I installed proprietary iwlwifi drivers for my wifi card
<atomizedalex>But I'm not a wiz with this. I followed the instructions from Daviwil systemcrafters page to install Guix with the Linux kernel rather than the libre kernel, so that it would work with iwlwifi
<Kolev>Sigh. Telegram Desktop keeps failing to build.
<apteryx>atomizedalex: hello! this channel is reserved to discuss free software; if you are having issues with proprietary software (which is not part of Guix), please seek guidance/assistance in that software space.
<atomizedalex>No I'm not having issues. I was responding to Ribby, pointing him to a resource that I used.
<vagrantc>free/libre firmware totally on topic, at least inasmuch as using it on guix
<atomizedalex>There are universal rules, and then rules are applied to concrete instances. This involves interpretation, which varies according to the interpreter. I was asking if what I said did infringe on the limits, and according to whose interpretation. Where is the rule posted?
<atomizedalex>The systemcrafters guy has contributed to Guix. Mentioning him seemed natural.
***califax- is now known as califax
<vagrantc>hmmm... tring to find some documentation
<AwesomeAdam54321>vagrantc: I remember that /topic of this channel stated that proprietary software was off-topic
<atomizedalex>I had tracked down that document as you were looking. I think that you were right in interpreting what I said as outside of the limits based on the "License Rules" section, "Information for practical use."
<atomizedalex>It would be helpful to have this stated more clearly upfront.
<vagrantc>probably worth bringing up on the list at some point
<vagrantc>gotta head out for now, but thanks for pointing out something that is either undocumented or at the very least, not trivial to find! :)
<atomizedalex>I agree with the aims of the FSF, in general terms, although my academic background leads me to see its approach as a bit Quaker--creating an island of purity with little influence on the political lifeblood of society. That of course means that there is an organizational difference and I might be more at home in a more catholic (universal) community with room for sin.
<vagrantc>or even a bug report to email@example.com
<vagrantc>you don't have to believe or agree 100%, just be willing to understand the boundaries :)
<oriansj>atomizedalex: one does not shift a political discussion by compromising core values.
<oriansj>and to argue that the FSF's puritan beliefs had little influence on the political lifeblood of society misses a great deal of the political reality of modern software.
<oriansj>but I will grant that guix might not hit the global use numbers of Redhat or Ubuntu or Android; but Nix and Guix are going to chance distros forever. In fact in some ways they already have.
<atomizedalex>I take your point and I appreciate programmatic points. I also appreciate the work of the FSF and the Guix developers (otherwise I would not have stumbled in here).
<MisterMentat>Is gfortran-toolchain supposed to *not* export libgfortran? And if so, what package can I get from Guix to get it?
<MisterMentat>After some digging, I found a gfortran installation in /gnu/store that has the libgfortran.so files but they don't seem to be exported from gfortran-toolchain. Is there some way to fix this? I'm new to Guix. (I do know scheme though.)
<apteryx>atomizedalex: hello! sorry, I was away for a bit and missed your replies. I think this policy comes from the GNU FSDG yes; and the commitment of GNU Guix to free software in general.
<apteryx>to be clear, steering someone toward instructions to install nonfree software is what went against it
<atomicalex>Yes, I understand; it is a central aim to make an operating system without proprietary black boxes. I share the committment, but mentioned nonfree blobs because I incline to jesuitical casuistry (which I won't do again here).
<civodul>i guess we should give it a try and see if there are corner cases or unintended consequences
<civodul>it's true that those (or native-inputs inputs) bits aren't pretty :-)
<vldn>mhh what for is the nix-daemon still used in guix? just for generating the hashstring+drvfile and navigating/creating the build processes? i mean the database api in guix store database is quite nice @ civodul, shouldn't be so hard to write a daemon replacement with guile-fibers or am i wrong?
<vldn>maybe someone knows in which specific place/file the nix-daemon is called from our guile scripts?
<sughosha>Hi, I have few questions regarding the Guix package manager. I would appreciate anyone for the help.
<sughosha>1. Is there a way to list system-wide installed applications? `guix package --list-installed` lists only profile's packages.
<sughosha>2. Is it possible to list files of an installed application?
<katco>hey guix friends! i'm trying to get a libvirt service to listen on a tcp socket. the docs for `listen-tcp?` say "You must set listen for this to have any effect.", but i can't find a `listen` parameter, nor a way to start libvirtd with `--listen`. any ideas?
<civodul>katco: hello! i think it's actually 'listen-addr', no?
<katco>civodul: hm, no i don't think so? that just tells it what address to listen on, but there is a `--listen` flag that enables listening at all
<katco>i.e. https://libvirt.org/remote.html " Note: it is also necessary to start the server in listening mode by running it with --listen or adding a LIBVIRTD_ARGS="--listen" line to /etc/sysconfig/libvirtd."
<jpoiret>mhmmm, i need some help on the guix bootstrapping process
<jpoiret>in build-aux/build-self.scm, we explicitely don't select (guix channels), but it is still somehow ends up inside the build environment of the derivation
<jpoiret>i say that because i added some code to (guix channels) that requires (guix git), in turn requiring (git object) which isn't available at this stage
<civodul>katco: oh, so could it be that we're just lacking that option?
<civodul>i've never used this service, so i'm just trying to guess :-)
<katco>civodul: i looks that way, but i wanted to check before i submit a bug!
<katco>in the meantime i'm wondering if i could work around it by passing a script into the service for its `libvirt` package
<jpoiret>well, if everything works fine, let's just ignore that
<leinad>Yeah, it works fine :) I just have the impression it steals a second or two of my boot time
<leinad>and was wondering whether I can do something about it.
<jpoiret>we start elogind manually rather than on-demand through dbus, and maybe there's a race between elogind registering to dbus and someone else asking for elogind on the dbus, leading to dbus trying to start it (again)
<jpoiret>although we haven't yet been able to see which program is the culprit
<acrow>leinad: I was able to avoid that message by putting elogind-service and the ssdm login manager together with xfce in my system configuration. The problems went away albeit because I had the flexibility to just make some different choices. Still, maybe there is a clue in there.
<leinad>I see... so maybe it's gdm itself which causes the race
<jpoiret>most of the shepherd services that rely on elogind should wait until it's fully started (written its pid file), and that happens after elogind registers on DBus
<acrow>leinad: that is kinda what I concluded but wasn't able to troubleshoot.
<acrow>jpoiret: I think those timing issues are difficult to resolve for all systems.
<ryanprior[m]>I'm having trouble with direnv installed via Guix on a foreign distro (my elementary OS laptop): when I try to run direnv it fails with an error like libc.so.6 - version not found
<vivien>Thank you acrow, it seems that I have a lot of libs to find!
<ryanprior[m]>But if I run `guix shell -C direnv bash coreutils` and then run direnv, it works fine. So it seems like direnv is picking up something incompatible from the base OS instead of from my profile?
<acrow>vivien: I got the same outcomes you did. Using guix size you can see that vips does reference glib-2. pkg-config may not dwelve deeply enough in a guixy world, no?
<jonsger>rekado_: it's a non-FDSG compliant package, so I obviously can not share the whole package definition...
<tanner40>Guix System newbie here - I see in my `/var/guix/profiles/per-user/me/` directory several symlinks with the prefix `current-guix-` and several symlinks with the prefix `guix-profile-`. What is the difference between these two types of profiles?
<jackhill>tanner40: hi, welcome to Guix! the current-guix- ones are what gets updated when you do a `guix pull` to get new package definities and guix code. The other one is for software you've installed with Guix e.g. with `guix install`.
<acrow>lilyp: I see how eternal vigilance is the price of liberty. Guix facilitates virtually limitless manipulation of the build process.
<tanner40>jackhill thanks! so does that mean guix itself runs in an environment defined by a current-guix- profile, and that all other software runs in an environment defined by a guix-profile- ?
<acrow>lilyp: The batik-all-jar was derived entirely from the Apache batik source package. I modified the build so tha the default guix ant build system target, 'jars', would yield the provided ant build target, 'all-jar'.