<lfam>That is interesting! They have a channel on freenode: #serveraptor <goglosh>hey guys what does this reader macro mean: #~ <alezost>goglosh: it is from gexps: (info "(guix) G-Expressions") ***exio4 is now known as init
***NiAsterisk_ is now known as NiAsterisk
<taylan>is it intentional that guix/config.scm and guix/tests.scm aren't in MODULES in the Makefile? ***yang_ is now known as yang
<amz3>I took the liberty to answer to Fabio on the ML <amz3>if someone has experience with third party guix package repository feel free to reply to my absence of knowledge in this regard <amz3>basicly fabio wants a fork of guix for guile-only which IMO doesn't make sens <amz3>What I /propose/ is a guile third party repository, but I don't if this is supported somehow, maybe via GUIX_PACKAGE_PATH <xd1le>as in, why would fabio want that? <amz3>because guix is too heavy more or less, he wants to package manager to works for users directly without system install <xd1le>"without system install", what does that mean? <amz3>usable as a user, without installation going through root user <xd1le>fair point, i guess he's free to do that if he can, just i think it's not an efficient use of resources <amz3>I think golang can work like that <xd1le>golang packaging toolchain is so horrible ***init is now known as exio4
<xd1le>also tbf, the binary installation of guix is really simple <xd1le>nix also has a curl pipe bash binary installation method, but i believe the script also requires root <xd1le>so it's not like guix cannot have it too <amz3>yes, that's what I said, but some people don't want to deal with command line kung-fu as root <xd1le>just it would require root i think <amz3>I think guix can be installed as user <amz3>but I can't find the documentation <xd1le>i'm not really sure if guix has gotten to the point where it can appeal to those who "don't want to deal with command line kung-fu" <xd1le>i mean i'm all behind making it easy to use <xd1le>but imo it's a pretty minimal installation method <amz3>that's the point of fabio, people who only want to use Guile, should have a fastpath to share their modules <amz3>I think the problem is not only about the installation but also about the package acceptance process, which requires send a patch etc. <xd1le>ah i see, a "package manager" just for guile <amz3>I think it's better to avoid guildhall and focus on making guix more guile friendly <amz3>Mind the fact, that while I say that, I know that it's not difficult to package guile for guix <amz3>What I mean is that it should more official to use guix as guile package manager <amz3>Even if, it will be a standing complain that guix is "big" because it support an OS.. <amz3>davexunit: what do you think? <davexunit>the people that want to use a guile-specific package manager will not want guix <davexunit>guix manages the *entire* dependency graph, there's no way around that. <davexunit>the people that want language-specific package managers don't want this. <davexunit>they want something that uses the compilers and native libraries from their host system <amz3>the end result is the same, you will have a working guile program, so I don't see where the trouble is <amz3>I mean: where the complain stands <amz3>that's what matters to me at least... <iyzsong>language-specific package managers come free and the packages are directly under the developer's control, no packager involved. <davexunit>where language-specific package managers fall apart is dealing with libraries that have native extensions or otherwise require C libraries or something. <xd1le>and that is definitely a real issue <davexunit>but they enable a loose, easy way to share code. <davexunit>so, I think the guildhall is the answer for guile. <davexunit>and Guix is the answer for *real* package management. <amz3>I think guildhall brings noise to the situation <davexunit>guix is a full-system package manager that just happens to be written in Guile. <amz3>having two package manager... doesn't look like a good idea <xd1le>so yes, remember that guix is not out to be 1 millionth + 1 pacakge manager, but the one that replaces them all. <davexunit>guix just happens to be written in Guile, but it is not suited to being a Guile-specific package manager. <amz3>davexunit: the situation can be improved, isn't it? <davexunit>but you are looking to satisfy a different set of users who will not want Guix. <davexunit>someone that wants to do Guile development on, say, Debian will probably be mad if they install a package manager that downloads a completely new GCC toolchain, kernel headers, etc. <davexunit>when all they wanted was guile-json or something <amz3>We can't satisfy everybody <xd1le>my opinion is, guix doesn't have the manpower to maintain a guile-specific port <xd1le>and as davexunit already said, guix's goal is not to be a "guile package manager" <xd1le>it's to be an "everything package manager", and it just so happens to be written in guile, so fabio is asking the wrong people <davexunit>amz3: but the people you wouldn't be satisfying are those that want a guile-specific package manager. <davexunit>I do all of my Guile hacking with Guix and it is fantastic, but there's a different set of users who would be better served with the Guildhall, and I think that's OK. <amz3>we must educate people about the situation, for the interest of guile, guix must be the sole package manager of Guile <davexunit>and if the Guildhall had an HTTP API or equivalent, we in the Guix project could write a package importer for it. <davexunit>amz3: I really don't think that has to be the case. <davexunit>of course, I highly recommend using Guix instead of the Guildhall, but I really need to stress that a certain class of user will not want it right now. <amz3>ok, then what must be done to avoid this question/complain to be raised all the time? <davexunit>has it been raised all the time? I certainly haven't heard it <amz3>yes, I read people looking for a package manager for guile all the time <amz3>even if I think, the problem is that there is not a lot or enough packages in guildhall to be taken seriously which is a different issue <amz3>not related to the previous discussion <amz3>at work, we use a debian repository for our softwares, it makes things really complex to understand how all things work together also we rely sysvinit. Then end result is that a single developper can't build the complete solution without relying on build bot <amz3>and build bot doesn't do all-the-thing since after building you still need to setup a vm or whatever lightweight container to run it <amz3>i think it's a perfect use case of guix <civodul>amz3: yeah, at work i use 'guix environment' on Jenkins slave for CI <amz3>pardon my ignorance, can we use guix if we don't modify guix? <amz3>or maybe we don't have to bundle guix in the sold package, I'm not sure <amz3>maybe this orthogonal, we might use guix for building and ship only the software <civodul>yes, you can use it without modifying it :-) ***jubalh is now known as Guest23947
***Guest23947 is now known as jubalh_
<xd1le>amz3: nice! looks like it's incomplete? <amz3>xd1le: yeah, obviously guile is so massive! <amz3>xd1le: what do you think is missing outside what is planned <xd1le>actually i don't know much scheme, hence asking <xd1le>and i'll probably read this shortly too <xd1le>yes i can see, still looks like quite nice <amz3>sicp is for lisp, and explain how to write programs -- and how to write programs in a functional way <amz3>I focus on introducing scheme <amz3>so it's straight forward <amz3>sicp is for beginner in programming afaik <amz3>my tutorial is for seasoned programmers <amz3>it's missing some things, but the basics are their <amz3>my tutorial again, is missing goops (all the thing OOP in guile) but it's not required for guix <amz3>it's missing how quasiquote/quote/unquote works <amz3>it's missing how macro works, but this is broad topic I think <amz3>xd1le: yes, but it's more powerful that python/ruby/whatever ;) <amz3>one thing it implements multiple class inheritance <amz3>anther thing is that you can implement methods for a class outside the same file, basically you can extend a thrid party library without inherting <amz3>those are the two things i know <amz3>also compared to java, it's dynamic, so I assume you can also extend attribute/method resolution <xd1le>amz3: so scheme encourages managing state? <amz3>it's based on cloos which the oop for lisp which is decades or engineering <amz3>goops is a guile thing, I don't think oop is part of any official scheme specification <amz3>oops is implemented as library in scheme <xd1le>oh, it's weird to here about oop in lisp <xd1le>guess it's just my inexperience <xd1le>anyhow, catch you later, gtg! :) <xd1le>thanks again for the tutorial <df_>amz3: "explicit" is not a verb, I think maybe "demonstrate" might be a good substitute for what you mean <amz3>it looks like a good candidate for a verb ;) <amz3>english is living language; it is what we make of it :) <df_>"expound" or "exposit" is, but I think demonstrate sounds more natural <amz3>anyway, thanks and thanks for reading :) <df_>thanks for writing :) are you planning to go on and write what's in the "beyond" section? <amz3>I mean a python dev, which prefers python, since I am in the same situations I'd like to be "up-to-date" <amz3>also, this is about thing I don't know actually <lfam>Any advice on using `guix system vm-image`? Should I adapt the script I get from `guix system vm` to work with the output of `guix system vm-image`? <lfam>Also, is it possible to "feed" entropy to qemu? That would make it easier to use `guix system vm`, since right now, you have to bash the keyboard to provide entropy for the vm, making it not that useful for spawning systems on demand. <rekado>lfam: there is the rng-tools service which can be used to generate more entropy <lfam>rekado: I'd need to bring that to Guix, right? <rekado>I should note that I haven't tried this before, but someone else claims that it works: <rekado>that also requires connecting /dev/random via virtio to the host's entropy source. <lfam>I need to learn more about qemu. I can't even tell how to get started with that <rekado>the instructions about editing the guest's xml conf only apply when you're using virsh/libvirt. <lfam>Yeah, that's what I thought. <lfam>Got any thoughts on my question about using `vm-image`? I should adapt the run.sh script created by `vm`? <civodul>you're looking for a way to boot the resulting image? <lfam>I'm just looking for guidance on the qemu invocation <lfam>And if it turns out that I actually needed the guidance, I'll try to augment the manual <civodul>so you should be able to just run: qemu the-image.img <civodul>it's best to add "-m 512" or similar, and also networking and such <lfam>Yeah, I need to figure out how to configure networking. Otherwise the images fail to boot <lfam>It's not really the manual's job to explain how to use qemu, but I think a breadcrumb could be helpful. I think many people would like to first try GuixSD without installing to bare metal <civodul>yeah, showing one example command-line would help <civodul>there are definitely things to borrow from the generated run-vm.sh <lfam>Okay, I'll work in that direction and hopefully produce a patch for the manual <civodul>taylan: "make -j4" takes 26 minutes on your machine?! <civodul>i've never actually measured on my machine, but thought it was less <taylan>civodul: from a fresh clone, yes. Intel i5. <lfam>The nice thing about `make clean` is that it makes me clean my apartment while I wait for `make` ;) <taylan>lfam: I'm afraid I'm breaking your use-case :P <lfam>Is that the one about the spacebar? ;) <lfam>I got the vm-image to boot. Now I have to figure out how to get it network access <taylan>by the way, I noticed some weirdness with guix/download.scm... when I build with my patch, then switch back to master and run make again, guix/download.go gets recompiled even though the .scm didn't change. <civodul>taylan: i think compile-all.sh guarantees the right order, but it'd be good to check what happens when GnuTLS is not installed <taylan>civodul: hm, it depends on what $^ expands to in the makefile, since that determines the order <lfam>What determines the existence of resolv.conf? I am using the desktop "template" <lfam>Should I create it by hand? I've never had to do that before <taylan>lfam: I think a DHCP daemon typically creates that <taylan>but maybe things are different on GuixSD <civodul>taylan: no i mean, since the compile-all.scm "preloads" all the modules, i think it sidesteps the issue that this extra edge in the makefile was addressing <civodul>lfam: indeed, "dhclient eth0" or similar <taylan>well I'll try to test tomorrow what happens when there's no gnutls, in any case <lfam>The bare-bones example configuration includes dhcp-client-service, but the desktop example does not. Is that intentional? Wouldn't the dhcp-client-service be part of desktop-services? <lfam>I think the desktop config needs some love