<OriansJ>Copenhagen_Bram: Screen is not a shell but a screen manager with VT100/ANSI terminal emulation <vagrantc>you can use tmux as a shell, but i've found the experience to be more hurtful than helpful <OriansJ>vagrantc: are you sure, you didn't mistake dash or busybox for tmux. As tmux is supposed to use your default shell? <vagrantc>OriansJ: screen and tmux are both valid shells on Debian ... but i wouldn't recommend it. ***anon is now known as Guest86455
<Copenhagen_Bram>Alright, I'll think about not using screen as a shell. But how do I reset my graphical session without restarting? <rekado_>Copenhagen_Bram: “sudo herd restart xorg-server”? <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 ***cd is now known as polyzen
<tune>so I'm thinking I can try to access my guixsd install from a debian liveusb via chroot and then run updates or see if I have to repair grub or something <tune>user@debian:~$ sudo chroot /mnt <tune>chroot: failed to run command ‘/bin/bash’: No such file or directory <tune>should I specify the shell differently? (since it's guix I'm trying to chroot into) <vagrantc>tune: it's a little tricky ... you need to specify PATH appropriately <vagrantc>tune: sudo chroot /mnt/gnu/store....bash-X.Y.Z/bin/bash <vagrantc>and then source /etc/profile or something from within the chroot <vagrantc>if there's a /bin/sh symlink in your the guixsd ... then something more like: sudo chroot /mnt /bin/sh <tune>ugh I have 5 bashs to choose from in the store <tune>0qcdnbs0qdls6g75b5aypd024ax2ldqn-bash gvwf71vddp8c1d7ydqg02p43mgdjrx6s-bash wj9ni83z23li82z6d2h2h8cn0qkqcw09-bash <tune>chsrhxr7qap5560nvrisw9yp7bqs2bmp-bash mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash <tune>I guess I'll check modifications dates with ls <tune>oh all the dates are january 1st 1970... heh <tune>whatever, I doubt an old bash will kill me <tune>user@debian:~$ sudo chroot /mnt /mnt/gnu/store/0qcdnbs0qdls6g75b5aypd024ax2ldqn-bash <tune>chroot: failed to run command ‘/mnt/gnu/store/0qcdnbs0qdls6g75b5aypd024ax2ldqn-bash’: No such file or directory <tune>can someone tell me what I'm missing here? <mbakke>tune: The third argument is relative to the chroot. So without the /mnt it should work fine. <mbakke>I suppose you could also use /var/guix/profiles/system/profile/bin/bash. <mbakke>wviana: Can you post the actual error message (unbound variable: something)? <tune>just removing /mnt from the previous said it couldn't execute binary file <mbakke>wviana: Thanks! The issue is that "/dev/sda1" should be quoted (as I did now), otherwise Guile thinks it's a variable name. <mbakke>Not sure why it says "config.scm:16" when it's clearly line 29, though. <tune>mbakke: there is some helpful info here, but I'm still getting SSL errors after the suggested export commands... :/ <tune>I noticed there is no .guix-profile in /root, though <tune>or in my normal user's home folder <mbakke>tune: That's odd. Do you have /var/guix/profiles/per-user/... ? <wviana>mbakke: Thank you very much, it was it. :D <mbakke>tune: Seems like something is fishy with your file system, but for now you can use those /var/guix/profiles/per-user/... directories directly, or create new ~/.guix-profile symlinks. <tune>the directories exist but appear to be empty <tune>root@debian ~# ls -hal /var/guix/profiles/per-user/root/ <tune>drwxr-xr-x 2 root root 4.0K Dec 31 21:17 ./ <tune>drwxrwxrwt 4 root root 4.0K Dec 31 21:42 ../ <tune>that bottom ../ is lit up green fyi <tune>and the dir for my user is the same <mbakke>tune: Those folders should contain "guix-profile-NN-link" symlinks pointing to profile generations. <mbakke>Which file system is this? Did you try to fsck? <tune>not sure how to answer that first question... I'm on a debian liveusb and I mounted /dev/sda2 to /mnt and /dev/sda3 to /mnt/home (root and home respectively) then chrooted in <tune>it's ext4 if that's what you mean <tune>can you give me the fsck command to try? <mbakke>So, the `~/.guix-profile` symlinks are missing from the home partition, and the guix profile generations are missing from the root partition. <mbakke>Somehow I doubt this has anything to do with file system corruption, but you can try to `umount /dev/sda3; e2fsck -y /dev/sda3`. <mbakke>Repeat for /dev/sda2 (probably have to exit the chroot). <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 <tune>not even getting to GRUB had me worried, though. not sure if GRUB or my EFI partition were somehow harmed or something <tune>otherwise I should be able to get to GRUB and boot a previously working generation <mbakke>tune: I see. Perhaps we can figure a way to restore boot without resorting to chrooting and reconfigure. <mbakke>Can you check that /mnt/boot/efi/EFI/grub contains "grubx64.efi"? <mbakke>Assuming your EFI System Partition is mounted at /mnt/boot/efi, that is.. <tune>there's nothing in my /mnt/boot/efi folder (no EFI) <tune>my efi partition might be mounted in a weird spot, that gave me some trouble during my original install <tune>let me check my config.scm quick <tune>(mount-point "/boot/efi") <tune>I think that's the relevant line <tune>type vfat, listed by uuid <mbakke>vagrantc: Bah, possibly a kernel issue. Are you able to test with an earlier kernel? <mbakke>Perhaps there are fixes available upstream. <mbakke>tune: Can you mount that partition at /mnt/boot/efi for inspection? <vagrantc>mbakke: earliest i can easily test is 4.16.x <tune>ah now there is an EFI folder in efi <mbakke>vagrantc: Alternatively, a newer elfutils (I see 0.172 is out :-)). <tune>It does contain grubx64.efi <vagrantc>mbakke: the guixsd machine is linux-libre 4.16.13-gnu, and the Debian machine is 4.17-rc7 <vagrantc>mbakke: probably going to wrap up for the day soonish ... but maybe tomorrow <mbakke>tune: Great. What size is the grubx64 executable? <tune>120K according to an ls -hal and a du -h <mbakke>tune: Okay, mine is 220k, but that's probably because it includes crypto modules. <mbakke>Now can you check if /mnt/boot/grub/grub.cfg seems good? <tune>mbakke: it's certainly there and has a bunch of entries. anything I should look for in particular? <mbakke>tune: Not sure, I was "hoping" it was empty/missing, or otherwise corrupted. <mbakke>tune: Try `mount -t proc /proc /mnt/proc` from a non-chrooted shell. <mbakke>tune: I didn't catch entirely how the system was rendered unbootable, was there a shutdown during reconfigure or something? <tune>reconfigure went fine (seemingly) <tune>I don't really know what went wrong at all <tune>just went for a routine boot and then I couldn't even get to GRUB, it just sent me back to my system's boot menu to try to boot from a different drive <tune>s/routine boot/routine reboot <tune>every time I chose my ssd it would send me back to the boot menu as if there were nothing bootable on that drive <mbakke>tune: Can you paste the output of `efibootmgr -v` from the live environment? <tune>I don't seem to have that command <tune>any idea what package would have it on debian? <mbakke>Try `apt-get install efibootmgr`. <tune>that's apparently not a package <tune>hang on, I might just have to do an apt update <mbakke>tune: Great. You probably had one in the store already, that you could use as well. <mbakke>tune: Thanks! The GuixSD entry should be on that list disguised as "grub" (we should change that..), but it's conspicuously missing. <tune>meaning my grub was wiped out? <mbakke>tune: Well, from the EFI variables on your motherboard anyway. <mbakke>But let's try to add it manually. <mbakke>ACTION studies efibootmgr documentation, again <mbakke>tune: Try this command (make sure to replace /dev/sda1 with your EFI System Partition): <mbakke>efibootmgr -c -d /dev/sda1 -L "fixguix" -l '\\EFI\\grub\\grubx64.efi' -p 1 <tune>looks like fixguix is at the bottom now <mbakke>tune: Excellent, now run: efibootmgr -n 0019 <mbakke>That should tell your mainboard to run that GRUB the next boot. <tune>okay so now should I reboot? <mbakke>If it doesn't boot, you should at least be able to see and maybe even modify it in BIOS. <tune>holy cow, you really saved my hide. I had my second monitor off and it defaulted to that one, so I didn't see the whole process, but it indeed brought me to my familiar guixsd login <tune>anything else I need to do now or am I basically back to normal? <mbakke>tune: The next reconfigure, if successful, should add yet another (identical) boot entry and tell your mainboard to use that. <tune>sweet, I'll get on that then <mbakke>You may want to keep that "fixguix" entry around in case of emergency ;-) <tune>yeah, I don't mind keeping it around haha <mbakke>(it won't delete itself, so you'll find it in the boot menu :-)) <mbakke>Well, unless your mainboard flips again and dispels all foreign EFI entries. <vagrantc>well, elfutils 0.172 build went fine on x86_64 <wviana>Is there a default pasword for a user that I've not set the password in installation ? <mbakke>vagrantc: Great, please send in the patch when you're done with it! ;-) <vagrantc>mbakke: it's a typical two-liner .. updated version and hash <mbakke>wviana: You should be able to log in (at a console) as root without password, and fix things from there. <mbakke>vagrantc: We don't discriminate! <vagrantc>i really need to learn how to do updates without running guix pull ... i've toyed with GUIX_PACKAGE_PATH or whatever, but don't always manage to get the right modules or something <mbakke>vagrantc: Have you tried out the "pre-inst-env" script? I think most developers simply use that with a "forked" Guix. <mbakke>I.e. "./pre-inst-env guix build elfutils" and so on. <vagrantc>i think last time i tried i failed to generate the pre-inst-env thing <mbakke>"guix environment guix", then "./bootstrap && ./configure --localstatedir=/var --sysconfdir=/etc && make" should be sufficient. <vagrantc>i think the manual section describing that was a bit less explicit <vagrantc>a fair bit of the manual, which pretty good, assumes a lot of existing knowledge <mbakke>Yes, there is a lot of room for improvements there. <Copenhagen_Bram>hello guix, how do i add ca-certificates for curl? i can't download weechat scripts or send an email <vagrantc>and, probably like many people, when i'm trying to do something and the manual is lacking, i still often want to finish whatever i'm trying to do rather than update the manual <mbakke>Copenhagen_Bram: Are you on GuixSD or a foreign distro? <vagrantc>dangerous rabbit holes to get lost in :) <mbakke>vagrantc: Hah, I never thought of that, but have definitely been there too. <mbakke>Copenhagen_Bram: I just realized this is a recurring topic (SSL in weechat), and I don't think it's resolved yet. <mbakke>Copenhagen_Bram: The problem is that libcurl (in Guix) has no built-in default certificate store, and thus the programs using it needs to set their own. <mbakke>Unfortunately few programs provide mechanisms for that. <mbakke>And IIRC the mechanism in Weechat doesn't work for plugins. <mbakke>vagrantc: Bah, I've come across that too, but never got around to file a bug report (typically because I'm busy fixing the substitute server... :-P). <mbakke>Copenhagen_Bram: I'm not sure, can you try the help-guix mailing list? It would be nice to have it "documented". <mbakke>I've patched some libcurl users before to respect $CURL_CA_BUNDLE like the `curl` tool, but it would be great to fix it in libcurl proper. <mbakke>Copenhagen_Bram: Haha, unfortunate catch 22! But I know there are multiple Claws users on the list, so surely it has something. <mbakke>Copenhagen_Bram: Just to make sure, do you have 'nss-certs' in the (packages ...) list of your system config? <tune>dang it, my reconfigure is failing on building mumble again. I think this means it's still trying to reconfigure the wrong thing <tune>The following environment variable definitions may be needed: <tune> export PATH="/root/.config/guix/current/bin${PATH:+:}$PATH" <tune>related to this, I think <tune>Building from Git commit 7af5c2a248b6c229187fc850517c84b0917c452b... <tune>is this old or new? this is was my 'sudo guix pull' defaults to <tune>seems to build from the same commit when doing /root/.config/guix/current/bin/guix pull <tune>but this time it's compiling things again instead of saying "nothing to be done" so maybe something is different <mbakke>Copenhagen_Bram: I'd check the Claws documentation and see if there's a way to set '/etc/ssl/ca-certificates.crt' as the CA store. <mbakke>tune: commit 7af5c2a248b6c229187fc850517c84b0917c452b is the very latest master branch. <tune>thanks for the confirmation <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 <vagrantc>i eventually manually set up a bridge through network manager and used that <vagrantc>although macvtap has the bug/feature that you can't talk to the host machine from the vm, just to the rest of the network <axd-v>vagrantc: not familiar with macvtap, but it in essence automates what creating a bridge with a wired slave with network manager does? <vagrantc>mbakke: i've never gotten around to trying openvswitch, but toyed with the idea now and then <vagrantc>axd-v: no, it's more like sneakily injecting network packets directly on the ethernet layer <vagrantc>axd-v: probably wouldn't work with wirless either <vagrantc>mbakke: presuming i get this elfutils update tested, do you want me to CC you on the bug report? <mbakke>vagrantc: Feel free to do that, although the response time will probably be the same (maybe even worse) :-) <mbakke>ACTION wants to get Ganeti into Guix. <mbakke>I'm heading off, gn peeps and bots! <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 <sdb>I need help with my config.scm <sdb>Im trying to define a custom meny-entry so that I can dual-boot with guixsd and ubuntu <sdb>here is the relevant part of my config.scm <sdb>I searched the internet for up-to-date working config.scm's with menu-enty defined but found none. <sdb>(use-service-modules desktop pm xorg) <sdb>(use-package-modules certs gnome) <sdb> (bootloader (bootloader-configuration <sdb> (bootloader grub-bootloader) <sdb> (target "/dev/sda") <sdb>guix system reconfigure complains this way: <snape>please sdb, could you use debian.paste.net to paste your config? <sdb>gives this error: config11.scm:52:3: error: =>: unbound variable <sdb>hint: Did you forget a `use-modules' form? <sdb>guix (GNU Guix) b4eae997fe5b928f179c34d281e9f2c3eccd3670 <sdb>pulled succesfully yesterday <sdb>got some hints to what is wrong by passing it to "guile -s" <sdb>last line of that is: config11.scm:12:0: config11.scm:12:0: In procedure private-lookup: No variable bound to #{% <menu-entry> abi-cookie}# in module (gnu bootloader) <snape>sdb: menu-entries is a list of meny-entry elements <snape>whereas in your code it's just one element <snape>it should rather be something like that: (menu-entries (list (menu-entry ...) (meny-entry ...))) <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? <roptat>civodul: do you think it would be a good idea to check whether the user passed a list of the correct type to menu-entries, file-systems, packages and services? <roptat>I think it would have avoided some troubles for sdb :) <civodul>roptat: i do have an idea, which would be to attach "contracts" to fields <civodul>i we can do this at some point, maybe after 1.0 though <roptat>like, changing define-record-type* to add something like a type to each field? <roptat>or maybe simply a procedure that returns a boolean <roptat>like (define-record-type* <something> (name something-name (default "unknown") (contract string?)) <roptat>and then, on invocation of something-name, it would throw an exception when contract returns #f, right? <roptat>that we could catch in (guix ui) and print hint for <roptat>I think that's something I can do :) <civodul>we could add type hints or contracts for all the system configuration things <civodul>the devil is in the detail though :-) <civodul>it cannot be just a predicate, otherwise all we could say is "wrong type" <civodul>whereas we'd like to say "got X, expected Y" <civodul>another thing worth investigating is whether some of these checks can be performed at macro-expansion time <roptat>maybe (define-record-type* <something> (name something-name (default "unknown") (contract string?) (hint (lambda (got) (G_ "got ~a, expected a string")))) <roptat>(well not exactly that, but this kind of thing) <civodul>yeah but we don't want to carry UI stuff in the record type definitions <civodul>where string/c is equipped to report errors <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 <civodul>in minikanren "predicates" can typically take two values <civodul>if you pass a placeholder, minikanren "generates" all the values that would satisfy the predicate <rekado>(that sounds like Haskell’s quickcheck) <civodul>it's logic programming, so like Prolog <civodul>value generation in QuickCheck is a bit more ad hoc, i think <civodul>an interesting application of this is "programming by example" <civodul>there are crazy talks by Will Byrd on this topic <civodul>roptat: again, i'm not saying this is something we should do for real because it's not even clear whether it'd be useful, but it's interesting <roptat>civodul: that's crazy, I love it :D <roptat>but indeed I don't know whether it's going to be useful for us <civodul>so i guess first step would be to add a very simple contract system <civodul>and the use add a 'contract' property to 'define-record-type*' <civodul>we would be able to use that from the start, and then we can always improve the contract system later <snape>sdb: I have a meeting during the whole day, I'll try to help when I find some time <sdb>snape, no problem. :) <sdb>does anybody have a valid config.scm that enables berlin.guixsd.org AND/OR has tlp-service-type with configuration? <tune>how hard is it to package something? getting sick of walking over to another machine to use deluge <tune>and it's been 6 months now <tune>fyi I have almost 0 knowledge of programming <efraim>Actually looks like I haven't configured my tlp service <sdb>efraim, thanks, looking now... <roptat>tune: once you've cloned it somewhere, you can use GUIX_PACKAGE_PATH=<directory where it was cloned> <roptat>I mean, export the environment variable <roptat>then guix will know about it and you can install this version of deluge <roptat>you can also ask the author of these recipes to send them to guix-patches@gnu.org, so we can add them to guix itself <tune>I only spoke to the author via this channel <tune>roptat: can I just do 'export...' in my shell or do I have to put it in a file somewhere? <sdb>I just got the guix-configuration to validate! Hooray! <sdb>And the menu-entries menu-entry! <sdb>now only the tlp-configuration refuses to validate <sdb>this works (service tlp-service-type <sdb> (cpu-boost-on-ac? #t))) <sdb>this does NOT: (service tlp-service-type <sdb> (cpu-boost-on-ac? #t))) <sdb>oops this does NOT (service tlp-service-type <sdb> (cpu-boost-on-ac? #t) <sdb> (cpu-scaling-govenor-on-ac '("conservative")))) <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. <sdb> Defaults to ‘disabled’. <sdb>I have tried to give it a list and a string - both fail. <roptat>tune: just export in your shell, or add it to .bashrc <roptat>sdb, what about '(conservative) ? <sdb>roptat, config11.scm:63:12: error: extraneous field initializers (cpu-scaling-govenor-on-ac) <sdb>I worked around the bug/problem by switching to this (my goal is to limit the freq to max 800): <roptat>oh, that's governor, not govenor <roptat>and '("conservative") should work <sdb>roptat, Ah, ok, will test now... <sdb>roptat, (cpu-scaling-governor-on-ac '("conservative") = valid <sdb>roptat, not valid without the "". gives: guix system: error: Invalid value for field cpu-scaling-governor-on-ac: (conservative) <sdb>Now my config is completely valid, hooray. Thanks for all the guix <3 <sdb>roptat, what are you called in the mailinglist? im swedebugia there... <sdb>running guix system reconfigure with --max-jobs=4 gives quite a messed up output where it seems that multiple processes tries to write progress to the same line. <civodul>Rukako: static type checking is more involved, but i'd like to have something like Racket's Turnstile someday, maybe <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>mbakke: not really, except that there was a boot-related error at the end of my reconfigure <tune>I get the feeling that without your fix I would've put myself in the same position again <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 <rekado>brendyn: what file system do you use? <civodul>Rukako: heh sure, it's quite a bit of work though :-) <civodul>Turnstile might be the "simplest" approach... <mbakke>brendyn: Does `df -i` report that something is full? <brendyn>/dev/sdc1 61054976 12030212 49024764 20% / <rekado>brendyn: maybe try “sudo tune2fs -l /dev/sda4” or similar, to see if you ran out of inodes. <mbakke>tune: That error looks scary... Can you confirm that /sys/firmware/efi exists? <mbakke>And that "secure boot" is disabled in your firmware? <tune>well, I've booted since then <brendyn>Seems like there are plenty of inodes <brendyn>I ran guix gc --optimize, and it's outputtin hundreds of similar lines, unable to link <mbakke>tune: The issue here is that GRUB fails to update the boot settings in your mainboard firmware. Don't know what may be causing it. <mbakke>Oh no, seems we missed the latest 'NSS' on staging. I'll update it before the next evaluation. <civodul>brendyn: note that the "cannot link" message is not an error <civodul>you have to have a very big store or bad ext4 parameters to hit it, though <civodul>also, note that you probably do not need to run 'guix gc --optimize' <mbakke>I'm trying to pull the latest commit (3f311279), but building compute-guix-derivation fails with Guile-Sqlite3 not being found. <mbakke>This is from 7af5c2a248b6c229187fc850517c84b0917c452b, so very recent. <civodul>dunno, depends on the ext4 parameters <brendyn>My store is 120GiB wit 27 million files <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. <mbakke>civodul: Any idea what's going on with Hydra? <mbakke>I'm getting 502 bad gateway for just about anything. <pkill9_>guix-daemon builds now, but guix pull fails with a different error: Exception thrown while printing backtrace: <pkill9_>In procedure private-lookup: No variable bound to define-module* in module (guile) <mbakke>pkill9_: That's a known bug in Guile. I believe a workaround for it was recently committed, so if you try again, you should get the fix once it succeeds. <snape>mbakke: what commit is supposed to fix it? <mbakke>Although, it could be for some other bug (I haven't been paying attention lately) :-) <snape>mbakke: oh, very nice, thank you! <nckx>Writing mail on GuixSD, & my emacs' GTK file chooser now lists every thinkable VFS in the left-hand pane: blkio, cgroup, cpuset, efi, perf_event, pts... <nckx>‘Attached, please find my scheduler settings.’ This is mos def a recent regression. Anyone else notice it? <efraim>Same, I wonder it's related to having gvfs in the os config <civodul>nckx: there was a discussion on help-guix on this topic a while back <nckx>efraim: Good guess. I'll take a look at that. Thanks. <nckx>civodul: Oh. I totally missed that. <nckx>I've been avoiding the ML recently, but ‘a while back’ sounds older than that. <civodul>mbakke: it should work now; hydra-server had gone crazy <brendyn>sudo guix pull works, but guix pull doesnt, is there a way to switch to the version of guix that root has with my regular user? <nckx>ACTION also uses i3, so that's probably the same bug, but I could have sworn it was fine at least a month ago... <brendyn>nckx: Yeah I discovered this months ago. It just started happening for some reason I haven't manage to figure out <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 <rekado>I’m not using i3 and I can’t remember a time when I didn’t see this. <brendyn>I guess many people see it and just live with it :( <nckx>brendyn: My slothy netbook struggles to run VMs that *don't* start X, but I'll give it a try. Just not now. <tune>oh I have that same issue in i3 <tune>I guess I wasn't sure if it counted as a bug <tune>I'm pretty sure i experienced it in thunar, but I don't have thunar anymore. I have pcmanfm right now and it definitely happens. <nckx>I'm... really 97% sure I would have noticed this sooner if it was a regular occurence. I'm starting to doubt my sanity now. <nckx>The GTK file chooser is the only ‘graphical file manager’ I ever use, though, so maybe it was previously unaffected for some reason? <nckx>Bah. This is going to be tedious to bisect. <tune>speaking of the gtk file chooser, anyone else have issues with it losing settings? I always check 'show hidden files' and 'sort folders before files' but they get unchecked if I restart icecat <tune>I had this issue on some other distros as well, I think... <civodul>nckx: i think the GTK file chooser has always had this problem <civodul>the thread above has quite a few hints already, let's just fix it gentlefolks :-) <nckx>tune: Sounds like that other permabug, ‘GLib-GIO-Message: 16:56:24.921: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.’ <firewall`>/msg civodul Pour mon probleme de processus qui ne se termine pas je pencer mettre les 'pid' dans un fichier et ajouté un 'atexit', ta une mellieurs idée ou je part la dessus ? <brendyn>Yeah i know I'm just not an experienced programmer or anything so I have no idea how to debug such a thing <nckx>I use that left-hand pane every time I attach a file from the browser, so I'm actually pretty certain it didn't happen previously, but I agree that we should just fix it. <rekado>I didn’t know that this represents a problem. <efraim>I see it on icecat as well, and libreoffice <rekado>there are many design decisions in many programs I need to use that I don’t understand. This was just one of them, in my opinion. <tune>It's ugly, so I can see people not agreeing on it being a problem for that, but the fact that it only happens in i3 definitely screams bug. <efraim>Also on enlightenment, maybe one of the icon sets that xfce or GNOME bundle? <tune>I'm using non-default theme and icons and experience the issue <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 <civodul>brendyn: are you sure you're running ~/.config/guix/current/bin/guix? <brendyn>nckx: You would not have all the config in your home directory interfering. Once I ran my system in a vm and didn't have the bug sometimes <nckx>brendyn: Interesting. TBH I'll just move ~ out of the way then, much faster than trying to boot a VM. <brendyn>That's weird. why is my guix pointing to /home/b/.guix-profile/bin/guix instead of /home/b/.config/guix/current/bin/guix? <vagrantc>hrm. lately ssh-daemon no longer starts at boot on guixsd... <rekado>brendyn: did you install “guix” into your profile? <brendyn>Yeah but its the older version. ill try '/home/b/.config/guix/current/bin/guix package -u guix' <civodul>brendyn: you shouldn't install guix in your main profile <civodul>otherwise you quickly end up with chicken-and-egg problems <brendyn>bash: /home/b/.guix-profile/bin/guix: No such file or directory <brendyn>There is now output. I've never heard of hash before <vagrantc>mbakke: thanks ... i'll try and see if it's the same issue for me... <nckx>pkill9_: What exactly do you mean? We currently don't build hplip with Qt support, so there's probably no way to make it work without editing the package. <pkill9_>running `hp-systray` says it needs pyqt <pkill9_>how do you add a printer so you can use it in print dialogs? ***Guest12551 is now known as apteryx
<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 <j3kyl_>wow I discovered what I was doing wrong <j3kyl_>%desktop-service must be inside an (services ) <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? <bavier>tune: and the free emulator is a good place for people to develop free software on top of <tune>You could maybe argue that if someone were to make their own homebrew games for an old console, they could then play them in an emulator, but I get the feeling that's not happened too much. <bavier>tune: this topic has been hashed out a lot before, and usually doesn't get far. If you'd like to discuss more, I'd suggest reading some of the previous ML threads and replying there <j3kyl_>hey I just did sudo guix pull and it recoommend to export PATH="/root/.config/guix/current/bin${PATH:+:}$PATH" <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 <brendyn>j3kyl_: Which bit don't you understand? <j3kyl_>brendyn: I had to reboot guixsd I literally did not read what you said while on that <brendyn>j3kyl_ | hey I just did sudo guix pull and it recoommend to export PATH="/root/.config/guix/current/bin${PATH:+:}$PATH" <nckx>j3kyl_: If you rebooted, PATH should now contain ‘/root/.config/guix/current/bin’ (you can check) so the point is moot :-) <brendyn>If that line is needed, it should go in .bash_profile, however I suspect it isn't actually needed <nckx>j3kyl_: My pleasure. I enjoy helping folks have a great Guix experience. <nckx>That sounded more... marketing-speak than intended. <nckx>brendyn: No idea. I wonder if Nix uses a cache nowadays, and how it compares to Guix otherwise. <nckx>(Not that this will teach you anything about Guile, mind you.) ***snape` is now known as snape
<brendyn>nckx: why Wouldn't it teach me about guile? <j3kyl_>done. GuixSD is now my daily driver replacing Debian! Just a few packages lacking, but nothing that I could build my own scm packs!\\ <nckx>brendyn: The Nix language implementation is nothing like Guile, is all. <brendyn>nckx: Oh, I thought you mean learning why guix is slow <pkill9_>should cups be added to %desktop-services? seems like a desktop service heh <apteryx>autossh seems broken, it just shows usage <nckx>(It's basically a one-liner but depends on some neurotic clean-up commit I made.) <nckx>Some tools insist on Qt 4 (others support 5) which might be a blocker... <pkill9_>how do i apply that to my guix? i gues you clone the guix repo and do something <nckx>‘curl $URL | patch -Np1’ IIRC. <nckx>Although if you don't have a git checkout and don't know how to bootstrap + use it & don't think it worth the trouble I'd understand. <nckx>I'll just post it to guix-patches. <pkill9_>it's simple enough to create a new package that inherits it and adds that as an input <pkill9_>i suppose you also gotta relpace the input for hplip <nckx>Whatever you feel comfortable with :-) It's a trivial change indeed (just add python-pyqt-4 to the inputs) but seems enough to make hplip blurt graphical dialogues to my screen. <pkill9_>yeah if it works for you then it probably works <nckx>pkill9_: Well, hp-wificonfig works, I can't test hp-systray without a (physical) HP printer so I don't know if it does. <pkill9_>how do you modify guix and then temporarily use that modified guix to build the package? <nckx>s/works/is now like all graphical & shit/ <rekado>pkill9_: the preferred way is to get a copy of the Guix code, configure and build it, and then use “pre-inst-env guix” instead of “guix”. <nckx>pkill9_: If your comment about ‘replacing input’ was about replacing cups' hplip input, don't bother. That's not required to test the GUI. <rekado>“pre-inst-env” (from the code directory) is how you can use your modified Guix. <pkill9_>nckx: why have you modified cups-filters instead of hplip? <pkill9_>oh i think i'm just reading the patch wrong <pkill9_>yeah that part belongs to the beginning part, my bad <nckx>That would've... invalidated some assumptions. <nckx>Hmm. Is there an equivalent to --with-input=... to add an input without replacing another? I could've saved pkill9_ a lot of time if that were true... <pkill9_>nah there isn't, i wanted that a while back <pkill9_>it would be trivial to add i would think, it could be called '--add-input' <pkill9_>also --with-input replaces all inputs in the dependency graph <pkill9_>i.e. all the inputs of the package's dependencies <nckx>...riiight, but... that wouldn't be relevant here. Adding an input to *all* dependencies is a weird enough use-case to say ‘you're on your own, write some code’. <nckx>Recursively replacing them is awesome. <pkill9_>yeah it's not relevant, i was just thinking out loud lol <nckx>Yeah, re-reading that you were basically agreeing with me so never mind my ranting. <nckx>I haven't used Nix in... wow. It's been a while. <grp>last sentence including "from" <pkill9_>i noticed that the nix package has been updated. Assuming that it's been fixed, does it use the nix substitutes? I don't think it does because it's built to use guix's store <nckx>grp: No, I de facto switched from Nix to Guix long ago. <grp>nckx: then, s/impossible/possible ? I mean, it doesn't make too much sense to me <grp>you switched, but wouldn't if that were possible? <rekado>grp: “if Guix had no way of rewriting dependencies recursively, it would not have been attractive to leave Nix and use Guix” <nckx>grp: It makes sense to me. I never would have switched from Nix if it were impossible to recursively replace inputs like I was used to doing in NixOS. <rekado>grp: Guix *does* have this feature, so there are no regrets :) <grp>oh, I thought you meant "impossible in Nix" <nckx>Thanks rekado, and indeed! <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>yeah, no worries, I'm a lisp advocate <rekado>grp: you need to know that systemd has quite a few features that the shepherd obviously doesn’t have. <grp>I haven't really got to install guixsd yet. Hope it has ZFS modules... or I'll be in for a bumpy ride until I get them done <rekado>there are no ZFS modules, though I suppose you could easily package them. <grp>like? cgroups management? <nckx>I wonder if Nix makes more sense to one familiar with Haskell. <rekado>nckx: it does not, to me at least. <rekado>I wrote and read a lot of Haskell before I dropped everything for stacking parentheses. <nckx>I don't mean to FUD, but wasn't there something about the Linux ZFS licence that was... controversial? <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. <nckx>grp: Hehe. My first naive question to this very room was ‘I don't get it, how can Guix work without a very lazy language?’ <nckx>Turns out, it somehow does. <grp>nckx: well, to be honest, laziness is irrelevant unless you are doing flow control or using silly algorithms <rekado>ProfessorDey: can you share more about how you are trying to do this? <rekado>laziness as in “delayed evaluation” is what we use in Guix as well. It just doesn’t have to be built into the language. <nckx>Yeah, that was before I read about staging. <OrangeShark>laziness is great to avoid unnecessary computations or representing infinite lists and such <nckx>Just don't make an error. <rekado>in Guix package expressions the inputs are delayed. <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>Hm, that's probably not super-useful without the talk. I can't find the paper... <rekado>it links to a bunch of opinions on this, including the Software Freedom Conservancy which states that Ubuntu violated the GPL by distributing the ZFS binary. <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 <nckx>grp: I hope it's readable. <nckx>Hard to tell if you already know what it says. <rekado>ProfessorDey: sorry, I can’t help you with non-free software. Do you get the same error with linux-libre? <bavier>I wonder if "#:substitutable? #f" would work for the ZFS case <ProfessorDey>rekado: do you know what the equivelant command would be to compile that? Not that familiar with GuixSD yet <rekado>bavier: I don’t know, because I think it would mean that a user would be violating the GPL when using “guix system” to share the binary system image with others. <nckx>bavier: Also, we wouldn't be able to provide ZFS-capable installer images. <rekado>bavier: I guess they can already violate licenses by just shipping binaries, so maybe it’s not too different. <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>OriansJ: unlikely for something as fundamental as that. <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>we’re also using this property to make the reference scanner faster. <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>1) what do you mean by “how upstream”? <RetardedOnion>rekado: changes made to the source before they are distributed <rekado>2) this varies wildly dependent on how many people care about certain packages. Updates are made by people who care. <rekado>We try to keep packages as upstream intended. <nckx>OriansJ: It can be done but the advantages aren't as clear-cut as advocates seem to think. And I started out as one. <rekado>We apply patches to ensure that things can be built on Guix. <ProfessorDey>rekado: I've found the page about the initrd so hopefully I can find a fix that there. Thanks for your help regardless <rekado>6) packaging KDE isn’t finished AFAIK. I don’t know if people work on this right now. <efraim>i believe kde is partially held up by qtwebengine <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. <nckx>pkill9_: Oh, that's the same error I got. I assumed it was just because I had no HP printer plugged into my laptop (I use a network print server). Did you? <nckx>pkill9_: Thanks for testing! <pkill9_>GuixSD makes managing the system soooo much easier <nckx>I like to temper the expectations of new users somewhat (they'll face plenty of challenges due to GuixSD being so ‘different’), but hell yes absolutely. <nckx>ACTION can't wait to pave over the last FreeBSD box with GuixSD. Almost there. <RetardedOnion>ACTION wants to have a guy that creates a guix installer that has proprietary blobs inside since pretty much no modern gpu/wifi card works without prop blobs <OriansJ>RetardedOnion: nothing is stopping you from forking guixsd <nckx>Wow. I look away for two minutes. <RetardedOnion>OriansJ: chill. first plasma, more interested users. i will think about it <rekado>ACTION has a modern Wifi card that works with linux libre. <snape>ACTION wonders which one is it <snape>civodul: in theory, <guix1>/build-aux/hydra/guix-modular.scm could return a guix modular derivation for a guix that is different than <guix1> right? <civodul>snape: that's definitely what it does <civodul>specifically, it returns a derivation of the guix specified by ARGUMENTS <snape>Yes, but in fact that guix is <guix1> <snape>because there is only one input per spec, right? <snape>that could really be the case if we had more than one input allowed <snape>is my understanding correct? <civodul>basically what guix-modular.scm does is the same that 'guix pull' does, or "make as-derivation" <civodul>that is, it uses an existing Guix installation to build a new Guix <snape>yes, I read about 'make as-derivation' today :-) nice <civodul>ideally it requires only basic features of the existing Guix <civodul>snape: BTW, really great you're diving into Cuirass :-) <snape>:-) the patch is arriving soon! <pkill9_>strangely searching 'cuirass software' and 'cuirass linux' doesn't turn up much <rekado>pkill9_: Cuirass is a system to help us build Guix packages continuously as the source repository of Guix changes. <rekado>it is a bit more flexible than that, but that’s the main purpose. <rekado>it allows a user to add specifications that describe what git repository to track, and how to generate build jobs. <rekado>Cuirass generates these build jobs according to the description periodically as the git repository changes, and executes them. <rekado>we use Cuirass on berlin.guixsd.org as a replacement of the Hydra software. <rekado>Tatiana is currently working as a GSoC student on a web interface for Cuirass. <snape>Hydra was built for Nix (in C++ and Perl) <rekado>I have a question about the message “substitute: updating list of substitutes from…” <rekado>first: is it fine to get rid of the “substitute: ” prefix? <rekado>the second is about ways to make it less confusing. <rekado>it prints this line multiple times because the substituter is invoked multiple times with different arguments. <rekado>can the substituter be invoked once with all arguments instead? <bavier>the "substitute: " prefix does seem redundant <rekado>it’s because the substituter is a separate process and the daemon indicates that this message comes from the substituter; but I think the message does not need it. <civodul>rekado: i trimmed the message a bit recently, commit 2bf9351e311cce0004756890b93f50693f133bb6 <civodul>the "substitute:" prefix comes from the daemon <civodul>the repeated invocations come from (guix grafts) <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. 
