IRC channel logs
2022-11-24.log
back to list of logs
<nckx>mv grubx64orwhateverexactly.efi bootx64.efi <Fare>nckx: race condition between my typing and my reading. <nckx>Full duplex humans still need to be invented, true. <Fare>nckx: do you mean mv /boot/EFI/Guix/grubx64.efi /boot/bootx64.efi ? <nckx>No, don't move it to another directory. <Fare>mv /boot/EFI/Guix/grubx64.efi /boot/EFI/Guix/bootx64.efi ? <nckx>mv /boot/EFI/Guix/grubx64.efi /boot/EFI/bootx64.efi <nckx>* file system, whatever, is what I meant. Sorry for the poor wording. <nckx>Re: duplex humans: I can't thumb-type and think gud at the same time. <Fare>the mountpoint is /boot not /boot/EFI <Fare>nckx: I can't think and good at the same time. <Fare>It's hard enough thinking and breathing at the same time. <nckx>Yeah, I meant don't move it to /boot. Anywoz. <vagrantc>ACTION thought it needed to be in /boot/EFI/boot/bootARCH.efi <vagrantc>at least, reading the u-boot source code, that's where it looks for it <nckx>So, I have 1 UEFI machine, and it uses \EFI\bootx64.efi. <Fare>vagrantc, after googling, that's the path I'm trying. Pray for me, friends, and see you on the other side, I hope. <nckx>But I certainly can't say it's not just weird or buggy. <nckx>I can't get rid of it soon enough TBH. But Coreboot isn't an option. <vagrantc>you can probably safely say it is buggy. that's easy money. <nckx>vagrantc: So I just ssh'd into it, moved the executable to \EFI\boot\bootx64.efi (the \boot directory didn't exist), and rebooted. Let's see if it comes back! <nckx>I'm pretty sure it won't because I tried this once! <nckx>It is taking longer than usual! <nckx>Yeah, it's not coming back. There's an off chance Guix itself failed to boot, but I didn't pull or reconfigure, so I think this is just a buggy implementation. Probably has some broken if(windows) { follow the spec; } else { oops we forgot to test this bit; } code or who knows. <chomwitt>hi. i am a regular debian user testing guix in a virtual machine. is there a rosetta style table of apt related actions mapped to guix ? for example to see a package installed files or depedencies ? <unmatched-paren>chomwitt: package dependencies: ``guix show guile | recsel -P dependencies'' <sneek>Welcome back unmatched-paren, you have 3 messages! <sneek>unmatched-paren, lechner says: With greetd, have you seen this error from pam_mount? Hxproc_run_async: ofl: No such file or directory <sneek>unmatched-paren, lechner says: i believe our 'pam-mount' lacks the input 'hxtools', which ships the 'ofl' executable but is presently unpackaged <vagrantc>ACTION re-reads the u-boot code and it's pretty opinionated about the path <CompanionCube>iirc 'bootARCH.efi' is the fallback default also used for removable devices <vagrantc>not that it is arguably the source of truth for EFI either :) <CompanionCube>if you want to use different names, you can set the boot option in the NVTA <nckx>vagrantc: Sure, I absolutely bow to the spec, or trust open sources over my only test box :) But the test box is where experience is made. <nckx>CompanionCube: Definitely, but does it have to be in \boot or is that optional? That was the question (which is pretty much resolved IMO—my box is just silly). <vagrantc>nckx: what, you mean discrepancies between "should be" and "is in actuality"? <chomwitt>unmatched-paren, 'recsel' command not found <unmatched-paren>chomwitt: use ``guix shell recutils -- recsel -P dependencies'' instead <CompanionCube>nckx: well, with an efivar var it can be anywhere on the ESP, but the fallback does need it in BOOT i think <nckx>chomwitt: ‘Rosetta’ things imply that concepts are the same, which isn't the case, so be aware of that. A ‘dependency’ in apt != one in Guix, to point out my pet peeve. Also, why are you looking them up in the first place, the answer to that might matter. Etc. <nckx>CompanionCube: That appears to be the case. <chomwitt>nckx, i thought that a 'rosetta' table could help me get familiar more quickly with guix <unmatched-paren>chomwitt: tbh nckx is right, you should probably re-learn things rather than risk imagining correspondences that aren't there <chomwitt>nckx, unmatched-paren i see what you mean. i'll try to read more carefully the installation manual then <nckx>chomwitt: It's a reasonable question, and there probably is one somewhere (‘guix pull = apt update’, ‘guix upgrade = apt upgrade’, etc.—I think? Been a long time since I apt). But there are just enough differences to trip you up once you go beyond ‘getting started’. <nckx>chomwitt: I thought for sure I'd fine one on the Web somewhere, but no luck. <mekeor[m]>personally, i prefer sensing the electromagnetic fields of my hard disk where my copy of the binary executable of guix lives <chomwitt>i took a look at how guix install everything in a /gnu/store and how ~/.guix-profile has links for all those installed files. no i did a 'guix pull' and i am curious to see which emacs version will install and if guix will keep also the old one. <nckx>whereiseveryone: Thanks, restarted, reported. <nckx>whereiseveryone: Yes, automatically built. Hourly last I dealt with it. <nckx>whereiseveryone: It's still hourly. <nckx>I do not review packages in my sleep, and I think that's a healthy sign. Good night! <Fare>for the record, EFI/boot/bootx64.efi worked. There are other issues with my installation I'm dealing with, but I wanted to share that with you. I have not tried EFI/bootx64.efi without the boot/ subdirectory, so it might work, too, for all I know. <chomwitt>after running 'guix pull' i got a hint to set the path (with no other details) and run hash guix but the manual(devel) says to paste another two lines in .bash_profile and then run 'hash guix'. But i have already pasted previously and set GUIX_PROFILE to "$HOME/.guix-profile" . Now i will have another value for the same variable in bash_profile ? <chomwitt>unless the purpose of that variable is only for the next command to source the right /etc/profile. <chomwitt>ok i've pasted both. i upgraded my packages and i roll backed in my previous ones (roll back was very fast!). How i undo the roll back to go again to my latest package versions ? <rothari>Hi. I installed Guix without a desktop (I do not need all the extras) and now I would like to get Openbox. I installed `openbox` but when I run `openbox-session` I get this error: "Openbox-Message: Failed to open the display from the DISPLAY environment variable." Seeing that `xorg-server` was not brought in as dependency, I installed it manually but the error persists. What am I missing? <chomwitt>rothari, maybe another depedency is needed then? <chomwitt>i mean if didnt pull xorg who knows what else possibly needs. <rothari>All the dependencies listed by `guix show openbox` are there, I don't know what else is needed. <rothari>Currently in a VM, but planning to use Guix as my daily driver <chomwitt>well if it was a pc i would guess a gpu blob missing but since its a vm there should be a problem i guess.. (i am newbie in guix!) <rothari>Maybe I need to install xinit as well? But I do not want to install a bunch of random things until it works lol. Or maybe I need to configure packages or services in /etc/config.scm. <chomwitt>look my second guess is that openbox as stand alone window manager will need xinit <chomwitt>unless you see a display manager in the depedencies <rothari>I just noticed the description of xinit explicitly says it is used on systems without a display manager like mine. Trying that path. <ph03n1xaimverncc>Should be searchable online I think. I don't have thr script now, I'm on gdm now with exwm <Fare>how do I avoid this error? guix system: error: while setting up the build environment: cannot pivot old root directory onto '/gnu/store/6x61r9qbp59vj4nxa2icr5bd00pjj0s7-provenance.drv.chroot/real-root': Invalid argument <rothari>ph03n1xaimverncc ok. Do you have a link? I do not really know what to search for. <Fare>ACTION tries mount --bind /mnt/gnu /gnu from outside the chroot <Fare>not enough. Doing more of the same and running guix-daemon *outside* the chroot... <Fare>oh, after rust-1.54.0 rust-1.55.0 rust-1.58.1 rust-1.59.0 I'm now at rust-1.60.0. Good news is these versions took less time to build than the first two. But really, why is it even building rust to begin with? Are will I be able to contribute the packages to an aarch64 cache or will every aarch64 user have to bootstrap everything from scratch??? <rothari>ph03n1xaimverncc: just found a bunch of links, but I do not have time to check them out right now. <rothari>If anyone has more ideas please share. <ph03n1xaimverncc><rothari> "/ph03n1x/aim (vern.cc) ok. Do..." <- startx not working in guix is ehat I searched for <jgart[m]>or should I be macro-expanding that instead of asking here? <jgart[m]>not sure that the full macroexpansion was helpful... <ph03n1xaimverncc>One of my friends game called opencraft didn't run well, not sure if xorg at fault tho <kozo[m]>Hello, how does guix shell handle the / size when using --container with --no-cwd? The default seems to be 16GB. Nothing is popping out to me as "aha, here is your answer!" when browsing the manual <Fare>after much more work than anticipated, I'm finally booted on guix on my usb stick. Feels good man. <Fare>Only regret: the BIOS won't boot on an sdcard, so it has to be USB. <Fare>gripe about guix: if I mistype my disk decryption passphrase, guix immediately drops me at an unusable debugger repl, instead of letting me try typing my password again. How do I fix that? <kozo[m]>That is the case for the first prompt, the second prompt will let you retype it <kozo[m]>Sorry, I do not know how to retry besides rebooting <Fare>who should I contact wrt adding aarch64 workers to the guix ci / build farm ? <Fare>I saw a guix-sysadmin mailinglist that seemed more fit. Sent email, but didn't subscribe. <mekeor[m]>rothari: that thread is not only about setting up xinit without a login manager, but also, without having xorg-service installed on system-level. do you want that? (i use exactly that setup.) <Fare>ouch, tracker-3.3.3 seems to fail building on aarch64, and plenty of things seem to depend indirectly on it. <rothari>mekeor[m]: as long as I can get Openbox to work without login manager, I am okay with that. <rothari>Actually, if there were a very minimal login manager that only starts Xorg/Openbox and does nothing else, it would be fine anyway. <mekeor[m]>rothari: there is slim, afaik. its very minimal <rothari>In any case, mekeor[m] if you could share your setup, that would be fantastic. <mekeor[m]>rothari: anyway, if you dont want system-wide xorg service, follow those instructions, and also install needed xf86- packages, e.g. -input-evdev and -video-intel, and install xinit, too <rothari>How do I know which xf86-* packages I need? <chomwitt>goodmorning from newbieland! . i got a first taste of guix following (devel)manual/getting_started . I installed some packages then did $guix pull and $guix upgrade and a $ guix upgrade. (i didnt follow the 'guix system' path) . I did then a $ guix package --roll-back . Is there a way to see a list of the 'atomic operations' that are rolled back and how do i roll forward ? <nckx>Fare: Both lists would have been appropriate. -devel is public, -sysadmin is not. <unwox>chomwitt: for a list of generations use "guix package --list-generations" <unwox>to roll forward use "guix package --switch-generation=ID" <mekeor[m]>rothari: i guess, from looking at your hardware, but im not sure <mekeor[m]>rothari: but also, jut try the packages i mentioned. its likely that they will work <chomwitt>unwox, generation 5 is listed last. But it has e.g: +emacs 28.2 and -emacs 27.2 . But then i performed a package roll back and my current emacs version is 27.2 . So i guess Generation 5 is my previous and my current one is not listed? <unwox>chomwitt: your current one should be listed with "(current)" marker <unwox>if you do rollback from 5th generation your current one should be 4th then <chomwitt>i see. so i went with the upgrade up to gen5 and then as a pointer i went back. <efraim>I would suggest piping 'guix package --list-generations' to less so you can scroll back and forth to see the differences <chomwitt>so $ guix describe is the generation of the guix system (like the quix related utilities) and its unrelated to the packages generations? <unwox>there are several profiles in guix: system, home + per-user packages. each with their own generations history <mekeor[m]>(using guix-home is optional. the home-profile only exists if guix-home is used) <chomwitt>by using a home profile is like version control on my whole home dir ? <unwox>chomwitt: version control of your configuration files (or whatever files you want actually), not your whole home dir <unwox>+ management of user-level herd services <unmatched-paren>you use ``guix home reconfigure'' to install a home config; it's like a user-specific version of ``guix system'' <chomwitt>so guix offers in parallel version controlled system software,userland software, config and i can roll back and forth on each of these 'timelines' as i like or for example there are some restrictions that for example bind some config generations with some user package generations ? <unmatched-paren>chomwitt: there is no "binding" between .guix-profile generations and .guix-home generations <unwox>chomwitt: profiles are completely separate and not linked with each other <chomwitt>i see . so in my early testing system rolling back and forth in package-generations will leave my ~/.config/* untouched ? <unwox>"guix package --rollback" does not rollback your system, only packages installed with "guix package --install" or "guix install" <unmatched-paren>sudo guix system roll-back is the command you use to rollback your system <unwox>but yes, "guix pakage --switch-generations" won't touch your .config directory <unmatched-paren>chomwitt: ~/.config is nothing to do with any of them, really; guix home happens to provide a service that lets you put files in there <chomwitt>and where can i see what parts or directories of my system a certain X profile looks after? <unmatched-paren>the package config doesn't modify anything except the ~/.guix-profile directory <chomwitt>i ve lost you a little. If a do changes in ~/.config/awesome they always stay there nomatter what system|package gen i change ? <unmatched-paren>unless you later configure a home setup that uses home-xdg-configuration-files-service-type to declaratively set up config files in that directory, yes <unmatched-paren>i mean, technically it's possible to replace them with a system config, but that'd be a very badly designed system config <chomwitt>so unmatched-paren i guess that home-config profile is for more quix-experienced user and i will propably not try it in my beginnings <unmatched-paren>guix home import ~/.config/guix will produce an auto-generated home config at ~/.config/guix/configuration.scm <chomwitt>i guess i would need a seperate git like command to do changes to my home profile if i'd used it <chomwitt>i mean in order a versioned home-profile to work i couldnt just open edit and save conf files <unmatched-paren>chomwitt: also, your current home config is stored at ~/.guix-home/configuration.scm, so if you roll back you should be able to get the config that you used to create the generation in the first place <chomwitt>so i guess one main burden of a guix sysadmin lies in keeping track of those parallel system user home timelines <unmatched-paren>chomwitt: sooo, if you do ``guix home import ~/.config/guix'' and open up ~/.config/guix/configuration.scm you should be able to get started with tha <unmatched-paren>as the "put file here" functionality is just a subset of home services <unmatched-paren>you could also use, say, the home-dbus-service-type to get a dbus session daemon running <unmatched-paren>services for mako, emacs, foot, and himitsu, courtesy of unwox and myself :) <unmatched-paren>i don't personally use any of rde's services, but you may find them useful <chomwitt>i run "$ guix home import ~/.config/guix" . Now a hint ask me to execute "$guix home reconfigure /home/chomwitt/.config/guix/home-configuration.scm" <chomwitt>my newbie eye understands that the home-configuration.scm by querying current state it will create related config dirs in ~/.guix-home/profile and do some magin on .bashrc to create a couple of home services <unmatched-paren>chomwitt: yeah, it'll modify .profile to run the ``.guix-home/setup-environment'' and ``.guix-home/on-first-login'' <unmatched-paren>chomwitt: which means you'll need to log out and log back in after reconfigure for guix home to do its thing <chomwitt>"$guix home reconfigure .." gave me at the start "guix home: warning: cannot determine provenance for current system" <chomwitt>so now i can edit ~/.config/* then "guix home reconfigure" and then i could see 'home profile' generations with '$ guix home --list-generations" ? <chomwitt>~/.guix-home/files/.config lists only one of dirs that i have in ~/.config <unmatched-paren>i'll show you how in a moment, but: which ones do you want to actually configure with guix home? <chomwitt>i have also ~/.config/qutebrowser and i plan to create awesome config <unmatched-paren>okay, do you see the list of services in the home-environment at the bottom? <chomwitt>and i plan also to tweak emacs to have its config there . <unmatched-paren>you'll want to add (service home-xdg-configuration-files-service-type) there <chomwitt>should (service home-xdg-configuration .. bee in the same level as (service home-bash-configuration .. ) ? <unmatched-paren>or you could do `(("awesome/config.lua" ,(plain-file "local foo = 32 ..."))) <unmatched-paren>you need to give it a file name so guix can put it in the store as /gnu/store/...-awesome-config.lua <unmatched-paren>and then that file is symlinked to ~/.config/awesome/config.lua by home-xdg-configuration-files-service-type <chomwitt>and what happens if i want to spit awesome config in many dirs and files ? <unmatched-paren>`(("awesome/config1.lua" ,(local-file "awesome-1.lua")) ("awesome/config2.lua" ,(local-file "awesome-2.lua"))) <chomwitt>basically i have to tell home profile of each file i want tracked ? <unmatched-paren>you could put that directory containing your home files into a git repo <unmatched-paren>chomwitt: some programs, though, have their own specialised services <unmatched-paren>so instead of writing the config by putting files in that list, you can write them with a scheme configuration <chomwitt>unmatched-paren, i think thats too difficult for me now. i ll try to track a simple config file for start <unmatched-paren>i'm trying to add paginated output to ``guix refresh --list-dependent'' and ``guix refresh --list-transitive'' <unmatched-paren>but for some reason even with these changes they're not displaying paginated output <unmatched-paren>chomwitt: i mean the contents of the paste; i'm trying to make a change to the guix source code :) <rothari>Also, that tutorial first says "We will run X server with user privileges" but then says "...otherwise X server refuses to start without root privileges" so I don't know how I should actually run it. <stevenroose>It's quite amazing how hard it is to find such things searching through documentation.. <unwox>rothari: setting startx up is painful in guix. you do indeed need to install xf86-* packages. which ones do you already have installed? <stevenroose>More specifically, I have a swap service that's broken: "Service swap-02758dae-ce01-46af-a350-4230b6bbdf0a could not be started." But I can't figure out where to find any logging about what's wrong with it.. <unmatched-paren>stevenroose: hmm... i did get a broken swap service myself at one point; pretty sure it's something silly with the uuid <stevenroose>The uuid in my config file is correct. I did notice though that I accidentally made it smaller than I intended to, it's slightly smaller than the amount of RAM I have <rothari>unwox I installed xf86-input-evdev because the description says it supports all input devices. <stevenroose>So I'm not sure I'll be able to hibernate into that swap <nckx>If data in RAM fits in free swap, you will. If it doesn't, you won't. There's no size that guarantees being able to swap, nor a minimum size requirement. <nckx>Your free swap needs to be about 70% of used RAM IME. <nckx>stevenroose: I'd expect that swap error to be logged in dmesg (which is also part of /var/log/messages). <stevenroose>I don't find anything more than that "Service swap-... could not be started". Grepped for `swap` and for the uuid. <stevenroose>it seems like it maybe had an old swsuspend signature on it, whatever that means, that might have anything involved with it? rebooting to see if it gets picked up <nckx>That would have been my guess. <nckx>Hibernation signature means you hibernated, then didn't resume from the image. Your system saw a hard power loss. If you resume from the image now, you'll experience severe file system corruption. Just mkswap it and enable it again. <stevenroose>nckx: So my issue seems to be that when I hibernate, it fails to start back up from hibernatino, but it somehow taints the swap so that it can't be used as swap anymore. <stevenroose>I have the resume=/dev/disk/by-uuid/... kernel argument <unmatched-paren>Something did a thingy, and my system froze up when I tried to resume from the hibernation. <stevenroose>What else should I be aware of to make hibernation work? <nckx>That's not a valid resume= parameter. <nckx>I think the raw UUID will work, but am not sure because I never tested that hard :-). Yes, raw devnode is safest. <nckx>There is no udev in the initramfs, so no elaborate /dev/by-colour symlink tree. It is currently unlikely to be added. <nckx>We could... fake it... 😈 <nckx>unmatched-paren: Yes, probably same mistake. <nckx>string-prefix? "/dev/disk/by-uuid" is so delectibly evil I'm seriously considering it. <minima>hi, is there a way i can add a channel to a system definition? i'd like to build a system image, boot it, and from within that system being able to guix pull from the extra channel <a12l>I need help with what modules I should add to the definition. <unmatched-paren>you also need to add a (name "my-st") and (version (package-version st)) <a12l>unmatched-paren: Thanks! <a12l>Note that I know very little about writing definitions, so maybe I'm misunderstanding something. <a12l>Do I need to provide a name? They don't have that in the first example. <a12l>does (version (package-version st)) make my variant have the same version as the original version? <unmatched-paren>also, you may want to add (file-name (string-append name "-" version ".tar.gz")) to the origin <a12l>I already have that? Or are I'm missunderstanding you? <unmatched-paren>file-name is what the downloaded source file is called in the store path <a12l>Looked it up in the manual <a12l>Looking at the Guile LOAD Path section in the guile manual, and unsure how to use it? <a12l>The *.diff files are located in the same dir as the scm file. <unmatched-paren>a12l: basically you just need to use (add-to-load-path (dirname (current-filename)) <a12l>Should (add-to-load-path (dirname (current-filename)) be added outside of the package definition? <rothari>I am slowly getting this https://lists.gnu.org/archive/html/help-guix/2018-07/msg00080.html to work. I wrote 2 lines ("xterm &" and "openbox-session") in ~/.xinitrc and now xinit actually opens an Openbox session with an xterm window. However, keyboard and mouse still do not work. I installed some xf86-* packages but apparently I am still missing something. Any ideas? <unmatched-paren>rothari: is your user in the input group? not sure whether that actually makes a difference, but you could try <rothari>unmatched-paren: No, should I add it among the supplementary groups in /etc/config.scm? <rothari>I am unfamiliar with Guix configuration. <unmatched-paren>a12l: use (define-module (st) #:use-module (gnu packages) #:use-module (guix download) #:use-module (guix packages)) <unmatched-paren>a12l: btw, file-name conventionally goes after uri, and patches usually goes before sha256 <unmatched-paren>there, you're basically trying to call a 0-argument lambda returned by search-patches <a12l>The "unbalanced" line gets added when I run `guix style -f st.scm`. Not sure why, can't see any missing parenthesises <a12l>Thanks, I'll keep than in mind not to rely blindly on it <a12l>I want to test to build the package before installing it. Should I just run guix build -f st.scm? <unmatched-paren>it writing a random word that wasn't there definitely seems like a bug <a12l>I get the error "error: st: unbound variable\n hint: Did you forget a `use-modules' form?\n\n guix build: error: my-st: unknown package" <a12l>Accidentally added spaces around the dot <rothari>unmatched-paren: I did that, then ran `sudo guix system reconfigure /etc/config.scm`. Unfortunately the problem persists. It was a very good suggestion though. <a12l>unmatched-paren: "guix build: error: my-st: unknown package" <unmatched-paren>a12l: oh, it has to be a public variable; use define-public rather than define <rothari>unmatched-paren: Actually, I just saw that system reconfigure exits with an error: "grub-install: error: cannot find a GRUB drive for /dev/sda. Check your device.map." <a12l>unmatched-paren: Thanks so much for the help! <a12l>This was ridiculously easy <unmatched-paren>a12l: if you want to apply more patches, put another one in that search-patches <lechner>jpoiret / Hi, I think you wrote one that 'guix publish' does not work for you. Do you use NetworkManager or ConnMan? I just switched to the latter, and it stopped working. <jpoiret>must've been someone else, I don't use `guix publish` :p <PotentialUser-30>if i inherit from a package, then also all the "arguments" are inherited - right? <PotentialUser-30>But if i only want to change one tiny little configure flag, it means that i can't use the "inheritance mechanism" for arguments any more ?? <PotentialUser-30>In the guix manual (8.5 build phases) i read: "Changing the set of build phases boils down to building a new alist of phases based on the %standard-phases alist described above." <PotentialUser-30>So only for changing #:configure-flags this means i have to start "from scratch" and define all phases again <PotentialUser-30>using (modify-phases %standard-phase ...) practically meaning i have to copy over from the package i've inherited from? (this can be a lot and sounds "bloated" and double effort for maintenance) <a12l>unmatched-paren: A little unsure, I can start `st`, but it looks normal <PotentialUser-30>Or is it possible to use the inherited phases and only change the configure flag?? Sorry for beeing little unprecise <a12l>unmatched-paren: Yep, I'm in the process of uninstalling it, just `guix home reconfigure` that take some time <a12l>I thought that the old package is maybe run, so I begun uninstalling it :) <PotentialUser-30>Using substitute-keyword-arguments macro all the other keywords (e.g. #phases) are unchanged (xo as they were in the package inherited from) ? <rothari>Ok so I managed to make system reconfigure work by replacing /dev/sda with /dev/vda (the actual device name that can be seen with lsblk) in /etc/config.scm. Now my user *should* be in the input group <a12l>unmatched-paren: It works! Thanks! :D <a12l>This has shown me that I really should get serious about moving from NixOS to Guix. <a12l>Much easier to modify to my taste <unmatched-paren>a12l: btw if you want you can put that package def directly in your home config <unmatched-paren>you'd probably want to create a patches/ directory next to your home config, and put the patch in there <unmatched-paren>then add (add-to-load-path (string-append (dirname (current-filename)) "/patches")) <a12l>unmatched-paren: I've used Nix for about two years. Have yet to learn how to actually create overrides and overlays in a good way. Currently I'm mostly copy-pasting stuff and hope that stuff should work. <unmatched-paren>a12l: i've never used nix, so it's interesting to hear that guix seems more hackable to you <a12l>It's more simple I think. <a12l>The problem with Nix (I think) is partially that it's its own separate language, while Guix use a EDSL. <a12l>And then it's also about Nix being ridiculously lazy, which result in pretty much only the Haskell crowd being comfortable with it. While I've done some Haskell in Uni, I've yet to really understand laziness. <a12l>E.g. functions that has its output as an input. <jgart[m]>What is the difference between gc.scm and gc.cc/hh? TLDR <jgart[m]>Or how are those interacting in the code? <unmatched-paren>the daemon is the only thing that's allowed to actually write to the stoe <unmatched-paren>scripts/gc.scm just defines the actual ``guix gc'' command; all it does is tell the daemon "do gc pls" <jgart[m]>Where does it tell the daemon via RPC exactly is what I'm trying to determine next <jgart[m]>Does it use a function from (guix build syscalls) to do it? <unmatched-paren>jgart[m]: looks like ``collect-garbage'' is implemented in guix/store.scm <jgart[m]>Looks like (guix build syscalls) does is all about doing FFI with low level Linux syscalls which I'm not fully familiar with <unmatched-paren>and that's implemented on top of run-gc (also in guix/store.scm) which directly writes a daemon request <jgart[m]>jgart follows the cookie trail to guix/store.com again <unmatched-paren>ACTION wishes they could figure out how to use geiser for code introspection <jgart[m]>unmatched-paren: Is geiser-edit-symbol-at-point working for you? <jgart[m]>Is that how you jumped to the definition? <unmatched-paren>no, i just noticed guix store was imported and opened it; and there it was :) <jgart[m]>Can you test it and confirm that it fails to jump to source <jgart[m]>I think you need to add your local guix git repo in your emacs config first to some dynamic variable list <jgart[m]>You found the config instructions for it in the manual? <jgart[m]>Yeah, try configuring that and see if geiser-edit-symbol-at-point works after. I've been wracking my brain with getting geiser to work fully <jgart[m]>Geiser seems so fragile for doing jump to source <jgart[m]>Sometimes I can jump to another file sometimes not <apteryx>I think something in the Guix code base confuses Geiser; perhaps the records. <jgart[m]>It's definitely not the LSP or sly/slime experience I'm used to/spoiled by <apteryx>I'd be nice to figure it out, perhaps issue a bug report to geiser if we can pinpoint what's exactly wrong <apteryx>From experience in other much smaller Guile projects, it worked much better there. So either the sheer size or the use of macros in Guix or something <apteryx>jgart[m]: they don't, but they're responsive and helpful to bug reports <jgart[m]>Would be great if we'd convince jao to start using Guix haha <jgart[m]>So, they can hack and test out geiser with Guix <jgart[m]>Otherwise, I'm going to have to really learn the geiser codebase <jgart[m]>And understand how it fully works so I can send jao better bug reports <jgart[m]><unmatched-paren> "jgart: tempel or yasnippet?" <- unmatche d-paren: What do you mean? <jgart[m]>I think someone is working on an actual LSP server implementation for scheme iirc <jgart[m]>Maybe it is more robust than geiser for doing jump to source... <jgart[m]>I like the simplicity and minimalism of the approach in geiser for implementing features similar to slime/sly and lsp but damn I need it to work for guix code <jgart[m]>This is how I approach yasnippet and tempel: <jgart[m]>I don't want to hack on yasnippet but I just install emacs-yasnippet, emacs-yasnippet-snippets, and emacs-consult-yasnippet <jgart[m]>The snippets that are not implemented for me in yasnippets I write in tempel <jgart[m]>So leverage all the snippets in yasnippets already written for us and then write more snippets in tempel <jgart[m]>emacs-consult-yasnippet makes the API to yasnippet look identical to tempel <jgart[m]>So I don't care where the yasnippets are coming from, I just use them from the consult interface <lechner>Hi, does the docker build fail for anyone? <jgart[m]>Why do we use use define-public for packages instead of #:export (foo)? <omlet[m]>orOr how can I do it to start a desktop through Startx? <jgart[m]>If it's simpler then why don't we do it everywhere? <rekado>for packages it doesn’t make much sense to duplicate the exports at the top <unwox>lechner: docker build fails for me too <rekado>but for everything else it’s nice to have the public API clearly specified at the top <jgart[m]>rekado: can you expound a bit on that. Why doesn't it make sense? <unmatched-paren>jgart[m]: only that i've never used anything other than sway and gnome, so i have no idea how to set up startx <jgart[m]>and sometimes I run startx to live in dwm <jgart[m]>But I want to see if I'll be able to help keep gnome up to date in master first <jgart[m]>unmatched-paren: We should work on adding the uninstaller to guix home <jgart[m]>There's a ticket open for it but not sure when someone will be able to get around to it <jgart[m]>I have some notes from abcdw of what needs to be done <jgart[m]>I think I put them in the ticket also iirc <rothari>jgart[m]: if you ever manage to get xinit/startx to work and see me online, please let me know <rothari>I have been trying to make it work for the last 3 days <rothari>lechner: in my case, it starts an X session with Openbox, but keyboard and mouse do not work <jgart[m]>To see if you get the same result of keyboard and mouse locking up <rothari>jgart[m]: I may do that when I have time, but I am used to Openbox and I have written my own dotfiles for it, so eventually I'd like to get that to work <jgart[m]>I'm just suggesting a sanity check to make sure it's not an issue with something else that is not Openbox <jgart[m]>What would a service look like to handle that? lechner: <jgart[m]>Should someone contribute a startx service or documentation for using startx in Guix System? <rothari>lechner: that's exactly the script I am already using to start X :( <morganw>sx is packaged and works, that is what I use instead of startx <rothari>jgart[m]: just tried dwm - same problem, input devices are stuck <jgart[m]>Should startx acomodate Guix filesystem hierarchy? <jgart[m]>It might just be swapping the startx command with sx command hopefully <rothari>jgart[m]: I have tried to use sx to start both dwm and openbox - same issue. At this point I am fairly sure it is a driver issue. <lechner>rothari / what do your logs say about detected devices? <lechner>Hi, does anyone else using Guix Home wish sometimes that a reconfigure would succeed and keep an old version of something when a newer version fails to build? <rothari>lechner: it says that modules fbdev, vesa do not exis. However, xf86-video-fbdev is installed. <lechner>The feature would be called "deploy the last version that builds" <jgart[m]>Is there any tool for auto applying patches across different branches/repos that are similar? <lechner>The reconfigure fails, and no changes to the Home configuration, such as the addition or removal of software, are processed <minima>hi, i added a channel to '/etc/guix/channels.scm' and i can see that the new channel does actually shows up when pulling; however, after a successful pull, i try and install a package (that i know is provided by my channel) but the package is not there... <minima>any intermediary step that i might be missing? <unmatched-paren>minima: pretty sure the right location is ~/.config/guix/channels.scm <jgart[m]>minima: ya try what unmatched-paren said <minima>oh i see... i was confused by the fact that guix pull does actually seem to pull from my personal channel <minima>super, it works! thanks unmatched-paren and jgart[m] :) yay <jgart[m]>macroexpansion of that doesn't seem helpful <jgart[m]>Are there any good guides for how to use Guix to develop a C project? I wish there was a tutorial for everything you'd ever want to do as a C developer with Guix as your development tool. <jgart[m]>For example, guix workflows on a C project <apteryx>I don't think guix is special for c development; guix shell 'gcc-toolchain gdb make' and hack away <jgart[m]>How about the stripping of debug symbols that Guix does? <jgart[m]>Using Guix for stripping or unstripping debug symbols, that is <apteryx>jgart[m]: when your C projects gets to the point you want it packaged in guix, Guix will take care of that yes <kaelyn>jgart[m]: AIUI the stripping of debug symbols is done as part of Guix-the-package-manager's build phase, and I believe it is simply a pre-defined phase from gnu-build-system <apteryx>but why would care about that while developing it? you probably want the debug symbols in to make your life easier <jgart[m]>What if the debug symbols are not in by default? <jgart[m]>apteryx: How about if you wanted to use C third party libraries? What would you do? <jgart[m]> How about if you wanted to use C third party libraries? What would you do? <jgart[m]>How do you use Guix to get your C third party libraries in a shell and link them to you current source file? <oriansj>anyone have a good kodi config for guix? <unmatched-paren>``pkg-config --cflags PKG'' to print compile flags, ``pkg-config --libs PKG'' for link flags <jgart[m]>unmatched-paren: can you give a concrete example with PKG <unmatched-paren>jgart[m]: ``guix shell glfw pkg-config -- pkg-config --cflags --libs glfw3'' <jgart[m]>just want to make sure I'm not confusing what gets substituted for that placeholder in your example <lechner>jgart[m] / you may like autoconf and automake <jgart[m]>unmatched-paren: That's been my experience also <jgart[m]>My soul is already defeated by autoconf and automake <jgart[m]>And it was ultimately shattered by GNU m4 <oriansj>well AIX and HP-UX systems still are around but it is best not to support them if possible <unmatched-paren>the whole point is to compensate for stupidity in various proprietary unices <oriansj>lechner: never, and even if you pry C from my hands, I'll just bootstrap it from assembly again. <lechner>oriansj / you did not express a dislike for autotools <jgart[m]>unmatched-paren: What's your workflow with meson when developing C? <oriansj>lechner: I don't use it execpt when required for bootstrapping purposes and it is a *bitch* to bootstrap <unmatched-paren>Until one of the *actual* replacements for C (hare or zig) rather than the *claimed* replacements for c (rust, go, a ton of others) become mature enough, i'm not giving up C :) <bdju>anyone getting stuck forever in cloudflare browser checks lately? happens for me in both qutebrowser and icecat. not the first I've run into this but it had been working okay for some months. <lechner>oriansj / is there a good modern build system that integrates with libtool? <jgart[m]>unmatched-paren: What would be your workflow for hacking on sbase with Guix? <unmatched-paren>jgart[m]: i mean, since sbase is suckless, it'd probably just be edit and ``make''? <jgart[m]>if sbase had one third party dependency on gtk what would you do? <jgart[m]>in some crazy world where sbase had a gtk GUI over all the binaries in the repo <apteryx>jgart[m]: for your C adventure, you may be interested in reading the recently authored "GNU C Language Intro and Reference", aka 'c-intro-and-ref' (packaged in Guix) <bdju>lechner: do they ever complete for you? <lechner>bdju / i only saw them twice today, and no. maybe they think we are robots <jgart[m]>singpolyma: full disclosure: I've never used pkg-config except by running `guix build foo` <bdju>lechner: interesting. so perhaps a guix issue then <jgart[m]>unmatched-paren: then how would you make those two available with guix shell and subsequently build sbase? <jgart[m]>and does that strategy work the same for every C project? <unmatched-paren>jgart[m]: well, we have a sbase package, so ``guix shell --pure -D sbase'' <unmatched-paren>jgart[m]: if we didn't, we'd do ``guix shell gcc-toolchain make gtk+'' <unmatched-paren>jgart[m]: then, for this particular package, it'd be ``make -j$(nproc)'' <jgart[m]>so guix shell --pure -D sbase would be enought to then just run make? <unmatched-paren>for a gnu build system package, ./bootstrap && ./configure && make -j$(nproc) a bit like guix <jgart[m]>and I don't think that would work for dwm, for example <unmatched-paren>jgart[m]: for a meson package, it's ``meson setup build-dir && meson compile -C build-dir'' <jgart[m]>make: *** [Makefile:18: drw.o] Error 127 <oriansj>lechner: after some reflection, I can't imagine a good usecase for libtool now that we have guix and nix <unmatched-paren>the problem here is that guix's gcc-toolchain doesn't provide a cc symlink <jgart[m]>right but how about as a dwm contributor that is using guix to develop dwm? <jgart[m]>they want the guix development experience when hacking on dwm <jgart[m]>gnu/store/a5909drfqigx0m0n6kshz3sxmbmz016h-profile/include/X11/Xft/Xft.h:39:10: fatal error: ft2build.h: No such file or directory <jgart[m]>fatal error: ft2build.h: No such file or directory <jgart[m]>I thought that Guix was supposed to handle that library for me <jgart[m]>That's reproducible as of at least a year to be conservative <lechner>oriansj / i kind of agree with that, i think. there are a few isolated uses, like PAM modules <unmatched-paren>jgart[m]: seems like some bug; guix edit dwm shows that we set some FREETYPE make flag <jgart[m]>I can't type this in a bash shell: FREETYPE=#$freetype/include/freetype2 <oriansj>lechner: well PAM is something one would probably want to replace or avoid if possible <lechner>oriansj / is ld.so also obsolete, then? <jgart[m]>unmatched-paren: Yes, please try it with dwm. I'm curious what you experience is of building locally with Guix <unmatched-paren>jgart[m]: ah, the problem there is it tries to use the variable $GUIX_ENVIRONMENT from your current shell <oriansj>lechner: well, some people like it (I don't understand why but I'm not one to enforce my choices on others) but from a technical perspective dynamic linking does allow for some development paths to be used. <unmatched-paren>this *should* work out of the box, but it looks like dwm's build setup has some wrinkles that need manual intervention <jgart[m]>I wish Guix would just do this part for me: FREETYPE=$GUIX_ENVIRONMENT/include/freetype2 <oriansj>if anything, guix needs a couple new types to enable package definitions to be able to cheaply express things like: I need atleast 1 font or the like <jgart[m]>And also figure out that I have to type that <lechner>Hi, does anyone need secondary (backup) DNS? Here is a free, password-less and redundant (i.e. anycasted) solution. It's the most ingenious thing I have seen in networking in years! https://www.ns-global.zone/ <unmatched-paren>jgart[m]: it's simply a wrinkle that needs to be figured out manually; the guix package definition also needs to be able to deal with this <lechner>oriansj / consuming packages also compile faster <jgart[m]>But can the Guix package set it instead of fixing upstream? <unmatched-paren>guix can't tell make "hey, this package definition has this extra flag, so please magically use that flag when compiling in this directory that i somehow know corresponds to this package" <oriansj>unmatched-paren: I am thinking in terms of gentoo builds and making it easy to avoid some packages from being downloaded or built like pulseaudio (I like alsa better) and trim down the dependencies to only those that are absolutely directly required. <jgart[m]>apteryx: $ icecat /gnu/store/mj4klnm735nhdnvy3j9l38389jrz02c2-c-intro-and-ref-0.0.0-0.f885596/share/doc/c.html <unmatched-paren>oriansj: That's entirely possible; you can create package variants with ``inherit''. <rekado>jgart[m]: see, this is exactly what a configure phase is meant to do <rekado>so that you don’t have to type any of that. <rekado>likewise LIBRARY_PATH should be consulted, and Guix does set it. <unmatched-paren>jgart[m]: not even "guix is not able to", it's "this is literally impossible" <rekado>and pkg-config exists to simplify this too. <rekado>so it’s not Guix’s job, really. And those who call configure tools “bloat” have been missing the point. <jgart[m]>See that dev user story for flask developing <unmatched-paren>rekado: ehh, i do think a lot of the features of autoconf etc are redundant when you only need e.g. to detect the c compiler <rekado>sorry, I don’t see how that URL is relevant to the problem here. <rekado>I’m talking about the “here’s a Makefile, that’s all you’ll ever need” crowd. <jgart[m]>rekado: you might be missing my point then <unmatched-paren>rekado: i quite like to write a ./configure script by hand, making sure it supports all the options gnu configure does (by ignoring any unknown options) <jgart[m]>unmatched-paren: do you think we should have tutorials that show how to develop on a C project with Guix? <lechner>ACTION wishes someone would write a nice build system in Guile <unmatched-paren>especially since there's muon and samurai which mean you don't need C++/Python-based dependencies <jgart[m]>Otherwise, I don't think we are developing a culture for seriously using Guix to develop on open source projects in various languages. <rekado>the equivalent to what this URL talks about is “guix shell python python-flask” <unmatched-paren>jgart[m]: that web page looks to be about creating nix packages that read from local directories for development <jgart[m]>For example, no one probably uses Guix for erlang development <jgart[m]>Probably no erlanger is going to want to use Guix to hack on an erlang project <unmatched-paren>and then we just add the directory to the shell-authorized-directories <jgart[m]>erlang build system currently doesn't fin erlang libraries <jgart[m]>erlang build system currently doesn't find erlang libraries <jgart[m]>I'm still not convinced by the right C dev guix workflow <unmatched-paren>once you've added it to the shell-authorized-directories, you can just do ``guix shell'' with no args and get a development environment <jgart[m]>Might just be easier to not use Guix for C development? <rekado>jgart[m]: GCC uses LIBRARY_PATH, and Guix sets it <unmatched-paren>jgart[m]: the problems you were having with dwm are dwm problems, not guix problems <rekado>it works just fine for C development. <rekado>unmatched-paren: worth discussing on guix-devel <jgart[m]>can you point me to the line you're referencing <unmatched-paren>rekado: i suspect it's already been discussed there; i'll search through <rekado>our clang really shouldn’t, but I guess that ship has sailed <rekado>yeah, we did discuss it in the past <rekado>jgart[m]: see the package definition <jgart[m]>How are we thinking about using Guix for rust development? <jgart[m]>It sounds like Guix is mostly being used to just package rust apps <lechner>re 'cc' they are different programs. should 'less' provide a symlink to 'more'? <unmatched-paren>you have to just write a package for the library and do ``guix build -f guix.scm'' <jgart[m]>can we learn anything additionally from how nix does things? <jgart[m]>not sure but iirc rust devs are using nix to develop rust programs <unmatched-paren>jgart[m]: the cargo-build-system basically copies all the guix rust sources into a guix-vendor directory <unmatched-paren>cargo is passed an option to use this directory instead of downloading from crates.io <unmatched-paren>any build-system that does much more than just invoke commands is gonna be quite difficult to replicate in a guix shell <unmatched-paren>jgart[m]: this is enough, but it requires lots of automation written as part of the cargo-build-system <jgart[m]>do we have details on the TODOs for that? <apteryx>jgart[m]: you seem to be jumping topics a lot ;-) perhaps slow down a bit and focus on one? <unmatched-paren>cargo-build-system, before building a package, sets up a guix-vendor directory <unmatched-paren>then it iterates through the cargo-inputs and dumps each one's source in the guix-vendor directory <jgart[m]>ya I've seen that in standard output printing <unmatched-paren>if you wanted to manually build a rust package with guix, you'd need to do all that *by hand* <unmatched-paren>it's almost impossible to do this by hand without losing your will to live <unmatched-paren>you can't build go packages in a ``guix shell'' either, for similar reasons <jgart[m]>f#~ckit let's jump back to our hare conversation <jgart[m]>Ya, basically guix is not useable for go and rust dev work <unmatched-paren>jgart[m]: Once antioxidant is done, you *will* be able to develop rust packages with guix <unmatched-paren>i think you'll be able to just use antioxidant like something like meson; probably ``antioxidant build'' <oriansj>well guix isn't done yet evolving to be the perfect package manager yet; there are a great deal of understanding that still needs to be incorporated first. <jgart[m]>Or if not then just where's the src for it? <unmatched-paren>it'll build the libraries as .a files like a good little build system <PotentialUser-63>Using gnu-build-system I get 'collect2: fatal error: cannot find ‘ld’'. I did include binutils to inputs, also in a guix shell it finds the linker. Any idea why ld is not present? <oriansj>mekeor[m]: I am referring to jgart[m]'s message about guix not being usable for go or rust dev work <lechner>PotentialUser-63 / did you use native-inputs? <lechner>PotentialUser-63 / also, did you use shell --development <lechner>PotentialUser-63 / not sure, you probably want to listen to unmatched-paren <PotentialUser-63>unmatched-paren: agreed, was just desperate. Thanks to your help yesterday I fixed the CC= issues but now I am stumped as to why ld is not found <oriansj>and never trust oriansj's work, he could be evil and compromising the root of trust for everything silently <unmatched-paren>oriansj: Except maybe ludo, as they presumably know what they're talking about if they're advising you on guix. <PotentialUser-63>unrelated to my current issue: I had plans to package hugo a static website generator written in go. Is my assumption correct, that I would also have to package every go dependency of hugo? <lechner>There are problems everywhere. Guix will develop a broad appeal in the near future <lechner>PotentialUser-63 / that is correct but relatively easy <unmatched-paren>PotentialUser-63: it would be really nice if you did (with ``guix import go'' <unmatched-paren>on a... somewhat related note, I only need one more commit access vouch; any non-maintainer committers around at the moment? :) <rekado>jgart[m]: I encourage you to specify *how* it could be improved and come up with steps to get there. <jgart[m]>rekado: Ya, I know. I will soon don't worry <jgart[m]>The licenses can be improved/more added from the hexpm API <unmatched-paren>meow looks like a "DIY modal editing setup" kit, meow is "modal editing but it doesn't interfere with the default emacs keybindings" <jgart[m]>Ya it's similar modal editing though right? <lechner>unmatched-paren / which 'samurai' did you refer to earlier, please? <unmatched-paren>jgart[m]: seems like it's a system for gradually easing into modal editing; so, not what i initially though <jgart[m]>I'd use meow over evil if someone had a good vim config for it <jgart[m]>I don't want to do the work of mapping everything <jgart[m]>mapping all the meow elisp functions to standard vim qwerty ones <rekado>unmatched-paren: that libreoffice thing is frustrating. <rekado>happens at the very end of a very long build, and the error is hardto diagnose. <rekado>I already built it with -fPIC to see if it makes a difference. It did not. <apteryx>rekado: did you try in a 'guix shell -CD libreoffice' ? <jgart[m]>It can be though as it provides the framework/library to make a clone <rekado>apteryx: I tried just the full build <apteryx>rekado: does it happen while linking the binary? <rekado>I didn’t build the thing manually yet, <rekado>I should run it with -K and then see what’s up in the work dir <jgart[m]>I'd prefer to start from the vim clone bindings and then hack away from it as I see fit <rekado>but I’m terrible at debugging this stuff <jgart[m]>instead of being in alien muscle memory territory <apteryx>rekado: if it happens during the linking, we could check/try that a) debug symbols are not being generated -- e.g. "release" build b) use a more memory efficient linker such as 'lld' for the build <apteryx>my guest being that the linking may well try to address more than 4 GiB and fail on i686 <minima>hi, can anyone point me to a minimalist system definition that includes a compositor or a graphical server, something that i can start with eg sway or startx? <rekado>apteryx: building with ld-gold-wrapper now. Let’s see. <minima>unmatched-paren: ah cool, i think i miss seatd then <minima>as i get an error if i try to launch sway otherwise and yeah, it does mention something something seatd :) <minima>ah, yeah, i think i nuked desktop-services at some point... time to put that back in :) <minima>ok, that's cool, i like the idea of adding things back in in a granular way <minima>i'll add seatd then - if i go for it, do i need to add my users to the seatd group or anything like that? <minima>super, thank you! let me try that then <lechner>unmatched-paren / guix shell: error: muon: unknown package and also guix shell: error: samurai: unknown package <Fare>How do I add a substitute server before I bootstrap guix? I was told about bordeaux.guix.gnu.org, but how do I convince guix it doesn't need to fully bootstrap rust before it starts using it? <apteryx>rekado: I forgot the numbers but rated by only memory requirements ldd < gold < bfd.ld <apteryx>is there a way to tell 'env' to use the content of my 'environment' file while preserving 'PATH' ? <unmatched-paren>i'm building libreoffice with lld-as-ld-wrapper in inputs and --system=i686-linux now <Fare>unmatched-paren, I'm still trying to complete the guix system reconfigure foo.scm on an aarch64 machine, but it's somehow trying to bootstrap rust, which is taking days, maybe weeks... and still failing because it's trying to install GNOME (that I don't even want... how do you NOT install any GNOME or X stuff?) <unmatched-paren>i have a fairly powerful computer, so i think it should finish soon... <apteryx>Fare: it probably wants GNOME stuff for the GDM graphical session manager <apteryx>you could replace that by slim for the most minimal option <unmatched-paren>Fare: you need to replace %desktop-services with %base-services to remove the GNOME/X stuff <lechner>greetd works great, but not with a FUSE-mounted home yet <apteryx>Fare: just taking out gdm-service-type from %desktop-services should go a long way toward reducing dependencies <apteryx>(and replacing it with some other display manager of your choosing) <Fare>apteryx, thanks a lot. How do I add xorg without GNOME? <Fare>can I modify %desktop-services into removing gdm or replacing it by something more lightweight? <jgart[m]>unmatched-paren: are you thinking of making a build system with samurai? <jgart[m]>or make meson-build-system configurable on samurai? <jgart[m]>doesn't meson build system use ninja iirc? <unmatched-paren>jgart[m]: it should be possible, i think, to set #:meson muon in a meson-build-system (arguments (list ...)) and have it Just Work <PotentialUser-30>I use GUIX as foreign distro. Its works quite well - e.g. i often do guix pack ... and it works . But whats the way to play with the guix git checkout (for contributing). Is it mandatory to go the ./pre-inst-env way or do i have to set the checkout path via -L switch <jgart[m]>unmatched-paren: how about cproc and gcc? <unmatched-paren>``./bootstrap && ./configure --localstatedir=/var && make -j$(nproc)'' <jgart[m]>ya but at least the ones backed by oasis will ;() <Fare>can I delete many things in one statement? I should also delete the gdm-file-system-service ... can I do it like that, or do I need to extract its 'type' somehow? <unmatched-paren>PotentialUser-30: to be honest i'm not sure why /var isn't the default <lechner>PotentialUser-30 / i have heard it will save your system from being corrupted, although I am not sure how <PotentialUser-30>I get configure.ac:92: error: possibly undefined macro: GUILE_MODULE_AVAILABLE <jgart[m]>unmatched-paren: why is localstatedir needed in that configure snippet? <unmatched-paren>PotentialUser-30: oh, you need to do those in ``guix shell -D guix'' <jgart[m]>I've been like -.o.- also for about 2 years or so <jgart[m]>Whats the purpose of the --localstatedir ? <PotentialUser-30>Its getting worse (other errors) :-( Do we need root for the bootstrapping process? I hope not? <jgart[m]>I'm going to email RMS to ask him whats the purpose of the --localstatedir in that command <Fare>Could not find build log for '/gnu/store/psb8yyl8685ncqaqcm9kj4bz4v2dd8q5-linux-modules.drv'. ==> how do I debug that? <jgart[m]>Ya but, maybe he can tell me who might know <PotentialUser-30>Perhaps it's somehow corrupted now? If i do: LANG=C guix shell -D guix i get Perhaps it's somehow corrupted now? If i do: LANG=C guix shell -D guix i get / In procedure mkdir: Permission denied <apteryx>jgart[m]: please don't email random people with random questions <jgart[m]>I'm curious what RMS thinks of Guix. Would be surprising if we get a [PATCH] gnu: emacs-next: Update to foo.bar. from RMS one day in mumi <lechner>we really want the one that says "change name to GNU OS" <PotentialUser-30>For not wasting your time i think i should try again from the beginning? So the right process is to do guix shell -D guix first and then ./bootstrap && ./configure --localstatedir=/var && make ?? <lechner>PotentialUser-30 / i would also reclone <unmatched-paren>because you'll probably need to look at the logs or bisect at some point <lechner>unmatched-paren / "Permission denied"? <apteryx>jgart[m]: but to answer your question, consult: info '(standards) Directory Variables'; the default location for localstatedir in GNU is expected to be /usr/local/var <apteryx>in Guix we should /var, hence the need to override the default <jgart[m]>thanks apteryx RMS replied and told me to RTFM and gave me the same info CLI invocation <apteryx>no way they could reach out that timely <PotentialUser-30>In the manual they're writing use guix environment guix --pure . Is it the same as guix shell -D guix ? don't think so... <jgart[m]>I wish info '(standards) Directory Variables' was a online video series <unmatched-paren>PotentialUser-30: you are reading the release manual, which is decrepit <jgart[m]>it's deprecated but you can still call it? <unmatched-paren>jgart[m]: a state of deprecation where you can't use it anymore is called "removal" :) <unmatched-paren>lechner: that's where it's deprecated and when you use it it spits out an inscrutiable error :P <PotentialUser-30>Here comes somewhat crazy thing: After LANG=C guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA" Authenticating commits 9edb3f6 to 8f3e10a (44884 new commits)... And then guix git: error: mkdir: Permission denied <iska>I'm having issues with doing go stuff, can anyone help? <iska>package golang.org/x/exp: no Go files in /tmp/guix-build-go-golang-org-x-exp-0.0.0-20221114191408-850992195362.drv-0/src/golang.org/x/exp <lechner>iska / make it a "source-only" package <iska>this is needed to update ipfs, almost a year out of date <lechner>i'm having some browser problems but you can find references in golang.scm <PotentialUser-30>Hmm - and also after: guix shell -D guix --pure i get: guix/scripts/shell.scm:262:18: In procedure guix-shell / In procedure mkdir: Permission denied <lechner>remove the build phase and disable tests, unless unmatched-paren says something else <lechner>PotentialUser-30 / did you at any point in time invoke sudo? <PotentialUser-30>Yes. I'm in GENTOO. But all the things i need (guix pack) are working quite well !! <iska>x/exp build passed, thanks :) <PotentialUser-30>The manual way (not the script) Perhaps 1 or two month ago. So there is al little chance that missed something... <gnucode>lechner: I was telling people at work that today is national hig a turkey day. (I'm vegan). :) <lechner>oriansj / PotentialUser-30 / both are basically the curl | bash thing. gentoo does not prvide a package? <lechner>gnucode / good for you! no need to pardon the turkey <lechner>PotentialUser-30 / unless you are attached to Gentoo, you may want to switch to Guix System. I did it one day in April. The first week was tough but then it all came together. Now I would not use anything else <lechner>i had not used the package manager before <PotentialUser-30>In the GENTOO ebuild in src_install( ... they have some permissions - perhaps i should check them first... <lechner>755 i think, but you are digging to deep and touching too much <lechner>if you really want Guix that badly you maybe better off going with a System installation, but Guix does not play so nice with multi-boot, I do not think <lechner>same headache and better result. plus, folks here may not help you (or know) what to do <lechner>i only manipulated those profiles manually once, when i changed my user ID in the declarative configuration and the per-user was not updated <oriansj>well guix on top of other distros is fine as long as you set your environment variables correctly <unmatched-paren>jgart[m]: A recipe for building recipes. It's recipes all the way down! <jgart[m]>portage doesn't motivate me like guix does but I don't mind using guix on gentoo if I had the time to use gentoo <oriansj>well gentoo has a few good ideas that guix should steal (and potentially improve upon) <jgart[m]>I used gentoo for about 6 months and then I switched to void linux <unmatched-paren>oriansj: i do think a package-features... feature would be a good addition to guix :) <jgart[m]>I think someone already tried to implement use flags <jgart[m]>There was talk about it for a while on the ML <iska>ipfs-go (aka kubo) is failing to build, seemingly from a bundled library we can't remove <oriansj>well I would love to see it; even if it ment I would have to jump through a few hoops to get it <iska>src/github.com/ipfs/kubo/vendor/github.com/lucas-clemente/quic-go/internal/utils/linkedlist/linkedlist.go:15:16: syntax error: unexpected any, expecting ] <iska>I think this is the culprit <iska>type Element[T any] struct { <iska>and this is what's causing the errors <unmatched-paren>iska: looks like it uses generics, which i don't think are in the version of go that go-build-system uses <iska>yeah it's for generics, said in the readme <unmatched-paren>jgart[m]: that looks exclusive to asdf-build-system? might be wrong though <jgart[m]>Ya, it's planned to be generalized to other langs iirc <iska>so do we update go-build-system? <jgart[m]>guixrus might get a pre-release of it soon <PotentialUser-30>[SOLVED] After putting the git checkout directory in .config/guix/shell-authorized-directories it works - unfortunately i got the tip only after invoking guix shell (and nothing more) <jgart[m]>Would be cool if guix lint warned you when you're trying to commit a package that has already been updated in another branch <jgart[m]>I've updated code before in master that was already done in core-updates <jgart[m]>Are people interested in having a meetup over jitsi with Dale Mellor? <apteryx>jgart[m]: It could be interesting to hear about Dale if they're inclined to <apteryx>hm, is savannah having issues? fatal: the remote end hung up unexpectedly <jgart[m]>apteryx: Cool. I'll reach out to Dale soon. <apteryx>debbugs seems to be struggling today (No HTTP response from server) <unmatched-paren>apteryx: hmm, and an email i sent to guix-devel a few minutes ago still hasn't gone through <lxsameer>hey folks, does guix system supports a similar concept to Gentoo's USE flags? <jgart[m]>unmatched-paren: that sounds good. dogfood package-with-features in guixrus? <jgart[m]>I like the with-package-features macro idea <rekado>ACTION tries to run guix init on kreuzberg to switch to the new SSD <rekado>jgart[m]: how does the link to some Carp code relate to Guile? <jgart[m]>Could we use a (doc ) form in a custom define-syntax? <jgart[m]>That supports making available docstring info from the macro to repl metacommands? <jgart[m]>unknown file:6:3: source expression failed to match any pattern in form cute <jgart[m]>Would be cute to get documentation with that repl metacommand <jgart[m]>Why is building this: ./pre-inst-env guix build emacs-carp <jgart[m]>rustc-1.60.0-src/vendor/term-0.6.1/tests/data/linux-c-nc etc... ad infinitum <jgart[m]>if emacs-carp does not have any rust in the package <jgart[m]>It just has emacs-clojure-mode and emacs-flycheck <apteryx>jgart[m]: you can check yourself with 'guix graph --path emacs-carp rust-dep' <jgart[m]>emacs-carp does not have a rust dep though <jgart[m]>this has happened to me before also with other packages that do not have a rust dep <rekado>when I build this there’s no rust involved <rekado>in fact it’s already done building it <apteryx>there's no emacs-carp in guix, so I can't tell <rekado>I just copied the thing from the first paste <rekado>so there’s got to be more to the story than just that paste on latest guix <jgart[m]>I just ran the above command to build emacs-carp in my guix checkout <jgart[m]>I expect to just build emacs-carp from running ./pre-inst-env guix build emacs-carp <jgart[m]>It starts to build rust stuff for some mysterious reason <rekado>the derivations have the answers <rekado>guix will never build anything that’s not referenced in the derivations <jgart[m]>I don't think a drv has been produced because I kill the build <jgart[m]>before it successfully builds emacs-carp <rekado>there will always be a derivation *first* <rekado>Guix can’t build anything without a derivation <jgart[m]>how do I list the derivation for that build I just ran? <jgart[m]>./pre-inst-env guix build emacs-carp --list-derivation <rekado> -d, --derivations return the derivation paths of the given packages <rekado>it’s the fifth option there; can’t miss it. <rekado>(where did you get “--list-derivation” from? It’s not mentioned anywhere in the help output or the manual.) <rekado>please try to reproduce this without any modifications, so that you can show us a “guix time-machine” command that we can use to reproduce this. <jgart[m]>in the context of what I was trying to do <jgart[m]>Well a ton of rust stuff is building right now after I ran it with -d <jgart[m]>So, hopefully I'll get to see the derivation at the end of all this if it doesn't fry my poor CPU <jgart[m]>patch-cargo-checksums: generate-checksums for vendor/jsonrpc-core-client <rekado>please show us how to reproduce this <rekado>we don’t have enough information <rekado>obviously it’s building rust stuff <jgart[m]>what info do you need? the drv when the command is finished? <rekado>you can tell Guix to not build anything and just show the build plan <jgart[m]>guix-shell ./pre-inst-env guix build emacs-carp -d --dry-run <jgart[m]>Do you want the contents of each of those drv files? <jgart[m]>now I see why adding rust to emacs was a mistake <jgart[m]>I thought that wasn't going to affect me <jgart[m]>ya but emacs-build-system uses gtk emacs with rust? <jgart[m]>can I switch out the emacs implicitly used in emacs-build-system globally? <jgart[m]>so how do I avoid the rust in the above? <jgart[m]>does one of those emacs deps of emacs-carp have gtk emacs as a dep? <rekado>emacs-minimal does not have gtk as an input <rekado>#:emacs ,emacs ; FIXME: tests fail with emacs-minimal <unmatched-paren>jgart[m]: surely, though, you should already have rust, gtk, etc installed because you have emacs installed? <jgart[m]>in theory it sounds good but maybe there's something we're missing here <rekado>FWIW emacs-s passes its tests with emacs-minimal just fine <jgart[m]>we found one problem thanks to rekado spotting that <unmatched-paren>jgart[m]: i guess you should change that in a separate commit and send a multi-patch set <jgart[m]>should we remove all non emacs-minimal usages? <rekado>jgart[m]: unfortunately, your patch set above has wrong commit messages <rekado>but it actually adds +(define-public rust-linux-raw-sys-0.0.46 <rekado>etc/committer.scm is for automating mass updates <rekado>(e.g. the 400+ commits for upgrading bioconductor, or the 200+ commits for upgrading CRAN, etc) <jgart[m]>I thought etc/committer.scm could do new packages? <unmatched-paren>jgart[m]: magit has a `v` keybinding on diff listings that allows you to select code to stage line-by-lin <rekado>the script’s top comment says: This script stages and commits changes to package definitions. <jgart[m]>tig gives me an ncurses window to stage lines <jgart[m]>Might be nice to add a more descriptive note at the top to that <jgart[m]>Like this script should only be used for doing mass updates, etc. <jgart[m]>rekado: Like you mentioned here. That irc info could just go in the module docstring <jgart[m]>Then someone might not accidentally do what I did <jgart[m]>I think etc/committer.scm is also not documented in the manual iirc <jgart[m]>It would be very useful if it did new packages <jgart[m]>I think it was doing new packages also but there's a bug somewhere that trips it up <jgart[m]>I did successfully auto commit packages with the correct name <rekado>the problem is with insertions that are very close to each other <rekado>we don’t get enough separation from git <jgart[m]>If it did work for how I thought it was working it would be such a guix life hack <jgart[m]>Would be cool to improve it to that stage <jgart[m]>Instead of having to manual sort crates-io.scm <jgart[m]>but my dag skills are not up to par to help here <jgart[m]>but my dag skills are not up to par to help here <rekado>not talking about “dag skills”; just the git diff bug <rekado>to prevent it from doing what it did to your pastel diff <jgart[m]>I'm not sure what the bug is exactly as of yet <jgart[m]>the sorting idea would involve some graph theory knowledge <jgart[m]>I've discussed it on the ML with someone who almost had it working <unmatched-paren>probably just read in each package as a sexp, order them by name, and then write them out with ``(guix read-print)''s procedures <jgart[m]>> If you have some graph theory and Guix know-how you might be able to get <unmatched-paren>More possible that I am incorrect, since I know less than zero about graph theory. <jgart[m]>You're approach sounds more like what I'd do <rekado>the goal here is to make sure that we add stuff only after all its inputs have been added. <unmatched-paren>rekado: i thought it didn't matter what order the packages were in, so long as they're all in the same module <unmatched-paren>i've definitely seen guile variables able to access other guile variables defined after them <rekado>unmatched-paren: this is about sorting *commits*, not definitions inside a file <rekado>to modify the insertion location with etc/committer.scm doesn’t make any sense <rekado>jgart[m]: we already have at least two implementations of topo sort in Guix <rekado>used for different purposes, but that doesn’t matter <jgart[m]>I don't think I'd identify them unless it would be pointed out but it would be useful to know <rekado>they are literally named topological-sort <rekado>one in import/utils.scm, another in build/store-copy.scm <jgart[m]>1541:(define (topologically-sorted store paths) <jgart[m]>thought it was just a pattern or feature <rekado>that one is less useful because it operates on the store <jgart[m]>like when people implement the visitor pattern in OOP but don't announce it to the world in the class or method name, etc. <rekado>but to fix the git diff bug in etc/committer.scm you won’t need any of this <rekado>you just need to know how to make git diff print the right thing and then operate on the output <jgart[m]>apteryx: that GNU C book you mentioned early is good so far. Nice opener to the book <rekado>the problem is likely in diff-info, which slurps up too much in the case of additions <rekado>expected result is: bug is fixed :) <jgart[m]>so we're all on the same page about what the fix would look like once implemented <jgart[m]>I don't think I fully understand the bug yet <rekado>I encourage you to play with diff-info to build a reproducer <rekado>and then reads diff hunks from the output <jgart[m]>But an example of the bug is in my pastel ticket commit messages? <rekado>somewhere along the way it must be reading more than it should <rekado>that pastel diff is hardly a minimal reproducer, though <jgart[m]>I'll look with more detail/scrutiny soon <rekado>but any of the patches we pointed out above would probably be a good test case. <rekado>i.e. make the changes in a pristine checkout and then see what diff-info has got to say about this. <jgart[m]>sorry can you repost the patches you pointed out <jgart[m]>I thought the only one I saw was the pastel ticket <jgart[m]>you mean the patches in my pastel ticket? <jgart[m]>or another separate ticket by someone else? <rekado>“git diff” shows the two additions <rekado>then I started “guile” and ran (load "etc/committer.scm") <rekado>and it made two separate commits <rekado>sooo… needs more work to figure out how to reproduce this <rekado>I guess we could apply all the changes from 59389 <jgart[m]>Does any elisp package provide that wget mumi trick? <jgart[m]>Or maybe it should be added to emacs-guix? <rekado>and then run etc/committer.scm on all of them to see if we can reproduce this <rekado>it applies fine for me on commit 5f8c11d48e4949aa77d7aaa1e7e25568bd8dfa97 <jgart[m]>I see rust-io-lifetimes-0.7 and rust-terminal-size-0.2 <jgart[m]>etc/committer.scm committed them perfectly <lechner>Hi, in a system configuration, can kernel modules be loaded regularly or only via initrd? <jgart[m]>I think I'll go out for pumpkin ice cream and think about this more <kozo[m]>Anyone have a working example of etc-service-type? I am trying to include it in my guix home configuration file but I can’t get the syntax right. Thank you 😁 <kozo[m]>Thanks, doesn’t work though. Probably why it’s commented <a12l>unmatched-paren: Regarding your suggestion about organizing my configuration files from earlier today, I've `a12l.scm` in my Guix conf dir's root (i.e. `/a12l.scm`); and then `st.scm` and patches stored in `/variants/st`. If I want to enable installing my packages together with my other files, should I just add the line (add-to-load-path (string-append (dirname (current-filename)) "/variants/st")) somewhere in `a12l.scm`? <jgart[m]>Has anyone tried to make a info file from all of wikipedia? I'd like to build and package that on a webhook <lechner>sneek / later tell unmatched-paren: Hi, a12l wrote a message to you on Thu Nov 24 at 14:33 PST <sneek>unmatched-paren, you have 1 message! <sneek>unmatched-paren, lechner says: Hi, a12l wrote a message to you on Thu Nov 24 at 14:33 PST <unmatched-paren>lechner: kernel modules can be loaded with kernel-module-loader-service-type <a12l>Thanks, and have some nice sleep! <a12l>lechner: And I'll remember sneek :)