<a_e>Can you not use the way back machine to load exactly the url you needed?
<NiAsterisk>i want to avoid to "hardfork" the downloadpage of unfonts to put them on a server in my control because I don't like such approaches.. maybe I find some distro or content network somewhere with the unfonts and unfonts-extra
<NiAsterisk>but: sure, i know how it works :) but I'm not sure if the file url would be catched by the guix downloader or, like in the case of a simple wget of the file link, catch a text document. I'll just have to try.
<Jookia>civodul: Oh, I also found out that falling back in init doesn't give a bournish shell, and that the (mount) command fails to mount btrfs. Unsure why, but it always give an Invalid device error (not sure the exact message)
<civodul>if 'statv' existed, maybe we could do something...
<Jookia>civodul: I might submit the LVM support if I can clean it up, then a patch to hack to just open all mapped devices at boot regardless of their use. As hacky as it is, it might be useful upstream as a stop-gap until we figure out a better way to handle block/swap/filesystem devices
<Jookia>civodul: Note on LVM support patch: It doesn't require changes the old patch required for the initramfs, it's self-contained
<civodul>Jookia: sure! i don't promise to review it thoroughly before the release, because we're getting late already ;-)
<rekado>I'd actually like us to release more often. Every time core-updates is merged another patch release, or something like that.
<Jookia>One problem with redoing the dependencies for block/swap/filesystem devices is that it'd probably require adding another guix-configuration option and deprecating the old ones, still allowing their use. Does Guix have a way to handle deprecation?
<Sleep_Walker>no GNUnet support for package distribution as GSoC this year?
<rekado>The nfs man page says that caching of file attributes is enabled by default with a minimum of 3 seconds. That should be sufficient to save on communication with the NFS server in the case of building a union for a new profile generation.
<NiAsterisk>Sleep_Walker: should the GsoC be listed on the Guix page, a link to the gnu.org gsoc page?
<SusWombat>Im just interested. I dont really care for steam on guix.
<Jookia>SusWombat: Steam downloads its own updates, avoids system packaging and also download others applications. In Guix, things tend not to run unless you patch them. Patching proprietary software is somewhat impossible
<SusWombat>Jookia, oh well im gonna try first in the vm then. Maybe i dont get Ts3 to work at all
<Jookia>It's also good practice to abandon these things even if it takes years
<SusWombat>Jookia, like i said its not possible atm. But i agree partly i guess. Aslong there are free alternatives which are somewhat on par
<Jookia>Neat! You might have a good chance of running it then :)
<SusWombat>Yeah but i need to first find out about that "needed" prop stuff first
<Jookia>SusWombat: On a technical level I think it's possible to package skype and/or teamspeak3 since I've seen NixOS do it, but if you're up for a small challenge I'm sure it wouldn't be that difficult, though none of us would really test it or use it. I wonder if it's even right to talk about it here? Unsure.
<SusWombat>Jookia, i ofc sont expect anyone to test or use it :)
<Jookia>SusWombat: Another experiment that would be worth doing is running these systems in a container running another distro
<SusWombat>Jookia, yeah but you have seen my horrible hardware ^^ or is the overhead really that low?
<Jookia>SusWombat: FWIW I'm running NixOS on an ARM board with probably less brute power than your machine with a container running OpenVPN which I'm using as an IRC proxy. Containers aren't full emulation or even require hardware virtualization (which I don't have)
<Jookia>SusWombat: I'm not exactly sure what the process is. All the packages are kept in one source tree which means people can easily bump them and test them, but I imagine as we get more packages people will have to stay on top of updates
<SusWombat>Jookia, well i dont mean i wouldnt update them.
<Jookia>NiAsterisk: for now you could just 'guix download' it and wait until civodul is around to discuss making the downloader more tolerant
<NiAsterisk>i have my ~/resources/ and it updates git checkouts, at some point I will try to get a bash script thing to check on updates of packages I cntroibuted to guix
<SusWombat>Every month or so i try to get into tilling :/
<Jookia>SusWombat: Hehe :P I have a backlog of photos I need to process anyway, so it wouldn't happen. Though once I get GuixSD on this machine I'll probably shove screenshots and photos of my setup in everyone's face
<NiAsterisk>kde plasma 5.5.5 is really good though, if one dislikes twms
<Jookia>If you have patience waiting a few days for a compile isn't that bad
<SusWombat>NiAsterisk, well as of know its not even safe im going to use guixSD at all (need to see first) but yes i would like to look at your list
<jmd>Strangely, after I changed the package definition and run guix build I don't get the complaint bout invalid checksum that I expected.
<NiAsterisk>currently: fix gnunet-gtk, fix lispf4, (both not really things I would recommend atm), a list of ones I am more familiar with: psyced, perlpsyc, and their dependencies. gnunet-dev, rust, rust imports (cargo), namazu, toxic, qtox, tox, anjuta-ide, tor-browser librefied, omiro, ricochet, utox, retroshare, torbrowser-launcher, onionshare, tails methods of ram erasing and similar ones, xonotic, cuberite,
<NiAsterisk>arphicfonts, git-daemon procedure for system.scm/confic.scm , equal services for some other packages in this list, awesome-wm, panaopticon (which requires rust cargo), pybitmessage (at some point there will be setup.py with 0.6.0 release, or I will contribute it so i can package it), that's the current list i think.
<SusWombat>NiAsterisk, sadly besides tox. I dont use any of these i dont even know the most
<mark_weaver>sorry, I guess I don't sufficiently understand what you're doing, so never mind me :)
<chewieQC>rakado: I think you can configure the linux kernel to cache things in ram
<SusWombat_>Ok so before installing guix. Is there a way to install an irc client in the live usb envoirement?
<mark_weaver>the thing is, given that the filesystem is read-write on the server, and NFS doesn't know about the restricted nature of the writes done to /gnu/store, it might not be okay for it to assume that the cached data is valid for purposes of implementing stat(2)
<lfam>Is anyone else having trouble importing and exporting archives since we starting grafting? I can send the archives to the remote machine, and they end up the store, but the remote machine still wants to build from source rather than use the substitute in its store
<mark_weaver>I know because I ran "ps auxww | grep git" while 'hydra-eval-guile-jobs' was running, and that command line includes the git revision. it's still in the scrollback buffer of window 2 of the screen session on hydra.
<a_e>suitsmeveryfine: I tried to set up an unencrypted /boot with an encrypted /.
<mark_weaver>petter, suitsmeveryfine: in cases where the GRUB from Guix will be used to boot the system (e.g. when not running Libreboot's own GRUB), I guess the Guix GRUB configuration needs to be modified to open the luks volume?
<mark_weaver>rain1: if you set yourself up to run guix from a git checkout, modify the code in there, and run "./pre-inst-env guix system reconfigure" as root from that directory, it will build a grub.cfg according to your changes. however, be warned that unlike almost all changes to guix, messing with grub can render your system unbootable.
<a_e>So as soon as nothing moves any more, just type your password, and things should get going again.
<mark_weaver>(although with some minor difficulties, you should be able to boot GuixSD manually by typing commands at the GRUB prompt, either the GRUB that GuixSD installed if it works, or else from some other working GRUB, e.g. from the USB installer
<suitsmeveryfine>a_e: yes, I know. It's a bit annoying, but having to enter the password twice is even more anying
<a_e>suitsmeveryfine: Yes, follow your fine guide :-)
<mark_weaver>suitsmeveryfine: if, like me, you end up wanting to *always* use the guix from your git checkout, then you can arrange for that by making ~/.config/guix/latest be a symlink pointing to your built guix git checkout.
<mark_weaver>suitsmeveryfine: sudo ./pre-inst-env guix system reconfigure
<mark_weaver>suitsmeveryfine: regarding my suggestion about ~/.config/guix/latest, a symlink like that needs to be done for every user that should use that copy of guix, so normally that includes both your normal user account and also root.
<mark_weaver>suitsmeveryfine: if you make those symlinks for both your normal user account and for root, then "sudo guix <anything>...", including "sudo guix system reconfigure", will use that copy of guix.
<suitsmeveryfine>very good. I'll try to set this up when I've got this new machine to boot up.
<mark_weaver>I should mention that "guix pull" also creates (or overwrites) that symlink to point to an automatically-built copy of guix in /gnu/store/
<suitsmeveryfine>ah, so I should never run guix pull in that case, but only git pull, as we talked about the other day
<mark_weaver>the only caveat is that if your git checkout gets into a bad state, then 'guix' may not work properly as long as those symlinks in place. it will only work as well at that git checkout works.
<suitsmeveryfine>mark_weaver: shouldn't these instructions be added to the manual you think?
<paroneayea>luckily I had a pdf of the talk because they had 0 adapters for my 2 different display output options!
<mark_weaver>so that's the tradeoff. but in my experience, it works quite well, and in the worst case you can always remove the symlinks.
<paroneayea>remember when it was the mac people who always needed the dongles at conferences? those were the days
<civodul>lfam: i just noticed that the Perl replacement breaks 'make check TESTS=tests/packages.scm' (rebuilds the world)