<mekeor[m]>6piz7wk: i've been using emacs for a long time. it's nice. but it sucks, too. for guix, it's nice. but tbh, if i could choose an editor from scratch, i'd probably go for (neo)vim or so, today
<M6piz7wk[m]>i have to use vscodium/theia to work on my project atm as it needs unreasonable amount of processing resources and i use it over the cloud
*M6piz7wk[m] didn't yet figured out how to use cloudmacs
<nckx>mekeor[m]: Honeycomb LX2 boards for the farm.
<M6piz7wk[m]>... well i tried cloudmacs but it needs like rework to be usable x.x
<M6piz7wk[m]>Is there a way to set a shebang for the guix shell file?
*M6piz7wk[m] is not sure what to put there other then #!/usr/bin/env guix shell -f ..?
<mekeor[m]>anyway, i think, you can either (1) suggest a change to guix on the guix-devel mailing list; (2) just live on with a single-line shell-script as increased complexity; or (3) package a "guix-shell" executable locally and install it.
<M6piz7wk[m]>> Actually they should provide additional cooling -.-
<M6piz7wk[m]>20089 Lenovo G770 that i've modded the hell out of O.o
<M6piz7wk[m]>by default it only has one cooling pipe and even when i added 4 more it still wasn't enough so i got a spare back cover and screwed a PSU fan on it :p
<mekeor[m]>florhizome, jgart: so, the manual creates a inferior channel inside a manifest.scm. i guess you could also use an inferior channel just as a channel. i guess (!), the order of the channels matters and a package would be installed from the first matching channel?
<jgart>what happens if you have a package in your channel named the same as a package in the main channel?
<jgart>maybe we should have a way to associate channels with packages in addition to versions
<jgart>Ideally, I'd prefer to not have to name the package in my channel something different so as not to conflict with the main channel's package of the same name, for example
<attila_lendvai>i packaged an app, built it, and installed it on my profile. should its icon be fine without a relogin? it doesn't show up, and i don't see why, everything seems to be there.
<mekeor[m]>jgart: as i said, i guess that the order of channels inside channel.scm matters
<jgart>attila_lendvai, what package are you referring to?
<jpoiret>cannot close compressed lock file when building inkscape on c-u-f, anyone else?
<jpoiret>did not reproduce a 3rd time, disregard that
<jpoiret>alright, libva needs an update on c-u-f, at least for wayland compositors to work with it
<rovanion>Is it possible to start a service as part of a guix shell/environment? The software I develop needs a postgres database and it would be sweet if I could just declare it in a .envrc and have it start up if I enter that project folder.
<jpoiret>docs are unclear, `guix graph --path FIRST SECOND` tries to find the shortest path to SECOND in the dependencies of FIRST, and so you cannot exchange those arguments. None of the docs mention this argument order issue. Patch incoming then
<jpoiret>nckx: are you running your system on master? if so and since libva isn't broken for compositors there, should the libva version bump be submitted to c-u-f instead of master? i'm still struggling to differentiate between where to send the patches
<jpoiret>i mean, c-u and master are kind clear, but c-u-f is supposed to be the "next" version so is not just "lots of rebuilds" vs. "just a handful", right?
<jpoiret>by the way, manifests and package rewriting are very impressive. Just tested upgrading libva in the dependency graph of a wayland compositor + libva-utils, used `guix environment`, and everything worked
<lilyp>rovanion: Guix environments are cheap -- they're no containers most of the time and even then it's often just a manual shell process
<lilyp>if you can arrange everything on your own inside of that then that's fine, but it is severely less expressive than operating-system
***stikonas_ is now known as stikonas
<tom112>Hi. I'm working on "erase your darlings" for Guix System. This will involve some small patches in the short term, and some longer term work. How am I best interacting with the mailing lists to track this?
<tom112>Raise an issue for long term tracking, and send separately send some the smaller patches to guix-patches@ ?
<tom112>Raise an issue for long term tracking, and separately send some the smaller patches to guix-patches@ ?*
<jpoiret>does anyone use a LUKS setup on Guix along those lines: encrypted root, use one passphrase in Grub, unlock in early userspace using key embedded in initramfs? if so, isn't the initramfs world-readable since it is in the store?
<lilyp>hmm, I wonder if there's a way to pass memory from GRUB to early userspace
***boosh[m] is now known as boost[m]
<jpoiret>tbf, i'm thinking of adding kexec support to shepherd so that we can reboot fast without going to grub, once we have that we could even consider using an EFISTUB minimal kernel+initramfs as a bootloader
<jpoiret>because one of GRUB's deficiencies is its terrible crypto performance for luks
<nckx>jpoiret: EFISTUB only works with UEFI firmware, though, which many people don't have and/or want, so we can't use it by default. That's GRUB's great advantage. Do you know if there's an alternative?
<jpoiret>yes. But then, if we don't really need the grub features, we could simply chose the smallest bootloader to chainload into the bootloader kernel. Although that would mean having an extra partition
<nckx>We're talking about the same thing, just not considering the same thing a ‘boot loader’.
<jpoiret>Also, that'll mean rebooting into a newly configured system will be faster
<jpoiret>nckx: about the libva version bump I talked about earlier, which branch should i send the patch for? master or c-u-f? it works fine as is on master, and only broke with c-u-f updates, that's why i'm wondering
<jpoiret>also since c-u is not c-u-f is not master
<jgart>It always builds guix.el from the latest commit
<minikN>jpoiret I got it. Quite embarrasing. I started coding that service directly in my config and moved it to its own file eventually, but I forgot to delete the residual shepherd service in my config :(
<jpoiret>heh, no worries, glad to see it's working :)
<minikN>jpoiret Not working yet, but at least I'm off to the next error :P
<ss2>nothing more? Can it be left out, or why is it placed there?
<minikN>roptat: Or maybe there is a better way? I'd like to only write the config option to file if the user specifies it. With strings that's easy, I can just set the default to "" and check for that, but with booleans, I have a problem because they need to either be #f or #t.
<roptat>it used to be required, so there's a message telling you to end the phase in #t, but it's actually not required anymore, so it's fine to leave it out
<tricon>roptat: I tried reversing their order but the results were the same. The issue I have is that when I reconfigure and restart networking, I lose access to my VM with dual NICs due to the default route changing. I can work around this, however.
<GNUHacker>how can I fix that?: "Received a bad CERTS cell: At least one certificate expired."
<minikN>roptat: It's working. This is how it is rn: https://paste.debian.net/1217683/ but if I pass a config option like so: (service iptsd-service-type (iptsd-configuration (block-on-palm "true"))) I get unbound variable block-on-palm.
<ajarara>If a dependency that guix itself depends on changes... then every guix involved in the boot-stripping process is rebuilt? How many are in the chain?
<apteryx>jgart: re the jami package in guix; have you tried it yet? works for me, at least the basic features such as video calling and sending messages. I haven't had much luck with calls recording though.
<roptat>minikN, '((string-append "BlockOnPalm = " block-on-palm)) makes block-on-palm a symbol, and in the gexp this symbols becomes a variable, that was never bound inside the gexp
<apteryx>sending files is also flaky (as in; requires an uninterrupted connection to the destination from the moment you initialize the request -- which is bound to fail) in the current release; that's supposed to change with a complete rework of the way it works in the upcoming release
<roptat>minikN, use `(,(string-append "BlockOnPalm = " block-on-palm)) instead
<lilyp>I think the real problem is that the term "boot stripping" does not really lend itself well to being searched (the confusion with bootstrapping is real)
<lilyp>ajarara: I don't think it is a hard requirement to build revision 3 with 2 with 1 with 0 with 1.2.x-n, and so on
<lilyp>but there are particular points where guix pull might fail to get you ahead
<lilyp>so you can't really jump from 0.14 all the way to 1.4
<lilyp>but with some intermediate steps (let's say, 0.16, 1.0, 1.2, 1.3-8) you might
<ajarara>I think I understand what you're saying: you mean that it's possible you pull before the latest version of guix, cache miss, and start building? But that we update guix infrequently enough that there's only a small window to observe that?
<ajarara>but I don't know how that relates, so I'm probably misunderstanding.
<lilyp>Well, cache miss and manual build might happen either way.
<ajarara>lilyp: I'm trying to update libssh for guix, specifically for ssh keys stored on security keys. It takes a _very_ long time, and the dependency graph when I swap out libssh for a local checkout is very large. I'm thinking this is the problem.
<lilyp>Well, yeah, updating libssh is probably a core-updates endeavour
<ajarara>hmm.. I'm going to play around with this some more and see if I can explain myself better later.
<jgart>has anyone used the jami package in guix successfully?
<roptat>ajarara, lilyp but guix pull has nothing to do with the guix package definition
<apteryx>jgart: for jami on a foreign distro, currently launching it is a bit tricky (because of the incontrolled dbus config of the host). You'll find pointers in the http://issues.guix.gnu.org/48538 issue.
<jgart>it seems pretty straightforward for me on xfce
<jgart>there's some magic going on that I'm not aware of
<attila_lendvai>tough luck: i imported countless packages with the go importer, but it probably produces circular dependencies, because attempting to build it runs for a while silently and eventually the heap blows up. is there circular dependency detection?
<nckx>M6piz7wk[m]: The latest IceCat release is 60.7. For comparison, the latest Firefox release is 93.0.
<nckx>I cannot in good conscience recommend running a release version of IceCat at this time.
<M6piz7wk[m]>the ice cat i have is 91.2.0 though so i assume it's maintained just the binaries are not released?