<lfam>Well, you could restart the service and try winning the `ps` race ;)
<lfam>I don't know how to find this information is a better way, but I'm sure there is one
<reepca>well, I ran herd enable ntpd and then herd start ntpd and I'm not seeing any new respawn messages in shepherd.log
<reepca>Still can't get into the GUI though, it seems to be frozen. Maybe if I restart and try one other than xmonad?
<ng0>we have tlsdate.. but i don't know if this is functional enough on guix (service?).. if ntpd is the problem
<reepca>okay, now I've restarted and tried starting a session with i3-wm and there's some red text in the bottom-right that says "Error: status_command not found or is missing a library dependency (exit 127)". There's a cursor I can move around and stuff but nothing there.
<reepca>okay so the problem with ntpd *does* happen when starting it directly via herd. Will try starting manually now.
<lfam>reepca: In i3, there is always nothing there. Try win+t for a terminal emulator or win+d for dmenu. I wish I had another name for that key ;)
<lfam>Some people try logging in in ways that set up the environment incorrectly, but logging in at the console should work fine unless you have written a broken shell initialization script and broken $PATH
<reepca>oh man... tried running guix pull to get newer icecat for my user (just realized that the guix versions for root and users aren't linked) and got complaints about 2016-10-12 being in the future. I should really find out what's happening with ntpd.
<lfam>I know that ntpd won't work normally if your date is very wrong
<lfam>I think you'll need to use ntpdate to force a clock update
<reepca>manually running ntpd the way it was listed by ps seems to cause it to print some stuff and then exit
<lfam>There's a cycle involving gtk+@3 on core-updates
<reepca>This is depressing. I'm watching information about the disk (in this case flash drive) usage scroll down as another terminal uses guix to install stuff. Rarely over 4KB/s, sometimes as high as 1 or 2 megabytes per second. It's just... saddening. I mean at least the flash drive works, unlike the 3 16GB ones I bought (all defective). Why do I have such rotten luck with flash drives?
<reepca>I'll be happy when I can get back to running icecat, had to use my other crappy flash drive to transfer the patch paste text. And I had to read up on the documentation for mount. Which you'd think I wouldn't need to do after using linux for over 2 years, but I guess Ubuntu spoils me.
<reepca>ahaha... with the patches, ntpd is still immediately shutting down and then getting started by shepherd. But the funny part is that I know why: "unable to bind to wildcard address :: - another process may be running - EXITING". I left my manually-started one on by accident lol
<reepca>terminated it, ntpd seems to be working fine now
<lfam>I wasn't sure if we'd yet taught shepherd to reload a changed ntpd service without rebooting. I'm glad it's working.
<reepca>now will I have to restart to see if the b43 firmware package helps?
<reepca>uh oh, now I've got an error message about ntpd: ntpd: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized. Not sure what the deal with that is.
<reepca>hm, apparently openfwwf-firmware is unbound. It's defined with define-public in the patch... what exactly does define-public do (coming from a common lisp background here)?
<reepca>I'll just rebuild it and log the build this time. Oh, and run make check. Probably should have done that the first time.
<reepca>and now I'm getting "perf: Interrupt took too long (<some number in the thousands> > <some other number in the thousands>), lowering kernel.perf_event_max_sample_rate to <some number in the ten thousands>
<reepca>arg, should have run make clean first. It didn't try rebuilding so I could see if anything went wrong there, just ran tests...
<reepca>getting quite a few ";;; ERROR: missing interface for module (charting)" messages
<reepca>okay, one of the tests failed: "FAIL: tests/syscalls.scm"
<reepca>ACTION goes to sleep now, class in the morning, look forward to working on this further
<ng0>I wonder what happened with neomutt.. been a while since someone told me my patch is working, but no patch got back to the list
<ng0>mutt is one of the many things where gentoo is not sticking to upstream.. you can create mutt, but the default is a frankenstein creation of mutt+neomutt+some+more+sources, which was actually very nice
<ng0>but if you start to believe this is mutt, you get irritated by the real mutt and its missing functions
<ng0>efraim, are you okay with me using this in an update to the vim.scm in master and if you aren't already named in the header adding your name there?
<efraim>ng0: sure, but it should be pared down a bit. In particular I don't think python2 and python3 can both be in at the same time
<efraim>I don't remember what some of the options mean
***tschwing_ is now known as tschwinge
<wingo>gpg fails to build on core-updates due to a patch that does not apply
<fps>jmd: ideally the guix cli should be self documenting :)
<ZombieChicken>"self documenting" doesn't help if people have a hard time finding the help 'feature'. And telling someone "Go sort out the Scheme code to learn how to use our software" is a really, really bad answer
<davexunit>ZombieChicken: that is not what the question was about
<jmd>rekado: It is difficult to assume good intentions from judgemental comments such as "you decided to ignore my advice"
<rekado>I have to go now but please look at the order of comments again. It would be good to avoid needless escalation like that in the future.
<davexunit>jmd: you responded to me with a complaint about it not being documented. it *is* documented but I just don't know the name of the procedure so I can't point out where in the guile docs it is!
<reepca>um... okay, so that was interesting. I had a separate ntpd running and killed it so that I could run the service one with herd, and thought I'd try out some command-line syntax to see if it worked, so I typed "herd enable ntpd start ntpd". And then I got a kernel panic and everything stopped.
<ng0>do you know if we need a small service for tldate?
<ng0>there's also this network time sync hidden-service based software TAILS uses, but they use some applications to ease their own building process so I'm working on that.. well, only debugging, packaging part is done.
<ng0>in case of software gitlab needs, or like mastodon
<reepca>So in the process of system init'ing another flash drive I've noticed that a lot of time is spent with little disk activity happening (according to iostat) and little cpu usage. I don't think my system could be considered heavily loaded, so I'm wondering what it's doing during that time?
<reepca>Right now it's just saying "copying /gnu/store/asdbasdfkjalsjdf-package..." and there's rather little disk activity happening. Maybe it's my accursed luck with flash drives at it again. But I tested this one, and it went at a pretty steady 27MB/s (not great, but definitely good enough).
<mark_weaver>reepca: I'm not sure if messages of consistently printed during network activity.
<reepca>it did a bunch of downloading from hydra, then it said "initializing operating system under 'media/reepca/GuixFlash/'", and now all it says is that it's copying stuff, but there's rather little disk io happening and it's taking quite awhile
<mark_weaver>reepca: if you tested disk activity with some simple file write before, it may be that the I/O patterns used during install are handled much less efficiently by the flash device.
<mark_weaver>the underlying flash hardware is not able to do random writes, so it requires a rather elaborate translation layer.
<reepca>so wait, flash hardware has variable latency?
<reepca>but still, it can go 8 seconds at a time with nothing being written to it according to iostat. Those would have to be some *really* weird i/o patterns
<ng0>can someone show me a bug/thread link where using the /gnu/store on a separate, dedicated partition lead to problems and was solved during that thread? the gentoo problem is just that. but we're discussing off list about that, which is not so good to make it publicly visible for progress
<ng0>or some 'do this, do that, done' line I could link to in the gnunet.org chat log
<ng0>rekado: there's this [https://github.com/Gargron/mastodon] which looks like a easy job but is in beginning stages.. already functional, but I want to see the password bug I just reported to be solved before I start with it
<ng0>all procrastination to slow me down with debugging services :/
<catern>hey #guix, besides grafting, are there any alternative ideas for mutating dependencies without rebuilding dependent packages?
<catern>that is a really useful ability for development
<catern>but grafting is (probably) way too slow to use for development
<catern>where "development" means I rebuild Z and now A, B, C are using the new version of Z and I test A, B, C
<catern>without having to rebuild A, B, C. like, I mean, maybe point A/B/C at some kind of "mutable" package directory?
<mark_weaver>catern: guix is based on the assumption that all items in /gnu/store are immutable. violate that assumption that lots of stuff will break badly.
<rekado>if Z is a library you could use LD_PRELOAD(?) or LD_LIBRARY_PATH to override the library
<rekado>for quick development iterations this might be useful.
<rekado>I wouldn’t always commit things to the store when developing.
<rekado>When I develop things with Guix I mainly use “guix environment”, not “guix build”
<catern>rekado: right, if I'm developing a leaf package, it's fine to use guix environment
<catern>but if I'm developing a library, then I want to see how packages behave when I change the library
<catern>this doesn't have to involve committing things to the store, necessarily, maybe there's a way that doesn't involve store commits on each rebuild?
<catern>the other issue with adding build artifacts to the store is, then I can't just mutate them in-place which is something else I might want to do while developing
<mark_weaver>catern: would rekado's suggestion to use "LD_PRELOAD(?) or LD_LIBRARY_PATH" work?
<catern>LD_LIBRARY_PATH certainly works for the specific case of C libraries
<ng0>afaik no.. when I do changes in gnunet and rebuild it with the guix file, it builds into the store
<catern>but I kind of want a more generic approach
<ng0>minimal changes, but still everything builds into the store. don't know how it would not
<mark_weaver>that sounds like a great goal, but I don't see an easy way to do it.
<rekado>I shudder at violating the invariant that all references map to items in the store.
<mark_weaver>rekado: in the general case, you may run a program that runs subprograms, each of which is wrapped
<catern>well okay so putting what we want to do in Guix terms, one way to achieve this would be, if we had a GUIX_PACKAGE_PATH which things (magically) looked up packages in first before actually looking at the baked-in hash
<mark_weaver>but maybe that doesn't happen often in practice, dunno.
<catern>oh! actually there is one Linux kernel extension that would allow that kind of approach (which sad to say didn't actually get comitted)
<rekado>(we have GUIX_PACKAGE_PATH, but it means something else ;))
<mark_weaver>catern: the deep problem here is that we've written a great deal of code that's heavily based on the assumption of an immutable store. most commonly, when we want to do a logical "copy" operation, we don't bother actually copying the data but only the reference.
<mark_weaver>to be more concrete, guix users have occasionally mutated something in there store, and then run into bizarre problems where they ask guix to build a new package, and the new package is bad because it aliased the part of the store they mutated.