IRC channel logs
2025-07-24.log
back to list of logs
<nomike>If there is another process to follow, I'd gladly do that. Or I can also just wait, if that's the best way forward. I just don't want this to be forgotten. <ekaitz>nomike: i don't think the commit message has the proper formatting <ekaitz>i'd say we have some text width limitation <ekaitz>and I'd like to have more context in the first commit <ekaitz>you are passing the variable through the keywords i guess <Kolev>Running `guix pull` today. Hope it works this time. <nomike>ekaitz: It started with 0559a4b547 where someone else removed the default values for a few arguments to the build phase of the guile-build-system. It took me a few iterations to have a proper fix. One of the parameters to the build phase is a regex. In the build-system module was a define with that regex. <ekaitz>nomike: don't tell me, say it in the commits <ekaitz>that's what I think we should do more in guix in general <nomike>But that's what the comment already says: "Provide explicit values to #:compile-flags, #:parallel-build, #:scheme-file-regex and #:not-compiled-file-regexp when calling `build of the guile-build-system as those parameters do no longer have default values." <jnms>I don't use pull anymore tbh. Just reconfigure with the latest "gnu: guix: ..." commit once in a while. I do wish there was another way to get the news pretty-printed. <nomike>Ahhh...now I got you. The first commit doesn't say why that variable was exported. And that's what you want to fix, right? <ekaitz>yes, but don't pay me too much attention, it's late and I should go to bed <ekaitz>also I have the weird habit of reading the commit messages, like expecting they tell me something about the context of the changes <nomike>BTW: What specifically do you mean about the comments not being formatted properly? I've looked ad several other commits who all had a similar structure. I've used autofill-mode to ensure there are not too many columns, what am I missing? <ekaitz>nomike: i'd say you are not wrapping text <ekaitz>if you git log in a large terminal you'll see how your commits don't wrap and others do <Kolev>Sometimes, getting Lisp to fit in the 70 char limit is hard. <ekaitz>Kolev: in this case I'm talking about the commit messages <Kolev>I was going to ask, what tricks do people do to keep within the column limit? <vagrantc>people do hideous things with string-append ... but rather than improving readability on machines with limited width, it makes it harder to read on all terminals... <nomike>What is the point behind this 80 column limit? I guess no-one uses an 80 column screen anymore nowadays, and that's where that came from. And modern editors can do line-wrapping properly anyway. <nomike>I'm arguing against it, I just want to understand the reasoning behind it. <vagrantc>with other languages, i find if you are nested that deeply, you are probably doing something wrong ... not sure that is the case with guile <nomike>ekaitz, and you're right. I did not wrap those lines properly in the commit. I could have sworn....but maybe I did it for another patch...damn you ADHD. <nomike>I will fix those comments right away. <nomike>I just force pushed two new commits with improved commit messages. <Kolev>nomike, I am trigger-happy with M-q. <ieure>Kolev, Guile-mode kind of sucks and M-q breaks comments. :( <Kolev>How long should a pull take? <ieure>Kolev, Depends on how long it's been since you last pulled. ~20 minutes if it's been a while. <noe>ieure, really? its never happened to me <nomike>For me it usually takes ~20-30 minutes. <ieure>noe, Happens to me alllll the time. Maybe Emacs 30 is better about it? <ieure>Haven't spent that much time with it. <noe>just tried it with some M-x spook and its working well indeed <Kolev>All I see is 'substitute:' and no loading. <noe>Kolev, that happens to me too but usually you get more output later <noe>if it stays there, I guess you can try changing substitute servers, or disabling substitutes for the pull <attila_lendvai>if i don't feel like using the gdb comman line, then what options do i have on guix? any usable gui frontends packaged? <noe>attila_lendvai, “guix search gdb gui” shows the seer-gdb package <nomike>Kolev, oh..nice. thanks for the tip. Didn't know that exists. <Kolev>Pull finished. Installing some packages now. <apteryx>alright, the guix-devel list should be back into a more real-time discussion <apteryx>(it had been placed on emergency mode by someone, probably forgotten so *every* mail had to go through moderation) <robin>lol, "why doesn't pharo use its rpath?" -> the smalltalk ffi library explicitly looks at LD_LIBRARY_PATH <podiki>rpath, ffi, ld_library_path...now that's a combination <robin>libdl has something to examine the program's own elf sections and i don't want to think about exporting that to smalltalk <robin>pharo wins, it's wrap-program time <mfg>Hey, i noticed that after the core-tema merge guile segfaults while booting, but the boot process continues anyways. I neither know how to debug, nor if this might have negative consequences. <mfg>Has anyone else the same problem? <hako>Is "manual merge" disabled in the Codeberg repository? <mfg>A second problem i have on /some/ of my machines is guix still sometimes hanging while reconfiguring (doesn't matter if home or system reconfigure). Sometimes this seems to lead to broken store items, one of my machines currently does not boot anymore since i reconfigured and experienced that issue. I also feel like i can reproduce these hangs better on modern hardware with many cores. <mfg>paste.debian.net is the correct URL, no? <mfg>that's all the info i get, which isn't much <Deltafire>mfg: i've got that segfault on boot also, as do a few others that mentioned it in here yesterday <apteryx>I wonder why 'guix build -P1 some-package' appears to take much longer to compute than 'guix refresh -l some-package' <podiki>hako: i didn't see the "manual merge" button appear yesterday when i pushed something, but have seen it before; not sure how finicky it is <Kolev>tmux: invalid LC_ALL, LC_CTYPE or LANG <sibl>when making an image with "guix system image", I see there isnt the "cow-store" service on it, is there a way to install it ? <sham1>IIRC cow-store is a very specific service for the installation-os <Kolev>Can a foreign distro with Guix package manager install Guix onto a blank hard drive? <Kolev>But I can't do herd cow-store <podiki>you can just "guix system init" and i've done that, easiest way to "install" as it just writes the image <podiki>you don't need cow store then, you are just writing to that disk directly <Kolev>So all you do is partition the disk and system init. <podiki>basically, just writing a system configuration to a different disk, just make sure you have the write disk labels/uuids in the config <sham1>cow-store is needed on the install ISOs because that puts you into an ramdisk, which is not a problem if you're on a foreign distro <podiki>i have some notes when i did this for a home server, let me check if there was anything else <Kolev>podiki, having a full system to do the installation from would be great. <podiki>you can create a vm image of the config as well to try it live <podiki>but yeah, it is the easiest, no need for the installer (you can also find the installer starting configs in the git repo) <podiki>correct on the install from a guix already running: partition (probably the trickiest part, make sure you get boot right), correct file systems in config, then "guix system init" to that disk <Kolev>I added Jellyfin and elogind to my system and now locales are all messed up. Can't launch tmux. Invalid LC_ALL LC_CTYPE LANG <podiki>have you done a reboot in last few days? post core-updates merge? <Kolev>podiki, I reboot every time I reconfigure. <Kolev>Should I do a guix pull and reconfigure? <podiki>sorry, out of ideas then. i'm not a tmux user but it does run here (zsh, foot terminal) <podiki>what commit are you on currently? or from when rather <Kolev>podiki, OK, I'll do that when I get home. <podiki>it will give build (reconfigure?) date and commits <Kolev>podiki, I have a thread about this on the mailing list. <podiki>that's good. i do recall similar things popping up last time there were some glibc updates or something like that <podiki>hopefully someone knows already! <podiki>other steps to try: from guix shell --pure, or guix time-machine if you have some idea of commit that worked <podiki>i did get some wrong terminal output when working from a local guix checkout that was post-merge while my system was pre-merge, but not that same message <podiki>reporting the commits of the generations that did/did not work will help in that thread <Kolev>podiki, will system describe show the info for the initial generation too? <podiki>use "guix system list-generations" to show all <gabber>if somebody could approve PR #1550 i think i could (finally) update my home configuration (: <Kabouik>Just curious, the recent issues with guix upgrades made me uninstall all r-* packages from my profile, and I'm thinking it's a good opportunity to start embracing the manifest.scm approach for my R analyses. How do you typically do that if you live within Emacs for browsing to the relevant folder and open the .R files in ESS? <Kabouik>I guess one way would be to use .org files with a shell snippet at the top to guix time-machine, and then org-babel R snippets, instead of just a R file? <cdegroot>Not specifically for your problem, but generally I use direnv. Emacs has excellent support and generally will do "the right thing", reading and executing the .envrc and then using that as the environment for that particular project. <cdegroot>If you just put `use guix` in an .envrc file, then I think manifest.scm will be picked up and The Right Thing™ will happen. <Kabouik>Ideally I would want something that doesn't need specific configurations and can be re-used by someone else who does not use Emacs (let alone my init.el), but maybe that's difficult to achieve <Kabouik>I'll investigate your suggestion, I've never used that. <identity>Kabouik: direnv has shell plugins and plugins for other editors, just make sure that if you are version-controling it, that the .envrc file is .ignore'd and provide .envrc.default (or similarly named) file and tell people to cp .envrc.default .envrc if they want to use it, otherwise anybody opening your repository will be prompted for whether to use the .envrc even if they just wanted to look at the code from a local checkout <Kabouik>Would a prompt to open the .envrc (or decline) not be better than adding a manual cp step for those who want to reproduce the work? <identity>Kabouik: what do you when you need to add more to the .envrc file, something specific to your setup for example? it is version-controled, so you can not do much about it without making a mess <Kabouik>I see, maybe I don't see well what the .envrc file will end up looking like because I've never used them and I don't know the exact capabilities/purposes <Kabouik>I was going to try cdegroot's suggestion to just add `use guix` <identity>Kabouik: direnv has support for stuff like ‘use nix’ and ‘use guix’, but it can also set environment variables, which was/is its primary purpose <mgd>Hello. I've built a really simple program made up of a main.scm, packages.scm and manifests.scm. Once I create the env with `guix shell -m manifests.scm` is there a way to see what has been installed in that environment? <identity>mgd: ‘guix build -m manifests.scm’ outputs the shell's profile, which you can then inspect with commands like ‘size’ (outputs all the packages in the profile and the size of their outputs) and ‘graph’ (outputs a graph of the profile that you can visualize with xdot or similar) <Kabouik>I'll give it a go identity. I have yet to really understand how to make ESS take it into account and run time-machine/shell before executing R, unless I misunderstood the tool. <Deltafire>any idea why "flatpak list" and "flatpak remotes" are showing nothing, when i definitely already have flatpaks installed?