IRC channel logs


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>* mountpoint, sorry.
<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>but i am absolutely weak in 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.
<vagrantc>good luck
<nckx>I can't get rid of it soon enough TBH. But Coreboot isn't an option.
<nckx>Fare: o/
<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
<sneek>unmatched-paren, lechner says: it's also noted in the source code (sorry, the upstream Git browser is not working currently)
<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
<unmatched-paren>lechner: sorry, never used pam-mount...
<vagrantc>not that it is arguably the source of truth for EFI either :)
<chomwitt>ACTION thanks nckx and unmatched-paren 
<unmatched-paren>chomwitt: and installed files: ``ls -R $(guix build guile)''
<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.
<unmatched-paren>Hmm... I'm trying to fix <> by using the latest commit of emacs-helpful <> but for some reason i'm still getting the error...
<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
<unmatched-paren>the recsel command comes from recutils
<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
<civodul>but see
<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’.
<chomwitt>civodul, i am printing it now! :-)
<nckx>chomwitt: I thought for sure I'd fine one on the Web somewhere, but no luck.
<chomwitt>ACTION humbly reads
<whereiseveryone>mumi is 504'n again
<whereiseveryone>how often does the documentation html site get deployed?
<whereiseveryone>it gets deployed on successful CI?
<mekeor[m]>chomwitt: guix changes quite fast. you might want to read the manual of the latest development version at :) -- also, welcome :)
<jgart[m]>I just read the texinfo in doc/
<mekeor[m]>personally, i prefer sensing the electromagnetic fields of my hard disk where my copy of the binary executable of guix lives
<chomwitt>mekeor[m], thanks! i bookmarked it.
<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.
<whereiseveryone>nckx: re: mumi restarted: cool! can you review this then?
<whereiseveryone>haha jk no pressure
<nckx>I do not review packages in my sleep, and I think that's a healthy sign. Good night!
<whereiseveryone>I wouldn't want to wish any rust review patch set on anyone
<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.
<chomwitt>are you in a pc or virtual machine ?
<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!)
<chomwitt>s/should/should not
<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.
<rothari>(Guix newbie here as well)
<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
<chomwitt>rothari, i checked openbox dependencies
<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>I have ran the xinit without dm
<ph03n1xaimverncc>You'll need a custom startx script
<ph03n1xaimverncc>Someone answered that on a guix mail thread or something
<ph03n1xaimverncc>That script worked wonderfully
<ph03n1xaimverncc>Called xinit from script with some args
<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...
<jgart[m]>would these be done with wrap-program?
<sneek>lechner: Greetings!
<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 ( ok. Do..." <- startx not working in guix is ehat I searched for
<ph03n1xaimverncc>I think it was this
<jgart[m]>will this wrap a delay around every pattern?
<jgart[m]>* will this macro wrap a
<jgart[m]>or should I be macro-expanding that instead of asking here?
<jgart[m]>not sure that the full macroexpansion was helpful...
<ph03n1xaimverncc><ph03n1xaimverncc> "" <- Do... (full message at <>)
<ph03n1xaimverncc>Do Java Apps work fine for you guys?
<ph03n1xaimverncc>I had to develop an app in guix and it was not showing at all.
<ph03n1xaimverncc>One of my friends game called opencraft didn't run well, not sure if xorg at fault tho
<ph03n1xaimverncc>Is there eclipse for guix?
<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
<rothari>Hi. I am struggling to get Openbox to work without login/display manager. I tried this but when I run the script I get a black screen with a cursor and can't do anything, I have to force shutdown. I do not know if I need any xf86-* packages or how I should set up ~/.xinitrc.
<Fare>who should I contact wrt adding aarch64 workers to the guix ci / build farm ?
<mekeor[m]>Fare: maybe the guix devel mailinglist
<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
<mekeor[m]>rothari: in xinitrc, simply start openbox
<mekeor[m]>i'm busy now, i can come back in 3h
<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?
<chomwitt>efraim, thanks for the tip
<unwox>chomwitt: right
<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
<unmatched-paren>they are separate
<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>chomwitt: well, the system config can modify any file on /
<unmatched-paren>it can't modify files
<unmatched-paren>it can create them
<unmatched-paren>well, configure them. it'll replace a file if it already exists.
<unmatched-paren>the home config can modify anything in ~
<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>chomwitt: guix home is very cool, you should definitely try it :)
<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
<unmatched-paren>chomwitt: ?
<chomwitt>i mean in order a versioned home-profile to work i couldnt just open edit and save conf files
<unmatched-paren>yes you could
<unmatched-paren>you do have to run ``guix home reconfigure'' to apply the changes
<unmatched-paren>which creates a new home generations
<unmatched-paren>you can roll-back etc that generation
<chomwitt>ok. thats looks interersting.
<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>guix home is a wee bit like gnu stow, but more general
<unmatched-paren>as the "put file here" functionality is just a subset of home services
<unmatched-paren>dotfile installation is implemented as the home-files-service-type
<unmatched-paren>you could also use, say, the home-dbus-service-type to get a dbus session daemon running
<unmatched-paren>there aren't that many actual shepherd services in guix mainline yet, but there are a few here:
<unmatched-paren>services for mako, emacs, foot, and himitsu, courtesy of unwox and myself :)
<unmatched-paren> <- there are also quite a lot here too
<unmatched-paren>personally i prefer my home-emacs-service-type to rde's
<unmatched-paren>rde provides services for things like sway and xmonad too though
<unmatched-paren>and alacritty, in case you prefer that over foot
<unmatched-paren>and gpg too :D
<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"
<unmatched-paren>chomwitt: i think you should have a look at that file first
<unmatched-paren>to see what it contains :)
<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"
<unmatched-paren>chomwitt: that's normal the first time you run it
<unmatched-paren>it's just because you don't have any home generations yet
<unmatched-paren>so it can't figure out what generation you're on
<chomwitt>i log out then
<chomwitt>so now i can edit ~/.config/* then "guix home reconfigure" and then i could see 'home profile' generations with '$ guix home --list-generations" ?
<unmatched-paren>chomwitt: ``guix home list-generations'' (no --), but yes :
<chomwitt>~/.guix-home/files/.config lists only one of dirs that i have in ~/.config
<unmatched-paren>there, that's what i meant to type :)
<unmatched-paren>chomwitt: which one?
<unmatched-paren>you do have to add the files you want to the home config yourself
<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>in configuration.scm
<unmatched-paren>sorry, (service home-xdg-configuration-files-service-type `(...))
<unmatched-paren>and in that `(...) you can add files, like this:
<unmatched-paren>`(("awesome/config.lua" ,(local-file "awesome-config.lua")))
<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>sorry, plain-file is actually
<unmatched-paren>(plain-file "awesome-config.lua" "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
<unmatched-paren>chomwitt: yes
<chomwitt>and what happens if i want to spit awesome config in many dirs and files ?
<unmatched-paren>chomwitt: well, you just add other entries, like this:
<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>like you would with stow
<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
<unmatched-paren> <- like this mako service
<unmatched-paren> <- or this batsignal service
<chomwitt>unmatched-paren, i think thats too difficult for me now. i ll try to track a simple config file for start
<unmatched-paren>hmm, why isn't this working? <>
<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
<chomwitt>your paste opened fine
<unmatched-paren>chomwitt: i mean the contents of the paste; i'm trying to make a change to the guix source code :)
<rothari>Hi guys. I am trying to use Openbox on Guix without any login manager. I tried but when I run the script I only get a black screen with a cursor and I cannot do anything, so I have to force a shutdown. I think that maybe I am missing some xf86-* packages, but I don't know which ones I need.
<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>Where do I find log files for shepherd services?
<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>unmatched-paren: but how to debug it? :)
<unmatched-paren>stevenroose: sorry, i don't know; it was quite a few months ago :(
<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>WDYM picked up?
<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.
<unmatched-paren>Ah! Yes.
<unmatched-paren>That's what happened.
<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.
<stevenroose>it should be /dev/nvme...?
<nckx>I think the raw UUID will work, but am not sure because I never tested that hard :-). Yes, raw devnode is safest.
<stevenroose>Hmm, k will try again
<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
<stevenroose>Ahah! It works!
<a12l>I want to apply a patch to st (suckless terminal), and I'm wondering if this package definition looks good?
<unmatched-paren>a12l: that's not quite right
<a12l>I need help with what modules I should add to the definition.
<unmatched-paren>you need (guix packages), (guix download), and (gnu packages)
<unmatched-paren>you also need to add a (name "my-st") and (version (package-version st))
<unmatched-paren>the patches should be (search-patches "st-nordtheme-0.8.5.patch")
<unmatched-paren>and they need to be somewhere in the guix load path
<a12l>unmatched-paren: Thanks!
<a12l>Just going on the example provided in the ref manual
<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>but it also binds that version to 'version'
<unmatched-paren>so your uri will work
<unmatched-paren>also, you may want to add (file-name (string-append name "-" version ".tar.gz")) to the origin
<unmatched-paren>it's not needed though
<a12l>I already have that? Or are I'm missunderstanding you?
<a12l>Line 8--9
<unmatched-paren>that's not the file-name, that's the uri
<unmatched-paren>file-name is what the downloaded source file is called in the store path
<unmatched-paren>/gnu/store/...-my-st-<ST_VERSION>.tar.gz, in that case
<a12l>Ah, thanks!
<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))
<unmatched-paren>or -L <DIR> in the guix invocation
<a12l>Should (add-to-load-path (dirname (current-filename)) be added outside of the package definition?
<rothari>I am slowly getting this 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
<a12l>unmatched-paren: How does it look know?
<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: actually, i think there's a better way to do this:
<unmatched-paren>rothari: Yes
<unmatched-paren>a12l: use (define-module (st) #:use-module (gnu packages) #:use-module (guix download) #:use-module (guix packages))
<unmatched-paren>rather than use-modules
<unmatched-paren>and remove the add-to-load-path thing
<unmatched-paren>a12l: also, it's just (patches (search-patches "..."))
<unmatched-paren>if you just quote it, it's just equivalent to this:
<unmatched-paren>(list (list 'search-patches "st-nordtheme-0.8.5.diff"))
<minima>(in case this may be of interest, with regard to my question above, i found this which provides a solution)
<unmatched-paren>a12l: now, you should be able to do ``guix install my-st -L .''
<unmatched-paren>a12l: oh, remember to add (name "my-st")...
<unmatched-paren>a12l: btw, file-name conventionally goes after uri, and patches usually goes before sha256
<unmatched-paren>a12l: no, not (patches ((search-patches "...")))...
<unmatched-paren>there, you're basically trying to call a 0-argument lambda returned by search-patches
<unmatched-paren>but of course search-patches doesn't return a lambda :)
<unmatched-paren>a12l: here you go
<a12l>The "unbalanced" line gets added when I run `guix style -f st.scm`. Not sure why, can't see any missing parenthesises
<unmatched-paren>a12l: guix style isn't too useful at the moment (imo)
<unmatched-paren>it can often make style worse rather than better
<a12l>Thanks, I'll keep than in mind not to rely blindly on it
<unmatched-paren>there are no unbalanced parens
<unmatched-paren>i checked in emacs
<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
<unmatched-paren>a12l: no, ``guix build -L . my-st
<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>Or no
<unmatched-paren>a12l: ah, you need to #:use-module (gnu packages suckless)
<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"
<unmatched-paren>rothari: Oh.
<unmatched-paren>I'm not sure what's wrong there, sorry :(
<a12l>unmatched-paren: Thanks so much for the help!
<unmatched-paren>a12l: does it work now? :)
<a12l>This was ridiculously easy
<unmatched-paren>a12l: if you want to apply more patches, put another one in that search-patches
<unmatched-paren>so (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>Hi all,
<unmatched-paren>PotentialUser-30: hello!
<PotentialUser-30>if i inherit from a package, then also all the "arguments" are inherited - right?
<unmatched-paren>PotentialUser-30: yes
<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."
<unmatched-paren>you can use the substitute-keyword-arguments macro
<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
<PotentialUser-30>Thanks for help
<lechner>rothari / Hi, i might try a device rescan similar to the one described here
<unmatched-paren>a12l: do you still have the old st package installed?
<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) ?
<unmatched-paren>PotentialUser-30: yes
<PotentialUser-30>Cool. Did i miss any documentation? I didnt found something about this macro in the guix manual. Is there only e.g. ?
<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>insert clip of Anakin
<unmatched-paren>PotentialUser-30: it might be missing idk
<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: is it? that's nice to hear :)
<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.
<PotentialUser-30>unmatched-paren:Thank you again !
<jgart[m]>What is the difference between gc.scm and TLDR
<jgart[m]>Or how are those interacting in the code?
<jgart[m]>Does anyone have a TLDR?
<unmatched-paren>jgart[m]: is there a gc.scm?
<unmatched-paren>where is it, apart from the one in scripts?
<jgart[m]>Or concept overview
<unmatched-paren>the daemon is the only thing that's allowed to actually write to the stoe
<unmatched-paren>so GC is implemented in C++ in the daemon source
<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
<unmatched-paren>ACTION looks
<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/ 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>jgart[m]: oh, i didn't know about that one :)
<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
<unmatched-paren>but that'll definitely be useful
<unmatched-paren>oh, yeah, it fails...
<unmatched-paren>it works intra-file, but not inter-file
<jgart[m]>I think you need to add your local guix git repo in your emacs config first to some dynamic variable list
<unmatched-paren>jgart[m]: ah
<unmatched-paren>i've found it
<jgart[m]>The set up for it is in the manual
<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]>I feel like 50% of it works
<jgart[m]>Geiser seems so fragile for doing jump to source
<jgart[m]>Sometimes I can jump to another file sometimes not
<unmatched-paren>jgart[m]: tempel or yasnippet?
<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
<jgart[m]>apteryx: That's good to know
<apteryx>I'd be nice to figure it out, perhaps issue a bug report to geiser if we can pinpoint what's exactly wrong
<jgart[m]>I thought I was going crazy haha
<mirai>more of a scheme question, is there a cleaner way to express this? (
<jgart[m]>jao doesn't use guix at all
<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]>And fix the bugs
<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]>It might support Guile
<jgart[m]>Maybe it is more robust than geiser for doing jump to source...
<unmatched-paren>jgart[m]: which should i use? guix has snippets for both
<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]>unmatched-paren: Why only use one?
<unmatched-paren>jgart[m]: do they not implement the same feature?
<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]>There's a ton of yasnippets
<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]>Since tempel is nicer to hack on
<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
<jgart[m]>unmatched-paren: HTHs more than bloats
<omlet[m]>the module xorg is startx?
<lechner>Hi, does the docker build fail for anyone?
<jgart[m]>Why do we use use define-public for packages instead of #:export (foo)?
<unmatched-paren>jgart[m]: it's simpler
<jgart[m]>Because of automation and guix import?
<unmatched-paren>yeah, that too
<omlet[m]>orOr how can I do it to start a desktop through Startx?
<unmatched-paren>crates-io.scm would have quite a large #:export
<jgart[m]>If it's simpler then why don't we do it everywhere?
<jgart[m]>unmatched-paren: oh ya
<lechner>omlet[m] / you want to start X?
<unmatched-paren>jgart[m]: because it's nicer to list the public api explicitly
<jgart[m]>omlet: look at jsoo1's guix dots
<jgart[m]>On GitHub
<jgart[m]>here specifically: omlet:
<jgart[m]>give it a startx package
<jgart[m]>unmatched-paren: does that sound right?
<unmatched-paren>jgart[m]: does what? :)
<jgart[m]>See the last link of jsoo1
<rekado>for packages it doesn’t make much sense to duplicate the exports at the top
<jgart[m]>line 193
<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]: that looks right, yeah
<unmatched-paren>i think?
<unmatched-paren>i've never used startx
<unmatched-paren>only wayland and gnome
<jgart[m]>For us mortal newbs
<jgart[m]>What about wayland and gnome?
<unmatched-paren>jgart[m]: ?
<jgart[m]>I run startxfce from the tty
<jgart[m]>But I'm on void
<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]>Oh ok
<jgart[m]>I might switch to gnome on guix system
<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]>That would be cool to have
<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
<lechner>rothari / xinit works for me
<rothari>lechner: in my case, it starts an X session with Openbox, but keyboard and mouse do not work
<jgart[m]>rothari try with dwm
<jgart[m]>or try with i3
<jgart[m]>To see if you get the same result of keyboard and mouse locking up
<lechner>rothari / try something like this (but adjust for your vt)
<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
<jgart[m]>Why does sx work and not startx?
<rothari>jgart[m]: according to startx does not like that Guix violates standard filesystem hierarchy
<rothari>But I don't know how sx works
<jgart[m]>Should that be fixed upstream?
<rothari>jgart[m]: just tried dwm - same problem, input devices are stuck
<jgart[m]>Should startx acomodate Guix filesystem hierarchy?
<jgart[m]>rothari: try sx like lechner: suggested
<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.
<kaelyn>Hi #guix! I want to bring to folks' attention my mesa patch for fixing the paths to the vulkan layers:, which resolves
<lechner>The feature would be called "deploy the last version that builds"
<jgart[m]>What happens currently?
<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>cool, let me try that, thanks
<minima>super, it works! thanks unmatched-paren and jgart[m] :) yay
<jgart[m]>great to hear
<jgart[m]>glad it worked
<jgart[m]>will this macro wrap a delay around every pattern?
<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]>Surely we should use Guix for that?
<jgart[m]>Instead of the traditional way
<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
<lechner>ACTION loves debugging symbols
<jgart[m]>What if the debug symbols are not in by default?
<jgart[m]>Just use make to add them?
<jgart[m]>apteryx: How about if you wanted to use C third party libraries? What would you do?
<jgart[m]>lechner: gcc ... -g
<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?
<unmatched-paren>jgart[m]: just use pkg-config as usual
<jgart[m]>guix shell -D foo?
<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
<jgart[m]>ah got it
<lechner>jgart[m] / you may like autoconf and automake
<unmatched-paren>please don't use autoconf and automake
<unmatched-paren>they will rot your soul and devour your will
<jgart[m]>lechner: I don't
<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
<unmatched-paren>they are almost completely unnecessary these days too
<jgart[m]>But here we are
<jgart[m]>unmatched-paren: What do you use?
<jgart[m]>What's in your C utility belt?
<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
<lechner>i would ditch C
<singpolyma>Just pkg-config and make are usually sufficient
<unmatched-paren>and nobody uses those proprietary unices anymore to be honest
<lechner>automake does more
<unmatched-paren>jgart[m]: i use meson
<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?
<jgart[m]>Does it fit on an index card?
<jgart[m]>The instructions, that is
<jgart[m]>or on a single line ideally
<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?
<jgart[m]>git clone
<unmatched-paren>jgart[m]: i mean, since sbase is suckless, it'd probably just be edit and ``make''?
<jgart[m]>What do you do after that step?
<unmatched-paren>oh, right, it's not suckless
<jgart[m]>cd sbase
<lechner>bdju / i saw some today
<unmatched-paren>jgart[m]: looks like just ``make -j$(nproc)''
<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?
<singpolyma>jgart[m]: pkg-config
<jgart[m]>apteryx: cool!
<unmatched-paren>jgart[m]: pkg-config gtk+3 would probably be the right thing
<unmatched-paren>jgart[m]: for meson, i just... use meson? :)
<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
<lechner>bdju / i am not sure about that
<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''
<jgart[m]>and then what do you do after that?
<unmatched-paren>jgart[m]: if we didn't, we'd do ``guix shell gcc-toolchain make gtk+''
<unmatched-paren>``guix shell gcc-toolchain pkg-config make gtk+ --pure''
<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?
<jgart[m]>I have an intuition that not
<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
<jgart[m]>or st
<unmatched-paren>jgart[m]: why not?
<jgart[m]>let's try it
<jgart[m]>git clone git://
<unmatched-paren>jgart[m]: for a meson package, it's ``meson setup build-dir && meson compile -C build-dir''
<unmatched-paren>not sure what it is for a cmake package
<jgart[m]>cd dwm
<unmatched-paren>probably something like ``cmake build-dir && make -C build-dir''...
<unmatched-paren>since cmake generates makefiles by default
<jgart[m]>guix shell --pure -D dwm
<jgart[m]>make: cc: No such file or directory
<unmatched-paren>jgart[m]: ah
<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
<jgart[m]>doesn't work
<unmatched-paren>the problem here is that guix's gcc-toolchain doesn't provide a cc symlink
<jgart[m]>so does the user have to provide that?
<unmatched-paren>in our dwm package, we set the CC=#$(cc-for-target) make flag
<jgart[m]>if so how?
<unmatched-paren>so just do ``make CC=gcc'
<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
<unmatched-paren>just... that...
<jgart[m]>not sure what you mean
<unmatched-paren>``guix shell -D dwm -- make -j$(nproc) CC=gcc''
<unmatched-paren>s/shell/shell --pure/
<unmatched-paren>that *is* the guix development experience
<jgart[m]> 39 | #include <ft2build.h>
<unmatched-paren>reproducible, pure environments
<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]>How do I deal with that now :)
<unmatched-paren>jgart[m]: that's odd...
<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
<jgart[m]>That issue is reproducible I mean
<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]>Does it fail for you in the same way?
<unmatched-paren>you'll need to use ``make -j$(pnroc) CC=gcc FREETYPE
<jgart[m]>I can't type this in a bash shell: FREETYPE=#$freetype/include/freetype2
<unmatched-paren>make -j$(nproc) CC=gcc FREETYPE=$GUIX_ENVIRONMENT/include/freetype2
<unmatched-paren>i think that'll work?
<oriansj>lechner: well PAM is something one would probably want to replace or avoid if possible
<unmatched-paren>ACTION git clones dwm
<lechner>oriansj / i am working on it
<lechner>oriansj / is 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
<unmatched-paren>not the internal shell
<unmatched-paren>just do ``guix shell -D dwm --pure''
<unmatched-paren>and run the rest in that 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>jgart[m]: ohhhh, i misread the guix package definition
<unmatched-paren>it's actually FREETYPEINC=...
<unmatched-paren>it builds \o/
<jgart[m]>yeah it worked here also
<jgart[m]>but should it be more automated?
<unmatched-paren>this *should* work out of the box, but it looks like dwm's build setup has some wrinkles that need manual intervention
<unmatched-paren>the FREETYPEINC thing
<jgart[m]>Should Guix handle it?
<jgart[m]>Or that's upstream
<unmatched-paren>it couldn't possibly
<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]>I don't want to have to type that
<unmatched-paren>jgart[m]: how would it know to be able to do that?
<unmatched-paren>s/to be able/that it has to/
<jgart[m]>And also figure out that I have to type that
<unmatched-paren>how though?
<unmatched-paren>it's a bug in dwm's makefile afaics
<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!
<jgart[m]>unmatched-paren: ¯\_(ツ)_/¯
<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
<unmatched-paren>s/be able//
<unmatched-paren>oriansj: what do you mean by that?
<lechner>oriansj / consuming packages also compile faster
<jgart[m]>But can the Guix package set it instead of fixing upstream?
<jgart[m]>The way it does with modify-phases
<unmatched-paren>jgart[m]: not if you're building it manually...
<jgart[m]>Why not?
<jgart[m]>Can't we do some setenv majic?
<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.
<unmatched-paren>oriansj: Ahh.
<jgart[m]>apteryx: $ icecat /gnu/store/mj4klnm735nhdnvy3j9l38389jrz02c2-c-intro-and-ref-0.0.0-0.f885596/share/doc/c.html
<jgart[m]>unmatched-paren: That's unfortunate
<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.
<jgart[m]>Ya but I want to develop in a guix development workflow like this:
<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
<apteryx>jgart[m]: or just 'info c'
<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>unmatched-paren: yes, certaily
<unmatched-paren>"Checking for <stdio.h>" i think i've seen that before :P
<jgart[m]>apteryx: thanks
<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
<rekado>well, just trying to help
<rekado>ACTION leaves
<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)
<unmatched-paren>but i prefer to just skip the whole thing and use meson :)
<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
<jgart[m]>similar to
<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
<unmatched-paren>jgart[m]: we can do that in guix with a guix.scm file
<jgart[m]>But we have an erlang build system
<unmatched-paren>which returns a package for the current directory
<lechner>they will, in time
<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]>For an erlang project?
<unmatched-paren>echo $PWD >>.config/guix/shell-authorized-directories
<jgart[m]>erlang build system currently doesn't fin erlang libraries
<unmatched-paren>jgart[m]: for any project
<jgart[m]>erlang build system currently doesn't find erlang libraries
<unmatched-paren>yeah, that's annoying
<jgart[m]>so we'd have to fix that first
<unmatched-paren>it's also the case for the dub build system
<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>what unmatched-paren says
<unmatched-paren>although i do think guix's gcc should provide a cc symlink
<unmatched-paren>our clang does
<jgart[m]>unmatched-paren: > our clang does
<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
<jgart[m]>regarding clang does
<rekado>yeah, we did discuss it in the past
<rekado>jgart[m]: see the package definition
<unmatched-paren>jgart[m]: ls $(guix build clang)/bin
<jgart[m]>oh k got it
<jgart[m]>How are we thinking about using Guix for rust development?
<unmatched-paren>jgart[m]: that is... somewhat harder
<jgart[m]>It sounds like Guix is mostly being used to just package rust apps
<unmatched-paren>you can't use guix shell for that because cargo is stupid
<lechner>re 'cc' they are different programs. should 'less' provide a symlink to 'more'?
<jgart[m]>why is cargo stupid with guix shell?
<unmatched-paren>you have to just write a package for the library and do ``guix build -f guix.scm''
<jgart[m]>how does the nix community solve cargo?
<jgart[m]>can we learn anything else from nix?
<unmatched-paren>jgart[m]: well, you *could* use it
<unmatched-paren>but cargo would just ignore guix-installed rust libraries
<jgart[m]>can we learn anything additionally from how nix does things?
<unmatched-paren>and download them by itself
<unmatched-paren>i doubt nix's situation will be any better
<jgart[m]>how nix deals with the cargo problem
<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
<jgart[m]>not just package rust apps
<unmatched-paren>cargo is passed an option to use this directory instead of downloading from
<jgart[m]>and why isn't that enough?
<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
<unmatched-paren>you couldn't do the same manually in a shell, at least not easily
<unmatched-paren>it would be *incredibly* tedious
<jgart[m]>what's left to automate?
<unmatched-paren>jgart[m]: everything :)
<jgart[m]>do we have details on the TODOs for that?
<unmatched-paren>there are no TODOs
<jgart[m]>everything is not useful
<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
<jgart[m]>Ok let's focus on cargo
<unmatched-paren>then it iterates through the cargo-inputs and dumps each one's source in the guix-vendor directory
<jgart[m]>> guix-vendor directory
<jgart[m]>ya I've seen that in standard output printing
<jgart[m]>and in /gnu/store
<unmatched-paren>if you wanted to manually build a rust package with guix, you'd need to do all that *by hand*
<unmatched-paren>in fact, it doesn't just drop each cargo-input in that directory
<unmatched-paren>it drops every cargo-input *and their cargo-inputs* in recursivly
<jgart[m]>right the dag
<unmatched-paren>because cargo is evil. :)
<jgart[m]>it drops a dag in the store
<unmatched-paren>it's almost impossible to do this by hand without losing your will to live
<unmatched-paren>which is why you can't build rust packages with a ``guix shell''
<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]>I mean C
<jgart[m]>Ya, basically guix is not useable for go and rust dev work
<jgart[m]>We can just package apps
<unmatched-paren>jgart[m]: Once antioxidant is done, you *will* be able to develop rust packages with guix
<jgart[m]>how so?
<unmatched-paren>i think you'll be able to just use antioxidant like something like meson; probably ``antioxidant build''
<jgart[m]>We're the documentation for antioxidant
<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?
<jgart[m]>Do we have it in a branch?
<jgart[m]>antioxidant branch?
<unmatched-paren>it'll build the libraries as .a files like a good little build system
<unmatched-paren>and be able to actually pick up guix-installed rust packages
<jgart[m]>What are .a files again?
<jgart[m]>Something standard?
<lechner>ar of .o
<jgart[m]>that rust decided not to do
<unmatched-paren>archive files stuffed with a bunch of .o files
<unmatched-paren>they're used as static libraries
<jgart[m]>oh k
<unmatched-paren>in c
<jgart[m]>Why static libs?
<jgart[m]>antioxidant produces static rust libs?
<jgart[m]>or why static?
<mekeor[m]>oriansj: what r u referring to?
<jgart[m]>and not dynamic
<unmatched-paren>you'll have to ask anti pode (who is currently on a hiatus)
<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?
<jgart[m]>why is antipode on break?
<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?
<mekeor[m]>jgart: ask themselves if you feel the need
<unmatched-paren>PotentialUser-63: you shouldn't need to add binutils to any inputs
<PotentialUser-63>lechner: no, should I?
<unmatched-paren>jgart[m]: dunno
<lechner>PotentialUser-63 / also, did you use shell --development
<mekeor[m]>afaik, we dont know the reason so far
<lechner>PotentialUser-63 / not sure, you probably want to listen to unmatched-paren
<unmatched-paren>please do not unquestioningly listen to unmatched-paren
<oriansj>or anyone else here
<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
<jgart[m]>except for jgart
<jgart[m]>haha jk
<unmatched-paren> <- ooooooh interesting emacs package
<oriansj>and never trust oriansj's work, he could be evil and compromising the root of trust for everything silently
<jgart[m]>unmatched-paren: sounds like
<unmatched-paren>oriansj: Except maybe ludo, as they presumably know what they're talking about if they're advising you on guix.
<jgart[m]>and wingo
<jgart[m]>The BHFL
<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?
<jgart[m]>Benevolent hacker for life
<lechner>There are problems everywhere. Guix will develop a broad appeal in the near future
<jgart[m]>that we all can't keep up with
<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>i'd definitely review it for you
<PotentialUser-63>guix import go was a dead-end. Somehow the hugo repo is not correctly configure, see here:
<unmatched-paren>on a... somewhat related note, I only need one more commit access vouch; any non-maintainer committers around at the moment? :)
<jgart[m]>erlang importer could be improved
<unmatched-paren>Oh, only one blocking issue left for 1.4.0!
<rekado>jgart[m]: I encourage you to specify *how* it could be improved and come up with steps to get there.
<rekado>it’s how we do things here
<unmatched-paren>"LibreOffice fails to build on i686-linux"
<mekeor[m]>unmatched-paren: which one? :D
<jgart[m]>what is 1.4.0?
<unmatched-paren>jgart[m]: next release
<jgart[m]>rekado: Ya, I know. I will soon don't worry
<unmatched-paren>jgart[m]: i don't think meow is the same as modalka
<jgart[m]>I have it on my TODO list
<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?
<jgart[m]>what is modalka instead?
<jgart[m]>or in contrast?
<jgart[m]>in contrast to meow
<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
<unmatched-paren>lechner: samurai is a pure-C replacement for ninja
<jgart[m]>I'd use meow over evil if someone had a good vim config for it
<lechner>unmatched-paren / thanks!
<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.
<mekeor[m]>ACTION is planning on remapping whole emacs
<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.
<jgart[m]>unmatched-paren: I tried once:
<unmatched-paren>jgart[m]: i think the whole point is it *isn't* a vim-clone config
<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
<jgart[m]>to make a vim clone, that is
<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
<rekado>ld-gold-wrapper maybe?
<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?
<unmatched-paren>minima: sway doesn't need to be included in a system config
<unmatched-paren>well, swaylock needs to be setuid
<unmatched-paren>but sway doesn't so long as you have elogind or seatd
<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 :)
<unmatched-paren>minima: you might already have elogind though
<minima>oh, ok
<unmatched-paren>oh, if it's failing to launch then you probably don't...
<unmatched-paren>minima: elogind is included in %desktop-services
<minima>ah, yeah, i think i nuked desktop-services at some point... time to put that back in :)
<unmatched-paren>minima: you don't need to
<unmatched-paren>you can just add seatd or elogind manually
<unmatched-paren>seatd is more minimal, but a few things will not work on it
<unmatched-paren>network-manager, upower, and anything else that requires polkit
<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?
<unmatched-paren>minima: possibly the "seat" group
<minima>super, thank you! let me try that then
<unmatched-paren>rekado: <- the first answer here might be relevant, maybe?
<lechner>unmatched-paren / guix shell: error: muon: unknown package and also guix shell: error: samurai: unknown package
<unmatched-paren>lechner: yeah, they're not packaged in guix yet
<Fare>How do I add a substitute server before I bootstrap guix? I was told about, but how do I convince guix it doesn't need to fully bootstrap rust before it starts using it?
<unmatched-paren>Fare: What do you mean "before you bootstrap Guix"? :)
<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...
<unmatched-paren>Fare: Ah. Maybe try ``guix system reconfigure --substitute-urls=""''.
<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>apteryx: or greetd
<apteryx>haven't tried that one yet
<unmatched-paren>Fare: you need to replace %desktop-services with %base-services to remove the GNOME/X stuff
<unmatched-paren>though it'll also remove things like elogind and network-manager
<lechner>greetd works great, but not with a FUSE-mounted home yet
<lechner>i love it
<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)
<unmatched-paren>rekado: Argh. The build fails with lld.
<Fare>apteryx, thanks a lot. How do I add xorg without GNOME?
<unmatched-paren>Fare: just remove gdm
<unmatched-paren>it'll keep x
<Fare>can I modify %desktop-services into removing gdm or replacing it by something more lightweight?
<unmatched-paren>Fare: You need to use (modify-services ...)
<unmatched-paren>(modify-services %desktop-services (delete gdm-service-type))
<unmatched-paren>and then just (cons* ...) (service some-service-type ...)
<unmatched-paren>onto the services list
<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
<unmatched-paren>PotentialUser-30: You must use pre-inst-env
<jgart[m]>unmatched-paren: how about cproc and gcc?
<jgart[m]>could we configure that via keywords?
<unmatched-paren>``./bootstrap && ./configure --localstatedir=/var && make -j$(nproc)''
<PotentialUser-30>OK. I got errors with it - so i think i have to solve them...
<unmatched-paren>PotentialUser-30: do that ^
<lechner>PotentialUser-30 / which error?
<unmatched-paren>then use pre-inst-env
<unmatched-paren>jgart[m]: it's unlikely that most packages would work with cproc
<unmatched-paren>as it implements only a small subset of C and a much smaller CLI
<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?
<PotentialUser-30>Whats the purpose of the --localstatedir ??
<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
<jgart[m]>You can build CPython with cproc
<jgart[m]>and all of these packages:
<unmatched-paren>Fare: hmm... i'm not sure how to do that, sorry :(
<PotentialUser-30>I get 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''
<unmatched-paren>jgart[m]: -.o.-
<unmatched-paren>it Just Is
<jgart[m]>I've been like -.o.- also for about 2 years or so
<unmatched-paren>i've been like -.o.- for my whole life, so :)
<jgart[m]>rekado: do you know?
<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?
<unmatched-paren>or, rather, why is /var not set as default?
<jgart[m]>some Guix veteran will tell us maybe
<unmatched-paren>PotentialUser-30: No.
<unmatched-paren>What are the errors?
<jgart[m]>I'm going to email RMS to ask him whats the purpose of the --localstatedir in that command
<unmatched-paren>jgart[m]: i don't think rms will know
<unmatched-paren>rms is not directly involved with guix
<jgart[m]>Maybe he knows
<Fare>Could not find build log for '/gnu/store/psb8yyl8685ncqaqcm9kj4bz4v2dd8q5-linux-modules.drv'. ==> how do I debug that?
<unmatched-paren>and they don't do programming anymore iirc
<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
<unmatched-paren>PotentialUser-30: please put the full error on
<apteryx>jgart[m]: please don't email random people with random questions
<PotentialUser-30>Is there kind of "make clean"  possibility ?
<unmatched-paren>jgart[m]: you should probably ask on help-guix
<lechner>PotentialUser-30 / yes
<unmatched-paren>PotentialUser-30: maybe...
<jgart[m]>I'm curious what RMS thinks of Guix. Would be surprising if we get a [PATCH] gnu: emacs-next: Update to from RMS one day in mumi
<unmatched-paren>jgart[m]: now *that* is *incredibly* unlikely. :)
<lechner>we really want the one that says "change name to GNU OS"
<jgart[m]>never say never
<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 ??
<unmatched-paren>PotentialUser-30: yes
<lechner>PotentialUser-30 / i would also reclone
<unmatched-paren>make -j$(nproc) will speed it up a *lot*
<nikolar>Gnu is already an os
<unmatched-paren>lechner: that's not necessary
<nikolar>The name that is
<PotentialUser-30>Is shallow clone sufficient? I would think yes??
<unmatched-paren>PotentialUser-30: yes, but don't
<unmatched-paren>because you'll probably need to look at the logs or bisect at some point
<lechner>unmatched-paren / "Permission denied"?
<jgart[m]>GNU is a community
<PotentialUser-30>So let's clone again :-)
<jgart[m]>* jgart sheds a tear
<unmatched-paren>lechner: Hmm, yeah, maybe you're right...
<unmatched-paren>I have no idea -.o.-
<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
<apteryx>s/we should/use/
<lechner>maybe GNU is not yet an OS
<jgart[m]>thanks apteryx RMS replied and told me to RTFM and gave me the same info CLI invocation
<jgart[m]>reading it now
<unmatched-paren>Whoa, that was quick.
<apteryx>no way they could reach out that timely
<jgart[m]>You did
<jgart[m]>Why do you think RMS couldn't also?
<jgart[m]>They are human too
<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...
<lechner>just follow the docs
<jgart[m]>RMS uses email like irc
<unmatched-paren>PotentialUser-30: it is
<jgart[m]>I wish info '(standards) Directory Variables' was a online video series
<apteryx>jgart[m]: there's also #gnu
<unmatched-paren>PotentialUser-30: you are reading the release manual, which is decrepit
<jgart[m]>Oh I haven't joined that channel
<unmatched-paren>guix environment is deprecated now
<lechner>PotentialUser-30 /
<lechner>it works either way
<PotentialUser-30>OK. So the "devel" ones are more recent / better ?
<jgart[m]>it's deprecated but you can still call it?
<jgart[m]>it's aliased to guix shell iirc
<unmatched-paren>jgart[m]: well, yeah, that's the whole point of deprecation
<jgart[m]>makes sense
<unmatched-paren>jgart[m]: a state of deprecation where you can't use it anymore is called "removal" :)
<lechner>or abandonment
<jgart[m]>makes sense too
<unmatched-paren>lechner: that's where it's deprecated and when you use it it spits out an inscrutiable error :P
<PotentialUser-30>With the full clone  guix git authenticate now also works :-)
<unmatched-paren>PotentialUser-30: sooo, just ``guix shell -D guix --pure''
<unmatched-paren>and then do that thing
<unmatched-paren>and then you can exit the shell and run ``./pre-inst-env guix ...''
<lechner>i am supposed to exit the shell?
<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
<PotentialUser-30>But it looks like its checking the 44884 new commits somehow...
<iska>I'm having issues with doing go stuff, can anyone help?
<iska>package no Go files in /tmp/guix-build-go-golang-org-x-exp-0.0.0-20221114191408-850992195362.drv-0/src/
<lechner>iska / make it a "source-only" package
<iska>this is needed to update ipfs, almost a year out of date
<iska>lechner wym and how?
<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>I dont think so. But who know...
<lechner>you are on a "foreign" distro?
<PotentialUser-30>Retry - Reboot - Reinstall ? ;-)
<lechner>are you using Guix System?
<PotentialUser-30>Yes. I'm in GENTOO. But all the things i need (guix pack) are working quite well !!
<lechner>for how long?
<PotentialUser-30>So no Guix System !
<PotentialUser-30>how long GENTOO or GUIX ?
<lechner>working well
<PotentialUser-30>I just tried guix pack mutt and it seems like it works
<lechner>how and when did you install Guix?
<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...
<lechner>which is the manual way, please?
<PotentialUser-30>I'm not absolutely sure but i think i did
<PotentialUser-30>(I'll check)
<oriansj>the manual procedure for just guix on a foriegn distro is: and for the manual procedure for guix system is:
<gnucode>happy thanksgiving!
<lechner>happy turkey day!
<lechner>or turducken!
<gnucode>lechner: I was telling people at work that today is national hig a turkey day. (I'm vegan). :)
<lechner>there is vegan gravy, i hope!
<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>or always pardon the turkey
<PotentialUser-30>They have a package in an overlay... Perhaps i should give it a try...
<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
<lechner>just make sure you have IRC!
<PotentialUser-30>In the GENTOO ebuild in src_install( ... they have some permissions - perhaps i should check them  first...
<PotentialUser-30>So it has to be: fperms 1777 /var/guix/profiles/per-user ???
<PotentialUser-30>I have: drwxr-xr-x 5 root root 4096 31. Okt 16:40 per-user
<PotentialUser-30>Thats now right. The 1 in 1777 is some sticky bit?
<lechner>i don't have sticky
<lechner>i have what you have
<PotentialUser-30>So what are the right permissions for /var/guix/profiles/per-user ??
<lechner>755 i think, but you are digging to deep and touching too much
<lechner>too deep
<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
<jgart[m]>We can run texinfo on these thanksgiving recipes and "lower" them into the store:
<jgart[m]>oriansj: amen
<unmatched-paren>jgart[m]: A recipe for building recipes. It's recipes all the way down!
<oriansj>and if you are more familiar with gentoo; you can see that the procedure listed here: would result in the same system. so that you can build a nice mental mapping
<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
<jgart[m]>Oh yeah
<jgart[m]>I agree
<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
<jgart[m]>charje is working on `guix provides`
<iska>ipfs-go (aka kubo) is failing to build, seemingly from a bundled library we can't remove
<unmatched-paren>jgart[m]: what would that do?
<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/ 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
<unmatched-paren>they were added pretty recently
<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
<unmatched-paren>iska: that would cause a lot of rebuilds
<jgart[m]>iska: go for it in core-updates?
<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)
<PotentialUser-30>Hurrayyyy :-)
<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]>microcosm of my life
<jgart[m]>Are people interested in having a meetup over jitsi with Dale Mellor?
<jgart[m]>Given he accepts the invite
<jgart[m]>Dale wrote mcron
<jgart[m]>Dale accepts bitcoin donations for mcron here:
<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
<apteryx>only from magit... weird
<jgart[m]>Would like to try pkgsrc on Guix System
<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
<apteryx>I poked the tech team in #savannah
<unmatched-paren>Hm. Now I get a 443 Forbidden from
<unmatched-paren>Aha, no longer.
<jgart[m]>How can we fix docstring support in guile macros and other objects?
<unmatched-paren>oriansj, jgart[m]: i posted a proposal for package feature flags here:
<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'd be happy to experiment with the API
<jgart[m]>and contribute where I can
<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]>scheme@(guile-user)> ,d cute
<jgart[m]>While executing meta-command:
<jgart[m]>Syntax error:
<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]>triggering a ton of rust to get built?
<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
<jgart[m]>blows my mind and my cpu
<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
<jgart[m]>No rust deps in that output
<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
<unmatched-paren>jgart[m]: i'm not sure it'd be possible to include it in guixrus
<unmatched-paren>given that it requires changes to the core of guix
<jgart[m]>I just ran the above command to build emacs-carp in my guix checkout
<rekado>look at the derivations
<jgart[m]>I expect to just build emacs-carp from running ./pre-inst-env guix build emacs-carp
<jgart[m]>But that's not what happens
<rekado>show us the derivations then
<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>of course there’s a derivation
<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
<jgart[m]>Or something else?
<rekado> -d, --derivations return the derivation paths of the given packages
<rekado>see “guix build --help”
<rekado>it’s the fifth option there; can’t miss it.
<jgart[m]>Ya, I'm running it
<rekado>(where did you get “--list-derivation” from? It’s not mentioned anywhere in the help output or the manual.)
<jgart[m]>with -d
<jgart[m]>rust stuff building again
<jgart[m]>I made it up to give an example
<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]>right now it is doing a ton of these:
<jgart[m]>patch-cargo-checksums: generate-checksums for vendor/jsonrpc-core-client
<jgart[m]>that phase
<rekado>please show us how to reproduce this
<jgart[m]>not sure what it is trying to build
<rekado>we don’t have enough information
<jgart[m]>can't make out the dag
<rekado>obviously it’s building rust stuff
<rekado>but that’s not the point
<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]>Building mrustc...
<jgart[m]>guix-shell ./pre-inst-env guix build emacs-carp -d --dry-run
<jgart[m]>running the above
<jgart[m]>Do you want the contents of each of those drv files?
<jgart[m]>because emacs is a dependency
<rekado>emacs –> gtk –> librsvg –> rust
<jgart[m]>and emacs has rust
<jgart[m]>saw that now
<jgart[m]>now I see why adding rust to emacs was a mistake
<jgart[m]>I thought that wasn't going to affect me
<unmatched-paren>emacs doesn't have rust...
<jgart[m]>but gtk does
<jgart[m]>and emacs has gtk
<unmatched-paren>mhm, which is good :)
<jgart[m]>ya but emacs-build-system uses gtk emacs with rust?
<jgart[m]>so hence my experience above?
<unmatched-paren>iiuc there is no non-gtk emacs
<jgart[m]>can I switch out the emacs implicitly used in emacs-build-system globally?
<unmatched-paren>there is emacs without pgtk, but that still uses some pgtk
<rekado>no, it should use emacs-minimal
<rekado>see (guix build-system emacs)
<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>please inspect the derivations
<rekado>emacs-s has emacs as an input
<rekado>not emacs-minimal
<rekado>#:emacs ,emacs ; FIXME: tests fail with emacs-minimal
<jgart[m]>ya that's it
<unmatched-paren>jgart[m]: surely, though, you should already have rust, gtk, etc installed because you have emacs installed?
<jgart[m]>so we need to fix that first
<jgart[m]>I do
<unmatched-paren>so i don't understand why it's building it
<jgart[m]>yup I don't understand either
<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]>about what I'm experiencing
<jgart[m]>we found one problem thanks to rekado spotting that
<jgart[m]>rekado: cool
<jgart[m]>so we should update emacs-s?
<unmatched-paren>jgart[m]: i guess you should change that in a separate commit and send a multi-patch set
<jgart[m]>rekado: can you push that commit?
<unmatched-paren>jgart[m]: they probably used --with-input
<jgart[m]>should we remove all non emacs-minimal usages?
<jgart[m]>in emacs packages?
<unmatched-paren>jgart[m]: like this:
<jgart[m]>unmatched-paren: like this?
<jgart[m]>is anybody able to review that btw? ;()
<unmatched-paren>jgart[m]: like that manual page says :)
<jgart[m]>before it gets rusty...
<rekado>jgart[m]: I pushed it
<rekado>jgart[m]: unfortunately, your patch set above has wrong commit messages
<rekado>for example:
<rekado>“Add rust-textwrap-0.16.”
<rekado>but it actually adds +(define-public rust-linux-raw-sys-0.0.46
<unmatched-paren>that one seems to add two packages at once
<jgart[m]>etc/committer.scm bug?
<unmatched-paren>same for #9
<unmatched-paren>i think it might be best to do this committing stuff with magit
<jgart[m]>I haven't been using magit
<rekado>here too
<jgart[m]>just tig
<rekado>etc/committer.scm is for automating mass updates
<jgart[m]>ya not sure how that happened
<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
<jgart[m]>I guess not from 59389
<unmatched-paren>so i find it quite useful for committing guix packages
<rekado>the script’s top comment says: This script stages and commits changes to package definitions.
<jgart[m]>tig has the same
<jgart[m]>or git commit -p
<jgart[m]>but tig is more like magit
<jgart[m]>still tedious when packaging rust
<unmatched-paren>git commit -p stages code hunk-by-hunk, not line-by-line :)
<unmatched-paren>yeah, rust/go/... packaging will always be tedious
<unmatched-paren>even with antioxidant, there'll still be quite a lot of packages
<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
<jgart[m]>but that might have been a chance event
<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]>And to do package sorting
<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
<rekado>would you like to fix it?
<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
<jgart[m]>you mean my pastel ticket that is open?
<jgart[m]>or something else?
<rekado>a fix to etc/
<rekado>to prevent it from doing what it did to your pastel diff
<unmatched-paren>there are no directed acrylic graphs here, jgart[m] :)
<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]>maybe not dags
<unmatched-paren>i... don't think it would?
<jgart[m]>I've discussed it on the ML with someone who almost had it working
<unmatched-paren>it's just sorting stuff
<jgart[m]>How do you sort Guix packages?
<jgart[m]>in a module
<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>Okay then. I stand corrected. :)
<jgart[m]>Unless Csepp is incorrect
<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.
<jgart[m]>I know less than -1
<rekado>so you need a topological sort
<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
<unmatched-paren>ACTION shudders at
<jgart[m]>The sorting is just a convention
<jgart[m]>A nicety
<rekado>unmatched-paren: this is about sorting *commits*, not definitions inside a file
<unmatched-paren>rekado: Ahh.
<unmatched-paren>That makes a lot more sense.
<unmatched-paren>Thanks :)
<rekado>to modify the insertion location with etc/committer.scm doesn’t make any sense
<unmatched-paren>yeah, that sounds like a job for guix style
<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]>Can you point them out?
<jgart[m]>I don't think I'd identify them unless it would be pointed out but it would be useful to know
<rekado>grep topo -r guix
<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]>found em
<jgart[m]>didn't realize they were called that
<jgart[m]>thought it was just a pattern or feature
<rekado>that one is less useful because it operates on the store
<jgart[m]>implementation detail
<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.
<jgart[m]>butcool TIL
<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
<jgart[m]>> make git diff print the right thing
<jgart[m]>got it
<jgart[m]>is there a bug report for this bug yet?
<jgart[m]>Can we define an AC?
<jgart[m]>Acceptance Criteria
<rekado>the problem is likely in diff-info, which slurps up too much in the case of additions
<jgart[m]>Expected result
<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>it runs “git diff-files … gnu”
<rekado>and then reads diff hunks from the output
<jgart[m]>But an example of the bug is in my pastel ticket commit messages?
<jgart[m]>I'll look again soon
<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
<jgart[m]>I have to play with it a bit
<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>FWIW I cannot reproduce it.
<rekado>here’s what I did:
<rekado>wget -O- | git apply
<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>don’t know
<jgart[m]>Or emacs-debbugs makes it irrelevant?
<jgart[m]>let me try wget -O- | git apply
<jgart[m]>in a branch
<jgart[m]>git checkout -b c
<jgart[m]>Switched to a new branch 'c'
<jgart[m]>looks like that patch set does not apply anymore
<rekado>it applies fine for me on commit 5f8c11d48e4949aa77d7aaa1e7e25568bd8dfa97
<jgart[m]>oh ok let me try
<jgart[m]>Ok it applied
<jgart[m]>looking at git diff
<jgart[m]>I see rust-io-lifetimes-0.7 and rust-terminal-size-0.2
<jgart[m]>etc/committer.scm committed them perfectly
<jgart[m]>as two separate packages
<jgart[m]>correct names line up with the commit
<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 😁
<jgart[m]>there's a buggy one
<jgart[m]>according to the docstring
<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`?
<lechner>a12l / you may wish to employ sneek
<lechner>sneek: botsnack
<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
<unmatched-paren>a12l: yeah, i think so
<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
<lechner>unmatched-paren / thanks!
<unmatched-paren>ACTION away, night \o
<a12l>Thanks, and have some nice sleep!
<a12l>lechner: And I'll remember sneek :)
<lechner>maybe you can feed him tonight