<tyrion-mx>for some reason my home directory was not created <tyrion-mx>:S it worked. I rebooted now grub does not start anymore <paroneayea>still don't have it solved, but I did have a bug in my code that I hadn't realized <paroneayea>ACTION still trying to netcat on both sides, failing <paroneayea>ACTION opened up a screen session on the server, runs "nc -l 8889" in one screen window and "echo debugz | nc 127.0.0.1 8889" and nothing happens! <paroneayea>so of course, going across the vm layer isn't going to either.... <paroneayea>maybe time to test with an ssh server or something. <mark_weaver>sneek: your home directory is probably on the root partition, obscured by the mounted filesystem. you should copy the dot files from your home directory as created by guix. you can get to your hidden home directory by bind-mounting the root filesystem somewhere else, using a command like "mount --bind / /rootfs" <mark_weaver>sneek: later tell tyrion-mx: your home directory is probably on the root partition, obscured by the mounted filesystem. you should copy the dot files from your home directory as created by guix. you can get to your hidden home directory by bind-mounting the root filesystem somewhere else, using a command like "mount --bind / /rootfs" ***codemac` is now known as codemac
<davexunit>so many things to hack on... but what to hack on right now? <davexunit>I wrote an nginx service last night, but I noticed that if I 'deco restart nginx' that it just hangs after starting it back up again. <davexunit>since nginx already runs as a daemon and has its own mechanisms for managing it, I opted to simply invoke nginx via system* <mark_weaver>I have baby duty right now, so can't talk reliably or much right now, but one question I had is: why did you make scripts to run the nginx start/stop commands instead of just running those commands directly? <davexunit>mark_weaver: because I'm not good at gexps :) <mark_weaver>also, the default config file should not hardcode the paths that can be overridden by the keyword arguments. it should take those into account <mark_weaver>anyway, I'm one-handed right now, so going afk again... <davexunit>hmm, there doesn't seem to be a way to add custom actions to guix services. <davexunit>dmd services facilitate this, but our <service> record type does not. <marusich>I have reviewed the section of the manual on using the guix configuration system; however, I'm not sure how to specify multiple file systems. If I want to mount a root fs and also another fs (e.g., for the users' home directories), how would I specify that in the config file? <davexunit>marusich: the file-systems field expects a list of file systems <marusich>davexunit, I think what I am missing is the scheme syntax that is expected; I'm only beginning to learn scheme, so it isn't obvious to me. <marusich>Can you point me in the right direction? <davexunit>(cons 1 (list 2 3)) produces the list (1 2 3) <davexunit>(cons* 1 2 (3 4)) produces the list (1 2 3 4) <davexunit>cons* allows you to add multiple to things to the front of another list <marusich>I see. I was able to find information about cons by searching around, but I couldn't find information about cons*. Where might I have looked to find that on my own? <davexunit>since you have guile installed for working with guix, you can also run 'guile' and ask for doc strings at the prompt <davexunit>but the Guile manual is your friend for learning more about how to use things. <marusich>I'll take a closer look at it. Thanks for the tips! <davexunit>you're welcome. I hope you come to enjoy Scheme once you learn the basics. <marusich>I'm reading through SICP, and so far I'm quite intrigued :) <marusich>I see in the Guix manual that it is possible to roll back system updates. I understand how to roll back a change to my own user profile using something like guix package --roll-back, but I do not see how one does this for the system itself. <davexunit>marusich: that is done via the grub boot menu <marusich>Oh, so you'd just select the previous version from there? <marusich>Are there changes that can't be rolled back? for example, if I update my system's config file to include a new file system, but later I decide I want to remove it after all, can I do a "roll back" or do I need to run something like "guix system reconfigure" on a modified copy of the config file which happens to be identical to the original one? <davexunit>in that case, if nothing else is different that you want to keep, you can just reboot and choose the old version of the system without that file system. <davexunit>the things that can't be rolled back are the inherently stateful things outside of guix's control: home directories, databases, etc. <marusich>My understanding is that GRUB "basically" just chooses what kernel to load and passes in some arguments to it. How is it that you can have totally different system configurations defined by different GRUB menu entries? Where might I look to find out more about that? <marusich>I don't want to take up your time with such minutiae, but I'm interested to know how to find out how those kinds of nitty gritty things are impliemented in the case of Guix, so I can understand it and hopefully help contribute later on. <sprang>I'm trying to integrate with geiser. The manual suggests, under "The Perfect Setup", doing this: (add-to-list geiser-guile-load-path "~/src/guix") <sprang>but I'm not sure where that goes... looks likes emacs/init, but 'geiser-guile-load-path is not defined <davexunit>marusich: to see the generated grub configs, you can run a command like: find /gnu/store -name "*grub.cfg" <davexunit>marusich: and you would want to check out gnu/system/grub.scm in the source <davexunit>(I haven't hacked on this part of the system, so I don't know much more than that :) <davexunit>sprang: have you done (require 'geiser) in your config? <sprang>still no joy, tried (require 'geiser) and (require 'geiser-install) <sprang>my understanding is that I shouldn't need those since I installed geiser through emacs package manager <sprang>without the load-path (or setting it directly) <sprang>doesn't seem to know anything about the guix code though, at least as far as I can tell <sprang>"no code for module" after ,use step <sprang>let me try setq'ing the load-path again <sprang>I'm trying to understand the general workflow... say I open a package (emacs.scm) and have the cursor over one of the inputs, how would I easily jump to it <davexunit>compiling the buffer loads it into the geiser sessoin <davexunit>the M-. stuff isn't your run-of-the-mill ctags or etags or whatever <davexunit>it's actually using the source information contained within the running guile environment <davexunit>once you know that simply looking at the code isn't enough, you have to load it into your guile session. <sprang>I've been reading about lisp/scheme/elisp and dabbling a bit for a long time, but this is the first time I'm trying to be a real lisper :-) <sprang>thanks, hopefully I can make some useful contributions once I get up to speed <sprang>tomorrow I'm going to try to get GuixSD working on the libreboot x200 I just received <davexunit>happy to see so many new people come by here <davexunit>I need to go to bed now. until next time, happy hacking! <marusich>During boot, the system's output stopped for a while, so I figured it was waiting for my input, even though there was no prompt on-screen. When I typed in my password for the encrypted device, the system immediately resumed booting up. Is this expected behavior? <amz3>marusich: sorry, i don't know. If nobody else can help you come back at 12:00 AM GMT. During the summer there is less devs around this time <sneek>Camel_, davexunit says: we do not yet have an nginx system service, though we do have a package. writing the service has been on my TODO list for awhile and I would be very happy if someone beat me to writing it. :) <Camel_>I've tried set screen resolution in Guix, but failed. <Camel_>(slim-service #:startx (xorg-start-command #:configuration-file (xorg-configuraion-file #:resolutions '((1366 768)))) <sprang>I think all the knowledgeable people are asleep at the moment <Camel_>By the way, what commands should I pass to upgrade my guix system? <Camel_>guix refresh --update && guix system reconfigure /etc/config.scm? <amz3>Camel_: you must do guix pull before all the other commands <amz3>also regargarding davexunit message Andreas posted a patch for a basic nginx service, look at guix master or the mailling list <amz3>regarding the resolution, I use a xrandr command to set up the resolution in .xsession. Maybe some else will have better answer <Camel_>amz3: Should guix pull && guix refresh --update && guix system reconfigure /etc/config.scm be enough? <amz3>guix refresh --update must be run as your normal user <amz3>and system reconfigure as root <amz3>and *both* requires that you guix pull <amz3>try that or wait for better answer ;) <marusich> Camel_: I was able to change my system (specifically, I was modifying mapper and file system mounts) by doing "guix pull" once and then doing "git system reconfigure $path_to_config_file" followed by a reboot, multiple times, until I got what I wanted. You can probably do something similar. <Camel_>"The primary audience of the guix refresh command is developers of the GNU software distribution." <phant0mas>while hurd-minimal libs are in the library path of the bootstrap environment, it fails to link against libhash <paroneayea>davexunit: so re: the port redirection stuff I'm working on <paroneayea>at this point I'm pretty sure it's passing the right stuff to qemu, and i can tell it even claimed the port it's redirecting locally, but <paroneayea>but it should be adding the right arguments, but for whatever reason I just can't get it to happen... maybe similar to why I can't netcat over localhost on the vm though I can on my own machine <davexunit>can you get something to work without using guix at all? <paroneayea>davexunit: good question, using the same arguments to say a debian image with qemu or something? <davexunit>paroneayea: yeah, something to reduce the problem set <davexunit>is it guix that is the problem, or is it the networking setup on your machine? <paroneayea>(an irony since I advocate for decentralized networked applications?) <davexunit>yeah, well we'll both keep working on it. ;) <paroneayea>most webdevs don't have to be good "at networking" though. <davexunit>I have to learn a thing or two for container networking <mark_weaver>paroneayea: first off, have you looked at the generated script to verify that the -redir arguments are getting generated as you expected? <mark_weaver>if so, then the second question is: are those -redir arguments sufficient. I have almost no experience working with VMs, so I don't know. <davexunit>yeah, I think there might need to be other networking config done <mark_weaver>reading the backlog more carefully, I guess he confirmed the answer to my first question and more. <paroneayea>mark_weaver: I've looked at the -redir arguments <paroneayea>but yeah I suspect more networking config things must be done <paroneayea>well I... sorta got some success with debian and qemu? :) <paroneayea>I got it to the point where I could ping it from that port on my machine to the virutal machine, and it soorrrrrta went through <paroneayea>it complained about not being able to reverse lookup the source <davexunit>reading it further I have some disagreements of opinion, but that's fine. <paroneayea>I think wingo's post is pretty realistic for a person who wants gnome to work and whatever hardware they have laying around at the moment Right Now (TM) <paroneayea>I think the main disagreement I might have is that he doesn't point out why deco is used in guix <paroneayea>which is because of the integration with service definitions <davexunit>yeah I wish he explained that the Guile integration makes it very attractive to us. <davexunit>we need to implement a reader for systemd unit files <amz3>I understand that his main arguments is: I need/want GNOME <davexunit>thankfully wingo isn't someone that just sits on the sidelines, he packaged a good deal of GNOME things in his short sprint with guix hacking. <davexunit>anyway, here's to hoping that it sparks a good conversation on HN :) <amz3>yes. he has a goind point. <davexunit>I also feel like we had some miscommunication about the nonfree stuff. he seemed upset at our attitude here, but we really didn't mean any harm. <davexunit>wingo is pretty much the last person I'd want to feel unwelcome here. <davexunit>being FSDG compliant is a real double-edged sword. <amz3>I'm not a good enough english reader to understand that <davexunit>what I mean is that it has great advantages and disadvantages <davexunit>one disadvantage being that our distro is not viewed as a practical solution <amz3>well, for gaming it's not a pratical solution as of right now maybe that's what he implied <amz3>at the same time, i did not try games with guixsd so maybe it works <davexunit>I think it was mostly about the proprietary firmware he needed for his intel wireless chip <quasinoxen>how does one come out with the impression that dmd is like systemd is beyond me <mark_weaver>I will freely admit that dmd is very primitive right now and needs a lot of work. I wouldn't have written that those words myself. <rekado->does someone have an overview on what is still required for GNOME? <rekado->we have a package for elogind, but no service for it yet. <mark_weaver>ultimately, dmd will be better for us because of the guile integration, and also systemd is not an option for us since we intend to support the hurd and the systemd developers are unabashedly uninterested in portability to anything other than linux (the kernel) <rekado->I just patched the build process until it compiled, i.e. by readding stuff Andy threw out. <quasinoxen>dmd at its state is indeed rather minimal, but the fact that it's Scheme in of itself bears plenty of leverage <davexunit>I spent some time reading the dmd code last night <quasinoxen>though i suppose many find that difficult to appreciate <davexunit>one feature that I would like it to have is repl server integration to facilitate live coding <mark_weaver>I'm currently working on one of the steps toward GNOME: network-manager, and my preliminary work has uncovered some serious problems in our current polkit and some other issues with the underlying frameworks. <quasinoxen>Does anyone actually know what features from systemd people want in dmd? <quasinoxen>Actual justifications, not just buzzwords like "socket activation". <davexunit>if we can hack a running dmd instance and add/remove/replace services easily, it will be a lot easier to work with. <davexunit>quasinoxen: hehe, "socket activation" *is* one of the things I want. <mark_weaver>quasinoxen: for starters, I definitely want the socket/dbus/automount activation stuff <rekado->davexunit: repl server sounds nice! I want a REPL everywhere. <quasinoxen>Do you define socket activation as pre-opening a socket, as passing fds, as doing inetd-style waiting, or...? <davexunit>the systemd way is pre-opening a socket and telling the daemon which socket to use, right? <quasinoxen>I'd wager integrating something like UCSPI would achieve more flexibility. <davexunit>I don't know a lot about this stuff, so I yield to whoever actually knows what they're talking about. :) <davexunit>all I know is what I want to live hack dmd because it will make my day to day life easier. <davexunit>dmd has a reload feature right now, but I don't know how to use it effectively <quasinoxen>Most "activation" schemes are simply fancy terms for conditional execution to begin with. <quasinoxen>Given dmd being Scheme, these would be relatively trivial to add. <mark_weaver>the basic idea is that systemd starts listening to all the sockets (and dbus services and for automount requests) immediately, before starting anything, and then lazily starts up the daemons upon the first attempt to talk to them over sockets/dbus or by attempting to access something within a mount point. <mark_weaver>so first of all, this means that dependencies don't have to be declared at all. <mark_weaver>and it massively improves the parallelism of system startup <mark_weaver>it would be a huge improvement for us to have this in dmd <mark_weaver>and it's probably not that hard to implement. there's just so much to do. <quasinoxen>This isn't exactly true. Dependencies are still used for ordering and relationships. In fact, the complex dependency and transaction management is the cornerstone of systemd. <quasinoxen>Parallelism, I'm not sure if it's even correct. It's more like asynchronicity than anything else. <quasinoxen>You have fundamental I/O constraints per Amdahl. <quasinoxen>launchd was the one that thought up the buzzword "socket activation" and it still requires sysadmins to manually set up synchronization and ordering policies, usually via Mach IPC or some other mechanism. <mark_weaver>CPU is not 100% utilized while starting up most services <mark_weaver>often they have to wait for I/O, or for some hardware device to become available, or whatever <mark_weaver>and when service B depends on service A in some way, it's a waste to have to wait for A to completely start up before even beginning to start B. <mark_weaver>these lazy activations allow A and B to start in parallel <mark_weaver>and maybe B won't even try to contact A until near the end of its startup procedure <quasinoxen>It's more concurrency here than it is parallelism. <quasinoxen>Since the point is to have deferred resource access. <quasinoxen>"Socket activation" needs to be expressly defined since it's ambiguous. It is a very small subset of checkpoint/restore in the larger view. <quasinoxen>Bus activation is already supported by D-Bus natively. <mark_weaver>okay, perhaps concurrency is the more appropriate term. I confess I mostly use them as synonyms <quasinoxen>I'm not sure how you're using "automount activation" here. Do you mean autofs, or device node managers listening to uevents? <quasinoxen>If so, assuming you're using (e)udev, this can already be done from rule sets. <quasinoxen>Though writing your own uevent listener isn't hard. <mark_weaver>I get the impression that you know more about this than I do. I confess I've only read a few articles by Poettering. <mark_weaver>however it is implemented, we could use similar features <quasinoxen>This is a problem in general with following any herds. You have to analyze your own needs and deconstruct the problem. <davexunit>mark_weaver: I'm curious what would change in the dmd api since right now it's very much based on the notion of dependencies <quasinoxen>They should be orthogonal, assuming architectural cohesion. <mark_weaver>well, for example, right now our services have to be started up serially, and the dependencies must be explicitly given. <quasinoxen>Again, all instances of x-activation boil down to conditional polling/waiting and exec()ing upon a return. <mark_weaver>and if service B depends on service A, the only place to declare that is within service B. <quasinoxen>It's a simple mechanism, I assume one could even have a generic activator function. <mark_weaver>and for example all of our non-root filesystems are mounted in the same phase of startup <mark_weaver>quasinoxen: if you'd like to work on this, that would be most welcome <mark_weaver>right now I'm working on something else (pidgin and pidgin-otr) <quasinoxen>mark_weaver: Thank you for the invitation. I'm rather occupied with other projects, however. I just finished conducting an experiment with Android init on GNU/Linux. I expect to post the article today or tomorrow. <davexunit>mark_weaver: oh cool, I started working on a pidgin package awhile ago and didn't make it very far <davexunit>due to lacking some dependencies that looked difficult to package <quasinoxen>Since I have been meddling with the Hurd, looking at dmd might not be out of scope soon. ***davi_ is now known as Guest90944
<mark_weaver>I have pidgin working, and I'm just working on allowing pidgin to find the OTR plugin. <quasinoxen>davexunit: Do you have any suggestions for promoting, other than working on X activation support (which in all honesty I do not see as high priorities, but providing a generic solution may be technically interesting)? <mark_weaver>another thing that DMD desperately needs is to way to update its services safely without rebooting the system. <mark_weaver>and also, to have it not die and thus cause a kernel panic if something goes wrong with one of its service definitions. <mark_weaver>the last time I added a service (wicd-service) to DMD, debugging was a pain because DMD would die and the kernel would panic (as it does when PID 1 dies), and it was hard to see what was wrong. <mark_weaver>it ended up being a simple typo; I mispelled an identifier somewhere. <mark_weaver>ideally, DMD would run the code associated with service definitions within a subprocess <mark_weaver>and this also seems like a good approach to allowing those service definitions to be replaced without restarting DMD. <mark_weaver>in a sense, DMD allows everything we need, because you can connect to it and get a REPL and change whatever you like in the running DMD process. <mark_weaver>however, it's unsafe. make a mistake, and boom, your system panics. <davexunit>DMD's REPL server integration should guard the evaluated code. <mark_weaver>we could improve the safety somewhat using Guile's exception catching mechanisms more comprehensively within DMD <mark_weaver>and maybe that would be good enough in practice, I don't know. <davexunit>it would certainly be an easy thing to start with <davexunit>that's how I keep typos from crashing the games I write in Sly. <mark_weaver>the thing is, since we also want to be able to update service definitions, it would seem clean to have those service definitions in separate guile scripts on disk, rather than loaded internally into PID 1. <mark_weaver>but i suppose this is a major architectural change, and maybe there are substantial disadvantages to it. I haven't thought it through. <paroneayea>I hope we can get mediagoblin and guixops to the point where I can switch my servers over to them soon, but if not I might switch to nix/nixops and keep helping until guixops is ready <paroneayea>I'd definitely prefer to have a guile basis, amongst other things, so I'm committed to guixops succeeding <paroneayea>in the worst case it might not be bad to learn how nixops works firsthand so I can help better with guix anyway <mark_weaver>it's too bad he anti-recommended guixsd and recommended a non-free system instead :-( <davexunit>I hope some day he will recommend it without caveats <davexunit>I wish we didn't get our wires crossed with regards to the nonfree firmware thing <mark_weaver>I guess he's not on board with a fully free OS, which is a disappointment. <mark_weaver>I guess he's more in the "I bought this newest Lenovo laptop without thinking about these issues, and now I just want you to include whatever's needed to make it work" camp. <davexunit>I just don't want him to feel like his presence isn't wanted because he doesn't personally use a fully free OS. <mark_weaver>well, I was quite clear that I was glad to see him here and welcomed his involvement, and even helped him create his custom linux package. <davexunit>well, I hope we all just continue to get along. I'm very happy that he shared how he's using guix to do v8 development. <davexunit>it's a good example of someone doing "real work" with guix <davexunit>curious why he didn't use 'guix environment'. <mark_weaver>I should make it clear that I like and admire wingo enormously <mark_weaver>I can be disappointed with someone that I love and admire <davexunit>happy hacking to all, and to all a good hack. <davexunit>interest in guix is definitely starting to grow. I'm excited. <mark_weaver>I really want to make a push to make progress on GNOME. <mark_weaver>these pidgin and pidgin-otr packages are done. one final test and I'm going to push it. <mark_weaver>then to try to get network-manager working. that is a tough one <ecraven>from a very distant point of view, is guix like nix? <davexunit>there are important differences, but if you squint, yes. ;) <ecraven>davexunit: does guix have anything like nixos' automatic provisioning of multiple containers/vms? <ecraven>I'd love to have something that uses Scheme :D <ecraven>I'll watch the fosdem video and read up on the docs, maybe I can help :) <davexunit>I've prioritized getting my container implementation into master <davexunit>and paroneayea here will be helping with the deployment stuff, too. <ecraven>I'll lurk, and ask questions when I know more <davexunit>so I'm aiming for something similar, but with a nice, Schemey interface. <ecraven>most of what I've seen is really nice in nix, I especially like that I can describe the entire system in one (or a few) files <ecraven>I'd love to have something like this for the servers I deploy to <davexunit>being able to define your system precisely, down to the compiler's compiler, is a huge win for me. <ecraven>great to have found you ;) have to run, but I'll study things a bit, then come back with proper questions ;) <mark_weaver>now to bang my head against network-manager some more :) <davexunit>I have no idea why redis fails its test suite, but at this point perhaps I should just propose the package with tests disabled and a note about it. <mark_weaver>somehow I suspect that network-manager will be at least an order of magnitude easier than ruby and node <paroneayea>mark_weaver: thinking out loud, would you be interested in running a guix hackathon with me either at fsf 30th or at librepplanet? <paroneayea>mark_weaver: I'm considering asking if we can do such a thing <mark_weaver>paroneayea: hmm. our community is so small now, I'm not sure there will be many people physically there to participate. <paroneayea>mark_weaver: hm, that's true, might be a good way to get people started :) <mark_weaver>rekado-: the source URI for 'vamp' is broken. can you find a new link? <mark_weaver>paroneayea: if we were to do such a thing, I suspect it would be a better fit for libreplanet than for the fsf 30th. <mark_weaver>I dunno, I feel like at this point, Guix hackathons are better done online.