IRC channel logs


back to list of logs

<davexunit>ACTION needs to tweak ruby-build-system to work with regular tarballs and directories instead of just gem archives
<davexunit>makes it hard to build from git when you have to.
<sprang_>I'm trying to figure out where the progress string for substitution downloads comes from...? it looks like it should be in guix/build/download.scm, but modifying the output there has no effect
<davexunit>hmmm not sure
<davexunit>never looked at that part of the code
<davexunit>ACTION hacks on containers
<sprang_>looking at progress-proc in that file
<davexunit>'guix environment --container' is feeling pretty decent now.
<sprang_>I'm working on prettying up the log when downloading... I have "guix download <blah>" showing a little progress bar
<davexunit>oh neat
<davexunit>that will be a nice UI improvement
<sprang_>should probably ask any #guile, but this is related. how does one get the width of the terminal? something like ioctl seems to be missing
<davexunit>sprang_: we have the beginnings of ioctl bindings in (guix build syscalls)
<sprang_>oh cool, I will check that out
<davexunit>what you want is probably missing
<davexunit>I have a patch in my own guix repo that starts to add bindings for pty stuff
<davexunit>for containers
<davexunit>sprang_: do you know the C code that you would need to get the terminal width?
<sprang_>it's not critical for what I'm doing here, but it'd be nice if I could adapt the output to the actual line length
<davexunit>leave a nice big TODO on the code :)
<davexunit>help would be appreciated sometime with terminal stuff like this
<sprang_>yeah, there's just a simple call to ioctl that can extract the value
<davexunit>I'm building up Guix to be a Docker competitor so we'll need it :D
<davexunit>sprang_: oh cool.
<sprang_>I think wrapping all of ioctl would be a bit more work
<davexunit>I'm pretty ignorant of the ioctl craziness.
<sprang_>I'm just really looking at it for the first time
<sprang_>oh, another question, is there a nice way in emacs to line up the values in a let statement, or the consequents in a cond, for example
<sprang_>that seems to be the style (at least in the guix file I'm editing)
<davexunit>sprang_: I don't know of one, that's a good question
<sprang>ha: (define %ioctl ;; The most terrible interface, live from Scheme.
<davexunit>sprang: :)
<davexunit>sweet, 'guix environment --container' now only bind-mounts the store items that need to be included in the environment
<davexunit>that is, the union of the closures of the packages.
<rekado->I'm still getting this error in the wicd logs: "dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.24" is not allowed to own the service "org.wicd.daemon" due to security policies in the configuration file"
<rekado->this happens after a fresh boot.
<rekado->as a result I cannot use wicd and have to use iproute2 to manually set up networking.
<rekado->it works fine on a fresh installation of GuixSD on another machine.
<rekado->this is my system configuration:
<rekado->even if I replace my services with this expression ( the behaviour is the same.
<rekado->the only weird thing about my setup is that /home is a logical volume on an encrypted device.
<rekado->after booting I manually decrypt, refresh LVM, and mount /home.
<rekado->when I then log in to XFCE I get the wicd error.
<rekado->anything dbus is really broken on my system.
<rekado->deco status dmd after reboot shows this:
<rekado->Stopped: (geoclue-daemon colord-daemon networking avahi-daemon upower-daemon ntpd)
<rekado->also for avahi: Connection ":1.19" is not allowed to own the service "org.freedesktop.Avahi" due to security policies in the configuration file
<rekado->did not reconfigure after last change; after removing "gnome-keyring" from my list of dbus-services, everything works fine.
<rekado->must be a broken dbus configuration for gnome-keyring.
***breton_ is now known as breton
***davi_ is now known as Guest57671
<davexunit>ACTION wonders about using xpra ( to "containerize" graphical applications
<civodul>davexunit: would be neat
<civodul>hey there!
<davexunit>civodul: hey!
<civodul>ACTION happily updated \\o/
<davexunit>civodul: armhf build machines! :D
<davexunit>ACTION fixes clone
<davexunit>very exciting to finally have that. I've been meaning to bootstrap my novena off of one of mark_weaver's machines but I just haven't gotten around to it.
<davexunit>sprang: thanks for the donation!
<davexunit>civodul: how soon until these things are in action?
<civodul>the Novena offered by sprang has been building for a couple of days already :-)
<davexunit>oh wow
<civodul>just core-updates so far
<civodul>thanks to mark_weaver who's taken care of it
<davexunit>is the other machine a Novena as well?
<civodul>no, it's a Wanderboard, and apparently it's more work to get it running
<davexunit>ah, never heard of that one
<davexunit> ?
<davexunit>solo, dual, or quad? sorry I'm nosy. ;)
<davexunit>ACTION attempts to get clone to behave like primitive-fork
<davexunit>using clone in the REPL revealed issues that primitive-fork doesn't have
<davexunit>primitive-fork results in a clone syscall that uses these flags: CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD
<davexunit>the clone calls I've been making have SIGCHLD, but not the other two.
<sprang>oh, awesome (novena set up). happy to help!
<davexunit>yesss CLONE_CHILD_CLEARTID | CLONE_CHILD_SETTID did the trick :)
<davexunit>ACTION sends container improvement patch to the list
<sprang>I'm trying to figure out where the progress string for substitution downloads comes from...? it looks like it should be in guix/build/download.scm, but modifying the output there has no effect
<davexunit>sprang: I imagine you've read guix/scripts/substitute.scm?
<davexunit>and are you using ./pre-inst-env to use the code you're editing?
<sprang>I have latest symlinked to my dev dir
<sprang>I poked around in there
<davexunit>sprang: make sure you are using ./pre-inst-env
<davexunit>that is likely the reason you aren't seeing your changes
<sprang>I see my changes if I do "guix download whatever" but the substitution stuff seems to be generating the progress string from somewhere else
<sprang>anyway, I think I am going to submit what I have as a patch and go from there
<davexunit>sprang: so, the daemon invokes guix-substitute-binary
<davexunit>you would need to run your own daemon using ./pre-inst-env
<davexunit>unless there's another way to tell the daemon what substituter to use
<davexunit>haven't looked into it
<sprang>oh, I think I see what you're saying
***frob_ is now known as auxo
<davexunit>sprang: yeah, you're working on the client software, but using the already running daemon installed to the system
<davexunit>which uses its own substituter
<davexunit>ACTION has working --expose/--share flags for 'guix environment --container' like 'guix system'
<davexunit>but now it's making me think of what the boundaries of certain subcommands should be
<civodul>davexunit: woohoo!
<civodul>that's really cool
<civodul>container built by 'guix environment' is not a full OS, unlike that created by 'guix system'
<civodul>i guess that would be the main difference, no?
<davexunit>civodul: yes
<davexunit>but then there's also the desire to have a 'guix container' subcommand to do things like insert processes into containers, pause/kill containers, and other daemon-style management things.
<davexunit>but I think having 'guix system' and 'guix environment' handle simple container things without requiring a daemon is nice.
<davexunit>and fancier container management stuff could happen in 'guix container' later when we get around to it.
<davexunit>ACTION goes afk