<lfam>Something that I miss from Hydra was being able to do `vim $(guix build --no-grafts --log-file qemu)` and have it show me the log file <lfam>Now I suppose the MIME type is not set correctly or something <lfam>But it's gzip compressed without a filename extension <lfam>I have a working build... trying to view the configure flags that were used <lfam>I can save this file. I can't decompress it right away because gzip won't play if there is no filename extension .gz <lfam>So I have to first rename it <lfam>It all works but it's tedious compared to before <lfam>With the extension, vim does the right thing <nckx>I'm going to regret saying this, but that sounds absolutely trivial to fix in the nginx configuration. <lfam>You can work on that while I figure out what version of libslirp is bundled in QEMU (and since when is SLIRP a separate project?!) <lfam>Or like, what tooling is used to add libslirp to the QEMU tarballs <nckx>Not to be snarky, but, like: the 90s? <lfam>QEMU publishes security advisories for libslirp, with links to libslirp patches... which is a big improvement. But now we have to figure out which patches apply to which QEMU versions <lfam>I guess I'm surprised because I figure we would have unbundled this during the unbundling craze <lfam>Alright, they use Git submodules for anyone following along <nckx>Hm, my nginx plan won't work. And this is probably something that needs to be ‘discussed’ with ‘people’ because it will ‘break’ their ‘stuff’. Bah. <nckx>lfam: Which unbundling craze? <lfam>Um... the first 5 years of Guix <nckx>Bundling has become more accepted? <lfam>I suppose this is just my own journey of changing priorities... Go is basically a language where everything is bundled <lfam>And there are plenty of packages with bundled libraries with ... unaccountable modifications <nckx>Oh, we don't build nginx with Lua… ☹ *jonsger has fun with PHP :) <jackhill>I wonder if go, specifically, will get better with go mod *nckx ignores the existence of Go. <lfam>If you want to get worried take a look at Dropbear's crypto and math dependencies, cross referenced against MITRE <nckx>If you want to get worried take a look at Dropbear *jackhill runs away and hides :) <lfam>They are heavily modified copies of external projects, and they don't "sync up" for years at a time *jonsger needs a build server for his channel consisting of one package :P <jackhill>nckx: there are some apealing quality of go to me: in particular a culture of not breaking things <nckx>Dropbear's great for use in initrds, just don't point it at the Internet you'll kill us all. <nckx>jackhill: I don't like how Go has claimed that slogan as their own (it's just marketing, and Go is very marketing-driven) but can't disagree with the goal itself. <nckx>Let's not break things in better ways. <leoprikler>But are there better ways than copying an entire repo from elsewhere and leaving the code untouched for years? <jackhill>nckx: good point, and I do see that elsewhere too (Clojure). Hopefully, Guile and Guix too :) I do think it's a cultural thing in addition too, and maybe the marketing can help form the culture. <jackhill>it's certinally not the only thing I care about in probrammings. <jackhill>on the flip side, there is legitimately useful sofware written in go, so I'm forced to care a little bit. <lfam>I mean, people are writing a lot of useful software in Go, types of software that did not exist or at least did not work well before. So there must be something to it <jackhill>and from a history perspective it's cool too (influence of Plan 9). <jackhill>anyway, I'm off to dinner, have fun softwaring #guix! <nckx>lfam: Interesting perspective. <lfam>It's sort of a facile statement to make but I still believe it <lfam>Restic is another useful thing, one can compare it to Borg as a next-generation backup tool <lfam>Ultimately the tool you are able to use is the best tool <lfam>If Go was supposed to be about making programmers more productive, I compare it to how Guix makes packages and OS builders more productive <NieDzejkob>nckx: Do you remember about the bcachefs patches? <nckx>The only real (besides silly SaaS Web API tools, boy was writing those in Go big a year or two ago) Go programme I've used was Restic. It… did not do wel. Neither did Borg. I await my aha-Go-moment. <NieDzejkob>ah, sorry. I guess my heuristic of "it's past midnight in your timezone" didn't work too well :P <nckx>NieDzejkob: By the way, ‘patches’: I have one bcachefs-tools patch ready, but the Guix System stuff is still very… bad. I'd like to bang on it for a few days, maybe even get multi-device working (my use case). <nckx>I thought you just needed the tools for now? <nckx>(I say ‘use case’; a bcachefs blew up in my face last week, obviously don't use this for stuff.) <nckx>‘Hey we'll pay you extra to be wide awake when you'd naturally be wide awake anyway.’ <nckx>‘Hmm you drive a hard bargain but OK.’ <jlicht>nckx: extrinsic motivation to stay up might just be one of the few things to make me tired very quickly ;-) <NieDzejkob>nckx: Ouch. Nothing compared to a facial explosion can be pleasant. I hope you didn't lose any data? <nckx>NieDzejkob: Nothing serious, an hour or so of kernel poking. Start again. The world's most tedious form of time travel. <nckx>Why would the same (native) gcc:lib have a different hash when taken from native-inputs vs. inputs? <nckx>Answer: when it's not the same GCC. 😒 <apteryx>hmm, I had to take out both glib and gcc from the entries of CPLUS_INCLUDE_PATH to get g++ to happily find its internal headers <apteryx>CPLUS_INCLUDE_PATH (-isystem) is preferable to CPATH (-I) as when using -W it doesn't warn about "other libraries" warnings, which is relied on for some projects such as Inkscape. <apteryx>no way to define a search path to do this though. So... ad-hoc hacks for now. <apteryx>arf, nevermind, the build failed farther with this error: # include <linux/errno.h> <apteryx>I have no idea how that is related to taking out gcc or glib from the include dirs (gcc has its own internal references to these anyway). <guixy>GNOME desktop isn't showing my battery status. Is this happening to anyone else? <guixy>I think I have the tweak configured correctly <guixy>It won't show the battery icon or percentage. <guixy>When I try to edit the power settings gnome crashes. <guixy>It looks like the power settings is supposed to show battery status, but it isn't showing anything related to the battery. <guixy>The laptop I'm using is still capable of battery power, but unless I know what the battery percentage is, it can shutdown unexpectedly unless kept plugged in. <guixy>When I roll back to a previous system generation it works fine though. <guixy>I'm going to try removing gnome-tweaks etc and see if that helps. <drakonis>power settings on gnome seems like a tough sell right now <sturm>guixy: I'm seeing a similar issue since a recent reconfigure <mfg>if we need to "make -j desired_number" in cmake-build-system. <mfg>how we could do that? <NieDzejkob>sneek: later tell mfg: I don't see why you'd want to do that. Either do parallel or don't, but setting the parallelism to a specific number per package makes no sense <NieDzejkob>sneek: later tell mfg: builds are parallel by default, but you can add #:parallel-build? #f to arguments to disable it <NieDzejkob>I like how hello messages aren't useless in this channel because of sneek *jonsger tests the installer ***emyles` is now known as emyles
***Noctambulist is now known as Sleep_Walker
***Server sets mode: +cnt
<civodul>does it proceed if you don't try to edit the config? <leoprikler>how does one use guile as interpreter in guix outside of a package? <leoprikler>okay, just discovered I've been writing the wrong file the entire time <civodul>ah no it doesn't, that was an "artist view" as they say :-) <civodul>but really, on Guix System you'd deploy your Guile program through 'program-file' <str1ngs>leoprikler: then you can have something like (define (main args) (display args)) <leoprikler>civodul: it's not a script meant for "deployment", it's for personal use in a very hackish way <leoprikler>perhaps I will make it a full program later, but for now i just need a wrapper to comfortably pass stuff to gst-launch in a way that Makefiles don't allow <leoprikler>Oh, I know about !#, I just messed up by writing to the wrong file and wondering why my shell didn't pick up the change. <leoprikler>(Basically the file that I asked it to interpret never had a #! line.) <leoprikler>I did use #!/run/current-system/profile/bin/guile, but your exec trick is much nicer <civodul>jonsger: found the problem with "Edit" <str1ngs>leoprikler helps when looking at processes yep <Parra>hey Guixers, I am getting an error when running guix pack, it says collision between file and directories, but those are unrelated <Parra>I'm building multiple packages in one scm file <Parra>yes, wait a moment, I'm trying to rebuild everything to be sure it isn't caching a bad state or something <Parra>and the error will be in 20min or so <Parra>it's building node right now <Parra>do you need complete build logs? <NieDzejkob>I decided to try building cherow on my machine and I'm getting the weirdest error ever <NieDzejkob>sneek: later tell Parra: what does ls -l /gnu/store/zra890lywm3z7dvkv547fsm52yysbrdv-cherow-1.6.9/ say? <Parra>NieDzejkob: it has a lib folder with node modules and all cherow js files inside, and another galled bun which is a symlink to the bin folder inside cherow node_modules <sneek>Parra, NieDzejkob says: what does ls -l /gnu/store/zra890lywm3z7dvkv547fsm52yysbrdv-cherow-1.6.9/ say? <Parra>mmm, no, it goes to the lib folder <Parra>the folder it's pointing to doesn't exist ***ng0_ is now known as ng0
<Parra>NieDzejkob: why can that happen? <NieDzejkob>I'm not sure, I'm looking at the source of node-build-system rn <NieDzejkob>so, this seems to happen with all node packages. Do you need cherow as a *propagated* input? <NieDzejkob>(oh, if anyone's curious, the problem with my error was that I used (guix build download) instead of (guix download) in my imports <NieDzejkob>are you checking the logs when you get disconnected? <Parra>I changed the phone and after installing irc in this one, the app works so badly <civodul>efraim: did you benchmark Guix on Guile 3 on ARM? <civodul>i vaguely remember reading comments from you <efraim>civodul: unfortunately my normal arm board is still down <efraim>I still have my pine64 set up, later I can time building guix vs guile3.0-guix <efraim>did the memory requirement to build it go down? <efraim>that machine is limited to 2GB of RAM <NieDzejkob>Parra: re: IRC app, I'm using Quassel for my IRC, it separates into a 'client' and 'server' which can be on different machines, and only the server needs to be online to get history. Like a bouncer but more integrated. <NieDzejkob>I just noticed I didn't close a parenthesis in one of my recent messages, so, ) <NieDzejkob>also, is it intentional that none of the node library packages (say, node-color-name) can be installed into your profile? <civodul>efraim: the memory requirements seem to be about the same <civodul>but i think you should get substitutes :-) <civodul>i'm interested in the timing of something like "guix build libreoffice -nd" <efraim>civodul: i'll have to get back to you, it turns out that arm machine is acting as a VPN and I can't access anything guixy over the tunnel <Parra>I don't know man, node-build-system seems to be totally fucked <Parra>Guix is making me feel so depressed <Parra>I want to use it, and it's powerful, but it lacks good doc and I'm getting so strange errors <jonsger>^ if you don't speak LISP it can be very hard <Parra>not only because of that, it implies guile <Parra>apart from that, it forces very strict requirements <Parra>like not allowing to download things during the build <Parra>I understand the reasons but it forces me to redesign my build system <Parra>also no doc for mixing build systems <Parra>which is exactly what I need <leoprikler>Mixing build systems works exactly like adding your own functions to an existing one, except that you have to adjust the modules being used more often. <dustyweb>I expect a lot of guix'ers to run this in the future <pkill9>i wont get one if the price is too much for me though, but still excited nonetheless <Parra>leoprikler: I've checked them, like emacs howm package, but it doesn't works with node build system, neither node build system supports building native modules <Parra>I think guix is quite good for c/c++ but for node it's just unusable <dustyweb>pkill9: mntmn made a very rough estimate of the cost when I asked them a while ago <leoprikler>"Neither node build system supports building native modules." <dustyweb>Parra: hi, I mentored getting Node stuff into Guix at one point <Parra>that will force me to abandon guix basically <dustyweb>the problem is the hygeine and reproducibility of Node packages <Parra>dude but I just want to use self contained packages <dustyweb>many packages have A depend on B which depends on an older version of A <Parra>and guix doesn't support that <dustyweb>Parra: that isn't really Guix's philosophy, yes <alextee[m]>those are all bad languages/frameworks but what do you do if that one tool/thing you want is only written by someone who chose to use them? <Parra>I'm talking about a package without any dependenxy <dustyweb>you *can* kludge it into working that way <dustyweb>Parra: here's a "solution" that I use for Node in Guix :) <leoprikler>Before hating on guix, try to build any node.js code using just what you can get from apt/portage/you-name-it <Parra>I think that's reproductible <jonsger>dustyweb: nice that it has the same SoC as my new phone :P <Parra>leoprikler: what do you mean <Parra>does nix allow to download during build? <dustyweb>civodul: yeah! it's a nice counter-direction to the direction everything else is going <dustyweb>pkill9: yes but it's very outdated, there's a thread explaining the current difficulty in updating it but I forget what it is <civodul>Parra: since the GSoC dustyweb mentored, there have been some more takes on this issue <civodul>it remains a hard problem, though :-/ <Parra>12.x has a problem with napi, they broke the extensions, it may be related <Parra>I'm fine with 10, is the one I'm using <dustyweb>Parra: at any rate, it's not that Guix devs don't care <pkill9>dustyweb: where does mbt reform source their components? <Parra>my idea is to build netcore and publish it <Parra>so it's available to the master <dustyweb>pkill9: I'm not sure but there's a #reform channel on here <Parra>I already discovered bugs and reported then <Parra>for example, libruby was statically linked instead of dynamically <dustyweb>also I haven't spoken so much in here lately, hello everyone o/ <Parra>I'm too tired and depressed now though <Parra>I'm thinking on changing the build system <Parra>but this is gonna be the Nth time I do it <dustyweb>I'd love to get it packaged in guix but I haven't had time to look at that, though Dimakakos I think is still working on the racket stuff <dustyweb>I also plan on porting Spritely Goblins to Guile, but not yet <dustyweb>I'd like to get Racket and Guile actors speaking to each other, but I am waiting until the reference implementation stabilizes a bit in Racket <leoprikler>for making the package easier to build in general <leoprikler>for mixing build systems you need something like (#:modules (%build-system-a-modules %build-system-b-modules (extra module x) (extra module y)) though <leoprikler>the thing is, that "mixing build systems" is not some magic, that will make all of your problems go away, though <leoprikler>it builds on the assumption, that part of your build system behaves like build-system-a and another part behaves like build-system-b <leoprikler>If you're not complete about what build-system-b actually does/needs to do, you'll get screwed over. <leoprikler>Hence my suggestion to modularize the build. If you can isolate your node weirdness to metacall-node, it will be easier to reason about it. <Parra>leoprikler: what is the difference with modules? <Parra>and related of what you said about build systems <Parra>in any case I think I'm not advanced enough, I should be an expert to build properly metacall with guix <leoprikler>I'm talking about modules in the general sense here, not modules in the Guile sense. <Parra>I don't know the difference, neither what's your point <leoprikler>You currently have metacall core depending on python, node and whatever. <leoprikler>However, I'd argue that few people will always need all metacall-core features in all of their packages. <Parra>that's right, but I want to package node at least <Parra>because I want to do an example importing telethon (python) from nodejs and using it <Parra>it should be doable at current state thought <Parra>but it's quite common node nowadays <Parra>I don't know, I'm gonna rest a bit, maybe I'm better later on <Parra>I want to contribute to guix and use it, but I'm not ok right now <leoprikler>I see metacall includes a JS loader, that does not use node. Would it be easer to enable that one? <Parra>leoprikler: the loaders are plugins that inject a runtime into metacall <Parra>basically node loader embeds nodejs runtime and exposes a ffi interface to metacall core, it can load scripts, introspect the js code and generate ffi calls to it <leoprikler>okay, but in the other direction that means that node is not needed if you make calls to python <Parra>but that runtime depends on a bootstrap script (just a js file) and a node module (a c++ module that nodejs can load) <Parra>that's right, right now metacall works fine with ruby and python <Parra>you can call ruby or python code from c and nodejs (because node port could be built with guix) <Parra>I couldn't run the tests yet <Parra>I have a stable version that you can install with guix or a sh script <leoprikler>instead of running a full suite, try `guix environment --ad-hoc metacall`, then run your js+python example from that <Parra>and thanks to guix it runs even in a busybox, and that's cool <jfred>Hmm, does guix have a concept of user services (so daemons started by/running as a specific user, like e.g. systemctl --user) <jfred>I've been looking through the guix documentation, but haven't seen references to it if so. The shepherd documentation seems to imply that it's possible with shepherd directly (though I haven't seen an example of how to do it) <leoprikler>For one, your user services are not managed by operating-system.scm or any other guix package file, which might surprise you if you come from systemd land. <jfred>right, that makes sense - since guix packages are installed per-user unlike with most package managers <leoprikler>However, you can start shepherd as user (try doing so from your ~/.profile, GNOME autostart or something similar) <leoprikler>in that case, your ~/.config/shepherd init.scm acts as configuration file and you can do everything you want there <jfred>ohhhh interesting, so it'd be a separate instance of shepherd entirely running as my user <leoprikler>you actually do that on systemd-based distros as well, but you don't notice it <jfred>makes me feel like it'd be useful to have another guix concept analogous to operating-system, but for user-specific configuration - so user packages (what you'd currently manage through a manifest) alongside user services <jfred>that's something I'd like to hack on, but I need to get way more familiar with guix's service system first :) <leoprikler>IIRC there's guix-home-manager, but that's probably overkill for your use case. <leoprikler>Btw. writing services without gexps removes one layer of indirection, which makes it very nice and easy to do. <jfred>so the context here is that I'd like to run gnunet as a guix service, but it seems to have two components: a system-level daemon and a user-level daemon <jfred>I don't think there's a service for gnunet yet in guix, so that's probably a good place to start <jfred>(it is already packaged, though) <leoprikler>not everything that provides a "service" so to speak needs a service at system level <leoprikler>in your case, if you want to start gnunet as a user service, adding a simple service to your shepherd config will likely be everything you need <jfred>str1ngs: you can, but I think if you want things like the nsswitch integration you also need to run it system-level, right? <leoprikler>unless it's actively overwriting system files, which sounds like a bad idea, i don't think that would be necessary <leoprikler>all your OS level stuff should be accessible to programs running under any user <str1ngs>leoprikler: did you just describe a micro kernel? :P <leoprikler>I did not. I meant operating-system stuff as in "stuff that you mention in your config.scm" <jfred>Ah hmm, so: gnunet installed as a system package, and a name-service-switch entry in operating-system <str1ngs>jfred: right, I think that is the way to go about it. <jfred>It looks like you might also need gnunet to be running as root though for the plugin to work (or for the user instance of gnunet to use sudo) <jfred>so I'm just thinking, like... is it possible for a guix service to add an nsswitch entry? that feels like a pretty clean representation of the intent here: an nsswitch plugin is one of the things that gnunet running at the system-level can "provide" in a sense <str1ngs>no I do'nt think you need root for this. the nss service already provides the nss switching. provided the gnunet libraries are there. <jfred>I may not have a full understanding of how nsswitch works here, but my current understanding is: my user-level programs talk to nscd to resolve names. nscd attempts to resolve a GNS domain with the gnunet plugin, and to do so must communicate with a running gnunet instance. This would presumably be a gnunet instance running at the system level. <jfred>Is my current understanding mistaken? <str1ngs>the nssswitch entry is added using they name-service-switch. you don't need another service to do that. <str1ngs>also nsswitch is only required to proxy dns for legacy dns to gns. an gnunet client does not need it of it's self. <jfred>Sure, but assuming I want to have legacy DNS proxying on my system (I do), and assuming that doing so requires a system-level gnunet instance to be running, I feel like it would make sense for a system-level guix service to (optionally) enable everything necessary to do so, if that's possible <jfred>Ah, yeah, from the gnunet docs: "When using GNUnet with system-wide DNS interception, it is absolutely necessary for all GNUnet service processes to be started by gnunet-service-arm as user and group ’gnunet’. You also need to be sure to run make install as root (or use the sudo option to configure) to grant GNUnet sufficient privileges." <jfred>so I misunderstood the other part of the instructions, and gnunet shouldn't be running as root, but there does need to be a system-level instance running ***apteryx_ is now known as apteryx
<str1ngs>jfred: even then, the nss switch service does the nsswitch configuration. lets say you wanted a system wide gnunet service then you would only write the service for that. no need for it to configure nsswitch as well <jfred>str1ngs: Yeah, I'm aware that it's not necessary for the gnunet service to do this, but my question is more like... *could* it? Because you and I know what nsswitch is/how it works/why you might need it, but I don't expect most people to, and if I as a packager can take care of this on behalf of the user I think that would be more user-friendly <jfred>dustyweb: I'm so looking forward to the Reform :D hopefully it'll be within my budget though haha <dustyweb>jfred: yeah, it sounds like it will be cheaper than Purism laptops at least <jfred>I'm really curious how that i.MX8 will perform as a laptop CPU and if the Librem 5 will be comparable when it comes out - though the Reform at least doesn't have quite the same thermal constraints <jfred>(and how much work it'll take to get Guix running on both :P) <jonsger>jfred: I have patches for phoc and phosh (the shell used on Librem5). But not really working yet... <jfred>my main concern is around performance I think; I've tried running guix on the pinebook pro and "guix pull" takes, well... >1h sometimes <jfred>SBC-type ARM chips are *slow* <str1ngs>jfred: I ordered one of those. but my plan is to build on a publish server and then use substitutes <jfred>oh yeah, if there's an available substitute for guix itself that'd speed things up, wouldn't it? <str1ngs>I rarely use guix pull these days. It's mostly ./pre-inst-env guix. and those builds are incremental lol <rekado_>jfred: we do provide substitutes for the parts of guix pull. <rekado_>but it takes some time to build them when there are new commits coming in all the time. <jfred>str1ngs: understandable haha - I'm still a guix user more than a developer for now <rekado_>we have a lot of fast build servers, though. I wonder if we can prioritize “guix pull” derivations somehow. <jfred>rekado_: yeah, so it ends up being a question of whether or not there'll be a substitute available at any given time, which is hard to predict <rekado_>jfred: you can check at ci.guix.gnu.org <jonsger>rekado_: but we don't have that many build servers for aarch64 <rekado_>jonsger: all the new x86_64 servers also build for aarch64 via qemu <jfred>(I think it's mostly a matter of me not having internalized all the terminology yet) <jonsger>jfred: it's only 60s build time, seems a bit fast <dejanr>Hi, anyone having Ryzen 3400g or similar, i have built 2 times custom iso for all nonlibre modules, and starting to get tired of this. My PC is just asrock a300 with ryzen 3400g, no dedicated gpu <cbaines>dejanr, it's not obvious to me from those photos where the problem is <dejanr>CompanionCube: where could i find a correct one? <gnutec>I install f-droid in my smartphone and is great. <dejanr>what's convention for guix configs, i dont find that many configs on github, just found few on gitlab <dejanr>looks like guix-config or guixsd-config repos similar to nixos <cbaines>dejanr, conventions regarding what specifically? <cbaines>Ah right, I don't know of any conventions regarding the repository name <efraim>I split up part of my config, I like the idea of inheriting the whole operating system *jonsger makes slow progress on nextcloud-capable PHP :) <NieDzejkob>dejanr: if you didn't get it working yet, try the whole linux-firmware package: (firmware (list linux-firmware)) <dejanr>NieDzejkob: still building a new iso, i would try that next, thanks! <NieDzejkob>Oh, did you try the install.scm from nonguix yet? <dejanr>NieDzejkob: oh, haven't seen that <dejanr>NieDzejkob: is there a substitute or archive for nonguix? <dejanr>what would be a good path for learning guile/scheme, i was thinking about starting with "The Little schemer", and then going over SICP *kmicu *coughs* “A free system distribution must not steer users towards obtaining any nonfree information for practical use” <jojoz[m]>dejanr: SICP won't really teach you practical Guile, but it's a really good book and will teach you many of the Scheme fundamentals well. <nckx>tar xf works and the actual data does not seem to be duplicated. I do get a stream of ‘Cannot unlink: Permission denied’ errors when extracting. 