IRC channel logs
2025-07-22.log
back to list of logs
<podiki>as far as i see graphite/isl is enabled from an older version (4.8) already <andreas-e>podiki: Good if you have the occasion of updating hypr* for removing the gcc-14, otherwise I suppose we would forget it and wonder in a few years why they are there... <podiki>i'll do it as part of updating the packages this week, yes <podiki>on the darktable side, stumped by this isl error <andreas-e>Is this not a package name? Maybe try to add it? <podiki>it is something gcc should be doing already, maybe some build options needed now with gcc-14? <andreas-e>I have just tried darktable, and it fails halfway through with this error message: <andreas-e>ld: /gnu/store/2mjyr379plg16nsr8rwrc8sr3an6n2iq-openexr-3.2.4/lib/libIlmThread-3_2.so.31.3.2.4: undefined reference to `__cxa_call_terminate@CXXABI_1.3.15' <podiki>yeah, that is with gcc-13 (my guess because everything else is with gcc-14 now) <podiki>well now it works, with gcc-14 explicit, let me double check i'm not going crazy here <andreas-e>I just looked it up, yes, that is openexr with gcc-14 and darktable still with gcc-13. Sorry! <podiki>oh, does cmake-build-system and with llvm specified do something different here for gcc? <podiki>yeah, need to explicitly say gcc-14 in native-inputs <podiki>but configure does say it finds /gnu/store/jb4szkjkmlqdc92nnhxvm9ypq6hvk9vw-gcc-14.3.0/ <podiki>different hash here when specifying gcc-14 <andreas-e>You could have a look at the derivation. But I am not surprised, the implicit and explicit inputs probably appear in different places/ <podiki>the hash for gcc-14 specified corresponds to what i get with a guix shell gcc-toolchain@14 <podiki>sure, different hash, but what is going on with why one doesn't have this isl graphite support? <podiki>(i would have said something something "grafts" but no more grafts right?) <andreas-e>We have not ungrafted the branch, unfortunately. Well, enough breakage in one branch... <andreas-e>But we need to ungraft; which would require us to take a break with other updates. <podiki>i just blame mysterious things like this on grafts <andreas-e>Should this make a difference? Normally not. <andreas-e>On my side, I have been successful as well and updated a Nintendo Wii emulator. I have never touched a Wii, I think :) <podiki>maybe some reference in gcc to the isl/cloog? and then is not grafted properly/lost in a graft? <podiki>i guess for now i can put some "XXX" comment in darktable about actually needing explicit gcc specified due to this error <podiki>"XXX: Need to explicitly specify gcc-14 here or else the build fails with missing Graphite/isl support in gcc for unknown reasons." <andreas-e>Sounds good. Written down mysterious are already half elucidated. <podiki>with a comment in commit log with more info (previous failure); will push after dinner and after i check if there are more failures in my manifests <eikcaz`>It seems like the build servers build fast enough, but struggle with network bandwidth to provide substitutes. Thinking about solutions, it seems like mirrors are an easy way address the problem. Or am I missing something? <umanwizard>is there any good way to start investigating questions like: "why does my desktop reconfigure require qtdeclarative to be built" <AidenIsik>A few questions: if I have written a package which depends on a specific version of a dependency which is currently the main one, should I still create a versioned version of that package (the package in question is icu4c 73, latest is icu4c-76) <AidenIsik>And if I'm modifying several packages to fix them building as they are dependencies for one specific package, should I create seperate pull requests for each one, waiting until all dependencies are merged before creating a PR for the main package, or just put it all in one PR? <AidenIsik_>I'm working on updating 0AD, currently I have updated/fixed premake 5.0.0-beta7 and mozjs 155.26.0 <meaty>AidenIsik_: I would put them all in the same PR. If the packages you're fixing are broken outright (not just in the context of 0ad) then maybe copy the fixes to other PRs if your 0ad PR is taking a long time <meaty>What email clients does everyone use? I tried claws before and it was janky wrt imap connections, etc; right now I use icedove but I'm sensing it's dated and it carries around all the mozilla "what were they thinking"-isms, like having no way to control quoting in messages <meaty>I still have to deal with the html-email normie world every once in a while, so I don't want to switch to mutt or emacs or w/e <Kolev>meaty, I use Evolution currently. I'd like to switch to Notmuch. <meaty>The name org.gnome.evolution.dataserver.Sources5 was not provided by any .service files <meaty>Kolev: does it work outside of GNOME? I'm giving it a whirl with guix shell and the setup wizard stops at "The name org.gnome.evolution.dataserver.Sources5 was not provided by any .service files <meaty>ACTION shakes fist at systemd <Kolev>meaty, hm... I didn't know that. <meaty>Kolev: yeah, seems I can't add an account 'cos it expects the evolution database systemd service to be running? how are you doing it? <Kolev>meaty, I'm not on Guix on my PC. <Kolev>I'm not brave enough to port my laptop to Guix System. <meaty>hmm... adding evolution-data-server to the shell doesn't help either <Kolev>meaty, if you figure out Evolution on System, email me. csh@bluehome.net <apteryx>I think one of the reason libgit2 is slow is that is validates correctness of every object, which the git CLI doesn't do IIRC <apteryx>that's configurable, so we could review whether the tradeoffs are worth it for our use cases <AidenIsik>meaty: just saw your message in the logs, I must have been disconnected when you sent it (my IRC has been really flaky recently) <AidenIsik>So yeah premake5 is completely broken, however mozjs is fine <AidenIsik>Just needed to specify an older version for 0ad <AidenIsik>So one PR for premake5, and another for 0ad and a specific version of mozjs sound sensible then? <meaty>I would hold off on copying the premake5 fix into another PR unless it was asked for or it's taking a long time. It's simpler to avoid having one PR depend on another. and yeah, I would make a 'mozjs-for-0ad', making sure to inherit as much as possible from the "main" mozjs <AidenIsik>Alright, I'll do that then. Thanks for the advice on that. <AidenIsik>I'll hopefully have it all working in the next few days <omentic>heyo -- trying to figure out guix. i've got a manifest.scm containing my dependendencies for a project. what do i pass to -L when invoking guile directly to run a file with said dependencies? <omentic>i think this is done somehow with the -e flag, but i don't understand the documentation. there is this weird @ symbol i have not seen before, and no munging of the examples has ended up working for me. <Rutherther>omentic: why are you trying to invoke guile directly in the first place? And what do you mean by 'run a file'? <omentic>Rutherther: i've got a .scm file i want to evaluate. it depends on the hoot ffi. while guile shell seems to work fine, i don't know how to provide it the hoot dependency. <Rutherther>omentic: if your manifest file depends on guile-hoot, you will need to already be in an environment with guile-hoot to evaluate it, meaning either to install guile-hoot (and guile to the same profile) or to use a shell with guile & guile-hoot. <omentic>Rutherther: i might have phrased things poorly. i have a manifest.scm file that builds a manifest containing guile-next, guile-hoot, and a couple other things. running guix shell --manifest=manifest.scm works perfectly. <omentic>once in the shell environment, i do not know how to run myprogram.scm, which expresses a use-modules dependency on (hoot ffi). well, i know how to run it. i do not know how to give it the (hoot ffi) dependency which presumably is somewhere thx to guix shell. <Rutherther>but okay, I then understand you have a manifest.scm that returns manifest with guile-next, guile-hoot and couple other packages then <Rutherther>omentic: guix will give you the dependencies via search paths that are then put to environment variables when you enter a shell. You can see what search paths are provided based on the manifest.scm if you append --search-paths to your guix shell invocation. You will see there is no GUILE_LOAD_PATH. This is because you presumably haven't added guile to the manifest <Rutherther>omentic: the thing is that there are packages that provide search paths and then there are packages that utilize those search paths. In this case, guile is the package providing the search path and guile-xxx are the packages that utilize them. If you don't have both, you will not have GUILE_LOAD_PATH <Rutherther>although wait... here the issue is different, you want to use guile-next instead of guile? <omentic>uh. maybe? i am not sure. for the hoot ffi stuff, i think i need guile-next. but i'm not quite sure why standard guile doesn't even *find* the package. <omentic>like, i have GUILE_LOAD_PATH when in the shell. <omentic>hrm. interesting. looking at $GUILE_LOAD_PATH/hoot i see some files... none of which are ffi.scm. and loading these other files in seems to work. <omentic>so i guess i have the wrong hoot version? lemmie go see if the version i have in the shell is too old or too new <omentic>well, upstream has ffi.scm (and loads more files). <omentic>but i think i'm holding something wrong. i copied the manifest.scm file from the hoot game jam template, that also has modules that rely on (hoot ffi). same thing happens there. i'm not sure how those modules are supposed to get built, if they can't see ffi.scm. <Rutherther>omentic: I think this is likely a package bug - the package guile-hoot somehow doesn't expose the ffi. it is under share guile-hoot version lib instead of share guile site. And this path is not propagated in any search path. Moreover even when using that path, hoot features is referenced, but missing - "guile -L "$GUIX_ENVIRONMENT/share/guile-hoot/0.6.1/lib"" <omentic>i do find the ffi.scm in /gnu/store/<hash>/share/guile-hoot/0.6.1/lib/hoot, at least. and loading that path (sans trailing /hoot) with -L is successful. but then... for some reason guile is saying the define-foreign variable literally exported in that file is undefined, lol <omentic>oh -- well, that was b/c i switched out the dependency in debugging and forgot. loading the hashed dir directly works. lemmie see if this guild thing is any nicer to use tho <omentic>oh what. okay, guild compile-wasm apparently implicitly adds hoot into the load path. explains why the original script didn't seem to do much magic. <omentic>i guess that is reasonable behavior. <omentic>hrm. i'm getting an error about char-set<= along the lines of it being unbound. this is strange to me since it's bound in the REPL by default. is there anything that's unimplemented for the hoot wasm backend? <omentic>(maybe this is a question better posed to #spritely) <meaty>does anyone here have an example pounce service config I could look at? <meaty>I have everything set, I think, but when I connect to the pounce server the connection immediately gets closed <jakef>how long was the last core updates branch cooking for? <jakef>i don't know anything but does that sound a bit longer than ideal? <Rutherther>I mean, ideal would be 0, get updates without spending time on them :) <andreas-e>Well, it is not as bad as it sounds - sometimes nothing has happened while people were working on a fix or going on vacation. During that time, other branches went to the front. <andreas-e>And surprisingly, just changing the gcc version is a massive change! I did not expect so many packages to break because gcc-14 has turned many warnings to errors. It feels a bit like compiling with -Werror. <andreas-e>And we still have our customary build farm problems, which is not as stable as it should. <Rutherther>so it taking so long is fault of programmers that ignore warnings! :D <andreas-e>Or programmers that disappeared. Right now I have fixed software from 2011 and a library from 2013, which is still used in a current program. <jakef>would a shorter cycle mean less changes and less packages to fix after merging? <andreas-e>We also need to strike a balance between the number of changes vs. the time to recompile. <Rutherther>andreas-e: in case of changes like gcc, how long does the build farm take to build it? <andreas-e>World rebuilds take a few days, we cannot just update core packages one by one, for instance. And some problems were only discovered close to the leaves, but still required a profound change. <andreas-e>I think we made the mistake of allowing changes to core packages too late in the cycle. <Rutherther>also... I am unsure if there can be such balance between number of changes vs time to recompile. When you change something in the bootstrap, or something used by all packages like gcc, it doesn't matter how many more changes you do, you will always recompile almost everything <andreas-e>Once a branch starts to build on the farm, I think we should only accept fixes to new problems and postpone other changes related to the team to the next turn. Otherwise we may end up with an infinite cycle. But the distinction is not always clear. <Rutherther>andreas-e: maybe core-updates-team-next branch could be made in such cases? <andreas-e>Or it could be held as pull requests on codeberg. They do not have to go to a branch immediately. I think that would be easier. <Rutherther>andreas-e: yeah, I suppose that could be fine most of the time <ekaitz>csantosb: waiting for your commit access request <ekaitz>as part of the electronics team i'm starting to get annoyed by your review requests :) <yelninei>is there a way to prepend a package to the list of packages with a service or otherwise enforce an ordering in the service extensions to make sure that an extension always resolves before another <ieure>yelninei, Is this for a service you're writing? <nameiwillforget>Hey everyone! I'm transitioning to Guix and I think it's great for the most part! But I have a custom keyboard layout that I wrote in a file called dxkb. In other systems I just put that file into /usr/share/X11/xkb/symbols but that doesn't exist in Guix. From what I understand I'm supposed to add this file to the xkeyboard-config package using a gexp, right? <ieure>nameiwillforget, I have a similar issue which I haven't resolved. The simplest thing is to make a package which inherits from xkeyboard-config and adds your symbols, then use grafts to replace xkeyboard-config with your version. <nameiwillforget>ieure: Ah, ok. Then I'll try to do that. Let's see how far I'll get! <yelninei>i guess I can just try where in the default-essential-services I have to add it to make the shepherd profile exrtension come first but this seems fragile <ieure>yelninei, Sorry, really don't understand what you're doing. The hurd package is in the hurd field of operating-system-hurd (like how operating-system has a kernel field with the linux kernel package). Why are you also putting it in a service? <Kolev>I was letting a `guix system reconfigure` run inside tmux. <Kabouik>Would any Guix user here have an exemple Emacs configuration for org-latex-to-pdf export? I tried to set up LaTeX compilation in Emacs following documentations and snippets I found online, but I'm hitting roadblock roadblock and am starting to thinkg it could be due to peculiarities in Guix packages. <Kabouik>I don't need to write LaTeX (would use Org instead), I am just interested in being able to compile it. <Kabouik>Typos: "roadblock after roadbloack and am starting to think"… <noe>Kabouik, in theory there is the emacs-org-texlive-collection to provide the necessary packages <noe>but I think last time I tried it wouldnt work so I have the full texlive package right now <Kabouik>I will give it a go, but I would not be surprised if my Emacs configuration was also not okay for LaTeX. Ideally I would like to avoid the massive packages because I really don't use LaTeX much and would just want to start using it with org. <Kabouik>Thank you, I'll update later when I have tried. <noe>on the emacs side I don’t have anything specific apart from setting org-latex-compiler to xelatex <Kabouik>That's already something I didn't have. My config had remnants of an attempt to use AucLaTeX + Tectonic, but I never managed to make it work. <csantosb>"Unable to find bison. Try to provide -DBISON_DIR=[path]" ... what the ? <Kabouik>noe: texlive-base doesn't seem to exist <Kabouik>Yet is listed and recommended in the manual. <noe>sorry, I sent the manual from years ago <csantosb>yelninei: "-DBISON_DIR=~a/bin", and not "-DBISON_DIR=~a" ! <yelninei>hmm. I made it work with shepherd but now there is the problem that hurd currently provides uptime,login,w,ps which now come from other packages. This is annoying <Kabouik>Thanks noe. I will try with emacs-org-texlive-collection first, since it seems to be made exactly for what I want and is lighter <yelninei>janneke: in f2cefd700d6fb6ee26a9289b8194524062d2778f you changed the provider of /hurd from the os field (which ends up in the system) to the one in the profile. Is this intended? I would expect it to be the one from the field in the os record <yelninei>this annoyed me when I tried to add a patch for streamio but it did not change anything unless I replaced the hurd from the packages field <janneke>yelninei: ah, you mean the system -> profile change, yes that's weird <janneke>the commit promises to be "chattier" and then also makes that change <Kabouik>So I get "I can't find the format file `pdflatex.fmt'!" when trying to run org-export-latex-to-pdf in Emacs using `pdflatex` as org-latex-compiler, and with texlive-collection-latexrecommended propagated from emacs-org-texlive-collection@9.7.25. <janneke>other than that the /hurd symlink could be stale and we certainly need to replace it <yelninei>i was trying to add patches to streamio to try to get shepherd-system-log to work but was very confused why it did not change anything for /dev/kmsg <noe>Kabouik, try with xelatex then <noe>guix locate says pdflatex.fmt is in the texlive-latex-bin package <umanwizard>sad news... I finally was able to reconfigure on aarch64, but the system just hangs when I log in :( <umanwizard>luckily, I could still ssh in so it was easy to roll back <ieure>umanwizard, You can pick a previous generation from GRUB when the system boots, too. <yelninei>janneke: Oh wait, it used to be always the system/profile/hurd but should it be just system/hurd? <umanwizard>Anyone have an idea how to start debugging this? / ever seen it before? <Kabouik>noe: yes I saw that too, and installed it, but emacs/pdflatex still won't find it. This is why I'm thinking this may be related to Guix packaging/non-FHS to some extent, but I'm not sure. <noe>Kabouik, can you send the whole log file <csantosb>ekaitz: a couple more to review tonight 😄; these two look interesting ... the engineering module needs more love, I'm afraid <Kabouik>I haven't tried xelatex yet noe, since this would be a new package to install most likely <ekaitz>you only need to convince a couple of people more and I can help you with that <ekaitz>we need to be more agile in the process <noe>Kabouik, the real error is “mktexfmt: No such file or directory” <Kabouik>I thought it was referring to pdflatex.fmt when it said that <ieure>umanwizard, Check the system logs, I guess. I'm not sure. I also have a system that currently isn't booting to gdm properly (it's probably the nVidia card :/), I haven't figured it out, I went back to my previous Debian install until I have time to sort it. <noe>Kabouik, I think its expecting mktexfmt to create that file <Kabouik>Unfortunately I can't seem to install texlive-latex-bin and emacs-org-latex-collection together due to a propagated input conflict <noe>its in in the texlive-scripts package <noe>maybe you don’t need texlive-latex-bin after all <Kabouik>LaTeX is already quite opaque to new users due to the many big packages and difficulty to clearly know what they are made for, add to that Emacs and Guix and you get me in an overwhelming situation. :> <Kabouik>I got to go but I appreciate your help noe, I'll try to look at it again later. Thanks! <noe>No problems, good luck! <Kabouik>texlive-latex-bin is required by the way, because if I remobe it, I get a "pdflatex: command not found" in the compilation errors and nothing else. <clarkf>Hi, I'm trying to install GuixSD on a Thinkpad, and after installation, it's failing to boot. The installer seems to have chosen `grub-bootloader' (/dev/firmware/efi is missing, though I think it shouldn't be). Is this a compat issue possibly? <clarkf>Other distros seem to report minimal compatibility issues, far as I can tell <ieure>clarkf, I think the installer will either detect how it was booted, or probe EFI support to choose which of grub-bootloader / grub-efi-bootloader to install. Possible you booted in legacy mode? Is your BIOS set to "UEFI Only" booting? If not -> change and reinstall. <ieure>clarkf, I don't have anything from that generation, but am running Guix on a variety of ThinkPads without that issue. <clarkf>I installed in "Both/UEFI first" mode, and, earlier, I installed manually using `grub-efi-bootloader', which failed outright <clarkf>I will try booting in "UEFI Only" mode and running the installer, see what it says <ieure>IMO there's not much reason to legacy boot anymore, and it causes more problems than it's worth. <ieure>clarkf, Are you using the stock install image, or something else? <clarkf>I'd prefer UEFI, yeah, but I'm open to whatever gets me up and running <ieure>Alright, yeah. I've installed that on several ThinkPads in UEFI only mode. <clarkf>This is a second-hand thinkpad, and it came with SecureBoot disabled, so I know someone fiddled with BIOS settings at some point <clarkf>Ah! Booting in "UEFI Only" mode has caused /sys/firmware/efi to exist !! <clarkf>Today I learned! Thanks, ieure!! <ieure>The installer images will boot on either UEFI or legacy BIOS, I have seen BIOSes pick the wrong one before. Sucks. <PotentialUser-4>How do I use a PAM module like pam-krb5 in my operating system configuration? <PotentialUser-4>Ah, you're supposed to use a system service, guess I'll make my own service for my own module then. <Kolev>Should I do && reboot after system reconfigure? <Kolev>tmux: invalid LC_ALL, LC_TYPE or LANG <clarkf>Rebooting after a system reconfigure is usually a good idea (though it depends on what was actually updated) <identity>Kolev: if a kernel update happens, then you MAY reboot if you want to use the new one. if you changed some environment variables, it is RECOMMENDED to log out and back in for the changes to take effect. <Kolev>Well, when I did my system reconfigure, I couldn't log in after adding containers. <identity>Kolev: you could manually set LANG&co. to a valid value like “LANG=C.utf8 tmux” <ieure>What are they currently set to? <Kolev>tmux was working before my system reconfigure. <Kolev>ieure, why aren't they being set? I haven't changed my configs at all. <clarkf>Have you logged out and back in to your current shell session? <ieure>Kolev, I'm not sure. Did you log out / back in? (Not suggesting that you do, just curious if you did). <Kolev>ieure, I had to reboot after system reconfigure because I could not log in after the system reconfigure due to elogind or something. <clarkf>btw, ieure, "UEFI Only" did the trick. Fully booted now! <Kolev>I was not having issues with locale before the reconfigure. : ( <Kolev>ieure, but I need the Jellyfin service that I added. <ieure>Kolev, Roll back and see if that fixes the issue or not? Roll back and see where the locale is getting set and what might have changed? <Kolev>It might be elogind, which is required for containers. <Kolev>Which is required for Jellyfin. <Kolev>I really don't want to roll back and reboot. Rebooting the server is harad. I have to connect a monitor and keyboard to it. <Kolev>ieure, fine. How do I roll back? <ieure>Kolev, `guix system roll-back' <Kolev>I'm frustrated. I just recovered from a disk failure and now I'm having issues getting Jellyfin back up. : ( <Kolev>Can't even start tmux on this thing. <ieure>Kolev, Huh, don't know what's up with that. <Kolev>Rebooted. Let's see what happens. I feel so lost... <Kolev>OK, the system is on the previous generation. tmux works now. But how will I be able to get both tmux and Jellyfin to work... <clarkf>Might be worth digging into `guix pull -l' and trying to figure out what changed between the generations <ieure>Kolev, Probably worth asking on help-guix. <ieure>Kolev, No need for apologies! That's just a better venue for more involved questions, which it seems like your is. <ieure>nameiwillforget, Please don't paste into the channel, use a pastebin. <ieure>nameiwillforget, xkeyboard-config-with-dxkb will not work, packages are built in an isolated environment which has no access to /home. You'll need to add your extra symbols as a patch or input to the package. <ieure>nameiwillforget, The second package is correct, but won't do anything unless you replace xkeyboard-config with it everywhere it appears in your system. package-mapping can help with that, nonguix also has some code to replace packages you can reuse. <nameiwillforget>ieure: But I commented out the "/home/alex/daselt/d-xkb/dxkb" and added the reference to #$dxkb that I defined before with (define dxkb…). Will that still not work? <ieure>nameiwillforget, Ah, I see, it wrapped and wasn't clear it was commented. It should work, but you shouldn't do it, since it makes the build unreproduceable. <ieure>Patch, snippet, or origin record in the inputs is what you want. <nameiwillforget>Ah, ok. So I should add the file in that way and then I have to use package-mapping to globally replace xkeyboard-config. I'll try that. Thanks! <Kolev>ieure, should I switch back to the system with the error? How do I switch back? <ieure>Kolev, `guix system list-generations' to see what you have and `guix system switch-generation' to change it. You probably have a better idea if you want to switch back than I do. <Kolev>ieure, well, I'll need to be on that system, to debug it. <umanwizard>my issues were fixed by switching from Gnome to MATE. Don't have time now to debug the Gnome issues, but at least I'm back to having a working setup on something reasonably close to master <umanwizard>The last necessary change to get it working on aarch64 is that a bunch of xf86 drivers need to be built with -Wno-error=implicit-function-declaration <umanwizard>which I haven't submitted yet, but will when I get some free time. <shcv>hey all; I'm trying to do a home reconfigure, but it's blocking on ungoogled-chromium which is failing at the moment. I already have a working version; how can I ask it to just keep the one I currently have in my profile instead of rebuilding? The version number looks the same too... <andreas-e>It failed after the core-packages-team merge, and if nobody steps up to upgrade it, chances are it will soon be removed for being too outdated. <andreas-e>bdju: How is the upgrade going? Are there still missing packages? <bdju>I think blender/krita are still held up by opencolorio, and OBS still needs to be fixed. <bdju>Interesting to hear ungoogled-chromium has been failing. I've been skipping that just because I know it would take ages to build on my machine, so I never had the chance to see it fail. <andreas-e>obs should be on its way, there are two competing patches to sort out... <andreas-e>blender and krita are really annoying, and we do not know what to do with opencolorio <bdju>shcv: I'm not running guix home, but try `guix package --upgrade . --do-not-upgrade=ungoogled-chromium` <ieure>bdju, Guix Home uses a different profile, that won't work. <ieure>shcv, You can't do partial upgrades with Guix home. <shcv>I mean, that seemed logical given the declarative nature and all - just wondered if there was a way to pin the current one <ieure>shcv, You can remove Chromium from your home configuration, or replace it with the fixed version. <ieure>You might be able to `guix time-machine' to install Chromium in your profile, then take it out of your home config, though I generally discourage people from mixing home and user profiles like that. <ieure>Or figure out inferiors. But since our ungoogled-chromium package is very old, it's likely riddled with vulnerabilities. <shcv>I wonder if I can leave it out and get it from a shell? <bdju>It should remain in the store after an uninstall, right? In a pinch you could then run it by its full path to the old binary. <shcv>yeah, the problem seems to be that GCC is too new to build it now <ieure>shcv, If it's not building in master, you'd have to `guix time-machine' back to a commit where it works, or have an inferior. <ieure>I haven't messed with inferiors, but I assume the manual & cookbook cover them. <ieure>LibreWolf is what I daily drive (I also maintain the Guix package), if you're up for switching. <ieure>I was waiting on CI to merge the latest bugfix, but it's been scheduled for five days, probably just push it soon. <bdju>LibreWolf seems like a fine alternative to IceCat, but some things only work in a flavor of chromium. It's useful to have both around. <shcv>ieure: interesting; I do use FF as my main browser actually. Sadly, I need to use Google Meet for work and it doesn't seem to like doing screenshare via FF in EXWM half the time <ieure>bdju, 99% of what I've found doesn't work OOTB in LibreWolf can be fixed by relaxing fingerprint resistance, enabling WebGL in about:config, or spoofing the user-agent. <andreas-e>ungoogled-chromium is a 500 line package. It may be possible to get it to build again, but I am afraid that without a good knowledge of the build, it will be difficult to update it securely. <bdju>Can we reach out to the last person who updated the package for assistance? <Kolev>Why is Guix slow to pull and slow to install stuff? <andreas-e>Slow to pull, because it needs to compile all of Guix. <umanwizard>what I don't understand is why if I change one file in my checkout, guix pulling from it still takes ages. Shouldn't smaller chunks of it be cached in the store ... <ieure>umanwizard, guile-git has some terrible performance issues which haven't been fixed. <ieure>Bug has been open for several years. <ieure>Don't remember where I saw that, but someone did a solid analysis, someone else provided a patch. Far as I know, it's still unfixed. <clarkf>libgit has significant performance problems, iirc. Specifically when pulling <bdju>A guix pull for me seems to be almost exactly 20 minutes every time, upgrades vary depending on how much I'm upgrading. <clarkf>switching the remote from 'file:///x/y/z' to '/x/y/z' can improve pull times dramatically <ieure>Substitutes don't make it much faster, I agree that ~20m is usual for a pull. <ieure>What I mean is, most systems already have substitutes enabled, and that's what makes it take 20m instead of an hour+. <bdju>Is this safe to ignore? Saw during a guix system reconfigure: WARNING: (guile-user): imported module (guix build utils) overrides core binding `delete' <ieure>bdju, It's a consequence of the Guile idiom of importing module symbols into the current module, which IMO should be a rarity instead of the default. <Kolev>Getting stuck on substitute: <umanwizard>ieure: what I mean is: if I do (from my checkout): guix pull --url=`pwd` --disable-authentication --branch=whatever <umanwizard>I would have expected it to not take as long the second time. But it does. <umanwizard>Why does it need to recompile _everything_; why can't some intermediate pieces be stored in the store from the last time I ran it <ieure>umanwizard, Because the package definitions are part of the Guix binary. <ieure>umanwizard, And reproduceable builds mean you don't reuse results of previous builds, because that's state. <vagrantc>i think guix is not reproducible, as even running it twice in a row sometimes results in rebuilding parts of it <umanwizard>ieure: I know all that; what I'm asking is why can't the derivation of the guix binary be partitioned into several derivations: (big chunk of scm files 1).drv, (big chunk of scm files 2).drv, and so on, and then have the final binary be produced by a "linking" stage at the end. Perhaps the answer is just that the Guile compilation module doesn't support this, but I think it's conceptually possible... <vagrantc>but sometimes it builds more or less than others, and sometimes substitutions are available for some parts but not others <vagrantc>a big part of it is just how interconnected all the various .scm are, as many import each other, directly or indirectly <sham1>Well, the concept of reproducibility in Guix doesn't really look at whether you need to build things or if you get substitutions. Just that given specific things from the store, the output will always be the same. Whether that's done by build or by substitution shouldn't matter <noe>Is it possible to get a core dump for a segfault happening inside a guix build? <neox>noe: perhaps with --keep-failed, but very unsure <Kolev>Still stuck on "substitute:". <noe>neox, good idea, but no core file was created so I can’t find it there <noe>I guess I need to convince the kernel to generate them <neox>> I guess I need to convince the kernel to generate them <neox>_how to bribe a kernel - lesson 1: command line arguments_ ? <noe>but since its in a container I’m not sure it will listen <noe>I should bribe the guix daemon instead :P <noe>that only sets it in the current shell, not in the build environment unfortunately <umanwizard>There must be a way to set resource limits on the guix daemon service <ieure>noe, Add a build step to your package that runs ulimit, then build with -K. <podiki>any cpp people here know of some change in gcc 14 over how some preprocessor stuff changed? <podiki>or wait, does endif correspond to elif too? <noe>ieure, ulimit is a shell builtin and only applies to processes started by that shell, but maybe I can make it work if I replace the check phase <Kolev>I've been waiting half an hour for a package to install. <noe>I got the core dump! Thanks everyone! <noe>I should document this somewhere <podiki>ah, something with how an (implict?) #else is handled in gcc-14 is different than in 12 and 13 <podiki>but i can't find documentation or what to search for exactly <umanwizard>I'd be a bit surprised if something as fundamental as how #if / #else/ #elif / #endif works has changed in gcc 14 <andreas-e>podiki: It looks reachable to me. __has_include is defined, then the #if/#elif/#endif block is executed (and includes hsa/hsa.h or hsa.h or nothing since an #else is missing) and then hsa/hsa.h is included. <podiki>that last line is not processed when i try with gcc 12 or 13 <podiki>i'm checking the gcc 14 notes now <podiki>or wait, i'm confused, let me double check <Kolev>Yeah, install and pull are not working. <podiki>i thought the last line of that block is for if __has_include is not available (e.g. older gcc) <andreas-e>There is no #else, it is just the last line of #if defined ... #endif. <umanwizard>podiki: yes, it seems to logically be missing an else <podiki>yeah i think i was just hitting a caching or the compiler finding an error instead in my little test program <podiki>somehow gcc-14 fails on that line (make sense, that file doesn't exist and seems there should have been an #else) while gcc-13 didn't previously <podiki>these packages and llvm haven't changed from what i can see, just the core-updates merge gcc change i think <podiki>maybe something in the cmake or configure changed some other includes or something? <andreas-e>Inclusion of standard headers changed. Previously one header could include another one, so by including the first you also got the second. Nowadays you often have to include the second one by hand (cstdint in C++ occurs often). But this does not seem to be the case here. <podiki>i do see they (upstream) added in an #else in the equivalent line in later version (to fix some warnings the commit says) <andreas-e>It definitely looks logically wrong now, be it with or without warnings... <podiki>i guess the fix here is to remove that line in a substitute* with a note about why; i'm still trying to track down if something somehow changed with some include paths