<rekado>they told me that none of the tools claiming to support HPC environments actually work for them on Cray systems. <rekado>and then we got to a point when it really seemed like Guix could be made to fit the requirements (with some porting efforts to use some Cray blobs) <rekado>overall there was a feeling that Guix really does the right thing, though currently the mainstream is still combining old-school package managers with Docker. <boq>lol joshuaBPMan_ that's like the exact opposite problem that ruined yesterday for me <boq>rekado: there really wasn't much trouble, and I knew it would be something silly like this <boq>there seems to be weird things happening with grub now though, 2 help emails this week and now joshuaBPMan_ <rekado>boq: if we can prevent a ruined day with a simple notification then I think it’s totally worth it. <lfam_>Juesto: Plus, there are many contributors who are not technically "members" <Juesto>there's also members that aren't contributors too i guess? <ng0>Juesto: take a look at git log <lfam_>Juesto: Sure, some of those listed on that page are less active than others <boq>what's the 0.1% that isn't reproducible? <rekado>boq: I guess it’s actually more than 0.1% <lfam_>boq: It's actually more that 0.1% currently. But, I think that 99.9% is the closest we can possibly get, and we can never be sure to have 100%. <rekado>e.g. Python’s compiled files seem to be non-deterministic <rekado>and then there’s the usual problems like embedded time stamps <lfam_>It's impossible to prove that a package is reproducible. At best we can say that it was reproducible at a certain time, or not. <Juesto>is the liveusb a full harddrive with a ready-to-use guix? <boq>feel free to do the word a great service and abandon python ;3 <reepca>Hm, commencement seems to have failed - a lot of "ERROR: no such language <tree-il/bytecode/assembly/etc>", although that doesn't seem to be what directly caused the failure <rekado>Guix provides very favourable conditions for software to be built reproducibly <rekado>Juesto: there are packages in Guix that are needed for a Hurd system. <rekado>Juesto: we are also building binaries for Hurd systems. <lfam_>The Python non-reproducibility issue is something that we can fix. We "just" need somebody to do the work :) <rekado>Juesto: but at the moment there is no GuixSD variant that installs GNU+Hurd. <rekado>reepca: this sounds like a Guile version mismatch <Juesto>in that case, i should install hurd distrubition then add guix to it? <rekado>Juesto: yes, you would install Debian GNU/Hurd and use Guix on top, though I’m not sure it’s 100% usable yet. <ng0>phhhhttt :D from a setup.py output just now: Are you root? Please execute as root <ng0>needs to be patched.. hopefully upstreamed aswell. <boq>ng0: polite malware is the best <ng0>no, I just found out I only need to ignore the setup.py... because all it does is copying stuff <boq>or add it as marrow.scm <lfam_>boq: Those configuration templates are just examples, and we expect people to change them as necessary. I think it's useful to show how to add a service and a package as in the bare-bones example. <boq>is there a way to download things from the installation image though? iirc, it didn't have wget or curl <lfam_>boq: `guix download` should do the trick <boq>oh neat, can this do local host stuff too? like if I wanted to grab something from a different machine running ssh over lan? <rekado>you can also install things in the booted GuixSD image. <rekado>catonano: berlin.guixsd.org is the new old bayfront, which is the new hydra. <rekado>catonano: berlin.guixsd.org is hosted at the MDC. Old Sun hardware, but hopefully good enough for our purposes. <rekado>berlin.guixsd.org runs cuirass, and might become the new frontend for the build farm, if everything goes well. <lfam_>My fingers are crossed so hard that they've become stuck ***propumpkin is now known as contrapumpkin
<jackhill>I'm just getting around to reading the GuixSD 0.13.0 release notes. I see that there is some question about whether mips64el will be supported in the future. I'm always sad to see things go, but if no one is working on it, then I suppose it makes sense. <lfam_>jackhill: My understanding is that the mips64el hardware in our build farm started to fail, and nobody had the time or motivation to fix it or buy new hardware. <lfam_>If you decide to try it, I'm sure that people will be willing to answer questions and give advice <jackhill>lfam_: thanks! I'm fairly new to Guix in general, so won't promise anything, but am certinally interested. <lfam_>I'm curious, did you get your GnuBee yet? It seems like an interesting project and I tend to accumulate 2.5" drives as time marches on <jackhill>I had been wanting such a device for a long time, so I'm super excited! <lfam_>I'm curious (again), which criteria do the GnuBee fill for you? <nckx>rekado: ‘berlin.guixsd.org is the new old bayfront’ – there's a new bayfront too? <rekado>it’s “new” as in “recent”, but it’s old hardware. <rekado>bayfront is just bayfront; no qualifier. <jackhill>lfam_: I like it because it's freemdom-frienly, and a low power device that can support a large amount of storage. <rekado>berlin.guixsd.org has worse specs than bayfront, but the hardware has served the institute very well for a couple of years without major reliability issues. <lfam_>Pretty much anything would be improvement over the current situation <rekado>jackhill: this really looks like a great project. <rekado>I’m glad that there are more and more projects that apply for the FSF’s RYF certification. <lfam_>If one is interested in the subject, it might be worth the ~50 minutes of his lecture <catonano>rekado: thanks ! Would you mind to write a note on the mailing list abouut this ? <rekado>catonano: I’d like to wait until it’s fully in operation. <rekado>catonano: it’s running Cuirass now, but it doesn’t seem to actually build anything. <rekado>I’m a bit confused to be honest, but I haven’t had the time yet to look into it. <rekado>oh, it actually *is* building things already. <rekado>all cores are busy and guix offload is running, too <lfam_>rekado: Is the mirror pulling things from it yet? <rekado>I don’t know. I haven’t changed the mirror configuration. Maybe Ludo did. <rekado>I should also add that other machine as a build host. <rekado>it’s just sitting in the rack, probably really bored. <rekado>ACTION runs Ludo’s “guix weather” script against berlin.guixsd.org <lfam_>We still have a bunch of packages that use super-short Git references :( <Juesto>so the lack of popularity is why guix and hurd are still alpha? <lfam_>Guix is not in the alpha stage anymore. But there are still some missing features, in our opinion. <Juesto>the original question is still valid through <lfam_>It's not about popularity, but rather about missing features. <rekado>Juesto: what lack of popularity do you mean? <Juesto>popularity, people attraction and such <lfam_>I can't find the most recent summary by civodul of what's missing <rekado>“6.6% substitutes available (402 out of 6,088)” <rekado>I hope that number will go up on berlin.guixsd.org. <rekado>it’s currently building gcc-5, so it’s still pretty much at the beginning <lfam_>The lower parts of the package graph are slow to build, but the middle goes very quickly in my experience. Then there is a long tail of super expensive leaf packages <Juesto>why the manual doesn't cover cd burning and such? <Juesto>does flashing guixsd to a usb effectively install guixsd in it? <lfam_>Yes. We don't cover CD burning because we don't provide an ISO that can be burned to a CD. <lfam_>Although people are working on it, so I think that the next release will include that <Juesto>So what's provided is a disk image? <Juesto>and effectively installs the distro on a stick, correct? <lfam_>It installs a variant of the distro that is intended to be used to install GuixSD on the host machine. But, it is GuixSD. <lfam_>There is the tool `guix system disk-image` that creates these disk images, and you can use it to create a more straightforward image if you want to use a USB stick to boot and use rather than to install <Juesto>I'm going to convert from raw image to vbox disk <Juesto>both seem to be in the same raw format suitable for dd <Juesto>in fact, the vm image is better compressed <Juesto>It doesn't seem to contain any boot data <lfam_>I mean, specifically, what goes wrong? What do you see? How does it fail? <Juesto>lfam_: doesn't seem to detect anything to boot <lfam_>What doesn't seem to detect anything? What messages are printed? I'm not able to help you unless you are more specific <Juesto>efi mode drops me to builtin shell <Juesto>and i have no clue how to manually load the efi file <lfam_>And this is the 0.13.0 VM image? <rekado>“9.6% substitutes available (584 out of 6,088)” <lfam_>Juesto: Hm, I'm not sure what's wrong. It works in QEMU. Perhaps the conversion process you used needs to be adjusted <rekado>hmm, it’s a bit strange, though, that berlin.guixsd.org builds things locally <Juesto>I've got the same result as opening the partition in 7zip <Juesto>i tried the usb install image too <lfam_>Juesto: Recently a VPS vendor told me they needed to "the root device from /dev/sda1 to /dev/vda1" to make it work on their platform. <lfam_>I mean, they needed to change "the root device..." <Juesto>Maybe this is meant for paravirtualized environments? <lfam_>There is definitely a kernel :) <lfam_>I use these images frequently <Juesto>there's nothing on /boot but grub <lfam_>I think the grub.cfg should load the kernel from somewhere in /gnu/store <Juesto>well grub isn't even booting at all <lfam_>Not sure, I don't have much experience with virtualbox <Juesto>how is this supposed to be ran in? <lfam_>I've heard of people running GuixSD in virtualbox, so it's definitely possible, but I don't know how to do it <lfam_>Juesto: Yes, on real hardware too <rekado>Juesto: I use GuixSD on many computers, all real hardware. <Juesto>i was using other linux configuration <lfam_>ACTION ruthlessly archives old emails <Juesto>in addition I've downloaded qemu <lfam_>Juesto: I thought you said it was working now in virtualbox, "i was using other linux configuration" <Juesto>but additionally i decided to get qemu anyway <Juesto>but now i can't find a network interface <lfam_>Okay. How did you run QEMU, and what have you tried in the VM? <Juesto>the interface problem is in vbox lfam_ <Juesto>in vbox it gets a i/o error on stty <Juesto>its linux 4, how are the network interfaces named? <lfam_>They should be listed in the output of `ifconfig -a` <sharlatan>gpg --verify guix-binary-0.13.0.x86_64-linux.tar.xz.sig <sharlatan>gpg: assuming signed data in `guix-binary-0.13.0.x86_64-linux.tar.xz' <sharlatan>gpg: Signature made Mon 22 May 2017 13:51:34 BST using RSA key ID 3D9AEBB5 <sharlatan>gpg: Good signature from "Ludovic Courtès <ludo@gnu.org>" <sharlatan>gpg: aka "Ludovic Courtès <ludo@chbouib.org>" <sharlatan>gpg: aka "Ludovic Courtès (Inria) <ludovic.courtes@inria.fr>" <sharlatan>gpg: WARNING: This key is not certified with a trusted signature! <sharlatan>gpg: There is no indication that the signature belongs to the owner. <sharlatan>Primary key fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 <lfam_>sharlatan: That output means that the signature was verified but that you haven't explicitly chosen to trust the key that was used. It's normal. <lfam_>I'm not familiar with this message: gpg: lookup_hashtable failed: eof <Juesto>anyway i find gnu software overwhelming so far <sharlatan>Takes time to go through the Binary-Install gued, want some flexability... <lfam_>Hm, there are 1407 builds queued on the master branch. Seems like a lot <lfam_>There's only a handful of changes between the previous evaluation (400 builds queued) and the current one <reepca>Hm, is the bootstrap guile a rebel when it comes to --no-auto-compile? I'm certain it's being invoked with --no-auto-compile, but it still says "note: auto-compilation is enabled" and does auto-compilation anyway. <lfam_>The large number of rebuilds is from python-pytz. 280 rebuilds per-system-type. <rekado_>“guix refresh -l” didn’t show many packages. <lfam_>It's mostly Python stuff so it will build quickly <lfam_>You have to pass both python-pytz and python2-pytz to the refresh calculator <lfam_>It's not even over the "staging branch" limit <lfam_>I hope we can finish core-updates this week. <rekado_>hmm, maybe I did something wrong before; I get more packages listed now than I thought I saw before. <rekado_>BTW: I just set up that extra host as a build server for berlin.guixsd.org. Offloading works fine. <lfam_>The time zone stuff is annoying. We want to keep it up to date but so many things need access to the TZ database. ***Zungo is now known as Juesto
<jackhill>When trying to install GuixSD from the USB image, it doesn't find the gnu-disk-image root device, and drops me to a guile shell. Can I get a born shell so I can poke around to see why it couldn't find it? Otherwise, how should I debug? <rekado_>jackhill: have you verified the integrity of the image? Have you run “sync” before removing the USB drive? <jackhill>rekado_: yes, the twist is that I'm trying to do the install on a VPS service (Linode), so I have dd-ed the image to a raw disk device. I think they're using kvm-qemu under the covers. It is using the grub that is in the usb image. <rekado_>jackhill: wouldn’t it be better to just use the VM image for a VPS? <rekado_>jackhill: from within that image you could then reconfigure the system. <jackhill>rekado_: maybe, but I'm not sure how to go from the qcow2 image to having it installed there. Oh I guess I could convert it to a raw image and post in on the web somewhere. <jackhill>but sleep does sound like a good idea :) thanks for your help! <jackhill>(the tricky part is just getting that image on Linode since they don't offer and easy upload disk image option) <jackhill>and if that idea fails, I might try installing Guix on top of a different GNU/Linux distro and use that to bootstrap an installation. <jackhill>Ah! The problem seems to have been the virtio devices. When I tick the box for the fully virtualized devices, it was able to find it. <jackhill>something to investigate after I sleep. Thanks for listening to my progress. <boq>k, weird problem I've never had before with su and screen <boq>I used to always $ su --login otheruser <boq>but now I'm getting `Cannot open your terminal '/dev/pts/1' - please check.' <boq>has some su alias I was unaware of changed or been removed? ***Juesto is now known as abcdef
***abcdef is now known as Juesto
***Juesto is now known as abcdef
***abcdef is now known as abcde
***abcde is now known as abcdefg
***abcdefg is now known as Juesto
***Zungo is now known as Juesto
<boq>sneek: tell lfam I found another 404, this time it's gstreamer-1.12.1 <sneek>lfam, boq says: I found another 404, this time it's gstreamer-1.12.1 <boq>different machine and it's long gone <rekado_>“14.8% substitutes available (903 out of 6,088)” for berlin.guixsd.org <rekado_>ACTION really likes the “guix weather” script. <boq>is there an `all fonts' meta package yet? <rgrinberg>Is there a reason why intellij hasn't been packaged on guix yet? Is it not free enough? <rekado_>I don’t know if it is free software. <rgrinberg>It seems to be apache licensed but it might have non free dependencies? <rgrinberg>Oh, I know it has a plugin system that probably lets you install non free software. Does that make it a no go? <rekado_>rgrinberg: it might not be a problem. As long as it doesn’t recommend the installation of non-free software. ***Juesto is now known as z_z
***z_z is now known as Juesto
<ng0>Do we have some Django'ists in Guix? Harmut, and maybe someone else? I did some work with hyperkitty but got stuck at my package of djangorestframework in the test phase (or build_ext?) of the djangorestframework <rain1>Status update from the Reproducible Builds project <ng0>the GUIX_PACKAGE_PATH is just modules… wouldn't it in theory be possible to place service modules there as well and call them from the system config? <ng0>ACTION makes a mental note to try this <rekado_>ng0: for other modules you can just use GUILE_LOAD_PATH <rekado_>ng0: we’re doing this for managing the system configs of the build farm, for example. <rekado_>the repository contains extra modules that we use in the config. <ng0>gnunet_bot: log pointer? <ng0>sunday evening discussion: some systems can detect which architecture they are on and boot arcordingly into the right one I was told last monday, and some can print warnings like "error, this medium is only only for $architecture". Size would grow, but we could create such a duality system with the GuixSD image aswell, I'm sure. <ng0>the problem is probably grub, and selecting the right one <buenouanq>prior to me updating to 0.13, I used to always $ su --login buen; $ screen -DR to do thing like attaching to irssi from wherever, <buenouanq>but now I get an error: `Cannot open your terminal '/dev/pts/7' - please check.' <buenouanq>I guess I'd like to know what has changed on me in the background configs so I can revert it. <janneke>buenouanq: what about: e586257b550918fefaab3970f2c314d6285f54ab <buenouanq>wgxm13wn9ldhwm6rq88fkva0mngmabdx-su is the hash I have for su <buenouanq>Running $ script /dev/null is the hack fix that's posted everywhere when I google the error - That just seems awful to me though, and I really don't want my screen alias to have to contain that. <lfam>Presumably something changed between shadow 4.4 and shadow 4.5 <buenouanq>also getting this now when I exit a screen `/var/run/utmp: No such file or directory' <efraim>Then maybe something between shadow and linux-util? <ng0>buenouanq: I have /var/run/utmpx <ng0>I think why I wasn't able to test bspwm: it requires some configuration which I haven't looked into. People using bspwm will complain if the update broke something <ng0>I could start into bspwm with X11, but had nothing <ng0>had to do 'killall bspwm' from outside to get out of it <ng0>that's even more minimal than my spectrwm <buenouanq>man, all the answers I'm finding today just seem so dumb <buenouanq>how and why would that fix anything? why wouldn't just touching the file work? <lfam>wigust: Does this not work? #:configure-flags '("--flags=with_utf8 with_xft") ***Zungo is now known as Juesto
<lfam>buenouanq: That would erase utmp <ng0>screenlockers need 'suid' set, right? I wouldn't know why i3lock and i3lockfancy would lock me out otherwise <ng0>like, lock works, only log back in is "password wrong, try again" ad infinity ;) <lfam>My screenlocker is not setuid on Debian <ng0>then maybe something with PAM? <wigust>lfam: yeah, thanks :-) I thought about splitting flags. Probably not needed. <lfam>wigust: I'm not sure if my suggestion will work, but that's what I would try first <wigust>lfam: It work's, because configure reports "--flags=with_utf8 with_xft" as a one string, I think. <ng0>tootstream is a python app which depends on Mastodon.py among other things. We already know python.scm is too long, is messaging a good place for things which are only a python interface to something + its dependencies? <lfam>I hope we will get more mastodon packages, so maybe we should add a mastodon module <ng0>Mastodon itself is blocked by nodejs. <lfam>We can't use our node package for it? <ng0>the problem is unbundling the nodejs dependencies <ng0>Mastodon itself is mostly Ruby + Nodejs, and it is easier to package GNUsocial which has its own problems but at least is just php <lfam>Okay, well, at least we can add supporting packages <jonsger>ng0: maybe social.scm. I planning for the future packaging diaspora... <ng0>social.scm as a name makes not much sense, it's too open <ng0>I could psyced in there when I'm done with it.. it's social aswell <lfam>I think that diaspora could get it its own module too. I expect it will be a big one <ng0>after all its just naming schemes <lfam>Ultimately, it's not that important. <lfam>Module naming and renaming is how we encourage people to submit their packages upstream ;) <ng0>If someone packages gnusocial it will be big aswell <lfam>jonsger: Try `guix package -s bundler` <ng0>I'll just claim (gnu packages mastodon). <jonsger>then I remembered right. this should make diaspora a *lot* easier <ng0>we have a rails branch which holds many gems needed for mastodon.. I looked into mastodon on request a while back <ng0>I'm still doing it, I'm just waiting on nodejs becoming easier which will probably when hell freezes over. <efraim>just ran `guix system init ~/odroid.scm /mnt', don't expect this initial one to work, i probably have to modify the boot.ini in /boot to tell u-boot where to find the kernel and such <ng0>In python, what is "dateutils"? I only found out it is not "dateutil" <ng0>ah, dateutls is a separate package <buenouanq>I don't get the screen errors if I ssh to the user. <ng0>is there anything special I need to do for jack to work? I installed qjackctl, trying to test the supercollider package I finished. Qjackctl can't start jackd <ng0>should I try without qt and just jack2? <ng0>or am I expected to run qjackctl as privileged user? <ng0>it's been a while since I've done this :) <rekado_>ng0: I have a little shepherd user service that starts jack <rekado_>JACK works best when you’ve lifted memory restrictions <rekado_> (pam-limits-entry "@realtime" 'both 'rtprio 99) <rekado_> (pam-limits-entry "@realtime" 'both 'memlock 'unlimited))) <ng0>do I use our jack2 or jack package? <rekado_><rekado_> ng0: I don’t use qjackctl or jack2 [22:05] <ng0>well for the quick test right now I just want to get jack going, but I'll make use of jack afterwards aswell. <buenouanq>why are there things like /run/systemd if we don't use systemd? <ng0>what's the difference between jack2 and jack? <lfam>buenouanq: For elogind. I recommend grepping the source code for 'systemd' if you're curious <rekado_>I use jack1 because I need support for ALSA MIDI and because it’s simpler (no dbus magic). <rekado_>all packages that need JACK use jack1 as an input, because the closure is smaller. But they will work just fine with jack2. <ng0>I think supercollider' error message tell me it wants realtime support.. I'll reconfigure <Juesto>is the devastous section of systemd stripped here at least? <lfam>GuixSD doesn't use systemd, it uses the Shepherd <Juesto>offtopic I'm still interested in systemd and why it's hated specifically <rekado_>lfam: it’s good that it actually has attracted people to continue the development. <rekado_>Juesto: you’d have to ask people who hate it then. <lfam>Juesto: It's complicated and extremely contentious. I recommend searching the net to get peoples' opinions. I'd rather not discuss it here too much because I don't want an off-topic flame war <lfam>rekado_: Yes, I think it's popular in Gentoo <ng0>rekado_: what else do you define in your config? I get realtime as a group is not defined <rekado_>ng0: define the group in your config <Juesto>I'm not looking for such war or anything, I'd be thankful if I'm pointed into the right direction <ng0>rekado_: this might not be very obvious, but how? I know how to do it in system services.. in config it is more or less the same I'd guess? <lfam>Juesto: I can't really offer a definitive source. So many people have a so many different things to say about it. <lfam>There are technical arguments, social / emotional arguments, philosophical arguments... meanwhile most of the big distros decided to use it. Go figure <rekado_>Juesto: chances are that if you don’t know what’s not to like about systemd then you probably wouldn’t care too much anyway. <ng0>(groups (cons (group "realtime") %base-groups)) should be right <Juesto>I've read about the hate but i don't fully understand <buenouanq>All I know is that once Debian moved to it, all my stuff started breaking. <buenouanq>And once I moved away from it, everything worked again. <rekado_>some of the reasons why people don’t like it may also apply to Shepherd. <lfam>Well, today is the day I change the expiration date on my signing key. Wish me luck <rekado_>but that depends a lot on what people value <rekado_>there’s many things to dislike about any piece of software. <rekado_>some people really don’t like Emacs for being an overflowing kitchen sink <buenouanq>they don't understand what Emacs actually is then <ng0>I think it's the first init system where I read all of the documentation and not just bits and pieces and other peoples work. <rekado_>others (like me) are irrationally attracted to just that. <buenouanq>Emacs `bloat' is nothing like, say, Firefox bloat. <rekado_>it certainly *is* an overflowing kitchen sink :) <rekado_>one person’s bloat is another person’s … erm, dunno. <ng0>the group thing did not really work. was my syntax wrong? <buenouanq>no but, how is shepherd at all like systemd? <rekado_>(groups (cons (user-group (name "realtime")) %base-groups)) <rekado_>buenouanq: no, that’s not what I meant. <rekado_>what things really *are* is secondary in these kinds of arguments. <ng0>I think I should look at a service to get the syntax right <rekado_>what matters is how they are perceived. <rekado_>ng0: have you looked at the documentation? <ng0>now I'm reading code to get what the documentation doesn't tell me <ng0>install.scm should have this kind of thing afaik <rekado_>buenouanq: there’s a never-ending back and forth between those who can’t stand systemd and those who don’t think it’s an unreasonable cost to pay for what it gets you. <ng0>no it doesn't. well, other modules.. <rekado_>ng0: the documentation says it all, though. <ng0>"see user-docuemtnation" <rekado_>ng0: I opened it, searched the index for “groups” and the second hit shows me an example: <ng0>that made me assume the line I wrote <rekado_>this: (groups (cons (group "realtime") %base-groups)) <rekado_>but you use “group”, not “user-group” <ng0>mysterious. I did the same. Maybe I got the wrong section <rekado_>hit “l” to go back to where you were in the manual <rekado_>it would be a terrible bug if the manual suggested something wrong. <rekado_>I think it’s pretty clear in this case. <rekado_>List of user accounts and groups. *Note User Accounts::. <rekado_>one tells you about the “groups” field in the OS config <rekado_>the other tells you everything there is to know about the values it can take. <ng0>my understanding to integrate it into my already working and functiuonal system config is that I just add: (user-group (name "realtime") %base-groups)) and I'm done <ng0>or did I forget a cons in there? <rekado_>“user-group” is a procedure that returns a user-group object <rekado_>you can’t just give it a field and some random list <ng0>imo, a full example would be better in the documentation and not to assume everyone understood the part about groups. <rekado_>according to 6.2.2 ‘operating-system’ Reference the “groups” field takes a list of groups. <rekado_>%base-groups is the default value; it’s a list <rekado_>to add a value to a list you take that value and cons it onto the list. <catonano>I think ng0 means (cons (user-group (name "blah")) %base-groups) <rekado_><rekado_> (groups (cons (user-group (name "realtime")) %base-groups)) <rekado_>first argument to “cons” is the single value: “(user-group (name "realtime"))” <rekado_>second argument to “cons” is an existing list: “%base-groups” <rekado_>so the value for the “groups” field is a list again, and everything is good now <ng0>if you did, I missed it <ng0>I'm a bit occupied with other issues which are weighting down on me.. I think after reading it, and with your explanation it is logical. Maybe it's easy without it aswell, but I'm not in my best form <rekado_>lfam: didn’t you write that you wanted to reorganize the manual at some point? <lfam>rekado_: Just the sections on GuixSD and virtualization <lfam>They have grown organically and I think they are confusing for new users <rekado_>I talked to Pjotr about the manual today, and I think it suffers a bit from the fact that the “reference manual” parts are intertwined with the explanatory prose. <lfam>Ultimately, it's up to whoever does the work. I find it much harder to work on the manual than the code <rekado_>Same here. I really like the manual, though. <lfam>Yes, I think it's very good in general <rekado_>when editing the manual one has to be aware of the overall flow <lfam>Right, it can't be modularized like software can. And the measure of success is more subjective <rekado_>the effects of a change are much less “local” than a change in code. <ng0>it's hard to get it right.. it is good already <lfam>I had some thoughts about the GuixSD / virtualization stuff and everything was crystal clear in my mind... while I walked to a train station. Then I got on the train and forgot <lfam>I'm waiting for my thoughts to clear up again <ng0>ACTION reboots to make computer pingpong noise test <lfam>My basic problem with those sections is that there are two overlapping topics (Installing and Running), and new users won't notice both of them or, if they do notice, they won't understand the distinction. <lfam>There is also some misinformation, although I think I've corrected it on the master branch <lfam>I think that the primary section should be on running GuixSD in QEMU, and then there should be a sub-section about how to install it in QEMU. <lfam>The serious mistakes are not online anymore, but there were some minor mistakes about QEMU image sizes that are fixed in the source code but not deployed to the web page <lfam>I'm not able to boot a generated disk-image on my x200s :( <lfam>The USB stick doesn't even show up in the BIOS boot device menu <lfam>The 0.13.0 installer image works, however <ng0>okay, at least now I know that I have to debug the supercollider build a bit <ng0>s.boot only causes a crash / doesn't boot <ng0>maybe an update of the package helps, I only worked with my old 3.7.2 .. I'll send a patch once I'm done with it :) <yegortimoshenko>does guix play well with inferior-lisp emacs mode? what i mean is, can i interactively create a package, or a whole-system configuration? <rekado_>yegortimoshenko: yes, but can do this, but then you wouldn’t use the command line interface but the equivalent Scheme procedures (either in the REPL or by sending them to the REPL with Emacs). <rekado_>I use geiser mostly for exploration, not so much for packaging work. <lfam>I got the disk-image to work, but I'm not sure what was wrong. Probably some spurious issue about flushing the writes to the USB stick <yegortimoshenko>rekado_: cool! geiser is a lot like inferior-lisp, or probably more like slime <rekado_>this happened to me before; forgot to run “sync”. <rekado_>yegortimoshenko: Guix also comes with extra REPL commands so that you can run the monadic procedures directly in the REPL without having to do all that plumbing yourself. <lfam>Perhaps the difference between fdatasync and fsync