<blake2b>not anymore, but I was doing my PhD in philosophy with an emphasis on philosophy of mathematics (set theory & category theory), focusing on formal theories of value, but from the continental tradition. I focused on the status of formalism in ontology and how this impacted the bourgeoning theories of value that continue to inform our present episteme, particularly in the major works of Kant, Hegel, Freud & Badiou. But school threatened
<blake2b>to separate my partner and I in unpredictable was due to covid, which has decimated the humanities. And I've become to obsessed with scheme & guix to imagine finishing any time soon haha
<blake2b>but i'm giving a guix day talk, so wouldn't want to spoil it ;)
<blake2b> Michal_Atlas: for sure! i'm surprised how good it looks "out of the box"; i had just imagined it would look like Racket's (pict), which I didn't spend much time with but recall it literally being a bit rough/dithered around the edges. the presentation I'm doing with it looks like a less shiny Beamer presentation, with little work. quite excitd about it now (and hope i can spread some of that excitement with this)
<blake2b>now i'm planning to make a guiser-present program now, it will be so easy :)
<Michal_Atlas[m]><the_tubular> "So which is it...? Latest or..." <- I think the easiest way to see at this point is to just test it 😅, my last unattended upgrade failed, but it does run guix time machine with the given channel file, and then simply just reconfigure.
<jaft>Not trying to spam anything but the logs from yesterday for this channel didn't show the messages I sent so, in case they didn't send properly or something (my internet connection drops periodically, which helps nothing…), I'm just going to post here, a second time.
<jaft>device was recognized, now, but trying to click on it or mount it still resulted in the error "No mtp devices found."
<jaft>Someone here recommended trying android-udev-rules so I did; this resulted in the phone not getting recognized, when plugged in, by Thunar, again – but it /was/ able to be recognized as a connected device by adb. So I'm not sure what else to try; any help, of course, is super appreciated!
<jgart>hi guixers! does guile have a syntax for accessing functions from a module that have not been exported?
<rp1>I'm afraid I'm new, so I don't really know what I'm doing. Where would I find the code that builds the current package? Is there some documentation I should go and read before bothering you folks on irc :)
<AwesomeAdam54321>rp1: By doing `guix edit $PACKAGE`, you can read the package definition of PACKAGE that's in the store, which is read-only. the name of the file you're editing is the place the package is defined
<AwesomeAdam54321>So you can git clone the guix repository, find the package definition and update it, and send the patches
<rp1>Once I've edited the definition on my own machine, how do I try to build it?
<jpoiret>I don't think it's possible to propagate things up the dependency graph, no?
<jpoiret>note that it's at runtime, so i'm talking pure shepherd services here
<florhizome[m]>To me it felt like, there are a bunch of things that are „desktop services“ and packages in the desktop environment services like gnome that could be handled by user interfaces but probably not all.
<florhizome[m]>how do you manage login/seat etc? Those are system services that need some info about your wayland compositor f.e.
<florhizome[m]>Seemed like you need some interface between system and user services to me
<florhizome[m]>(or the other way around, you need certain system services to start a certain wayland compositor)
<gnoo>you don't need a system service to start a wayland compositor
<gnoo>just `sway' and you're done. you do need seatd as a system service tho.
<gnoo>there's also seatd-run which probably doesn't need seatd running as a system service.
<gnoo>hmm, can normal users install programs that need suid to function
<jpoiret>we're just spoiled because guix lets you do a bunch of things as a non-privileged user, so we sometimes forget that everywhere else, you need to elevate to do anything meaningful
<gnoo>florhizome[m]: the package's documentation should tell what services it needs to function properly
<gnoo>accounting for every service and it's possible dependency is hard
<jpoiret>florhizome[m]: right, but if a user does `./configure --prefix=$HOME/test; make; make install` and the program doesn't work because the system is missing some functionality, it'll be the same issue
<florhizome[m]>For example for those user services that need a certain system service you could tie them to guix system
<florhizome[m]>So If a user wants to install a service that depends on some system service shoot them a warning; if this doesn't work and you're on guix you might need some system service; if you're not on guix then we blame Linux :D
<jpoiret>well, if they're not on Guix they could ask their administrator to add the relevant software to the system
<jpoiret>in both cases it's the same issue: the administrator needs to step in and add the dependencies. I'm not sure that we need to maintain that dependency warning ourselves though, since the issue is common for all distributions
<jpoiret>maybe a warning in the docs rather? saying that such and such software requires x or y
<florhizome[m]>I think you should be able to turn it off in some way or form
<florhizome[m]>like a mechanism where an admin can install configuration options and you can opt into using them by installing the user parts but if the prerequisites haven't been installed you get a message that lets you know that.
<gnoo>there can be multiple ways to start a service, it's better to leave it at the user's choice, no?
<gnoo>i mean there's no need to add that to guix home, it sounds like something that'll only work on some very specific cases
<florhizome[m]>gnoo: i mean, that's kind of the thing about guix, that you can use it for mostly anything, surely you can still use things in other ways
<florhizome[m]>And i think guix wants to provide stuff that other distros do, too, or guix users want to use things via guix.
<florhizome[m]>I think i arrive at interesting questions, but i agree if you say that's overcomplicated in some way or form^^
<lilyp>gnoo: No one's forcing you to use (guix home)
<lilyp>I personally don't use it yet either, it has a few pet peeves that irk me too much.
<gnoo>lilyp: i mean, it sounds like slightly harder to make guix home behave like that, and if it does work, that'll only work for very few cases
<ngz>rekado: Hello. So we don't duplicate efforts, I worked on fixing a few Texlive packages: see <https://paste.debian.net/1230756/>. I'll push them to core-updates soon, unless you want to beat me to it. In particular, you may want to look at the dance in texlive-graphics. In particular, it shows that texlive-hyperref is broken.
<ArneBab>vldn: the simplest way ist just prefixing any top-level form with . (dot space) :-) — otherwise there isn’t yet. It’s possible to create such a tool, but different from wisp→scheme, scheme→wisp is an optimization problem (wisp has restrictions that make the conversion to scheme easier: The sublist with colon (:) ends on its line)
<ArneBab>I’ve got some ideas how to do it, but have not realized them yet.
<ArneBab>vldn: but the really simplest way is to just have the scheme in a different file and pre-compile that with guile. Then it can be used from wisp just like a wisp file.
<Kolev>podman: Error: short-name "jellyfin/jellyfin:latest" did not resolve to an alias and no containers-registries.conf(5) was foun
<ArneBab>lilyp: yes — but you’ll want to prefix top-level definitions with . to avoid calling the defines :-)
<vldn>@ArneBab maybe using some prettified scheme output for an easier conversion, that's the indention is halfway right and it's mostly about deleting parens and adding some colons :D
<vldn>and a flag for using other guile language implementations like (--language=wisp) for guix system files would be really cool, like guix build --language=wisp or guix system reconfigure --language=wisp
<ArneBab>There are some edge-cases where you need either one more newline or parenthesized style in wisp. I intentionally chose not to resolve them, because that would have made the structure more complex (it would have required taking symbols within earlier lines into account to understand what indentation means, and while a parser can do that, it’s much harder for humans reading the code).
<pinoaffe>vldn: I think a #lang directive in guile would be a more "clean" solution
<permcu>To clarify: I get the error if I try to start a guix container inside an other guix container.
<singpolyma>I think you can't do most guix operations inside a guix container or vm because the store is already read only in there. Maybe you can have something outside the container you signal with some IPC to start a new one?
<jpoiret>you shouldn't be able to talk to the guix daemon inside the container, no?
<permcu>I have defined a guix server os that uses guix shell --container for some service and wanted to test it with guix system --container
<permcu>jpoiret yes it can't add anything and fails creating the profile.
<permcu>Does that mean you can't really test a containerized guix operating-system? At leat not if testing means adding to the store.
<permcu>I really like guix "theoretical" container/virtualization capabilities. But damn everytime I try to use it it shoots me in the foot. At least I learned a lot about linux namespaces;)
<lilyp>permcu: wdym by testing? you can absolutely pre-build all the store items you need
<jpoiret>it's 100% expected behavior, since you're an unprivileged user, you shouldn't be able to add anything to the store
<permcu>lilyp: I wanted to set up a local containerized test-server (from an operating-system declaration with guix system container). This works as expected & veth makes the network possible. But the test-server uses guix shell --container [...] inside a git hook and that fails.
<permcu>Now I have to figure out how to prebuild that or abandon this approach.
<jpoiret>you could try --share=/var/guix/daemon-socket/socket
<jpoiret>but you'd need to remove the guix daemon from the config
<permcu>jpoiret: Thanks. That could work. Breaking isolation, but the store is garbage-collected anyway.
<jpoiret>well, that or you'd have to unshare the store, but I don't think that's supported in any way
<jpoiret>i think the `guix system container` command really expects to already have a working store inside the namespace
<permcu>:D No unsharing is not supported. I read the source some time ago and the whole store is just made available.
<permcu>Just checked it again: %store-mapping in file-systems.scm just maps the host store ro into the container namespace.
<singpolyma>jpoiret: oh that's an interesting idea. I've been playing around with ideas to safely run guix system vm on untrusted scm with the result ending up in host store
<permcu>Prebuilding does not seem to work. Running just guix shell on the host, then starting the system container and running guix shell inside the container also leads to the remounting /gnu/store writable error. This seems to indicate that guix shell always needs a working=writable store.
<permcu>This leaves only jpoiret idea as a viable solution.
<permcu>Thank you. You have been great help in triaging this problem.
<balbi_>would anyone be able to point me to a guix system config.scm example using sway? I just installed my system, but I'm having some difficulty figuring out what I'm missing. For example, C-l doesn't work to clear the terminal, any pagers give me errors that terminal is not fully working, and other oddities
<pinoaffe>balbi_: I think your terminal emulator is the issue
<vagrantc>balbi_: i recall having similar issues with foot ... ironically, i use sakura which is not wayland based and it works fine :)
<pinoaffe>I was under the impression that they don't
<lilyp>atomizedalex: That analogy rests on the assumption that the FSF seeks "harm reduction", which is not really the point, though. What the FSF seeks is complete liberation
<lilyp>the Microsoft OS won't be more free just because you have managed to (fool yourself into thinking you've) disable(d) some telemetry
<atomizedalex>"Complete liberation" through control of software, without regard to broader social relations of production. Complete liberation in which in production people are still accessories to the machinery, in the organization of production the needs and desires of the workers are subordinate to competitive demands, subordinate to management prerogative, subordinate to dynamics of accumulation.
<lilyp>stop there or you might accidentally pick up a hammer, a sickle, or the red flag of functional programming
<atomizedalex>There is a great deal of resonance between the FSF project and Adorno & Horkehimer, that the means of production are simultaneously the means of destruction when imprisoned within the logic of domination.
<lilyp>I haven't read much Horkheimer, but the negative labour done in wide areas of software development is real.
<htsr[m]>Hi guix! I can't guix pull anymore, it raise an exception: In procedure load-thunk-from-memory: incompatible bytecode version
<florhizome[m]><ngz> "There's no hash mismatch if I..." <- guix will use an origin identified by the hash from the store if it can find it, which means all modifications to origin are irrelevant if a matching hash is found