IRC channel logs
2026-01-29.log
back to list of logs
<gabber>`sudo ip link add dev wg0 type wireguard` yields "Error: Unknown device type". this is on a pinebook pro with a non-liberated kernel. this is unrelated to the initrd-modules set to '(), right? <gabber>`sudo modprobe wireguard` fails: "modprobe: FATAL: Module wireguard not found in directory /run/booted-system/kernel/lib/modules/6.17.12" <bdunahu>It seems the texlive package was recently deprecated and some things moved around, and now the example minimal latex setup in the manual no longer works for me (url points to packages I have and the error I receive) https://paste.debian.net/hidden/3243792b <bdunahu>Online forums for this error suggests that a package is missing, but does anyone know which? <bdunahu>my snippet is missing the `rubber' package, but I have that as well <bdunahu>if someone has a working set of packages that is not minimal that would also help me <gabber>shouldn't these kernel modules just be there? <apteryx>cbaines: hello! in my checkout: error: %substitutable-nar-size-procedure: unbound variable on attempting to build something with ./pre-inst-env guix build something; seems something caused by the recent substitute-related commits? <apteryx>it's caused by 0c1ea038e9d and following commits <apteryx>maybe they got rewritten before submission <apteryx>I guess one needs to update their daemon to use the new code <apteryx>that didn't appear to help (reconfigured on a latest guix pull, and 'herd restart guix-daemon'); still getting error: <substitutable>: unbound variable <apteryx>looks limited to the checkout; I'm guessing 'make clean-go' will resolve it <vagrantc>apteryx: sure it's not just a need to re-run ./bootstrap && ./configure ... etc. from scratch ? <apteryx>I tried reconfigure at least, the new substitute code does heavy macrology so stale .go makes sense I think <efraim>had a power outage yesterday and now all my riscv64 machines are down :/ <parra>ieure: I have changed the channels.scm and a pull from 6 of January until today with riscv is taking +8h in a 36 core machine <parra>efraim: is this related to what I'm mentioning? 🤣 <parra>it seems some tests fail of cmake-bootstrap-3.31.10 <parra>so this means riscv is not supported anymore? <efraim>its still supported. there's not always a lot of substitutes for riscv64 and there was just a large update to a lot of packages <efraim>I have a couple of riscv64 boards here that I test with and they didn't like the power outage <parra>how I should proceed now? basically it's really hard to have riscv64 incremental builds, no? <ArneBab>I just tried updating inetutils to version 2.8, but after everything else failed, softwareheritage provided a tarball for version 2.5. That sounds like dangerous behavior. <parra>but it's too fragile, I can't do it for all architectures <efraim>ArneBab: did you change the hash? <ArneBab>because I don’t know the hash yet: I ran guix build to get the hash. <efraim>if you don't change the hash then the fallback is software heritage to search for that hash <ArneBab>ah, then it’s not dangerous -- thank you! <efraim>I sometimes replace the first couple of letters of the hash with zeroes <efraim>looka like at least one of my POE splitters is dead <parra>I don't know what to do man, guix is so fragile <parra>is there any way to skip tests during guix pull --fallback ? <Rutherther>parra, not really and note that skipping tests means changing derivations <Rutherther>untrusem-: sure they are, guix pull can build packages <parra>untrusem-: I am trying to make incremental builds but riscv64 fails on master <parra>Rutherther: so it's impossible to build riscv64 right now on master, no? <parra>it's failing on cmake-bootstrap tests <Rutherther>parra: is it failing period or failing for you? Sometimes tests can fail on some devices and not others. So this issue might have been present even before, you just didnt notice it because bordeaux built it before etc. <parra>I'm using Qemu for building it <parra>how that happen? isn't guix reproducible? <Rutherther>Guix is trying to be reproducible. Doesnt mean its always is <Rutherther>Tests are hard to get right. Moreso in Qemu, thats going to fail often <parra>why? what's wrong with qemu? <identity>you can only do so much to make software reproducible; QEMU can only be so accurate <identity>it is a common woe of OS developers: it runs fine in QEMU, but not on real hardware <ruthertmp>it uses real machines, like StarFive 2 or HiFive Unmatched IIRC <cbaines>that happens on two VisionFive 2 boards and two HiFive Unmatched boards <ruthertmp>the derivations wouldn't match if it cross-compiled, natively compiled and cross-compiled packages produce different derivations <cbaines>but that's not enough to keep up, let alone to test branches, even if we had the setup to do that, which we don't at the moment <parra>is riscv64 normally up to date with master branch respect to substitutes? what's normally the gap between current stable version with substitutes and master? <ruthertmp>On CI the situation is even more brisk than on bordeaux, you can try searching in what state it's there <parra>what do you mean? what's the difference? <ruthertmp>parra: That is not easily said, because it depends on what has changed and what you're building... <ruthertmp>parra: Because sometimes it will be missing only leaf packages and sometimes the whole bootstrap chain will be missing... and based on that you would know when to expect substitutes <parra>I just want to make incremental builds but it's really hard 🤣 <cbaines>for the last 6 months, 27% substitute availbility is the peak for riscv64-linux <parra>so basically I should avoid riscv until a full release of guix is done? <parra>yes but after less than one month I cannot build riscv anymore <cbaines>right, this isn't an issue connected to releases <Rutherther>parra: because now there has been merge of next master to master that caused a lot of rebuilds <parra>what should I do, wait until rebuilds are done? <parra>this the first ci that broke <parra>I mean for implementing incremental builds <parra>I'm just doing guix pull, and packacing guix-current + cache <parra>that's basically what I want to achieve <parra>is there a way to know what is the last commit built in substitutes servers for each architecture? <parra>(mostly in the official substitute servers) <cbaines>not an easy way, especially with grafts mixed in to guix pull <parra>so it means that normally substitutes are built with no clear order.. and it's hard to find commits with full substitutes, right? <parra>I think the question doesn't make sense because you said riscv64 only has 20% of builds and I'm specifically talking about guix-current <parra>I understand why is so hard to find a commit that has all substitutes for guix-current <cbaines>that's good, because I often struggle <cbaines>but that's for specific revisions, and there's no way currently to look at it over time <cbaines>I think there's a Cuirass specific thing intended to be used when guix pull'ing <parra>what do you mean? do you have reference? <csantosb>cbaines: interesting exchange with futurile, in yesterday's chat; IIUC, pushing 10 commits in a row won't trigger the package built of every single commit, so things are kind of optimised, right ? <cbaines>csantosb, I wouldn't call that an optimisation really <csantosb>You gave an example about 5 leaf, and 5 other with lots of dependencies <csantosb>The question which came to me is, then, we don't keep substitutes for every single commit in Guix log history <cbaines>I was more trying to get across how you can group changes differently to reduce the number of times packages are rebuilt <parra>cbaines: but even if I use channels with substitutes feature you mentioned, this won't ensure proper pulls? or how does it work? it will pull until substitutes are available for the current installed programs? <cbaines>csantosb, yeah, if you look at the data service or Cuirass, they look at states of the repository, rather than individiual commits <csantosb>cbaines, ok, so if I guix pull a random commit, chances are the substitutes are not available <cbaines>csantosb, package substitutes should be available. If they're not, but available for the repository state before and after that commit, then something's gone wrong with that range of changes <cbaines>csantosb, however for the substitutes for guix pull, they probably won't be available <cbaines>since those derivations tend to be commit specific, and there's nothing building them for each commit <parra>how can I use it with multiple substitutes? <cbaines>parra, there's an example on the page I linked to <parra>I thought it would be better to have more substitute servers to avoid this issue but it seems it maybe better to use the feature you mentioned and stick to the official mirror? <cbaines>unfortunately that won't help with riscv since ci.guix.gnu.org doesn't build this jobset for riscv <parra>so I'm fucked in any case XD <parra>I should drop riscv support maybe..? it's really hard to make incremental builds reliably <parra>cbaines: but the thing you said is not true because I built riscv after 1.5.0 and there were substitutes <cbaines>parra probably from the bordeaux build farm, rather than ci.guix.gnu.org <cbaines>unfortunately the riscv machines aren't that reliable, and there's only 4 of them which isn't enough to start with, so it requires quite a bit of my attention to keep things going <cbaines>(despite the fact they're not really making a dent in the ~15,000 build backlog...) <parra>the feature you shared with me also works in bordeaux? or it's only dor ci.guix.gnu.org? <cbaines>no, only ci.guix.gnu.org, and only for the systems enabled on that job <parra>what are the architectures supported by ci.guix.gnu.org? <parra>(are you the responsable of riscv machines by the way? just curious) <parra>cbaines: I don't understand what you mean by specific job, you mean that it basically won't have riscv substitutes right? <cbaines>but the channel with substitutes available thing just looks at builds for the specification/jobset named "guix" <parra>ah, it doesn't look for guix-other-archs for example, right? <cbaines>I don't believe so, but you should check the code <parra>I will, maybe I will also modify the code <parra>I think it's a potential solution to my issue but it's involving a lot of time in general to achieve what I want <newguixbie>I infer mesa-updates must have been rebased since this evaluation but it makes tracing hard so I'm mentioning it <newguixbie>my reason for exploring these commits was to find hurd package builds compatible with version-1.5.0 . it would be nice if all the systems were built in release branches. <newguixbie>but in larger news congratulations on version 1.5.0, super heartening to see a release, very excited to install later and easily get much more up to date :D <Rutherther>newguixbie|away: wdym that the mesa-updates evaluation is responsible for version-1.5.0? <newguixbie>@Rutherther yes overlapping issue. The builds should be associated with all evaluations that produce them rather than just one. <newguixbie>saying that, I realize I can trust other evaluations' commits to produce identical derivation which addresses my reason to worry :) <Rutherther>I would say it is the issue. The builds have too high priority so they might never be built. Its caused by this <newguixbie>Yes. Additionally codeberg dropped old commit history and if a published branch was rebased the evaluation history is now dissociated from the code. Small things though. <Nessah>Very nicely done with the 1.5 release so far. Plasma feels better, with a couple of major issues still. Firstly, installing/updatibg packages does not always update the menu entries properly. Even after restarting, plasma left me on an older, unpatched icecat that i had to mess around with the app menu editor to point to the correct /gnu/store/ <Nessah>And the second one is the startup stuck on the splash screen for a bit too long <futurile-afk>Nessah: have a look if there's an issue on Codeberg.org/guix/guix for the plasma update maybe <Nessah>futurile: It's #5902 by the looks. "xdg-desktop-menu forceupdate" i havent tried yet, but the GUI method i was using works around it. Might add it there too <futurile>Nessah: thanks for checking, yeah a comment if you have a workaround is worth it <csantosb>How can one use the `native-search-paths` field pointing to `lib/python3.11/site-packages`, without being dependent on the python version ? Is it yet possible ? <Guest21>If I add a new service type to Guix, how would be the workflow to test out my changes? <identity>Guest21: probably re-configuring from the checkout and seeing if it works <futurile>FuncProgLinux: not too much, I'm working on figuring out how much we've collected from fundraising for Guix, and what it likely means for the project <futurile>FuncProgLinux: what about you? A lot of people are travelling to FOSDEM I assume <FuncProgLinux>I'm eager to see what's new on FOSDEM. I'm thinking to spend time learning C and GTK due to dev shortage in MATE <untrusem>for the few days I have been getting this error when I try to build something in my local guix checkout, I am using ` guix shell -m manifest.scm --pure` to get a guix shell and building things with `./pre-inst-env guix build -L . <package>` -> https://bpa.st/HRITG <untrusem>I am on commit 64429ac5864d68d3ef066f4533a07ce32adc4f87 <ieure>untrusem, Remove the -L . argument. <futurile>FuncProgLinux: feels like we're seeing a generational change away from C to Rust. Maybe it's just noise. I find it quite interesting Rust gets so much attention when I'd have said golang is much more widely used in commercial devel <futurile>FuncProgLinux: hopefully lots of the older desktop codebases that are in C will still have enough contributors long-term <untrusem>then how it would build the local package? <ieure>untrusem, The pre-inst-env runs guix from the repo you built; that's what it's for. <ieure>untrusem, Also `guix build -L.' in the guix repo doesn't work at all. <ieure>Yes, -L. in some other channel is the correct way to build stuff from it without pulling. <ieure>But the guix channel / repo is special. <ieure>Do you get the same error in the Guix repo without -L. ? <ieure>Are you in a `guix shell' or using pre-inst-env when building out of your own channel? <ieure>Hacking on my personal channel: no shell, `guix build -L. whatever-package' <ieure>Hacking on guix: `guix shell -m manifest.scm --pure' and `./pre-inst-env guix build whatever-package' <ieure>That's what works for me and as far as I know the only way it works. <untrusem>I thing is I need rust-1.89 but then I would need to build it on my own machine if I want to use it <untrusem>because we can't import things from rust-team branch in another channel <futurile>well it's a full copy of 'guix' so you can just switch to that branch can't you? I guess it may not be as up to date? <Kabouik>I have an Emacs manifest with packages coming both from the guix channel and the github.com/garrgravarr/guix-emacs channel, most of the time without specifying specific versions (I just have both because some of the packages I want are not in guix); but sometimes I do if that helped resolving dep conflicts. Now I do have conflicts after a recent guix pull, which I'd like to resolve primarily by listing which packages come from which channel when I <Kabouik>`guix package -m thatmanifest.scm`. Is there a way to do that? It's a 172-line manifest so I would like to avoid just manual guix searches. <FuncProgLinux>futurile: I think the use of golang depends much on the business. I do use it but it's for mostly web stuff or anything daemonic. <Kabouik>Listing what comes from guix-emacs or guix would help me prioritizing what I should comment out first when trying to identify the root conflicts <untrusem>futurile: I mean I want to use rust-1.89 in my own channel that is available on rust-team branch in guix repo, so I would need to build it myself. won't I? <ieure>untrusem, In situations like that, I'd copy the rust-1.89 package definition into my channel's default branch. <untrusem>ieure: yeah I did that, it tries to build it <ieure>untrusem, I don't believe the channel is included in the derivation, possible you changed something about the package when copying it? Is the package hash identical between rust-team and your channel? <ieure>untrusem, `guix build -n' should give you the package derivation, but not actually build it; you can compare their hashes that way. <ieure>I am preeeeettty sure I've seen substitutes work across channels when copying package definitions. <untrusem>I ediffed the definations, I did not changes anything <Kabouik>Answer to myself: the `guix package -m manifest.scm` command does list all packages and their version before failing, and version numbers help seeing where packages come from: https://0x0.st/Pqzk.txt. Now, I have too many packages coming from both sources to realistically hope fixing the conflicts, and installing everything from guix-emacs wouldn't be satisfactory either since some packages do need some manual patches for Guix (like emacs-pdf-tools). <Kabouik>I've ended up in a quite uncomfortable situation, I'll probably have to let go some packages if I want to upgrade. <untrusem>ieure: copying the whole file did the trick I might have change something <ieure>Kabouik, Are you using specifications->manifest in your manifest? <ieure>untrusem, Cool, glad you figured it out! <ieure>Kabouik, It will be difficult to determine the package source. It's going to be whichever channel defines the package with the highest version, according to Guix's version sorting. <ieure>Kabouik, What I would recommend is importing both sources with a prefix (ex: (use-modules ((guix package emacs-xyz) #:prefix guix/))), then using packages->manifest and giving the package itself, ex. guix/emacs-compat <ieure>I would also bias towards the guix channel packages unless you have a specific reason to use one from guix-emacs. <Kabouik>Yeah, but I can see it from the `guix package -m manifest.scm` attempt, since package from guix-emacs all have a version number in the form YYYYMMDD.HHmm. So I could just force versions from this source for everyting (usually, not specifying a @guix-channel-versio-number next to the package name is enough), and it will probably build, but some packages simply can't work on Guix with just the automatic packaging in place at guix-emacs. <Kabouik>My specific reasons for using guix-emacs is some packages I value are not available in Guix, and I don't think I have the skill to package them myself <ieure>Kabouik, Yeah, I was just going to mention that since these are building everything in M/ELPA, they'll probably have date-style versions. <ieure>Kabouik, You could open one or more PRs with the emacs-guix package definition and label it help-wanted. <Kabouik>With my current manifest, I seem to have ended up in a state where I could magically split packages and their deps from both sources, by fixing guix version numbers to some packages, without breaking dependencies elsewhere, but of course that worked for a specific commit and no longer works <ieure>Kabouik, My suggested approach of prefixing and using package objects directly instead of specifications would solve the problem. <ieure>Kabouik, I think it's fine to use the emacs-guix channel, but not explicitly specifying the packages you want from it means that many of those packages are used instead of the ones in Guix. And I think that's generally not great. <Kabouik>Didn't know about that tag ieure. Good to know. I might open an uncomfortable number of issues though. <Kabouik>I am not sure I understand how that approach works ieure. For reference, this was my manifest the last time it worked (it no longer does because I guix pulled): https://0x0.st/Pqi8.txt <ieure>Kabouik, That's fine. I would recommend that you start with a handful, the feedback you get from those will make the later ones easier, and reduce the total number of changes you'll have to make. <ieure>Kabouik, What part do you not understand? <Kabouik>I use specifications->manifest because I replicated it from examples, without clear understanding of what it does, and therefore no clear understanding on the functioning of the alternate approach you suggested with prefixes, or how to use them. <Kabouik>What this would do is default to packages from Guix' emacs-xyz.scm by default before relying on guix-emacs if the package name is not found in Guix? <ieure>I will hit you with some knowledge. <ieure>Kabouik, Guix packages are defined as Scheme record types, bound to Scheme variables. When using Scheme, you can refer directly to those variables to access the packages. If the package definition or version changes, you still reference the package, but its new definition. <ieure>Kabouik, Separately, Guix has a mechanism called "specifications." You refer to them as a string, instead of a Scheme variable; and Guix resolves that string using information from every package in every channel it's configured to use. <ieure>Kabouik, So, if you have a specification "emacs-compat", that's an expression meaning: the latest version of emacs-compat (according to Guix's built-in version comparison, which is a string comparison of the versions). <ieure>Kabouik, So, if you only have the Guix channel, the specification "emacs-compat" gives you the one in Guix. But as soon as you add the emacs-guix channel, "emacs-compat" refers to the package in that channel, because its version is greater. In many cases, it will not actually be a newer version, but it's considered newer because the version format differs. <Kabouik>Yes, that I understood from my testings indeed. <ieure>Kabouik, When creating a manifest, you can choose to refer to packages by either their Scheme variable, or a specification. Importantly, while both variables and specifications will refer to the latest version, the specification is the latest version across all channels, while the variable will always be the latest version *within* a channel. <ieure>Kabouik, So, you can write Scheme to use the modules which define the packages, and give those to the `packages->manifest' procedure to get your manifest. <ieure>Kabouik, In order to do that, you have to use the Scheme modules which define the packages. Importantly, if you use both, the variables from the later module will replace the ones from the earlier. So if you just (use-modules (guix packages emacs-xyz) (emacs packages melpa)) -- you'll get largely the same result as you have now. <Kabouik>So https://0x0.st/Pqiq.txt would try to install from Guix channel in priority, and only that channel, correct? And then trying to package the channels I'm missing from guix-emacs with #help-wanted (most likely). <ieure>Kabouik, So, you want to add a prefix when you use the modules: (use-modules (guix packages emacs-xyz) ((emacs packages melpa) #:prefix melpa/)) <ieure>Kabouik, Then, you can mix packages from either source in your manifest: (packages->manifest (list emacs-compat melpa/emacs-something-else)) <ieure>Kabouik, You need to remove the quotes from the list inside packages->manifest. <ieure>(packages->manifest (list aspell)) <ieure>Will put the package bound to the aspell variable into the manifest. <Kabouik>Hum, there's something I'm not sure how to format to be able to mix packages from sources (and there's the potential issue of whenthey share similar deps). I need to try writing that manifest, fail and iterate I think. <Kabouik>First of all, thanks a lot for this knowledge storm. I'm definitely keeping a screenshot of that (I know there are IRC logs, but I need to frame that on my wall). <ieure>Yes, could definitely be an issue with dependency diamonds (your manifest depends on two packages, which both depend on different versions of the same package). It is possible to work around this, but irksome. <Kabouik>I think the single-line nature of IRC is what makes it difficult to understand how to reproduce what you posted here. I'm not sure how to combine prefixes. <ieure>What do you mean by combine prefixes? <Kabouik>You used examples with #:prefix guix/ and #prefix: melpa here for instance. <Kabouik>Are they mutually exclusive or can they be combined? <ieure>They are not mutually exclusive, you can do (packages->manifest (list guix/emacs-foo melpa/emacs-bar)) <ieure>Each refers to one package from a specific channel.i <ieure>And a manifest is a collection of packages. <ieure>Kabouik, The danger there is the one I mentioned, dependency diamonds. Limiting which packages you use from emacs-guix will help with that. Or... which packages you use from Guix. <Kabouik>So in my case, that would be (packages->manifest (list guix/emacs-xyz guix-emacs/emacs))? <Kabouik>To you last message: yes, absolutely, and at the moment I'm really in a bad position because I have many from both channels. <ieure>Kabouik, emacs-xyz is part of the module name in Guix, and is not a package; it's a thing packages are defined in. And the specific prefix is completely arbitrary, you can provide any you want. It just has to match your use-modules. <Kabouik>Hah. Yes I knew about emacs-xyz but definitely did not get that prefixes are userset. <ieure>(use-modules (gnu package emacs-xyz)) ;; all public variables from that module are in your package now, you can refer to the unprefixed, like: emacs-compat <ieure>(use-modules ((gnu package emacs-xyz) #:prefix guix/)) ;; all public variables from that module are in your package now, but have a prefix: guix/emacs-compat <ieure>(use-modules ((gnu package emacs-xyz) #:prefix whoop-whoop:)) ;; all public variables from that module are in your package now, but have a prefix: whoop-whoop:emacs-compat <Kabouik>So I'm mute but that's because I'm trying to reflect that in my manifest, see if I understood enough of it to give it a go. <ieure>Kabouik, Happy to take a look if/when you'd find that helpful. <ieure>Kabouik, I would recommend: not prefixing (guix packages emacs-xyz), and prefixing (emacs packages melpa) with something. Using the Guix version of all packages. When one gives you an unbound symbol error, adding the (emacs packages melpa) prefix you choose. <ieure>newguixbie, I'm not sure if it's intentional or not that some of those builds vanish. Why are you scraping CI instead of looking at the package definitions locally? <ieure>CI is wildly unreliable, scraping is going to a) not work a lot of the time, and b) make it worse for non-bot users. <csantosb>futurile: no, no answer to my previous question 😢 <Kabouik>I can see some missing parentheses already but we wouldn't be here if we didn't like them. <newguixbie>ieure: I do not have local package definitions yet, I tried locally but it took a very long time to compute all the derivations so this time I thought I'd ask the server <newguixbie>Rutherther: the missing id from the 3rd paste was listed as a dependency this morning in the 1st paste. It appears to be its source/origin. <Kabouik>I believe I got the gist of it ieure: https://0x0.st/Pq-8.txt Thanks a lot, I would never have found that by myself. Now I have a lot of fingers to cross because I'm still stuck in case of dependency diamonds. <newguixbie>ieure: I understand not to use the ci build servers for this. I shared because the problem looked severe and important. <Kabouik>(And there are some deps clashes, of course) <newguixbie>Honestly it looks like wither there is corruption of some sort happening on the primary package server everybody is using, or somebody removed source origins from the interface today or such <newguixbie>could also be on my end, e.g. AI firewall somewhere <Kabouik>Yup, I've got a list of 10 packages from guix-emacs that won't install due to dep conflicts when I prioritize everything from Guix channel when possible. And 15 other packages from guix-emacs that I think will build, but that would be safer to package for Guix to avoid such issues in the future. Quite some work. D: <Rutherther>newguixbie: I see. Cuirass regularly removes old evaluations, so presumably that checkout has been part of an old evaluation, so it got removed <ieure>Kabouik, Glad to help. I don't have time to assist, but you can use package-input-rewriting to resolve the dependency diamond, by replacing the conflicting inputs of your emacs-guix packages with inputs from Guix. Note that this will require a package rebuild; it's pretty fast with most Emacs packages, but things like the Org Mode test suite can be a lot. <ieure>Kabouik, And the real endgame here is getting those packages into Guix. I'd be happy to give review / feedback if you open some PRs (and ping me about them). <newguixbie>Rutherther, thank you, I websearched a little and don't fully understand but i do understand now that all CI material is considered transient. Thank you all for your time, energy, and capacity. <Kabouik>I have given package-input-rewriting a go but it's a massive failure so far. Thank you for offering your help. I might try submitting a few patches, though the number is a bit overwhelming. At least I have a list now, if my first attempts are successful, that'll encourage me trying to address the others. Thanks again. <ieure>Kabouik, Sure thing. Just ping me if you put up PRs that could use review. Emacs packages are generally pretty straightforward in Guix. <Kabouik>ieure: this seems to build a profile, but jeez, the manifest is getting complicated and I need a LLM to help me write it, which is going in an uncomfortable direction. https://0x0.st/Pqo5.txt <ieure>Kabouik, I'd have one rewrite per package. And please do not use LLMs, they're awful. <Kabouik>That's my point yeah (but there was no way I could get the rewrites right without it here). It also required a lot of failure amd retries when building the profile before I could get the full list of deps to rewrite. <ieure>Kabouik, The method should be: use guix packages for everything. Add emacs-guix ones, one at a time. If it produces a conflict, rewrite it so it doesn't. Repeat until all the emacs-guix packages have been added. <Kabouik>Okay. That's something I should try at a later point, getting late at work here! <parra>cbaines: I tried that but seems not to find the substitutes anyway can I use bordeaux ci too? <parra>all architectures are showing "could not find substitutes" <cbaines>parra, this is Cuirass specific, and bordeaux.guix.gnu.org doesn't use Cuirass <parra>I have to use ci.guix.gnu.org, but can I use codeberg repo then? or I have to use Savanah <cbaines>either should work, but git.guix.gnu.org is best