IRC channel logs
2023-09-02.log
back to list of logs
<rekado>minimal packages is easier in a traditional system with a global namespace for all libraries <rekado>because you can build packages fully and then install only some of the libraries, or you can have variants and replace libraries from the small build with libraries from the fully featured build later <rekado>I’ve started to work on a shepherd extension for managing Guix containers. <rekado>it’s pretty crude so I’m calling it “swineherd”. <rekado>it lets you instantiate Guix System containers from OS definitions and perform operations on them (e.g. to bring up / tear down bridged veth networking, or to execute a command in the container context) <rekado>each instantiated container is a shepherd service with a set of actions. <rekado>haven’t really figured out yet how close the integration with shepherd should be. “herd eval root” is powerful enough (and not too inconvenient) to extend a running shepherd process. <vagrantc>doing some housecleaning on the bug tracker ... 14 closed bugs and counting today... :) <Guest40>How do I know that my configured mcron job actually ran? <nckx>Sleep_Walker: I got home very late, sorry. Here's… something: https://paste.debian.net/plainh/84f7055a I hope that makes the issues clear (Guix takes ‘dependencies’ literally—if you pass it the list of every single MD on your system, it will believe you) and gives you something to refine. Night! <nckx>I only verified that the generated grub.cfg is what you said you wanted, not whether it would boot on a system with all those devices :) <Noisytoot>Is there any reason why the packaged rakudo version is so old or is it just that nobody has updated it? <RavenJoad>How should I go about diagnosing an error in the 'validate-runpath' phase? <apteryx>it's usually about adding some locations of the output to the runpath <trannus_aran>hey, is there any way to get guix running on fedora without selinux/jumping to root to start the build daemon shenanigans? <trannus_aran>as far as I know, that's still the way things are now (even with the included systemd .service file for guix) <apteryx>vagrantc: thanks for going through the bugs stack and cleaning it up! <trannus_aran>I'd love to use guix more (and guile more in general, it's my favorite scheme), but the current workflow is clunky ;/ <RavenJoad>apteryx: Does the package being build not get added to the runpath automatically? The validation is failing on a python .so that needs shared objects from the package (which have already been built and installed to $out/lib/... <apteryx>it should if there is a link directive with it <apteryx>but sometimes they are dynamically loaded perhaps... <RavenJoad>It looks like the xen output package is not in the RUNPATH list. <apteryx>ah, or maybe related: [8140639.156586] __vm_enough_memory: pid: 64353, comm: guix-daemon, not enough memory for the allocation <vagrantc>apteryx: i just apparently fell into the mood of doing some low-hanging fruit tidying :) <mirai>apteryx: (fluff) I wouldn't say that only _recent_ cpus have AVX2 <mirai>its been 10y since its debut 😅 <lilyp>still, avx2 is an extension and we want to support older cpus as well <vagrantc>31 bugs closed, 7 retitled more appropriate to outstanding issues. whew. <sneek>samplet?, pretty sure was seen in #guile 20 days ago, saying: That’s an ancient (but still neat) treatment of the idea.. <davidl>When using guix build mypkg --with-input=deppkg=deppkg@ver can you exclude modifying the deppkg@ver for 1-2 dependencies in the recursive dependency chain? Like I need pangomm@2.50.1 but also pangomm@1.4 for some specific ones in the dependency chain of mypkg. <cbaines>I get guix-cookbook.de.texi:611: @menu reference to nonexistent node `A ``Hello World'' package' <janneke>cbaines: after a rebase and make, i get <janneke>no wait a bit, that's the wrong compilation buffer <cbaines>make clean didn't seem to help, but I deleted the contents of files mentioned in the errors, and that seems to have got things working <janneke>cbaines: this was the cheap test, testing a clean worktree now but that will take some more time <janneke>hmm, would be nice if make clean fixed that... <janneke>that's what i did on my scratch worktree to test the build...but i've learnt not to tell others to run that ;) <janneke>well, i guess it should depend on the audience <apteryx>po4a was recently taught to translate nodes lacking a description <apteryx>and such nodes are used in the cookbook (autogenerated via C-c C-u a in Emacs) <oriansj>janneke: completely fair, some people run commands without knowing what they will do and why. <oriansj>others read and apply thinking prior to action; but it is hard to know what is in someone's nature. I tend to favor sharing of knowledge even if it may be dangerous to those who don't criticially digest it. <oriansj>But then again, I hope that no one trusts me blindly <janneke>oriansj: completely fair; people learn best from making mistakes anyway <janneke>oriansj: interestingly, such a thing is said most often by trustworthy people :) <nmeum>I am currently trying to tidy up my /gnu/store: running `guix gc` currently doesn't remove any additional files for me but `guix gc --list-live` prints several paths. how can I determine why these paths are still needed? <ngz>Disclaimer: I know very little in C. If a variable Env is declared this way: char *Env; what kind of value shall I set it to? I assume Env = "foo" is not good, because this is not a string. <ngz>(FWIW, it's Guix-related since I need to understand that to fix a package) <nckx>"foo" is a string, char* is a string. <nckx>A static string, though, which may or may not be appropriate. <ngz>nckx: Thanks. However, I'm still lost (sorry). Later the variable is set like this: Env = kpse_var_value("TEXMFMAIN") I tried to write Env = "/the/dir/i/m/interested/in" but I obtain "munmap_chunk(): invalid pointer" at runtime. <ngz>The error is related because that's the only change I made, and I don't get this error without the change. <lilyp>ngz: the pointer is probably freed later, try strdup ("foo") or similar <ngz>Yes, there is free(Env); a few lines below. <nckx>Right. When you write ‘char *Env = "string"’ at the top [one hopes, style-wise] of a function or file, you're pointing it to a constant buffer that can't be freed. <ngz>nckx: No, I leave the char *Env line alone. I change the line where the variable is set, not when it is defined. <nckx>But the RHS is still a static buffer. <ngz>lilyp: So, I should write Env = strdup("whatever") ? <nckx>(Which is what I do for an entire afternoon if I haven't written C in a month. Fun.) <nckx>Just FYI, since you're probably not used to it: (lib)c functions have man pages. <janneke>boo man-pages, there's an amazing glibc info manual! <lilyp>someone should do an esolang where statements are delimited by 😉️ <ngz>strdup seems to work, indeed. <ngz>IIUC, when I write a raw string to a pointer (?), I need to use strdup, but when the return value is from a function (here kpse_val_value), this is not needed? <lilyp>it's not that simple; if you write a raw string somewhere and it doesn't get freed, using strdup causes memory to leak <lilyp>whether you pass that to another function or use return doesn't really matter here <lilyp>what matters is whether some code calls free (your_string) afterwards <ngz>I understand that part. I'm troubled by the fact that my string needs a special treatment (strdup) while the initial value did not. <ngz>The free(Env); happens in both cases anyway, so it does not explain that difference. <mwette>If the code calls free(Env) then Env needs to be zero or a value returned by malloc(). the global `char *Env;' will cause it to be initialized to zero. <lilyp>the initial string has probably been allocated with malloc <ngz>Ah. malloc (*takes notes*) <lilyp>char *Env; actually returns "random" garbage, doing anything with it before it's assigned results in UB <lilyp>viaken: sure, but that's a little overblown <mwette>lilyp: it'll be in BSS and zeroed on load, unless I mistaken for some odd reason <mwette>assuming Env is defined at "global" level, i.e., outside of a function <janneke>bah, i've removed gobject-introspection from gdk-pixbuf-2 as a dependency for the Hurd... <janneke>...now it fails with _the same_ error as gobject-introspection <janneke>(process:2035): GLib-ERROR **: 17:25:15.280: getauxval () failed: No such file or directory <janneke>jpoiret: this is where guix system reconfige is stuck right now, on the Hurd <lilyp>sounds like glib itself is broken on hurd <lilyp>you need to go back a few more steps, sadly <janneke>i know nothing about any of this gnome party <lilyp>gnome uses namespaces for its errors, so GLib is pretty likely inside of glib itself <janneke>a sad thing that we need gnome to be able to system reconfigure <mwette>lilyp: I lost context when my computer rebooted, I thought ngz said it was declared globally. When inside a function yes, it is garbage. <ngz>mwette: Actually it is defined within the function, at the beginning. <mwette>ngz: so declare with "char *Env = 0;" <lilyp>I think the point is that ngz wants to try things out with a meaningful value. <mwette>or "NULL" to be more conventional <lilyp>But we're solving an XY problem here; ngz, what are you actually debugging? <lilyp>it's related to tex, I can guess that much <kaizer>Hey guys, just got my fresh guix install and I'm pretty stoked to get hacking but I've run into a few problems. I've asked for help already on the guix matrix and system-crafters channels, but all the resources say this is the main place to ask for help so here I am. It's nothing major, rust-analyzer build fails and the patch is already out according to this thread: https://issues.guix.gnu.org/64720. My question lies around the issue of <kaizer>contributing, how to change package definitions and pushing to upstream etc. <kaizer>Also, I just wanna say guix is freaking awesome <kaizer>Anyway, any help is greatly appreciated and a huge thanks to the team that made this possible <ngz>lilyp: the chktex executable needs to locate a global configuration file. Otherwise, this leads to a runtime error. Locating that file happens at build time, in "OpSys.c" where the "int SetupVars(void)" function is defined. <lilyp>kaizer: don't ask to ask, just ask :) <ngz>lilyp: Among other things, that function tries to find the configuration file with the help of TEXMFMAIN environment variable, but that variable is too complicated for it in modular TeX Live. <lilyp>as for 64720, the submitter bumped the patch recently, so it'll take some time to get reviewed <ngz>lilyp: So, I want to short-circuit that part and directly point to the configuration file from the store. Let me paste the full function. <kaizer>Alright, I'll sit tight. Thanks again lilyp. <kaizer>Any pointers on how to get started contributing? I know there's a guide in the manual but I just wanted to ask in case there's anything I should know <ngz>lilyp: Here <https://paste.debian.net/1290765/>. I'm trying to act on (Env = kpse_var_value("TEXMFMAIN")) and replace it with (Env = "/the/store/location/of/the/configuration/file"). But that fails at runtime. However, replacing it with (Env = strdup("/the/store/location/of/the/configuration/file")) does not generate any error at runtime. <vagrantc>kaizer: if you had more specific questions, that would help to answer them <ngz>lilyp: So I'm kinda happy. But since I don't fully understand what I'm doing, I'm trying to make sure there no simpler way to solve this. <lilyp>I'd recommend a wrapper CHKTEX_CONFIG=${CHKTEX_CONFIG:-/gnu/store/...} <lilyp>since that line is tried first, you can circumvent the texmf call <ngz>lilyp: This is what I did previously, but a wrapper is meh, and controlling the value of TEXMFMAIN looks like a more general solution. <ngz>I mean, other binaries could have the same problem with TEXMFMAIN without an environment variable to save the day. <ngz>I can confirm, however, that the wrapper works as expected. <lilyp>fair enough, but what exactly are we trying to do here? <lilyp>circumvent texmfmain at all cost? <lilyp>btw can you paste the definition for tackon as well? <kaizer>Okay. vargantc, my second question was that I was thinking I could help by contributing package definitions or patches when I run into problems and I'm able to fix them. I'm just not sure how to do this exactly. I know there's a guide in the manual but I just wanted clarification as to whether that was all I needed to know. If I solve a problem then sb else doesn't have to deal with it. That's what I was thinking. <lilyp>the most important takeaways from the manual are the following points: <lilyp>1. how to checkout the code and try out stuff <lilyp>2. how to structure your patches <tissevert>I can't build guix from the source (after a complete cleaning, make clean, even rm -rf * && git checkout .) <lilyp>3. how to write your commit messages <lilyp>4. how to use git send-email :) <ngz>lilyp: and to answer your question, some parts of TeX Live do understand multiple values in TEXMFMAIN, so others don't. <tissevert>it's been a while since I've done that so maybe that's just me being rusted, but is it perhaps a known issue in the process of being fixed ? <tissevert>it whines about "@menu references to nonexistent node", a dozen of times, for the german cookbook <tissevert>and since I don't know how guix-cookbook.de.texi is generated, I can't figure out when the problem could have been introduced <kaizer>alright, thanks yet again lilyp. I think I can do all that, no problem, no stress. Time to hack and hunt for bugs! Thanks y'all! <bonz060>Hi Guix. I was in some Linux User's group here in Nairobi, and some one asked me about Guix' government. Other than: "the community is dope; and anything major has the maintenors with the last say", I never really had anything else to say. I feel like I'm missing something. Is this doc'd somewhere? <lilyp>btw. I should warn you, the first patch you submit might take longer; we have a mod manually checking for spam mail <lilyp>bonz060: it's more or less that, but recently there are also topical teams <kaizer>cool, no problem, I'm in it for the long haul <lilyp>we also have a contributer covenant <lilyp>ngz: this looks to be one that doesn't? <ngz>lilyp: Here, TEXMFMAIN is treated as if it should contain a single directory, but TeX Live supports multiple directories in that variable. <RifftE>Is the website down right now? I cannot access it. <ngz>lilyp: You added the #ifdef GUIX_CHECK_CONFIG right? <lilyp>guix.gnu.org works, so it might be a localized issue <ngz>lilyp: But this environment variable is never set? Also, even if it set, the break statement means that CHKTEX_CONFIG is never checked? <lilyp>well, the basic idea is to use a compile-time constant <RifftE>What can guix do compared to flatpak? I know that guix is for app isolation, but what makes guix different? <lilyp>but you're right, foregoing the CHKTEX_CONFIG envvar might be too heavy handed <lilyp>idk what you're going for exactly, so ¯\_(ツ)_/¯ <bonz060>RifftE: guix makes a strong guarantee that you are running libre software, and that's important to some folk like me. Also, the declarative package definitions makes your build very transparent---can't say that about flatpak(?). Also, community. <bonz060>RifftE: : And guix, beyond being just a package manager, can also be a full-fledged system with no systemD <ngz>lilyp: Probably. At that point we have two working solutions: the wrapper, and strdup. I'd lean towards the second one, as writing C gives me the illusion I'm a true hacker ;) But anything goes, really. <__dan>declarative config, i dont know <__dan>its good for some stuff , and I would love it on servers <bonz060>RifftE: Also, guix makes packaging more accessible to many folk. Like I was able to package a WIP some local project for checking power outages where I live. Mad internet points for that accessibility. <lilyp>lilyp, you can also move my code block around to feel like an even greater hacker <__dan>on a laptop so faar its just been an uphiill battle with everything <__dan>maybe this will improve in timme as I use it <bonz060>RifftE: And the DSL---read guile---guix uses is much nicer than what I've seen elsewhere (Nix I'm looking at you) ;) <lilyp>just don't forget to define GUIX_CHKTEX_CONFIG at compile time and you'll be fine <bonz060>BTW, are there any providers that offer GUIX? I want to shift my blog there from ScaleWay. <bonz060>__dan: what's been uphill for you? I moved to Guix some times back from ArchLinux and my experience has been stellar. <bonz060>__dan: to the point where I'm trying to convince people to try out Guix, even in a VM. <tissevert>ok so no one else is facing this issue compiling guix-cookbook.de.texi ? <lilyp>there's guix-hosting.com, gives you a VPS <bonz060>__dan: And I do not say that lightly. I've been one of those hard-headed ArchLinux users---been on Arch for the past decade or so. <lilyp>tissevert: I had something similar recently, but that's cause I majorly horked up my checkout <__dan>guys system reconfigure hangs many time <apteryx>tissevert: if the error is about HELP2MAN, then 'make clean-go' and rebuild <__dan>prolly was because server issuesI dont know caus eit gives no message <RifftE>I would use arch linux, but damn, I just like how worry free (9/10 times) debian is when it comes to updates and package stability. <__dan>you have to learn a lot details of every service how to configure it <tissevert>nope, like I said earlier I make clean everything, and even went as far as deleting all non-hidden files and dirs in the repo before restoring them with git checkout <__dan>getting X to run with startx was a fucking nightmare <lilyp>good thing that guix gives you stability and bleeding edge at the same time <bonz060>__dan: but you can pin your guix version no? <tissevert>so I think I'm pretty much covered for left over stuff <lilyp>(except for gnome and that's my fault ._.) <tissevert>so I get from the "guix pull" advice that the deps have changed for guix ? <bonz060>__dan: I pin my guix on a given commit; but when I feel dangerous, I set to Master. <bonz060>__dan: living life on the fast lane ey? <__dan>luckily I stilll remember some common lisp else I would have throw it out days ao in frustration <tissevert>(I'd rather not guix pull again, that broke my ibus config last time I did it 😢) <__dan>every error thros ofc scheme erros, leaking abstraction <bonz060>__dan: Lisp is a beautiful language. Hard to convince non-believers though. <__dan>needs better erroc checking and better error emssages <lilyp>tissevert can you run guix describe for us please? :) <RifftE>ACTION holds up the K&R book like it's a holy guide. <tissevert>cee17521ec4af3cc29da957933e840b5d6163b9a (Sat Sep 2 08:47:14 2023 -0300) <__dan>also , problems with rebooting, it hangs sometimes <lilyp>that's definitely recent enough <bonz060>__dan: What do you mean leaking abstraction? Also, FWIW, it's sort of why the community is here. Things, at least in my eyes, look pretty much improved compared to the last time I looked at the source tree. <lilyp>and you're running a fresh `guix shell guix'? <__dan>well, imo the configure program failure should tell you exactly what is wrong <__dan>right now throws a schme compilation error <__dan>some of thse are easy to daignse <tissevert>but guix itself is 7dd076ed, that's Sat Jul 29 12:00:47 2023 -0400 <__dan>some not, till you get a hang of what is what <tissevert>so no, I think apteryx' advice may be the key <__dan>this is what I mean with leaking abstractin <tissevert>I would update more often if I had the time to fix the broken stuff in between <__dan>also Shepher is IMO fundamentally flawed <RifftE>What would one have to do to have a blog or website hosted through guix? <__dan>fibers on single thread do not bode well <tissevert>and since I can't use anthy anymore, no update for me yet <__dan>meaning one can starve the syste forvver <lilyp>well sure, but solothreading is even more cooperative <apteryx>why did anthy break? maybe just a clearing cache issue? <__dan>there is no preemption and no time outs <bonz060>RifftE: One simple way is run it in a container and expose it using the "-N" flag, and do your thing with Nginx as a reverse proxy. What you put in the container is up to you. <__dan>All this beein said, the system is awesome <__dan>and will certainly improve still a lot <lilyp>apteryx: has been clearing caches for me for months <bonz060>__dan: no system is perfect. But with love it gets close. <lilyp>the ibus cache specifically :) <__dan>a lot of care has been put in it, i can see <__dan>I have 6 days on it, and some days I didnt have time ebcause of work <RifftE>bonz060, Can I host this using notabug or maybe github? <lilyp>I haven't contributed much to shepherd, but I still kinda like it <bonz060>I'm lucky, my work requires me to use Guix lolz. <lilyp>wish I had your negotiation skills <__dan>if you MT shepherd, you ahve the fork problem <__dan>if you let it like it is, you have no sabe supervision <__dan>like I said, cooperative finners dont mesh well with supervision issues <__dan>and since you use a Schme runtime in it, the Mt fork problem is really a fucking probl <RifftE>I think I got the idea of a blog through guix is a central server like a traditional website. Guix be more p2p like IRC? If I was to make an analogy. <bonz060>lilyp: Nope. I was nerding out about some BSD, Emacs, Org-Mode and SICP. And some random dude gave me work. Been working at the same space ever since. And said person told me to check out Guix. And we kept getting like-minded folk. Fun times. I'm lucky. <lilyp>you should try the lottery, lol <lilyp>__dan sorry to broke this to you, but between shepherd and the blockchain there's only one giant waste of energy and despite all the goats it ain't shepherd <bonz060>lilyp: I live in a place where even using Linux was(note the past tense, things are better now), let alone free s/w, was seen as an outlier, so there's that. <lilyp>given the 90% market share of desktop spaces, I'd say just around everywhere safe for the DPRK <bonz060>RifftE: The only gotcha is that the thing you are using to blog is packageable. I'm trying to re-write a hugo-compatible thing, just for my own blog, so that I can stop using HuGo. HuGo is a pain to package :( :( <lilyp>bonz060: have you tried haunt? <RifftE>I've read about haunt. Wasn't sure if it was good or not. <__dan>for what is worth, my wife calls Linux the handicapped OS <bonz060>lilyp: I've most definitely come across it. Thing with Haunt is that IIRC it does no parsing. I have 7 year's worth of markdown files. I want to parse that mark down to html and serve that in a way that won't break my current work-flow (which btw is org-centric). <RifftE>My confusion rests with how do I distribute a blog made with and for guile. I get I can use something like haunt. But what am I missing? <lilyp>bonz060: IIUC (commonmark) markdown should not be an issue, though YMMV <lilyp>you could also try org->html <bonz060>lilyp: Ahhhhh! Now I see it. Silly me. I've always thought you write stuff in sexps. Aaaarghhh. I feel so silly :( lolz <nckx>apteryx: Do you happen to know which P9 machine was having the networking troubles? <bonz060>lilyp: Thanks for pointing that out. A long time this has been with that assumption. <janneke>__dan: name-calling a noble, equalizing initiative, thats interesting... <bonz060>lilyp: many internet points to you ;) <apteryx>lilyp: so you mean you had to manually clear caches many times in the last months, for anthy towork? <bonz060>RifftE: You use guix to provision everything you need to build your blog. And that includes haunt. I hope that's clear. With haunt, you'd have everything you need to do that. Guix does the provisioning for you. <lilyp>my typical workflow after rebooting is rm ~/.cache/ibus; ibus-daemon -drx; <__dan>janneke: human behavior is interesting <RifftE>I was under the impression it was like a torrent where I give someone a file and they get the blog from there. <lilyp>if that's unrelated to the behaviour you're experiencing, idk <bonz060>RifftE: Ah if you mean distribute, not host, then you can use "guix pack", generate a docker container or something else, and share that. <bonz060>Will work on whatever system you give them (other than the non-free ones whose names shall not be mentioned) <apteryx>civodul: any ideas about [8140639.175055] __vm_enough_memory: pid: 64353, comm: guix-daemon, not enough memory for the allocation happening on berlin? <civodul>apteryx: hi! no idea off the top of my head, but lemme see <apteryx>it's reproducible there (berlin) as we speak: guix gc: error: build daemon out of memory <apteryx>with associated dmesg output: [8193259.500276] __vm_enough_memory: pid: 15517, comm: guix-daemon, not enough memory for the allocation <apteryx>there's plenty of memory on the system, so it may be some process imposed limit? <civodul>is there a way to narrow the search space; like do we know which 'guix' package introduced it? <civodul>what happens in 'top' before it terminates? <apteryx>looking at 'ps aux | grep guix-daemon', I see most of the instances are from 44bbfc2, but we also have a single dc5430c <RavenJoad>sneek: Later tell RifftE: Hosting a blog with Guix, haunt, and nginx is not difficult. I actually just made a blog post about that. <apteryx>i'll kill the older 120279 process that corresponds to dc5430c <apteryx>so now we're only dealing with 44bbfc2 <lilyp>RavenJoad: sure would be nice of you to share the link as well <civodul>apteryx: i mean do we see memory usage rise in 'top'? <RavenJoad>janneke: Just tried it, it seems fine. Why do you ask? <RavenJoad>civodul: Thanks! It took me a while to figure out the nginx rules and the certbot "oddities". It is nice to be able to just deploy the system now though. <janneke>RavenJoad: hmm, it doesn't work for me; loading... <RavenJoad>It loads fine for me. The server is hosted in Chicago, so that might be something? But I don't know why it does not work for you. The site is fine in eww, firefox, and chromium as far as I can tell. <janneke>hmm seems i'm having an ipv6 problem, can't even wget it <RavenJoad>The server does have an ipv6 address, but I have not configured it much, beyond an AAAA record. <janneke>RavenJoad: it loads fine from another machine, sorry for the noise <janneke>must be my modem/internet connection; crap <RavenJoad>Ok. I just checked, and the record is right, so you should be able to find it. <RavenJoad>Are there any Xen masters who could help diagnose a validate-runpath issue? I have xc.so (compiled for Python2) that cannot find another shared object, despite -L../../tools/libs/ctrl, -lxenctrl, and -Wl,-rpath-link=/tmp/.../tools/python/../../tools/libs/ctrl all being present when compiling xc.so. <janneke>ACTION reverts their modem ipv6-support setting to "use native ipv4 conection"; whatever that may mean -- sigh <janneke>our internet-provider had a hostile takeover and things have been going downhill <apteryx>civodul: I have no clue, perhaps we can reboot berlin and hope for the best? <apteryx>nckx: sorry, I don't know which one it was, and it seems hard to find similar occurences at the moment <apteryx>that said, we still have: Sep 2 17:49:28 localhost shepherd[1]: [knotd] 2023-09-02T17:49:28+0200 error: [guix.gnu.org.] zone event 'refresh' failed (no usable master) <apteryx>in /var/log/messages on berlin, not sure how that can impact things <apteryx>it's caused by a connection timeout to bayfront <apteryx>seems the default timeout is fairly low, 500 ms <apteryx>but there's a caution attached to raising its value (Slow Loris attack) <apteryx>is it OK to reboot berlin now? should be back in max 10 minutes (if everything goes smoothly) <janneke>RavenJoad: great post! -- interesting you should introduce "simple-website" so oarly on; do you know of a (standard) recipe for a "simple-haunt-website" grom a haunt git url? <RavenJoad>janneke: It is introduced early, but only so people get to see a real website at the end of the post. A "standard" recipe? No. No one agrees on that. <RavenJoad>I reverse-engineered my haunt-stuff (and sxml) using dthompson's site and Mathieu's site, then a healthy dose of grep-ing through source code to figure some stuff out, and some real-time testing. <janneke>motachece's use of maintenance.git's static-web-site-service-type is interesting too <__dan>guys, what can end in ~/.config/guix/current/bin , plase ? <RavenJoad>__dan: On my machine, only guix and guix-daemon are in ~/.config/guix/current/bin. <__dan>so basically the place where you have the always uptaded guix, the demon <__dan>I have a nano editor too. Donno how it ended up there. I assume its there so you do not end without an editor on the system <RavenJoad>__dan: rde is a channel from another developer for making Reproducible Development Environments. I think there is a #rde channel on IRC for it. <__dan>Im slowly getting the hang of the OS <mirai>I suspect this `(apply invoke "make" "install" make-flags)' from install in gnu-build-system might not be correct <mirai>I'm getting different behavior depending on the make-flags position <mirai>I think the make-flags have to be placed before the rule i.e. (apply invoke `("make" ,@make-flags "<the-rule>")) <RavenJoad>mirai: That depends on what the flags are I believe. <RavenJoad>Yeah. The make manual would have more information about it. I know that environment variables and overriding makefile flags use the same syntax, but are separated by the use of "make" in the command line. Something similar may be happening? <mirai>huh, I think it might be that args actually has #:make-flags as well <mirai>because echoing it out I see a #:configure-flags (--enable-openmp) #:make-flags () <mirai>I thought it would have been absorbed by the explicit binding <mirai>as Guile has it: “When #:key is used together with a rest argument, the keyword parameters in a call all remain in the rest list.” <RavenJoad>Normally it’s an error if a call has keywords other than those specified by ‘#:key’, but adding ‘#:allow-other-keys’ to the definition (after the keyword argument declarations) will ignore unknown keywords. (guile) lambda* and define* <mirai>turns out it doesn't complain about duplicate keyword arguments too <lilyp>mirai: that's well-defined behaviour, the last one takes precedence