IRC channel logs
2023-11-16.log
back to list of logs
<Kolev>So just add (service docker-service-type) to (services) and add myself to "docker" group. Got it. <Kolev>Oh, and use the (gnu services docker) module. <Kolev>I'm so glad Guix uses a real language for its configs. <mange>If you've just added yourself to the docker group then you'll need to log out+in to make that effective. A full reboot shouldn't be needed, but will also work. <Kabouik>So I tried both the official Guix installer and the installer from Systemcrafters, with a small USB stick as well as a 128GB stick, and I get the same issue all the time. Eve-ry-time I chroot into my existing install and try to guix system reconfigure, dbus crashes and, with it, the network interfaces, thereby totally preventing the guix system reconfigure. I can't see to find any other way to fix my boot partition. <Kolev>mange, tried it in another TTY. It works well. I can now use Thumbsup to generate photo albums! đ <Kabouik>Would there be another way to reinstall Grub on tw the ESP/EFI partition? <mange>When your networks go down, how do you get the interfaces back up? Have you tried manually running dhclient {interface} to get an IP thorough DHCP? <Kabouik>I tried `ip link dev eth0 up`, but not dhclient eth0. I can try that, but even if it works, I think D-bus will still be killed and cause many other issues (or get killed again). <mange>I imagine so, too, but having a live network is better than nothing. :) <Kabouik>I'll try it again and let you know mange! <Kabouik>So just before I try to revive the network interfaces, this is the issue when guix system reconfiguring: https://0x0.st/Hv2v.jpg This is with the official Guix installer, which may not be ideal for my config.scm because it contains nonfree stuff, but I also tried Systemcrafter's installer and got the same D-bus kill. <Kabouik>dhclient works to restore the IP mange, but unfortunately the original issue persists <Kabouik>It may save me from rebooting and manually typing all commands over and over though (unless the D-bus crash causes other issues, which is likely), thanks. <Kabouik>Hum. There's some hope again mange. After reviving the interfaces with your help, I tried a guix pull and it worked (though it guix pulled as root since I was in chroot). And now I'm trying the reconfigure again and it doesn't seem to fail as early as it used too. Fingers crossed really hard. <Kabouik>My EFI partition is 500 MB large, is that too small? I think it worked so far. There's also 3.72 GiB of unallocated storage juster between this partition and the root partition. Should I try to allocate them to the boot partition and retry the reconfigure? <KE0VVT>Can I do a system reconfigure while doing a home reconfigure? <Kabouik>Can someone with Guix system show me their boot and root partitions in Gparted please? <KE0VVT>Kabouik: It may take a while. I don't have Parted installed. <Kabouik>Meanwhile, just lsblk and fdisk -l could be of great help KE0VVT! <Kabouik>I'm trying to check if my EFI partition should be extended and if that unallocated space after it is expected. <KE0VVT>Kabouik: I just have two partitions and both are ext. <podiki>my boot partition is 500 megabytes of which 11 are used (roughly) <Kabouik>Thanks, so I guess mine is normal. Any idea about the issue in the picture above podiki? <KE0VVT>I'm stuck in a TTY until guix pull finishes. <podiki>i'm not sure but setup should be the same as anywhere else I think <Kabouik>Could it be that mounting /dev/nvmen1p1 to /mnt/boot/efi is not enough, since as far as I remember the boot is encrypted too in Guix, no? <podiki>i don't have any encrypted drives/boot on my guix box <podiki>encrytped boot is always tricky, not sure how that works here <podiki>other people do encrypt drives but I'm not sure if boot is included <Kabouik>In my case it's not a setup, but an attempt at rescuing an existing system that no longer boots; so I'm chrooting into it and trying to reconfigure from there. It was working until grub-install complained that there was nos space left on device <Kabouik>I don't actually now for sure whether the boot partition is encrypted, but I know I used to need to type my passphrase once to reach Grub, and then once again to reach the logon screen. <Kabouik>And I can luksOpen the root partition, but not the boot one, so I don't know how to unlock it if it is encrypted. <podiki>if you needed a passphrase before grub then I think it is encrypted <podiki>there's just the prompt for a password that unlocks the boot partition, if it is like what I did on my laptop (not guix) <podiki>then grub loads and asks for password to unlock root (unless it is set up where first password also gets grub a passkey file to unlock root for instance) <podiki>but just guessing based on my own setup; could be something else like it is not mounted where it is expected? or not mounted read-write? <Kabouik>Yes, passphrase prompt, Grub, passphrase prompt. But while in a Guix installer or another Live USB, I can luksOpen the / partition but not boot. I can even mount it directly, and I assume this may be the issue when it says no space left. <ulfvonbelow>guix build --no-grafts --derivations -e '(begin (use-modules (guix packages) (gnu packages gtk)) ((package-mapping identity) cairo-sans-poppler))' -e '(@ (gnu packages gtk) cairo-sans-poppler)' <ulfvonbelow>I want to confirm they produce different derivations and it's not just a consequence of my local tinkering <podiki>ulfvonbelow: /gnu/store/51hwf2mc2ig76a3nm86msv4z9az3s0j3-cairo-1.16.0.drv <podiki>/gnu/store/q78ziqcg2dvi2lzj18hzdld85bcydzwk-cairo-1.16.0.drv <podiki>have to run but if I think of anything I'll let you know. maybe post on help-guix list to get some visibility? <Kabouik>Thanks anyway. Crossing fingers for other Guix wizards to spawn here. :< <mange>Kabouik: what does df -h show? <Kabouik>It did show >400M of free space mange <mange>Does it show any other partition being close to full? Presumably something is full? <Kabouik>My understanding from the photo was that the full partition was /boot, no? <mange>Sure, but you're saying it's not full, so I'm just trying to think about other potential explanations for that error message. <Kabouik>The root partition is not full but has only 25 GB free, and I have seen situations whereby this wouldn't be enough for some Guix operations; plus it's btrfs so I'm not sure about how reliable is this 25GB estimate <Kabouik>The SSD is actually larger (it was cloned from a smaller one but I didn't expanda1d the btrfs fs yet), so I can try that, that's a good idea <Kabouik>But I'm thinking tw the issue could also be that /boot might be encrypted since I would typically had to type my passphrase before Grub when it was booting. <mange>But you could see its contents? You run "ls /boot/efi" and get results, right? <Kabouik>I only see a single file in /boot/efi/EFI/Guix/grubx64.efi, which sounds weird mange <mange>Maybe the issue isn't actually to do with /boot. Reading your error message again, it says "Could not prepare Boot variable", which is something different. You could try something like this: https://unix.stackexchange.com/a/379824 <Kabouik>Hum that could be it mange, I did it and then tried to reconfigure and I didn't get the same error, but the network breakage hapened again and `ip link set dev eth0` does not put it back up it now⌠Aaaaaa. <podiki>Kabouik: I meant an email to the help-guix mailing list; you could repeat or summarize pointing out you filed a bug report; just a possibility <Kabouik>Holy Molly mange! How about marrying me? Don't bother answering, I decided for you. Marry me. <Kabouik>I could boot! It froze immediately on my desktop, but still, it booted! <podiki>wooo! glad you got it figured out <Kabouik>Me too, thanks podiki! I'm not out of toruble yet though, it seems my network interfaces no longer work now, either WiFi or Eth <Kabouik>I assume it may be because I ran `guix system reconfigure` from the official Guix installer, and the libre kernel does not support my hardware. I have a RJ45 port but it doesn't get an IP. <podiki>wired I guess could need non-free but I would hope that is rare <Kabouik>WLAN doesn't even show up, and wired stays DOWN <Kabouik>I had an older guix system generation that boots and has network, phew! <Kabouik>What would be the best strategy from there? Guix system reconfigure directly, or deleting the older generation with no network? <podiki>i would just reconfigure, keep old ones until you really want to free up space or are sure <podiki>probably not that much space on just a system generation (my guess, as one that keeps my config light on packages in system) <Kabouik>I should lighten my packages in system actually, but don't use guix home yet so I initially filled it with al packages I'd like on a new install. <Kabouik>These efivars/dump-* files were apparently the culprit for me, as they prevented a grub-install in my latest reconfigure. Is that a known issue? It seems pretty bad as it breaks boot and is not straightforward. <podiki>i think the question is what causes it and if something guix does that can lead to it <podiki>or if this is a known issue in general and something we can do to mitigate <Kabouik>Looking at the #guix logs, I found jpoiret mentioning the deletion of /sys/firmware/efi/efivars/dump-* too. <Kabouik>I guess it is fine to cumulate them until they make a reconfigure/grub-install abort and break the boot <Kabouik>Heh, I found another match in the logs⌠Involving jpoiret and myself. But at the time, this didn't break boot, just reconfigure, so it was not that bad. <KE0VVT>What does this mean? guix system: error: aborting reconfiguration because commit a60ff4611a8814d1f33d64af07401762afbcc597 of channel 'guix' is not a descendant of 3d15e9e5bcd7cdad33 <KE0VVT>mange: I'm just reconfiguring my system. Why could this have come up? <mange>Well, commit a60ff4611a is from last week, and commit 3d15e9e5bc is from two days ago. Guix is blocking you from rolling back your OS ~5 days. Can you check which guix you're running with "guix describe"? <KE0VVT>mange: d987b75618a62c95c030e7ca53e0972e700c4f06 <mange>Right, so that's neither of the two commits mentioned in the error message. Is it possible you're running the system reconfigure using root's guix? What does "sudo guix describe" say? <KE0VVT>mange: I'm doing sudo guix system reconfigure. <KE0VVT>mange: `sudo guix describe` is at commit d987b75618a62c95c030e7ca53e0972e700c4f06 <pret7>hmmm, is system reconfigure hanging for anyone else? I'm at d987b75618a62c95c030e7ca53e0972e700c4f06, and running at any verbosity level doesn't seem to output anything, just hangs <pret7>not really sure how to debug this, strace says it's polling something or the other, but that's not particularly informative <pret7>oh wait no it started again, something wrong with one of my substitute servers I guess. Hmm, that was something like 5-6 min without any output. I might see if it's possible to add some warnings or something <saravia>Hi coleagues, I have a question, is posible reproduce for example an "hyperbola" or "hyperboliced" guix environment, because, hyperbola is to light, then, I was see on guix you can reproduce enviroments <saravia>^ maybe using the list of packages versions <jacobk>As someone who doesn't know that much about Guix, what you are asking for seems possible, but maybe someone more knowledgable can give a better answer <KE0VVT>jacobk: I'm thinking of reproducing the Trisquel desktop with Guix. ;) <jacobk>Then if Ubuntu moves more towards using snaps for everything maybe Trisquel 13.0 can be based on Guix instead of Ubuntu xD <jacobk>but fix the package versions so people don't notice the difference <saravia>KE0VVT: yes that is good idea, reproduce Trisquel or Hyperbola maybe, Guix a envirometer <saravia>jacobk: what difference? of what package repair? <jacobk>the difference that Trisquel is no longer using apt and software from Ubuntu, but guix instead <saravia>jacobk: for example on my virtual machine I can use hyperbola with guix like package repository only for for add hyperbola banned packages <jacobk>yes, but your core is still from Hyperbola <saravia>jacobk: oh so yes, Its true but I think for replace apt in Trisquel will be dificult, because some people use a GUI for install packages and for replace that GUI I think maybe it will very dificult <jacobk>Could just make a apt replacement that translates apt commands to guix commands <jacobk>That's probably harder than it sounds <retropikzel>I noticed that tuba does not work on guix because it needs gsettings-desktop-schemas package. Where is right place to report this? <efraim>here's what I'm seeing as the minimum: guix shell --pure tuba gsettings-desktop-schemas dbus glib:bin -- tuba <efraim>retropikzel: actually on the bug-guix mailing list, but I can take care of it now <efraim>retropikzel: ok, it's fixed. if you run guix pull you can update tuba and now all it wants is dbus for the secret storage <efraim>ok, I'm putting the haskell cross compiler on hold and going back to the rust cross compiler <efraim>I might need some patches for llvm-15 :/ only successfully built the sysroot for i686 and aarch64 from x86_64 <Kabouik>efraim, I added in my config the bits from yours about swaylock, but swaylock still complains about being setuid but compiled with the PAM backend. However, I have another swaylock-related chunk in my config: https://0x0.st/HvL5.txt Could that be the culprit? <Kabouik>It's swaylock-effects, not swaylock, but is within (setuid-programs âŚ). <efraim>probably. does swaylock-effects also provide swaylock? <efraim>if you want to use setuid then I'd set using-pam? to #f and using-setuid? to #t, and then you can use swaylock-effects as the package in specification->package instead of swaylock <Kabouik>That's a good question. I assumed that it didn't, but indeed its binary is just `swaylock` <Kabouik>I don't know the difference between setuid and pam really, so I'll stick to the recommended standard. Maybe I can just delete that chunk from the pastebin above, and replace swaylock by swaylock-effects in your chunk? <efraim>Kabouik: that's what I'd suggest <Kabouik>It's not clear to me if I should also change the (name "swaylock") or whether this one should reflect the name of the binary <efraim>the "name" I'd leave as swaylock, the program I'd switch the specification->pacakge to be swaylock-effects <efraim>I checked for fun, can't build the rust sysroot for the hurd or 32bit or 64bit windows <civodul>so youâd use (cute x <> (expensive a b c)) to ensure âexpensiveâ is called only once <phf>civodul: Ah, I see. Thanks! <sturm>hi folks :) If I am running an mcron service with guix home, does shepherd capture the stdout/stderr output? <Lumine>I'm still trying to figure that one out. It didn't seem to start any daemons after enabling the mcron service for me. <Lumine>And I can't figure out the correct g-expression to add the jobs directly, I must've tried half a dozen combos. Being a Guile noob sucks. <sturm>I also had to add (gnu packages idutils) and (gnu home services mcron) to (use-modules ...) <Lumine>Thanks for the tip, I had the latter module loaded already <mirai>are there instructions on how to create a guix livecd/volatile image? I'd like to have a âvolatileâ boot media with xfce for airgapped operations <efraim>cbaines: it might have a not new enough daemon <cbaines>indeed, I can have a look at updating the daemon on some machines <Kabouik>How can I use the equivalent of `guix build --with-c-toolchain=hwloc=clang-toolchain` in a package definition to favour clang and clang++ for compilation? <civodul>cbaines: the client determines whether the daemon itâs talking to supports âbuiltin:git-downloadâ; when it does, it creates a derivation that uses it <civodul>if you move that derivation to a machine with an older daemon, it wonât be able to do anything with it <civodul>thatâs probably whatâs happening here <cbaines>when running the data service at least, I haven't being attempting to control the guix-daemon version <civodul>thatâs generally unnecessary⌠except here <civodul>maybe we need a knob to disable use of âbuiltin:git-downloadâ <civodul>Kabouik: in packages, itâs often sufficient to add âclangâ (say) to ânative-inputsâ <civodul>sturm: hi! mcron itself captures stdout/stderr of its jobs and writes it to its log file <Kabouik>Ah, it's just in inputs currently. Do you think removing the setenvs and just moving clang to native-inputs could work? Let's try. <cbaines>yeah, I'm not sure where that is best placed though <civodul>sturm: thatâs in ~/.local/state/shepherd/mcron.log on my machine (kinda weird actually) <cbaines>I assume Cuirass has the same issue though, and maybe offloading too <mirai>civodul: the log dir looks right to me <mirai>unless there's a syslog equivalent we could use? <mirai>user mcron using ~/.local/state conforms to XDG Base directory <civodul>mirai: âlocate mcron.log |grep /homeâ shows me 3 files: ~/.local/var/log (June 18), ~/.local/state/log (Aug. 20), and ~/.local/state/shepherd (now) <efraim>civodul: time to use the features field if the build-machine definition? <civodul>so it seems to have changed over time :-) <civodul>efraim: thatâs more intended for KVM, GPUs, things like that <civodul>and it would only help for offloading <mirai>~/.local/var/log isn't good IMO, the kind of file here fits best under $XDG_STATE_HOME <mirai>I recall tweaking with guix-home's XDG_LOG_HOME in the past <mirai>it got another round of tweaks after that <mirai>something that could be worth exploring is whether there's a syslog equivalent for guix-home <mirai>for guix-home services to unify their logging in the same way that regular system services behave (i.e. using syslog) <Kabouik>I think I needed what you said + removing the gcc import + re-enabling the CC and CXX setenvs civodul. I believe it's using clang now. <civodul>mirai: one thing iâve considered is implementing syslog in the shepherd <civodul>thatâd give us the needed flexibility, among other benefits <civodul>also iâd like to replace rottlog: itâs all clunky and insists on having config files in /etc, so you canât use it for Home <civodul>plus we can get the basic features in place in maybe 100 lines of code <civodul>we put that in (gnu build log-rotation) and fire it from an mcron job <mirai>hmm⌠something tells me that there's some non-trivial work on getting it right⢠(see sneek's occasionally missing logs, something something time is hard - see fibers, shepherd hangs & co.) <hannes`>hi guys how to change linux VT font size? do i use console-font-service-type? which pkg is this in? how can i generally search for which service-type is provided where? <f1refly>how does one use webrtc screensharing on guix? <f1refly>the line I use in my sway config on my other system has a --systemd flag and I doubt it'll work on this system :) <f1refly>it's a bit of a problem because i'm on wayland and haven't figured things out yet <hannes`>how well does wayland work? i have a gpu, only see people grafting stuff onto xorg, unsure how this would work. but i really want to give hyprland a try <ohdienge>What packages are (semi-)unique in guix and (mostly) not available elsewhere ? (such as icecat) <ohdienge>(I'm using guix on top of another distro) <Kabouik>Nyxt I think is only packaged for Guix, and I guess a lot of stuff in Guix private channels <gabber`>ohdienge: i don't think icecat is *that* specific. i'd guess cuirass <gabber`>and GNU shepherd and other Guix specifics probably too, like mcron <antipode>sneek: later tell efraim: on Rust cross-compilation: I tried adding cross-compilation support to antioxidant, and while I didn't finish it, it appeared to be relatively simple -- IIRC, almost all I needed to do was defining a package for the standard Rust library (a slight difficulty was that the Cargo.toml of the Rust library and its dependencies is incomplete, so I had to add a few files). I don't think I saved the partial work, t <ohdienge>gabber`: cool thanks. Any idea whether cuirass integrates with forgejo ? <gabber`>ohdienge: not the slightest idea. what i know for sure it that these tools were designed *for* Guix (system) - so depending on what you intend to do, installing GNU Guix System might be the easiest path to go <Kabouik>If you look into CLI tools or private channels, I think you'll find tens of packages that are only packaged for Guix because some Guix users needed them at some point. In my case, there's nmail, nchat, shirah, batsignal, rot8, which I think are not packaged for other distros (but these are just examples). There's also hundreds of tools packaged for everything but Guix. :p <antipode>sneek: later tell civodul: rottlog and equivalents are fundamentally racy/lossy, better do something else instead like e.g. telling the service to write to a pipe (instead of a regular file) and implementing a service that reads from the pipes and writing it to an appropriately-named (new or already existing) (i.e., including something like the date or a -1,-2 suffix). (Also nicer w.r.t. sandboxing.) <Kabouik>What is the policy regarding packages that are built based on latest commits in a branch? I plan on submitting two packages for the main Guix channel that are release-based (which I think is typical), but also have two package variations for them to get latest commits, and thought they'd go well together. Should I submit them or discard them? <sneek>civodul, you have 1 message! <sneek>civodul, antipode says: rottlog and equivalents are fundamentally racy/lossy, better do something else instead like e.g. telling the service to write to a pipe (instead of a regular file) and implementing a service that reads from the pipes and writing it to an appropriately-named (new or already existing) (i.e., including something like the date or a -1,-2 suffix). (Also nicer w.r.t. sandboxing.) <civodul>itâs actually shepherd writing those log files so maybe it could be made a little smarter⌠<antipode>I mean, almost anything is better than a shell script, but the fundamental design can be improved. <antipode>I thought that it was (non-Guix) software that had "--log file-name" arguments or the like (which has to be be occasionally deleted or rotated (with something like rottlog or better) to keep things from growing indefinitely and to keep tings orderly) , but perhaps that's (currently) only present in Guix System stuff. <civodul>antipode: re anythingâs better than this shell script, agreed <civodul>i think services we have either write to stdout/stderr, and that is channeled by shepherd, or they write to syslog <civodul>i think few of them write directly to a file <antipode>Few is not none, though, but perhaps those services can simply be told write to the 'file' /dev/fd/[some number]. <civodul>itâd be good to view which services do that actually <civodul>new security team officer, right? :-) <civodul>ACTION just caught up on 1.5mo of guix-devel activity <podiki>:) I saw your email but didn't have a chance to read fully yet <podiki>also saw some xorg security patch (for master, no graft needed I think) <antipode>There might be software out there that assumes logs are regular files (and break with, say, pipes) (I think there exist some software that moves the old log out of the way and create a new log), but those probably are simple to patch. <antipode>(Alternatively, the âmoving logsâ functionality can simply be left in-place, because that's pretty much the purpose of things like rottlog.) <podiki>efraim: how are things looking for mesa-updates on your end? my quick look shows we're down on aarch64 most noticeably <civodul>antipode: i guess we can start with rottlog-in-scheme, because thatâs easy and immediately usable, and then gradually move to the better option <antipode>Personally I would go directly to the better option, but that's an improvement over the status quo too. <dthompson>ah, a log discussion! I was just dealing with rottlog this morning. <sneek>Welcome back dthompson, you have 1 message! <sneek>dthompson, parnikkapore says: ok, nice! I saw a lot of emphasis on SXML in a quick look through the documentation so I wasn't sure if making it do gemtext etc. would be too against the grain <dthompson>I would love a better solution for managing logs of things like nginx <dthompson>I have to use rottlog to rotate them and then send SIGUSR1 to nginx to reopen the log files <tribals>Could you please help me properly configure Guix system's swap file? <Kabouik>unmatched-paren, I remember that you sent me once a short text file synthesizing the commands required to submit a patch to Guix using git-mail. Would you by any chance still have it somewhere? <tribals>I've configure some swap file, but seems like system doesn't use it <tribals>Do I need to create such a file beforehand? <tribals>Kabouik could you please share it for me? anthony_s <Kabouik>I just did, but it looks fairly similar to what you did and I'm not skilled enough to help you debug yours if it doesn't work, sorry. :( <tribals>Oh. I'm getting 401 on sr.ht. That's what I mean by "share it" <tribals>But it is really similar - don't bother <Kabouik>Oh, maybe my guix-config is private actually, sorry. https://0x0.st/Hvf4.txt It really looks like yours, except for /swap/swapfile, and I don't know how important that is. <tribals>I'm betting the file name may be arbitrary <Kabouik>Found it burried somewhere on my drive unmatched-paren! <tribals>But how to specify file size then?.. đ¤ <Kabouik>Mine is 16GB but I cannot find any line in my config setting that. <podiki>didn't see full discussion but the creation of the file you handle outside of the config, as far as I remember <podiki>I don't know of a way to do that in the config, though I suppose you can have some service to create the file with the right settings and permissions if it doesn't exist? though not sure if that can happen early enough? or you'd want to do it on reconfig.... <Kabouik>I was thinking that maybe the file was just created once manually indeed <tribals>Created it by hand, and it is picked up! <tribals>It is now interesting if (dependencies file-systems) is required <podiki>I think it is in my case, of btrfs subvols to have it available when mounting at boot, but I don't remember for sure (haven't not looked at your config and what dependencies is for yours though) <tribals>Yep, dependencies are unnecessary (I have only one root partition, though) <Kabouik>Speaking of btrfs. My root filesystem is in btrfs but I never created any subvolume. I think I'm missing all the pros of having btrfs. :< <efraim>sneek: later tell antipode if you want to see where I'm at with rust cross-compilation https://bpa.st/5LJA . Ignore make-rust-cross, make-rust-sysroot pretty much just works. I'm still getting tons of problems with building it for some architectures and with some crates not finding their dependencies <sneek>efraim, antipode says: on Rust cross-compilation: I tried adding cross-compilation support to antioxidant, and while I didn't finish it, it appeared to be relatively simple -- IIRC, almost all I needed to do was defining a package for the standard Rust library (a slight difficulty was that the Cargo.toml of the Rust library and its dependencies is incomplete, so I had to add a few files). I don't think I saved the partial work, t <jpoiret>efraim: is antioxidant getting picked up again? <efraim>but curl built fine for armhf and aarch64 so that's fixed <efraim>jpoiret: I hope to now that I'm almost caught up with the rust releases <jpoiret>wow, that's great, thanks for picking it up <vivien>Iâm progressing on upgrading gnome-builder, but I will hit a problem soon: there are many individual updates I sent earlier that will be required. QA will miss them and report failure. Is there a solution for QA to understand I need other patches before this series? <tribals>Another question is: can I distribute Guix services in channel? <mhcat>I have a question re guix.el - the guix-profiles interface seems not to be working for me; "c", which is bound to guix-profile-list-set-current, seems to copy the path of the profile to my kill ring and do nothing else. When I refresh the buffer the (current) mark hasn't moved <mhcat>also, the guix-set-emacs-environment command seems not to know about the profiles I've configured via the `guix-profiles` variable <mhcat>I guess my question is: am I doing this wrong? :) <bumble>hello and thank you for applying the scrollbar width patch! :) <roptat>bumble, yw, any more problems with progress bars? <bumble>no problems, everything works and looks great! <roptat>the visit cards on the sides are new, the stickers on the right are the old ones I had left, the ones on the left are the new ones. Better orange, but the dark gray is is a bit funny <roptat>just in time for this weekend :) <roptat>and if we don't meet this weekend, I'll bring them to Fosdem <roptat>also, happy to send a few by mail if you can't make it to Fosdem either! <podiki>efraim: yeah, non x86 low across the board except powerpc holding out at 76% <podiki>efraim: seems bordeaux does better on the other archs, given some time <efraim>as someone with an ibook g4 behind them, I assume you meant powerpc64le :) <podiki>i'm ignorant on pretty much any architecture that isn't x86/x86_64 <efraim>powerpc64le is a big beefy machine that puts x86_64 to shame, powerpc is used in routers (sometimes) and in 20 year old machines :) <podiki>on the general topic, do you run guix on any sbc or similar small machines? <efraim>I have guix system running on my pine64, rock64, pinebook pro and hifive unmatched. Haven't worked on the image yet for the visionfive2 yet and not sure I'll bother with the visionfive1 <efraim>I guess I'm starting to collect devices :) <podiki>I'm looking to replace my pi4 which I run with Arch as a home server (nothing too heavy duty, maybe synapse is the most intensive) <podiki>I'd probably have to resort to Docker to run a lot of the services but would be nice to use guix <podiki>any recommendations to look into? <PotentialUser73>Hello. Is there a way to import a manifest.scm file into another manifest? Say I have some packages that I want to always include in every dev shell, could I have a "main" manifest that gets imported into "sub" manifests that target different projects? I eventually want each of those "sub" manifests to be packaged with guix pack, so I don't think I <PotentialUser73>can install those "main" manifest packages globally and still have pack work as needed <efraim>an old laptop might be best ;D it comes with a battery, doesn't use a lot of power and has a screen and keyboard for when necessary <efraim>one of my rock64s has been doing great thermally, the other one I need to find a fan for. all the riscv64 stuff is incredibly slow <podiki>having recently gone up and down the stairs from the basement to the top floor to bring my pi to a monitor and keyboard (all it wanted was one keystroke to resume a boot it turns out)....that is a good point <podiki>I haven't kept track closely but can't wait to see more riscv in the future <podiki>pretty much. one of those "control-d to continue or drop into rescue shell" <efraim>occasionally I have to take out the sd card and run fsck and put it back in <podiki>due to bad update on arch (the pi has been really disliking upgrades recently and freezes up); which really makes me want guix <podiki>yup, done that too in the past but I was worried the failed update hosed it (luckily not) <efraim>I think there was interest in running guix on the pi, not sure where that went beyond getting netboot working <podiki>something with working around the bootloader was the main obstacle maybe? <podiki>also an excuse to get a new toy :) <efraim>I ordered a pi5, its waiting at my parents' house in the states. I have my pi1 in a drawer in case I ever suddenly need it again <podiki>going to go guix on the pi5? I was considering that too but figured I'd ask around and see what else is new these days <vivien>spiderbit, some development has been done on gnome-team for hwdb support in eudev <tribals>Another question is about Cuirass. I set up an instance to build my own channel. Everything seems to go well, but I don't know: in the cuirass spec, do I need to specify main guix channel if I only want to build my own package? <efraim>I'm thinking of changing my pine64 to host tftp images for the different boards since I always wanted to figure that out, and then I needed another arm board <podiki>tribals: I don't think so? (haven't used cuirass on my own but based on seeing other sub servers) <spiderbit>does eudev not have hwdb support? I don't think that is true? I thought I am just to inexperienced to configure guix to dynamically create the files in the eudev process used by the other services <vivien>spiderbit, you might want to cherry-pick eudev-related updates in gnome-team, but unfortunately, it is not merged yet <spiderbit>vivien I don't get how that is related to gnome are you talking about wayland maybe? it's supposed to work in all X and even on tty <spiderbit>even without Xserver as far as I understand it should work or at least with all X <vivien>spiderbit, it was a big world rebuild that was required for gnome, and so we did it on gnome-team <vivien>Maybe it could be cherry-picked into core-updates <spiderbit>and when is this sheduled to hit upstream in guix next gnome release? <vivien>Weâre working to package 44.6. <vivien>I have submitted updates for entries up to gnome-builder <vivien>I am now working on gnome-builder <tribals>My logic was: cuirass needs to be able to load everything it instructed to build. Even if it is instructed to build my own package, such a package definetely needs "whole" guix because there is no such thing as "a package" without it. <vivien>I donât know how guix wants to release things <podiki>tribals: ah yes, I see the same on a different channel <spiderbit>so eudev had no way to load hwdb files before this change? <podiki>vivien and spiderbit: usually whenever the branch is built and works it will be merged <spiderbit>ahh it was broken, so my bad guix skills were not the problem :) at least not the only one... <podiki>a core-updates merge should be coming "soon" too, so fixes could go through there first if that will be done sooner <spiderbit>Ahh I see the fix is in euvdev 3.2.14 but guix has 3.2.12 currently <podiki>or if we get another mesa-updates before gnome is ready we can put it there; normally should be a quick branch update but this time did some ungrafting and more rebuilds <KE0VVT_>Where does Ungoogled Chromium store its settings? <KE0VVT_>zamfofex: Is that fully equivalent to ~/.mozilla/? I'm migrating someone's home directory to Guix System. <spiderbit>so do you then add this config settings, something like wit the rule file: udev-rule [file-name contents] <Andronikos>I have a disk image which I created through using dd. Can I now just run "gzip -9 <dd-image> <output-path>.gz"? Since, how does it know it can compress the unused space? <vivien>podiki, spiderbit, you might want to look around cde1becfaba7a5757b881a5940ef0c6c2a70794f..ee554a35e012ecefc9e9e2267e1387b3bf1ca5a5 to cherry-pick stuff <vivien>Maybe thereâs more around these commits but I canât search efficiently <Andronikos>The disk image is 466GiB but the actual used size should be ~80GiB. I had 150GiB free space on the HDD that stored the compressed image and gzip stopped with "ouf of space". <podiki>vivien: thanks, will keep that in mind if we need to move some updates in sooner <spiderbit>vivien that looks like all the config options are exposed neccesary: <spiderbit>looks great I can wait a few weeks I guess don't know how to cherry pick my own version of guix :D <spiderbit>can I switch to guix "head" by switching the repository or something :D <vivien>Thatâs decided when you run "guix pull", but unfortunately the gnome-team branch is far from being ready yet sorry <spiderbit>but it's not in master, but must be merged right? <spiderbit>vivien ok then I wait should come this year I guess not so urgent <spiderbit>I waited 3 years for that can wait a few more weeks :D <vivien>I canât give you a timeline, because we are used to GNOME doing surprising things <spiderbit>I still don't get what that has to do with gnome but we will see <ekaitz>efraim: can you help me a little? <antipode>sneek: later tell efraim: IIRC, instead of building a Rust cross-compiler, I âmerelyâ used the native Russ cross-compiler and passed it the equivalent of --target=.... (OTOH, I only started doing it, I didn't get to the point where I build an actual application). <sneek>Welcome back antipode, you have 1 message! <sneek>antipode, efraim says: if you want to see where I'm at with rust cross-compilation https://bpa.st/5LJA . Ignore make-rust-cross, make-rust-sysroot pretty much just works. I'm still getting tons of problems with building it for some architectures and with some crates not finding their dependencies <antipode>sneek: later tell efraim: those "[target.STUFF] STUFF" look familiar, though. <PotentialUser-70>how to daemonize the docker? Herd doesnt have it and I couldnt find it in guix services but it keeps saying me Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? (Details: [2] No such file or directory) <jbnote>Hi Guix, all my NFS-mounted root filesystem GuixSD systems are refusing to reboot due to some NFS kernel thread being waited for by the Shepherd during shutdown. I've seen in (gnu services shepherd) that there is a provision to add 'omitted pids' which I think this NFSv4 thread is falling under [the infinite wait which triggers is circa line 629]. How is one supposed to fill in the %do-not-kill file /etc/shepherd/do-not-kill ? I ca <jbnote>find no reference to it beyond this file, and never in write mode. <antipode>chucho: if it weren't Rust, it would be quite simple (Rust in Guix is in a terrible shape currently -- there has been work on fixing the situation but it isn't 100% there yet and it's not something that can partially be merged). Now, despite the cargo madness, it is not super long, so it should be doable (still simple, but less simple than typical C software). <antipode>So, I'd say, try it out? (There are instructions in the manual) <antipode>(Also, Go has similar issues with dependency duplication and explosion.) <antipode>jbnote: I don't know NFS well, but better update your system -- GuixSD is old, better update to Guix System. <jbnote>antipode: what's the difference? I'm using mainline Guix to generate the systems. <Kolev>Why the change from GuixSD to Guix System? <jbnote>antipode: Ok, so i'm mistaken then. I'm using Guix System ;) <antipode>Kolev: â We used to refer to Guix System as âGuix System Distributionâ or âGuixSDâ. We now consider it makes more sense to group everything under the âGuixâ banner since, after all, Guix System is readily available through the âguix systemâ command, even if youâre using a different distro underneath!â <Andronikos>PotentialUser-70: You need to add (docker-service-type) to your config.scm (system config). You also need to import the module (gnu services docker). <Kolev>antipode, I love how you can install Guix from another running operating system. <antipode>(Even if you aren't using Guix System (because different distro), you still have access to Guix System in form of the VM!) <antipode>PotentialUser-70: Maybe you should look in the Guix services again? <antipode>nevermind, seems like Andronikos already answered. <Andronikos>Can we change the HTML generation of the documentation? It is really annyoing to not have anchors and always scroll up to the index for posting it in here. <antipode>If texinfo doesn't already have an option for that, surely texinfo could be patched to add that functionality. <Andronikos>Should I create an issue or would this be more fitted in the guix-devel ML? <Andronikos>Just to be sure, it was simply sending an email to guix-devel@gnu.org? <antipode>Though I would say there's a good chance you will more-or-less be redirected towards the texinfo mailing list (perhaps with some other people following you to assist with implementation.) <antipode>If that's your first e-mail, it will be in a waiting queue for a while to be âapprovedâ (manual spam filtering), but later e-mails shouldn't be delayed. <antipode>(a while: <2 days, from what I've heard) <Andronikos>sneek: later tell antipode: I sent it to the ML. <ieugen>hello vagrantc, can I bother you about guix on debian ? I saw you are a maintainer <PotentialUser73>Is there a way to import a manifest.scm file into another manifest? Say I have some packages that I want to always include in every dev shell, could I have a "main" manifest that gets imported into "sub" manifests that target different projects? I eventually want each of those "sub" manifests to be packaged with guix pack, so I don't think I can <PotentialUser73>install those "main" manifest packages globally and still have pack work as needed <civodul>PotentialUser73: hi! you can always do (load "sub-manifest.scm") from your main manifest <civodul>and write: (contactenate-manifests (list m1 m2 m3 âŚ)) <PotentialUser73>so how are m1, m2, etc defined? Say my main manifest is just (specifications->manifest '("bash")) <civodul>yes, you can have (define m1 (specifications->manifest '("bash"))) <civodul>and (define m2 (load "that-other-manifest.scm")) <nathan-lt>Is there a tool for quickly testing a patch that has been posted to the mailing list? 
