IRC channel logs


back to list of logs

<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
<leoprikler>does --log-file return the log file?
<lfam>But it's gzip compressed without a filename extension
<leoprikler>got any breaking build to try it with?
<lfam>I have a working build... trying to view the configure flags that were used
<lfam>For example, for me it currently returns <>
<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>Great news nckx :)
<nckx>Damn it.
<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>I never knew
<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 punts unashamedly.
<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>Okay ;)
<nckx>Sorry. Too easy.
<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
<lfam>E.g. Syncthing
<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>(Borg is python)
<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
<nckx>Good thing there's IRC.
<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.
<nckx>NieDzejkob: Yes?
<nckx>I haven't forgot.
<NieDzejkob>ah, sorry. I guess my heuristic of "it's past midnight in your timezone" didn't work too well :P
<nckx>Not with me 🙂
<NieDzejkob>night shift?
<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>NieDzejkob: Indeed.
<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>jlicht: ‘Extrinsic’ you say.
<nckx>I'll live.
<nckx>Well, maybe.
<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>Hello guix!
<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>*gnome settings
<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>Any ideas?
<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>Hi everyone.
<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
<sneek>Got it.
<NieDzejkob>sneek: later tell mfg: builds are parallel by default, but you can add #:parallel-build? #f to arguments to disable it
<sneek>Will do.
<civodul>Hello Guix!
<NieDzejkob>I like how hello messages aren't useless in this channel because of sneek
<NieDzejkob>sneek, botsnack
<brettgilio>Sneek, any messages?
<brettgilio>Sneek, botsnack.
*jonsger tests the installer
*jonsger founds a bug
***emyles` is now known as emyles
*jonsger opened
***Noctambulist is now known as Sleep_Walker
***Server sets mode: +cnt
<civodul>jonsger: ouch, weird bug!
<civodul>does it proceed if you don't try to edit the config?
<jonsger>yes it does
<leoprikler>how does one use guile as interpreter in guix outside of a package?
<leoprikler>i.e. how to shebang correctly
<civodul>"#!/bin/guile -ds" should work
<leoprikler>nope, still sh
<leoprikler>okay, just discovered I've been writing the wrong file the entire time
<leoprikler>btw. how does /bin/guile work?
<leoprikler>okay, it doesn't
<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: I like to use
<str1ngs>leoprikler: then you can have something like (define (main args) (display args))
<leoprikler>str1ngs: stealing that
<str1ngs>it's GPL so you are okay :P :P
<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
<civodul>yeah, i see
<str1ngs>leoprikler: this reference should help namely !# is unique to guile.
<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"
<jonsger>civodul: nice :)
<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
<NieDzejkob>Parra: could you paste the exact command you're using, the error you're getting, and your package definition file on and send us the link?
<Parra>yes, wait a moment, I'm trying to rebuild everything to be sure it isn't caching a bad state or something
<Parra>I use guix inside docker
<Parra>and the project is big
<Parra>those are the commands
<Parra>this is the schema file:
<Parra>and the error will be in 20min or so
<Parra>it's building node right now
<guixy>Updating doesn't work.
<Parra>the logs
<Parra>do you need complete build logs?
<Parra>or is that enough?
<NieDzejkob>oh god, that's quite some lonely parentheses ;)
<NieDzejkob>I decided to try building cherow on my machine and I'm getting the weirdest error ever
<NieDzejkob>(cherow.scm being this file
<NieDzejkob>sneek: later tell Parra: what does ls -l /gnu/store/zra890lywm3z7dvkv547fsm52yysbrdv-cherow-1.6.9/ say?
<sneek>Got it.
<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, you have 1 message.
<sneek>Parra, NieDzejkob says: what does ls -l /gnu/store/zra890lywm3z7dvkv547fsm52yysbrdv-cherow-1.6.9/ say?
<Parra>I was trying to answer xD
<Parra>called bin*
<NieDzejkob>a dangling symlink?
<Parra>mmm, no, it goes to the lib folder
<Parra>I think it's ok
<NieDzejkob>on my side it highlights it on red and blinks
<Parra>you are right
<Parra>it's pointing to nowhere
<Parra>the folder it's pointing to doesn't exist
<Parra>what to do nowM
***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>where are they?
<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
<NieDzejkob>Parra: see
<Parra>dude that's insane XD
<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.
<efraim>i also use quassel
<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?
<NieDzejkob>not that one'd want to...
<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 checked the logs
<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
<Parra>it's difficult to use
<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
<Parra>I'm so tired
<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>hi #guix
<dustyweb>Who is excited about the MNT Reform laptop btw? :)
<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
<dustyweb>I love the older pics on with all the 3d printed pieces on it
<Parra>I think guix is quite good for c/c++ but for node it's just unusable
<leoprikler>There is more than one node-build-system?
<Parra>I don't know what you mean
<dustyweb>pkill9: mntmn made a very rough estimate of the cost when I asked them a while ago
<alextee[m]>node/java/mono is unusable on guix
<dustyweb>"around 900 EUR" at the time
<dustyweb>that seems quite reasonable to me
<leoprikler>"Neither node build system supports building native modules."
<dustyweb>like, super reasonable.
<dustyweb>Parra: hi, I mentored getting Node stuff into Guix at one point
<dustyweb>I can explain why it's so bad
<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
<Parra>without dependencies
<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>but if you want that
<Parra>guix has only to copy it
<Parra>or build it with node-gyp
<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
<dustyweb>guix package -i nix
<dustyweb>nix-env -i nodejs
<civodul>dustyweb: the Reform looks nice!
<Parra>does nix allow to download during build?
<pkill9>guix has nodejs too
<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>you could ping the mailing list
<civodul>it remains a hard problem, though :-/
<Parra>it isn't dustyweb
<dustyweb>that's true, I'm out of the loop ;)
<Parra>it's 10.x
<Parra>it's quite new
<dustyweb>hm, I guess I needed 12.x recently
<dustyweb>for messing with Agoric's stuff
<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
<dustyweb>it's that the problem is hard
<dustyweb>and needs more help
<dustyweb>maybe you'd like to help?
<Parra>I want but I can't
<pkill9>dustyweb: where does mbt reform source their components?
<Parra>I'm not enough expert
<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
<dustyweb>maybe ask in there
<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
<dustyweb>I did a fun thing
<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
<Parra>I'm gonna try nix
<Parra>sorry guys XD
<dustyweb>good luck Parra
<Parra>I need more than luck XD
<leoprikler>you could try ~modules~
<Parra>for mixing build systems?
<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>perhaps with some more quoting/unquoting
<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.
<leoprikler>Aaaaaaaaaand they're gone.
<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
<Parra>see you later
<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
<leoprikler>I mean calls from JS into python
<Parra>you can call ruby or python code from c and nodejs (because node port could be built with guix)
<Parra>or it seems so
<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>It kinda does and it kinda does not.
<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
<leoprikler>at least last time I checked
<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.
<jfred>ah, true
<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
<str1ngs>you can run gnunet as a user.
<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
<str1ngs>jfred: I think you might only need for that
<leoprikler>all your OS level stuff should be accessible to programs running under any user
<leoprikler>(excluding containers for obvious reasons)
<str1ngs>jfred: with
<str1ngs>leoprikler: did you just describe a micro kernel? :P
*str1ngs stampede!
<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>hello janneke
<janneke>hello str1ngs
<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
<dustyweb>oh another article about the Reform
<rekado_>dustyweb: this is so beautiful!
<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
<dustyweb>but we'll have to wait and see
*jfred nods
<jonsger>dustyweb: and so much slower...
<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>ooh, sweet :D
<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
<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
<jonsger>ah nice
<jfred>I admittedly find the CI system a bit hard to read sometimes, but e.g. this is what I'd be looking for, right?
<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
<dejanr>latest state
<dejanr>and my config.scm
<dejanr>for the iso
<CompanionCube>even though it's nonfree...those are the same link
<dejanr>ah sorry
<dejanr>gist with config.scm
<dejanr>i was following this guide, which is a really nicely explained how to create a custom iso
<cbaines>dejanr, it's not obvious to me from those photos where the problem is
<cbaines>do you think it's graphics related?
<CompanionCube>i'd say it's the nonfree micorode that's missing
<dejanr>aha, i will try to add that
<gnutec>Guile 3.0 is here.
<dejanr>could this work?
<NieDzejkob>it did for me
<NieDzejkob>nonguix is bae
<CompanionCube>that's the wrong microcode
<dejanr>CompanionCube: where could i find a correct one?
<CompanionCube>dejanr: earlier in the file is the microcode you want
<raghav-gururajan>Hello Guix!
<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
<gnutec>I install Elementary, Sudoku, 2048, SolitaireCG, Minetest, Pixel Wheels, all work fine.
<dejanr>looks like guix-config or guixsd-config repos similar to nixos
<cbaines>dejanr, conventions regarding what specifically?
<dejanr>git repository name of user configs, e.g.
<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
<dejanr>efraim: i was just looking at your config on github, i like that to, i did something similar with nixos, but wanna give a try to guix now
<pkill9>i split up my config too
*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>Morning #guix.
<nckx>I noticed something strange:
<nckx>Hard link weirdage?
<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.