IRC channel logs


back to list of logs

<paron_remote>hosting for the Hurd and Nix???
<paron_remote>ACTION tries to convince them to adopt GuixSD :)
<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
<amz3>xd1le: why what?
<xd1le>as in, why would fabio want that?
<amz3>to improve guile reach
<xd1le>but why fork..
<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
<amz3>I think he wants something like: curl -x | bash
<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
<xd1le>(last i checked)
***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
<xd1le>oh well, just my opinion
<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.
<amz3>the usual complain :/
<xd1le>ah i see, a "package manager" just for guile
<xd1le>amz3: yeah
<davexunit>just use the guildhall for pure guile
<amz3>I think it's better to avoid guildhall and focus on making guix more guile friendly
<amz3>s/guile/guile package
<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
<davexunit>that comes with significant challenges.
<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...
<davexunit>then you are fine with Guix as-is
<davexunit>as an everything-manager.
<davexunit>this is what I like, too.
<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>for easily sharing pure-Guile modules
<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
<davexunit>there's a million package managers
<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>I use Guix for all of my Guile development.
<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
<xd1le>unfortunately for him
<davexunit>amz3: but the people you wouldn't be satisfying are those that want a guile-specific package manager.
<davexunit>Guix is already great for Guile development
<davexunit>no changes need to be made there
<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.
<davexunit>Guildhall will be more up their alley.
<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
<davexunit>well someone needs to develop that, then.
<civodul>Hello Guix!
<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 :-)
<civodul>i briefly mentioned the Jenkins use case at
<amz3>the jenkins example is at 30 minutes
***jubalh is now known as Guest23947
<alezost>Guest23947: hello
***Guest23947 is now known as jubalh_
<amz3>hey guix people, want to learn guile !
<amz3>comments welcome!
<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>i just started reading sicp
<xd1le>and i'll probably read this shortly too
<amz3>it's very short
<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
<xd1le>afaict sicp uses scheme
<amz3>ah yes, it use scheme
<amz3>right x)
<xd1le>yeah bc it says so
<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
<amz3>sorry I was interupted
<xd1le>scheme has oop?
<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 ;)
<xd1le>amz3: how?
<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>well, no
<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
<amz3>cloos is famous in lisp
<amz3>xd1le: see you :)
<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
<df_>that's true
<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>yes, I plan to do this, but I'm reading the book of a former python dev
<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
<Gamayun>'explicate' ;)
<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 script created by `vm`?
<civodul>lfam: what's wrong with 'vm-image'?
<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>the image includes GRUB
<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
<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.
<civodul>mine is an i5 too
<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>Oh well :)
<lfam>Is that the one about the spacebar? ;)
<taylan>had the same in mind :D
<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.
<taylan>I'm now seeing this in the and wondering whether my patch has any implications on it:
<civodul>taylan: i think 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>DHCP client, rather
<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>oh ok, that's nice
<taylan>well I'll try to test tomorrow what happens when there's no gnutls, in any case
<civodul>great, thanks :-)
<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