<goglosh>one thing I like about guixSD is that it is simple ***ttuegel_ is now known as ttuegel
<davexunit>does anyone happen to know of a (free, of course) multi-user music streaming daemon + client? <davexunit>mpd may be controlled by any number of clients, but they all manipulate the same state <davexunit>and it doesn't stream without having to use icecast or something. <dmarinoj>Ampache is pretty nice, my dad runs it on our server <davexunit>I've heard of ampache, but it looks very old and written in php <davexunit>ideally there would be a daemon that spoke some sane protocol that any sort of client could connect to, not just a web client. <dmarinoj>Last update was 2014, it looks pretty sleek actually <dmarinoj>But yeah, if that is what you want mpd is better <davexunit>every client operates on the same global state of what is playing <davexunit>ampache looks *much* better than the last time I looked at it. <dmarinoj>Yeah, it's nice. There is an android client too if you are into the botnet <davexunit>I'm just not eager to run another php application <davexunit>I have 0 confidence in php application's to not have huge amounts of security issues ***anthk_ is now known as anthk
<anthk>idk if it's a Trisquel error or a GUIX one <anthk> loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed. <davexunit>it's a nasty issue that we're trying to make sure never happens again <alezost>anthk: a workaround is to "export LC_ALL=C" <anthk>alezost: I already did that, don't worry <anthk>statically linked binary, with emacs/vi clones. Useful with glibc breaks <davexunit>what I'm doing on an ubuntu/guix machine is unsetting LOCPATH entirely, ensuring all my guix software is post-glibc-2.22 upgrade, and trying hard not to mix ubuntu things with guix things <anthk>"Solution: unset LOCPATH and say goodbye to locales for Guix-provided <anthk> packages (setting LOCPATH=$HOME/.guix-profile/lib/locale would break <anthk> all the distro-provided programs), or use exclusively Guix-provided <anthk> programs, or use the “C” locale. <anthk>in my case using tmux from Guix with LOCPATH set up aborted <mark_weaver>we have a plan to fix this, but it will take a week or two to build out and deploy <anthk>btw, how is this bug in guixsd? <mark_weaver>I'm not sure I'd really call it a bug in guixsd, exactly. it's a limitation in glibc that its system of dealing with locales cannot tolerate more than one libc on the same system. <mark_weaver>because programs linked with glibc-2.21 can't cope with locales made using glibc-2.22, and vice versa. <mark_weaver>if it's a bug in GuixSD, the bug is that we didn't realize that this limitation existed, and failed to modify glibc to add support for this. <mark_weaver>but I think the case could be made that this is a problem in glibc that doesn't show itself on most systems, because most systems never include more than one version of glibc. <anthk>I mean guixsd should cope with that "bug", as guix can use several versions of the same library at once <anthk>but I think the locales are just in one place <mark_weaver>yes, we will patch glibc to support multiple versions, somehow. there is still some disagreement about how best to do it. <mark_weaver>the patches are already written, it's just a matter of choosing between the options. <mark_weaver>there will likely be a GUIX_LOCPATH environment variable, which Guix's libc will honor but other libcs will ignore. <mark_weaver>what remains to be decided is whether libc should look in <DIR>/<LIBC_VERSION> or just <DIR> for locales, where <DIR> is a component from GUIX_LOCPATH ***davi_ is now known as Guest697
<karhunguixi>I've been trying to start a vm using "guix system vm", but this has caused 2 system freezes. I've also tried "guix system vm-image", which crashed my system (Segmentation fault at address 0x0). <mark_weaver>that's the problem. it doesn't support hardware virtualization. <mark_weaver>guix can be modified to not request hardware virtualization when running qemu, but it's not supported out of the box <mark_weaver>probably we should have a better way to disable that <karhunguixi>i have the "vmx" flag in /proc/cpuinfo though. I read that i should look for that. <mark_weaver>the x200 supports hardware virtualization, but it's broken without blobs. I'm not sure whether it's the lack of microcode updates for the CPU or lack of ME. some folks on #libreboot could probably tell you more. <mark_weaver>some other hardware supports hardware virtualization with libreboot, e.g. the X60, T60, and KFSN4-DRE. <karhunguixi>should installing GuixSD in QEMU be fairly easy for an average Joe? I'm struggling.. <mark_weaver>karhunguixi: it should be very easy with "guix system vm", but at present that assumes you have working KVM <mark_weaver>I expect it should be fairly easy to modify guix to not use KVM, but it would require you to first build 'guix' from a git checkout <mark_weaver>(making sure to pass --localstatedir=/var to configure) <karhunguixi>right, i went with trying to install it on my own, but i can't get QEMU to boot from anything GuixSD related (cdrom, usb, file) <mark_weaver>actually, building guix from git has many other advantages as well, including vastly faster updating and the ability to make arbitrary modifications to your local copy of guix, while easily keeping up-to-date with upstream. <mark_weaver>see section 8.1 (Building from Git) of the guix manual <mark_weaver>oh, on my copy it's 8.1. I guess a new chapter was added at some point. <karhunguixi>i've recently been through this process, so it's good to go <mark_weaver>instead, run it directly out of the git checkout, by prefixing the commands with ./pre-inst-env after it's built <mark_weaver>or, if you want to use the git checkout by default, make ~/.config/guix/latest a symlink to the git checkout after its built. that's what I do. <mark_weaver>I also make /root/.config/guix/latest a symlink to the same git checkout <mark_weaver>because I run "guix system reconfigure ..." using the git checkout <mark_weaver>e.g. right now I'm typing this from GuixSD running on a Lemote YeeLoong, which requires several patches on my private branch, not yet pushed to the 'master' branch. <mark_weaver>and in general, I almost always tend to have some local patches to guix that aren't yet ready to push. <mark_weaver>that's one way to do it, but because I added those aforementioned symlinks, I don't have to. <mark_weaver>~/.config/guix/latest is normally created/updated by "guix pull". but I never use "guix pull". instead, I manually point that symlink to my git checkout for both my normal user and root. <mark_weaver>it's just two different ways of accomplishing almost the same result <karhunguixi>and thus why you've said earlier that you've never run "guix pull". Because it would overwrite your symlink, right? <karhunguixi>so, should i run "./pre-inst-env guix system reconfigure" and make the symlink? And don't use "guix pull" anymore? <mark_weaver>karhunguixi: for now, I would just use "./pre-inst-env". <karhunguixi>I don't see how all this works together yet, but this is a good way to find out. <mark_weaver>./pre-inst-env basically just sets some environment variables to ensure that the code in that directory is used <karhunguixi>i'll do a reconfigure with ./pre-inst-env and see what happens <karhunguixi>mark_weaver, this is biting me: guix system: error: could not find bootstrap binary 'guile-2.0.9.tar.xz' for system 'x86_64-linux' <mark_weaver>there are other steps needed as well. see section 8.1 (Building from Git) of the guix manual <civodul>mark_weaver: your thoughts on GUIX_LOCPATH? :-) <karhunguixi>(the manual doesn't actually tell you to do the make step though) <mark_weaver>civodul: I think glibc should add "/2.22" to the directories in GUIX_LOCPATH. <mark_weaver>otherwise, I think people will be unhappy that things break without manual intervention the next time glibc changes the locale format incompatibly. <mark_weaver>(and when that happens, people must wonder whether guix can actually deliver on its promises) <civodul>my concern with this approach is that (1) this is unusual behavior, and (2) that's a noticeable departure from what libc does <efraim>i'm planning on moving /gnu/store from my root partition to its own partition, any one have experience with this? rsync flags to make sure all the links are preserved? <karhunguixi>in my mind it's fine for something in an alpha state to have these kinds of issues though <mark_weaver>civodul: I think those disadvantages are minor compared with having people's systems break badly when glibc is upgraded. <mark_weaver>I really think it's important that the next transition be automatic and trouble-free. <mark_weaver>people shouldn't have to follow our mailing list closely in order to avoid breakage. <mark_weaver>most people don't read the manual very carefully. I suspect most people read just enough to accomplish what they want. <davexunit>I follow closely and still had a tough time :/ <davexunit>things just break in unexpected ways, even when I think I have the right configuration. <mark_weaver>efraim: "cp -a" is the best, fastest way to do it all in one step. *much* faster than rsync. <mark_weaver>if for whatever reason it doesn't finish, you can always resume the copy with rsync. <anthk>tar cf - * | ( cd /target; tar xfp -) <mark_weaver>I'm not sure where 'tar' would be used to copy a directory from one partition to another. <mark_weaver>'cp' is definitely much faster than doing it that way, and also preserves the hard links which is quite important here. <efraim>its only 3.4 Gb and on an SSD so i could delete and recopy if it gets interrupted <mark_weaver>actually, it looks like GNU tar might be able to preserve hard links, but even so, I'd be quite surprised if cp isn't faster. <mark_weaver>efraim: I did a comparison between "cp -a" and "rsync -a" once, and as I recall the speed ratio was at least 10x. <mark_weaver>although I suppose I don't remember that clearly. I only remember that it was a *lot*. <efraim>considering my computer is cpu bound and not drive-speed bound for the copying, rsync would probably be slowest <efraim>none of cp, tar or rsync are multi-threaded, right? <efraim>although with 2 cores it wouldn't make a big difference <mark_weaver>ah, found my comparison test. it was actually a factor of 7x. <mark_weaver>I tried copying a /gnu/store/...-texlive-texmf-2014 with both cp -a and rsync -aHSP <efraim>would it be faster without the S flag? there shouldn't be anything sparse compressable in there <anthk>it can preserve permissions , links and such <mark_weaver>efraim: I don't know, but I don't think it makes a very large difference. most of the time I don't use the S flag, and I've still noticed that rsync is dramatically slower than cp <mark_weaver>which is understandable, since it has a lot more work to do. <efraim>looking at conky looks like i was drive limited, 2:05 real time for cp -a <efraim>stayed under 30% utilization the whole time <anthk>pax is actually faster than cp, but I am not sure about hard links, must create one or two <civodul>mark_weaver: i'm sorry for the hesitations, but it feels like we're between a rock and a hard place :-/ <mark_weaver>and if it doesn't preserve hard links, it's not a fair test <anthk>mark_weaver: some git repos of roguelikes, and a bunch of Linux isos <anthk>mark_weaver: you are right, I'll create one or two right now <mark_weaver>civodul: hesitations are probably justified. we should make sure to get this right so it doesn't bite us next time. this bite was painful. <davexunit>hopefully they can be convinced that multiple versions of libc on a machine ought to be supported. <civodul>davexunit: yes, the problem is more with the "big" patch <davexunit>getting people to understand the design principles of guix can be tough <taylan>indeed, I know both from difficulties I had, and how much I always feel lost when I want to explain it to someone else <anthk>the problem is Guix uses Scheme's jargon on help files , and they are not basically explained <davexunit>I was talking about high-level concepts, like why it make sense to have applications built with 2 different libcs <anthk>oh sorry davexunit , I tough you were patching about explaining Guix as a whole for the users <davexunit>I'd still like to know what jargon confused you <davexunit>because perhaps there's a way to rephrase that will make it more clear <anthk>davexunit: monadic procedures <davexunit>well I don't think we mention that outside of the programming interface docfs <civodul>that will leave the part about services soon <civodul>if i manage to get out of the locale quagmire :-) <civodul>it's "experimental" in the sense of not being "production-ready" <civodul>but the general mode of operation is not really experimental <karhunguixi>right. I tipped someone in #fsf about GuixSD and someone else simply comments "GuixSD is experimental" <civodul>that person should have talked with the fine Guix folks at FSF30 ;-) <karhunguixi>i don't know enough to get involved in discussions like these