<tune>broke my install last night upon rebooting. I'll be back later with more info, but my computer won'y boot the ssd, keeps looping back to boot menu as if there's nothing to boot. Can't even get to grub. afk a bit
<mbakke>Oddly enough, the "/var/guix/profiles/system"-links appear to exist, since you could chroot using bash from the system profile.
<mbakke>Perhaps these two users simply never installed anything?
<tune>last night I was running updates via the full path to the guix "current" folder and deleting the guix "latest" folder, and then supposedly on reboot my path was supposed to fix itself (I was getting old updates due to latest being deprecated or something), but somehow I couldn't boot again after rebooting. Not sure if something I did was harmful.
<tune>Oh, yeah, I never using guix package -i or what, I specified everything in /etc/config.scm and just did system reconfigures
<axd-v>Quick update on my experimentation with libvirt. Everything that I wanted from VMs I now have on guixSD. I'm quite happy.
<vagrantc>axd-v: what method did you use for networking?
<axd-v>New question: does anyone connect their android device to their computer? I see some android packages in the repo, but most seem intended for android dev, and `adb` and `fastboot` are for rooting.
<axd-v>vagrantc: it's really dead simple. No bridge to set up with nmcli or anything like that. Just went to virt-manager network setting, set up a virtual network with pretty much all defaults that were already set, making sure to select NAT. It created a network, which I then instructed every VM to use and they just see it as a wired connection, even though guixSD using using wifi. All is happy.
<axd-v>vagrantc: tested with debian stable, ubuntu 18.04 and even win10.
<axd-v>didn't have to install or configure anything extra.
<vagrantc>axd-v: yeah, that's generally the easiest way
<vagrantc>you can't access the VMs from the network at large, but often that's good enough
<vagrantc>ACTION wanted to get macvtap bridges working, but had trouble
<axd-v>honestly I never thought I could be this comfy with guixSD/Emacs/EXWM/Spacemacs, but after a few hours of polishing my init.el equivalent in spacemacs, the system fits like a glove. More than that, like a third hand that I grew heh. If only we could get the latest qutebrowser packaged, it would be bliss.
<axd-v>vagrantc: I see, is that for a use case of running VMs on one machine and then using libvirt on another machine to access them over the network?
<vagrantc>axd-v: no, that's for, say, running a web server in a VM and having it accessible to machines other than the host machine
<mbakke>vagrantc: I use Open vSwitch for that, not in conjunction with libvirt though.
<axd-v>vagrantc: interesting, you were trying to set up a bridge for a wireless network on the host? Because I saw instructions given to me by another #guix member that let you set up a wired bridge which should work properly, but I don't know if it work for what you described.
<vagrantc>on debian, macvtap is one of those easy drop-downs in virt-manager ... but it wasn't available when i tried on guixsd
<axd-v>vagrantc: interesting, don't need that at the moment, but glad you found a work around at all. I'm out of my depth for these more involved setups. I just wanted a simple VM like what VirtualBox provides, and I finally have all of that working. Don't forsee ever switching from guixSD, other distros pale in comparison other than the lack of a few packaged softwares. Nothing that isn't addressable with a bit of work and time.
<vagrantc>yeah, i'm pretty impressed with guixsd too
<tune>https://paste.debian.net/plain/1029837 just got this at the end of my reconfigure... I notice "Could not prepare Boot variable: No such file or directory". I wonder if that's related to why my efi wiped out the guixsd boot entry before
<civodul>sdb: for "guile -s config.scm" to work, you'd need to add the right -L and -C, but it wouldn't be very useful
<sdb>civodul, thanks for the pointers. I used it as a "look at the problem from another angle" not really expecting it to work. Got useful hints multiple times when guix was not very verbose about the error.
<sdb>snape, now I made it a list. It still gives me the same error... hmm
<sdb>civodul, has anyone thought of modifying "guix lint" to be able to also guide in creating a valid config.scm?
<rekado>I have a question for other EXWM users: when opening a GPG encrypted file with Emacs the pinentry GTK dialog pops up and I’m asked to unlock my key, but I cannot type anything into that window. This works fine when I use “gpg --decrypt” on the shell, though, or when I’m asked to sign emails/commits.
<civodul>roptat: another idea (a bit crazy, so it shouldn't stop you from doing real things :-)) would be to use minikanren
<rekado>do other EXWM users have the same problem? If not, what are your pinentry settings?
<civodul>so we'd use, say, "stringo" to check whether a value is a string, *or* to generate a value that matches that spec
<civodul>not very useful for strings, but could be interesting in other cases maybe
<Rukako>civodul: is there any work on a static type checker? something like typed racket maybe? that would fit the whole contracts theme very nicely
<sdb>this is the relevant doc: tlp-configuration parameter: maybe-space-separated-string-list cpu-scaling-governor-on-ac
<sdb> CPU frequency scaling governor on AC mode. With intel_pstate driver, alternatives are powersave and performance. With acpi-cpufreq driver, alternatives are ondemand, powersave, performance and conservative.
<tune>roptat: sweet, it shows up now doing guix package -s. If I put it in my /etc/config.scm it says unknown package, failed to load. Do I have to store that environment variable somewhere that root will read it? where's a good place? can I manually edit /etc/profile?
<roptat>tune: I think you need to import (gnu packages mrosset)
<roptat>and you need to export GUIX_PACKAGE_PATH for root too
<tune>is that "import" thing the actual command to run? and I'm doing this via sudo, so how should I make sure that's exported for root?
<roptat>tune: import is for creating a package definition, but you already have one
<roptat>for sudo, I don't know, it's confusing for me
<rekado>tune: to use packages defined in the module “(gnu packages mrosset)” you would need to add the line “(use-modules (gnu packages mrosset))” in your manifest or system configuration before referencing any of the variables defined therein.
<Rukako>I remember reading about the typed macros thing
<Rukako>civodul: if there is any interest, I would not mind working on a static type checker for guile once gsoc is over
<Rukako>turnstile sounds too difficult for me though
<mbakke>tune: Did you figure out why GRUB failed to update EFI variables?
<tune>I've rebooted again since then and I don't know if it still happens
<brendyn>I'm getting these errors again running guix pull
<brendyn>cannot link `/gnu/store/.links/0mxym0vn0lvn6238g2965sdainrhyryz15rvdg1xkvmsncjncmsa' to `/gnu/store/w3jgj8466q0ji27h3848yhjm0vm5aa9b-python2-2.7.14/lib/python2.7/site-packages/pip/commands/download.pyc': No space left on device
<mbakke>I had to remove the "unpack" output to make it fit in a paste.
<pkill9_>./guix/store.scm:934:15: Throw to key `srfi-34' with args `(#<condition &nix-protocol-error [message: "build of `/gnu/store/dj3l4hwxzis6s6nz01z0lgjv762svv58-guix-daemon-0.14.0-13.7af5c2a.drv' failed"
<pkill9_>i think it's result of build error: configure: error: A recent Guile-SQLite3 could not be found; please install it.
<brendyn>I've got guix pull to complete successfully, but somehow it doesn't actually give me the latest guix. When I run 'guix package --show=linux-libre' it shows linux 4.17, whereas on my other computer and a few days ago I had 4.17.1. Somehow I've managed to downgrade myself
<nckx><brendyn> nckx: Can you try starting your system in a vm and seeing if it works. also test pcmanfm, thunar, etc and see it they all do it
<nckx>Reading that again: could you explain what difference the VM would make?
<tune>brendyn: maybe related to the latest to current change
<nckx>pkill9_: I manage CUPS entirely through its own web interface. I've never used any of the add-ons.
<nckx>ACTION gives adding Qt support to hplip a go.
<brendyn>pkill9_: last I checked the hplip package had a lot missing. I think I started editing to make a printer work but adding some pything deps resulted in a cyclic dependency. I don't remember much now
<brendyn>I think if you try building hplip and look ad the configure output you'll see lots of things missing and could start there to improve it. It was ages ago that I looked at it though so maybe its more complete now
<nckx>pkill9_: Aside from the systray, everything should work without Qt. I can certainly print on my HP through hplip without issue, and stuff like hp-levels works fine if only on the CLI.
<apteryx>Is there an easy way to print the definition of a shepherd service?
<snape>apteryx: there is 'guix system search', it gives the location of the service
<tune>I noticed that some emulators are packaged. They are of course free software, but it still feels weird. Don't the ROMs you play with them count as non-free software? I'm not sure if there's some reason they don't count. Or is this just not a concern since the ROMs aren't the thing being packaged?
<tune>bavier: which mailing list? any chance you can give me a link? I checked bug-guix, help-guix, guix-commits
<tune>I found a thread about MAME that seems related
<nckx>j3kyl_: Just paste that into your currently running terminal session(s). It will be set automatically in new ones.
<nckx><brendyn> nckx: I find guix quite slow for a package manager. 'guix package -s' is slower than any other package\\
<nckx> manager I've seen. It's even slower than searching the raw git repo with ag to find a package.
<nckx>Absolutely. Hence... fine, and not ‘great’. I use my own scripts for the same reason. I just meant that a few percentage points worth of optimisation won't make a meaningful difference, while slow compilation is a *huge* annoyance to many.
<nckx>To solve the ‘compiled Guix is still slow’ problem we should, as civodul once noted, stop using Scheme as a database & use an actual DB/cache. Maybe the fact that quile-sqlite is now mandatory anyway will encourage someone(TM) to implement this.
<nckx>(On the other hand, I do appreciate the peace of mind that whatever's in my git checkout is exactly what Guix will operate on. I don't want to have to run yet another command to invalidate the cache every time I save an edit. But that's stuff for the future.)
<brendyn>nckx: I'm interested in learning why it is slower though so I can understand guile and guix better. I would have thought guile could at least be as fast as scanning a text file
<brendyn>j3kyl_: If you do need that, it should go in .bash_profile, and then will take effect when you re-login/reboot
<grp>well, I'm currently using devuan and want to switch. Been messing with nixos for a couple of days. I don't like the syntax (c'mon, wtf, pointless semicolons everywhere...) and strongly dislike systemd
<rekado>grp: in Guix you get to swap the semicolons for paretheses. They are round.
<grp>nckx: you could say it makes more sense in terms of laziness, but other than that, it's fucking disgusting imho
<nckx>I was familiar with neither Haskell nor Lisp when I discovered Guix and I strongly agree that Scheme is much more to my liking.
<ProfessorDey>Hey chat, just dropped in because I'm having trouble compiling a disk image for GuixSD, it keeps complaining about a missing isci.ko module even though I've definitely set the SCSI and ISCI flags in the configuration. Does anyone have any ideas what the issue could be? If not, can anyone tell me how to modify the expected modules for the initramfs so it isn't required? I can get everything else compiled it
<ProfessorDey>seems, module wise, but I don't have any Intel c600 devices on the system I'm building an install disk for anyway, that I'm aware of.
<rekado>the “package” syntax just hides that from the user.
<grp>it's also great to blow away resources usage predictability
<ProfessorDey>rekado: I'm using a non linux-libre kernel due to the fact that the server I'm installing to has a nVidea north bridge that isn't supported by it, meaning I can't even use the install disk because that's connected over sata, via said bridge.
<rekado>ProfessorDey: how are you trying to compile the disk image?
<nckx>rekado: Yep. That's what I was half-remembering :-/
<grp>rekado: I'm aware of the license problem, however, it's only an issue if you intend to ship (prebuilt?) ZFS modules with the distro. Shipping build scripts that build from sources (or a package definition in this case) is not a problem AFAIK
<rekado>ProfessorDey: do you want to build an *installer* image or just a disk image of a GuixSD system?
<rekado>ProfessorDey: for building just a GuixSD system from a configuration file you would typically do “guix system build config.scm”
<rekado>once that works you can go a step further to build the desired target format.
<ProfessorDey>rekado: I was of the impression that they were functionally one and the same due to using guix. And in this case the issue is really just whether linux-libre contains the firmware for the nVidia MCP61, if it does I'm golden and am happy to use it, since it's just meant to be a build server. Don't know if the nForce2 devices have opensourced code powering them or not
<rekado>ProfessorDey: an installer image is a little different from a plain system configuration.
<rekado>ProfessorDey: it needs a few more things (like the cow-store).
<grp>ACTION would have preferred /gnu/store/package-x.xx-<hash> Makes for easier navigation, derivations are naturally grouped by name and if one needs to address derivations, doing /gnu/store/*c54iy/ is just as convenient as having the hash first
<OriansJ>grp: you can always make a patch and see if it gets accepted
<rekado>changing this would require countless changes to e.g. the reference scanner, the grafting code, … so a lot of work for a cosmetic change, which isn’t clearly an improvement.
<nckx>grp: That's one of those subjects that keeps coming up. I do agree, but it's very unlikely to change at this point.
<rekado>there are people who say that starting with the hash is best, because it allows you to disambiguate different packages much more quickly
<rekado>but personally, I don’t really care either way :)
<rekado>FWIW I started out thinking that having the hash later would be nicer
<bavier>A discussion of the benefits and drawbacks would probably be a good start
<rekado>one could also argue that it doesn’t matter and that one could even drop the package name and version from the directory name…
<rekado>everything under /gnu/store is not really meant for users (or developers). It’s just a cache.
<grp>the main benefit is: you can explore derivations easily while tab-completing packages names. I remember when I first tried to fix a nix pkg, I was trying to locate the generated derivation folder to check out it's structure and it was a pain
<nckx>The current <ignore nonsense>-<meaningful package name>-<version>/<meaningful path> also has its merits. Much easier to visually scan than a hash that moves around every row.
<rekado>ProfessorDey: is the installer image at all usable for you?
<OriansJ>in short it can be done but it would require someone to put in all of the work required and make sure there aren't any bugs introduced.
<rekado>ProfessorDey: if it is I would suggest using it to install a *minimal* default system first, and then to use “guix system reconfigure my-config.scm” with your changes.
<ProfessorDey>rekado: fair enough, in that case, is there something I can insert into a system/package definition that excludes the isci module from being checked for in the initramfs? even when the embedded platforms are removed, it still tries to create the initramfs so I assume there's a default that needs to be overridden. And no it doesn't even see the disk it boots from because it can't communicate with the north
<RetardedOnion>hi there. i am an arch user atm. i got interested in guix purely because of the build system. i got some questions before i slowly try to switch: 1) how upstream is guix compared to arch? 2) how fast are the updates to packages? 3) how can i easily find out beforehand if my hardware will work without nonfree-firmware? i am concerned about nvme drives, my audio (realtek s1220a) and my graphics card(rx 460). i dont really trust h-node since i know the
<RetardedOnion> gtx 780 does not work with a free gnu 4) can someone confirm pci passthrough via ovmf with qemu is working? 5) are there any drawbacks that i do not think about (other than the software availability with free software) 6) how far is plasma in going up? my main DE is kde. so would like to keep using it. 7) was this the right place to ask?
<rekado>I’m not sure about the module checker. Maybe someone else can chime in.
<rekado>5) you may have some problems that stem from installing packages into separate prefixes that you wouldn’t have on a system that installs everything into a global namespace. This can be annoying or require odd work-arounds.
<RetardedOnion>thank you for your answers. maybe i will install it on a spare hdd and find out. i just found out that my graphics card does require proprietary blobs. so i will be having a lot more hassle than i would like to have.
<pkill9_>nckx: i tried to test hp-systray but it still didn't run while i had the printer plugged in, but wifimenu starts when i add the python-pyqt input for me as well. Also it successfully printed the test page so hplip + cups works.
<pkill9_>this is the error it shows for me when running hp-systray: warning: No hp: or hpfax: devices found in any installed CUPS queue. Exiting.
<nckx>There's not a line of code to support it, so unless it works without distro help: absolutely not.
<OriansJ>I wonder if guix should consider having a seperate branch labeled stable for guix pull and a branch LATEST for current development; where the stable only includes things from LATEST that has passed manual testing.