<zybell>for the log and snape in the morning:generic solution:a daemon uses ever unix-sockets,and a symlink points clients to the current. That socket however is private,between daemons and daemon clients. Every daemon runs a daemon client,that in turn opens the poblic interface of the daemon and interconverts public and private protocol. The private protocol (additionally to the commands from the client daemons) contains commands for initiating <zybell>switching,that are sent by daemon only. <snape>zybell: I'll think about it. good night! <vagrantcish>hrm. libvirt is looking for a qemu build that no longer exists <vagrantcish>is this potentially another "must reboot to take effect" problem? <vagrantcish>ACTION wonders if there's a technical reason not to do /gnu/store/PACKAGE/VERSION/HASH instead of /gnu/store/HASH-PACKAGE-VERSION ... beyond the overwhelming powers of momentum <mbakke>vagrantcish: Perhaps the XMLs generated by libvirt includes the absolute store path to a garbage collected qemu? <mbakke>I don't remember the libvirt commands to dump the XML. <vagrantcish>mbakke: ah, seems to use a newer qemu with a newly created system <mbakke>vagrantcish: We've had similar problems with e.g. `cgit`, which would embed an absolute perl in generated scripts IIRC. <jaxara>Hey everyone. So it seems like 0.14 has come out a few months ago.. is there a new release coming up? I read up a lot on this distro and kind of want to install it on my hardware. I have a laptop with a libre wifi card, so linux-libre kernel should be good. I already got it basically isntalled in virtualbox,but now I want to do it properly and set up disk encryption etc. <jaxara>I also wanted to ask why does guix seem to take so much much longer than apt, pacman, dnf, etc. ever did? Even if it saying that it is using the substitutes, it still takes a really long time. Is this normal and is it ever going to get faster? I'm just amazed as to how long installing something as simple as emacs can take while most operations like this don't take over a minute on other distros. <vagrantcish>manually putting /run/current-system/profile/bin/qemu-system-x86_64 into the .xml file it works like a charm. <mbakke>Hello jaxara! I think there will be a new release in a month or two. But installing with 0.14 should work too -- you'll get the latest version as soon as you run `guix pull` and upgrade the installed system. <vagrantcish>so libvirt needs to be patched to use the relevent symlinks <mbakke>vagrantcish: Yeah. Perhaps hard-coding `/run/current-system` is fine in this case. Provided the libvirt service includes qemu in the global profile. <mbakke>Or, it's probably better to leave that to the user. <mbakke>So they can use a custom qemu easily. <mbakke>jaxara: Regarding the slowness of `guix pull`, it has a lot to do with a weakness in the Guile 2.2 compiler. It used to be faster :-/ <mbakke>vagrantcish: Yeah, PATH is empty for Shepherd services unless specified. <mbakke>Great. Patches are even better! ;) <vagrantcish>notably, i'm like three layers deep in bug reports here ... i wanted to start a debian vm to compare against the same software in guix <jaxara>mbakke: thank you for the answers. So after a guix pull, the release will be up to the current development version? Do you expect the guile compiler to improve? I'm just surprised it is as slow as it currently is. I still don't know how complicated the job of guix package are, but every other package manager that I've used was like multiple times faster at installing things. <vagrantcish>jaxara: every other package manager doesn't instantiate the entire graph of dependencies necessary to build the software... <mbakke>jaxara: `guix pull` updates the package definitions only (as in `apt-get update`). Then you can `guix package -u` to upgrade all your packages, and `guix system reconfigure` to upgrade the system. <jaxara>vagrantcish: well here is precisely the place where I'm ignorant. Will have to learn about the difficulty of this. If there are substitutes already available in the repos, will guix just quickly install those? I have found that it still does many many steps referencing all kinds of packages, and I don't really understand why there are so many steps if the package should already be a pre-built binary. <jaxara>mbakke: How come guix pull seems to have a different database for every user? So to update the packges of the user, I need to first use `guix pull` and the `guix package -u`. But if I want to update the packages of the root user or the system I first need to run `guix pull` as the root user? Also what happens if I install for example `tlp` as a user. Will it just work as normal as if it is installed for the system? <mbakke>jaxara: Each user being able to use a different version is a feature :) <jaxara>mbakke: I had tried to include the tlp into the services to be launched by shepherd, and while I can see that tlp is running, I can not see a way to querry it as a user. It's not even anywhere in the path. Am I supposed to manually find it somehow? <mbakke>And yes, things will work identical when installed as a normal user. I only have a handful "system packages". <mbakke>jaxara: If you think tlp command line tools should be available when included as a service, can you file a bug report? It's a simple fix. <mbakke>I don't use TLP so I don't know anything about it. <mbakke>In the meantime, you can simply install the tlp package as your user. <jaxara>mbakke: thanks for clarification. Another question: does `guix system reconfigure` user the root user's guix's database's package definitions or has its own? <jaxara>mbakke: about TLP: would there be any redundancy if I have any program listed in both services/packages for the system and at the same time installed as the user? <jaxara>mbakke: I just thought that if TLP is running as a service then it must be installed, and if it's installed, I should be able to interract with it beyond saying start or stop to the shepherd daemon. <vagrantcish>i didn't think services could run as the user ... e.g. screen lockers need setuid and such <mbakke>jaxara: Any `guix` command will use the package definitions of the current user. Only root can do all the necessary actions for `reconfigure`. <vagrantcish>jaxara: i don't have tlp installed in my user profile, but by default, it's in my user's default PATH <mbakke>jaxara: If TLP includes tools for querying, it makes sense to include them in the global profile. <jaxara>mbakke: so the root user will need to have run `guix pull` before doing a system reconfigure? <mbakke>Oh, sounds like TLP is already in the global profile then. <vagrantcish>jaxara: maybe you don't have /run/current-system/... in your PATH? <vagrantcish>yeah, i pretty much never update root's profile, only using sudo -E ... granted, i still feel pretty new at all this <jaxara>vagrantcish: so you enabled the TLP client in your system profile, but not your user profile, and you still have tlp in your user's path? <jaxara>mbakke: thanks for explaining. Do you think we could ever expect guix to get close to the speed of the conventional package managers? <vagrantcish>jaxara: i must say, many times a package update of one thing will pull in and install or build lots of seemingly unrelated things ... it's a bit much to get used to <jaxara>vagrantcish: is that because some of the dependencies might have also been updated to a slightly higher minor version as well? <mbakke>Re: TLP, sounds like we should make the service "install" it to the system profile, no? <jaxara>vagrantcish: does guix reuse the same versions of a package, or is that rare to have when every package can be using any version it precisely needs? <jaxara>mbakke: that's how I thought about it intuitively. At the moment one would need to have it listed for both the services and the system profile? I just don't see how it makes sense to have either one without the other. <mbakke>jaxara: The "version" identifier in Guix is mostly cosmetic. <mbakke>Regarding services, it's optional whether to add them to the system profile. <vagrantcish>jaxara: it can even be the same version, but built against newer libraries <mbakke>You'll find there are a lot of "rebuild cycles" in Guix. <mbakke>Very recently all graphic stuffs were rebuilt (mesa etc) on the 'staging' branch. <jaxara>mbakke: what do you mean by rebuild cycles? Like building the same version of a program against newer libraries like vagrantcish mentioned? <jaxara>When do you think this project will hit a 1.0 and can start market itself towards more of a production type use which would create a greater community around it and help polish it even more in return? <mbakke>Some distros "cheat" by allowing you to upgrade something without rebuilding everything that depends on it. Guix enforces that relationship. And has a different mechanism for "cheating": grafts, where rebuilding everything is too expensive. <jaxara>Also how would the current project's community feel if there was a derivative made that didn't follow GNU's FSDG in order to make it obvious to people how to install proprietary software or other freedom encumbered stuff using guix? It would be anti-thetical to FSF's vision but it would help guix adoption for people that have started to use linux but still rely on some non-libre software. <jaxara>I guess stuff like firmware-linux is the biggest detriment to people. It even keep people from using debian, even though they made it trivial to install proprietary components. <vagrantcish>nix might be a better fit that guix ... unless you really like guile <jaxara>Also, is FSF's relationship to GuixSD similar to Canonical with Ubuntu and RedHat with Fedora? <vagrantcish>ACTION actually likes guix because of the focus on user freedoms <jaxara>vagrantcish: well I like guile actually. I'm a big emacs user so the more lisp in my life, the better. I like the fact that I should be able to arrange even init scripts in scheme. <vagrantcish>ACTION is finding it a bit of a steep learning curve <jaxara>vagrantcish: I care about the freedom aspect, but I also want to not be the only one with freedom. I think guix needs to get out in the open so that people will use it and it will bring more contributors which will help make the project more mature and streamlined. I can't see how that can be done with the mainstream linux community if not a single proprietary component can be installed. Libre by default is great, but some people still <jaxara>...worse-that-ideal software, so it would make it easier for them to transition to a fully free system, if the only thing that was holding them back would go away (i.e. inability to continue using their proprietary program). Over time, I'm sure the guix community would force them to illiminate even those last bits of proprietary control in their life, but not everything can be done at once. Baby step are sometimes needed, and as I found <mbakke>jaxara: It's pretty easy in GuixSD too, to use third party firmwares and stuff. But you'll need to use vanilla Linux and create packages for your firmwares (blobs or not). <jaxara>...privacy, baby steps is how it seems to develop. <vagrantcish>guix is amazingly easy to install out-of-tree software <vagrantcish>ironically, it might even be easier to install some non-free software on guix than many other distros :) <jaxara>mbakke: I know, I've come across some people's githubs with configs to get iwl intel wireless drivers to work on guix. I just wonder if there was a community that's part of the guix greater community that helped people use guix with the proprietary components they aren't willing to let go, would that be good or bad for the project as a whole. <vagrantcish>as long as it does the right thing with a standard build system... <jaxara>vagrantcish: you mean like the package recipe definitions are easy to make for custom proprietary stuff on demand? <jaxara>vagrantcish: so you're focused on libre right now. Are you using a librebooted motherboard or at least corebooted? <vagrantcish>i've got a librem, but running debian on that... the one i'm running guixsd on doesn't seem to require any non-free firmware <jaxara>vagrantcish: I picked up an X230 recently and want to make it my primary machine. I should be able to get Heads+Coreboot on it from my research. Still stuck on getting a raspberry pi to use for flashing. <vagrantcish>heh. just figured out how to flash with raspberry pi for the veyron-speedy/asus-c201 <jaxara>vagrantcish: librem from Purism? Nice! I saw that they have a sale going on for the month of May. <mbakke>vagrantcish: What was the problem with librem? Intel GPU? <vagrantcish>jaxara: yeah. i've mixed feelings about purism, but overall can't say they're worse than any other vendors <mbakke>vagrantcish: Say what? I have a c201 laying around. <vagrantcish>mbakke: problem is the librem is my main debian system, and i'm mostly a debian developer. this guix stuff is new for me <jaxara>mbakke: ME still has a 90 kB blob after the me_cleaner finishes. It's the only essential parts for cpu initialization, but it is signed with intels key and can't be replace as of now. <jaxara>vagrantcish: are you running guix on debian or guixsd? <mbakke>vagrantcish: What are you running on the C201? <vagrantcish>jaxara: i experimented with running it on top of debian in a virtual machine, but i've mostly been running guixsd ... there are some annoying issues that are just better integrated with guixsd <mbakke>I flashed Arch, and then tried to boot a custom kernel but failed miserably. <vagrantcish>mbakke: kinda sorta running debian on it ... but not very succesfully <vagrantcish>mbakke: lots of bugs ... in #linux-rockchip there's someone who's working on porting u-boot to it <mbakke>Ooh, u-boot sounds great. I'm willing to sacrifice mine. <mbakke>I just got a black screen on everything I tried. <vagrantcish>my main problem was eMMC ... but i suspect that was from an ancient libreboot build <mbakke>Is it possible to request substitutes for a foreign architecture short of cross-compiling? <mbakke>Apart from i686/amd64 and similar. <vagrantcish>i was curious how possible "guix system init" would be for a foreign architecture <vagrantcish>huh. on thinking of guix in debian again... the bootstrap binaries may not be an issue so much, since everything the debian package would install can be built from source <jahb>builder for `/gnu/store/zpx6x9j3fhy8dcikmxhiycgjrikqwb51-unzip-6.0.drv' failed with exit code 1 <jahb>ERROR: In procedure scm-error: <jahb>invalid build result (#<derivation /gnu/store/p7gcgia69lwl74pgg55v8rrf12fqxwv2-compute-guix-derivation.drv => /gnu/store/vx7apy452mi0wnpjyvzwy2q1mdmkqlyw-com <jahb>pute-guix-derivation 3dbc960> "") <vagrantcish>jahb: i've seen a few of those, and simply re-running has worked sometimes ... which seems... not great, but i don't decipher guile tracebacks well <jahb>vagrantcish: i'll try again then (and --keep-going to see what happens) <davidl>Do anyone have a working mpd service? I have to start it as my normal user. <davidl>I get pa_context_context connection_refused messages <str1ngs>seems like it can't connect to pulse audio? <catonano>I decided to upgrade the packages in my profile and now Nautilus is building <catonano>mbakke: thank you for repairing Icecat. The experience is so better now ! ***MinceR_ is now known as MinceR
<nee``>Is there some way to debug why a shepherd service that I'm writing isn't starting, like see the exit code and stderr? /var/log/shepherd.log doesn't seem to have that info. And shepherd just hogs 100% CPU trying to restart the service infinitly. <davidl>nee``: strace herd restart myservice <davidl>nee``: for example strace herd restart mpd (as regular user) gives last line: +++ exited with 1 +++ <nee``>Thanks, that gave me a couple of pages of output I'll look at it now. <nee``>I don't see any outputs related to my service outside of the inital args listing though, there are only logs about shepherd itself. <davidl>nee``: hm, alright. I don't know much about this stuff. Maybe if your service has it's own process after you start it with shepherd start myservice, that you can find it's pid with ps aux | grep myservice, and then tail -f /proc/pid/fd/{0,1,2,X} to get some info. ***Apteryx is now known as apteryx
<mbakke>nckx: Using `man -E utf8` works around the man bug. <mbakke>Wait, never mind. I was in a profile that does not reproduce the bug. Progress I guess. <mbakke>Gotem. Installing `groff` resolves it. Now to find the reference. <mbakke>Oh no. It works with `groff` in PATH, but not `groff-minimal`. <jahb>vagrantcish: ha! fail was because /tmp is mounted noexec. <jahb>ACTION puts two thumbs up <civodul>mbakke: i've just started full core-updates on berlin, let's see how it goes! <mbakke>By the way, I can't `guix pull --branch=core-updates`, but have been too lazy to file a bug report. <civodul>well i'll try that later, already enough bugs to deal with :-) <civodul>efraim: didn't we discuss a patch long ago to allow guix-daemon to perform armhf builds on aarch64? <civodul>i thought we had something like this but apparently not <efraim>Yes, but my minimal testing of it didn't have it working <efraim>I don't remember if it was or just a 'look at the code for i686 on x86_64, it should be about the same' <civodul>i was thinking we could use the overdrives for armhf as well <efraim>It should work, they're not ThunderX-s <mbakke>I've figured out the man/locale/duplication issue. It needs "preconv" which was not in groff-minimal. Further, it doesn't even try preconv if it's not in PATH; now to find out how to embed an absolute reference instead. <zybell>nee`` the -f flag to strace is a great help <mbakke>civodul: Two problems: one is that `groff-minimal` lacks `preconv` (easy fix), the other is that man-db checks for preconv in PATH regardless of whether it has an absolute reference. Didn't start on that yet. <civodul>double-check what "guix size groff-minimal" says before & after the preconv addition <rekado>I’m still busy debugging this annoying circuit. <mbakke>I think we've had that man issue since introducing "groff-minimal". <mbakke>Preserving the "preconv" executable adds ~0.1 MiB to the groff-minimal closure.