IRC channel logs
2025-09-23.log
back to list of logs
<loquatdev>ieure, I manged to wget the narinfo from the other machine. It looks fine; the actual hash stored in the narinfo is the same as the one shown as the "actual hash" in the logs. Nothing looks incorrect... I'm rebuilding it on the build machine one more time. I'm starting to wonder if perhaps something in my Guix store was corrupted at one point and <loquatdev>is messing up the hash (from a sudden loss of power or something like that). I'll attempt to build the packaged on a third machine and see if the results are any different. If it matches the same hash given by my secondary machine, I might have to repair my store or reinstall on my build machine. <Chwoka2>so i've installed ungoogled-chromium, it shows up when i export manifest, guix install goes "nothing to install chief", but i can't find any way to launch it at all, not from the GUI, not from xfce application search, not from terminal ("bash: ungoogled-chromium: command not found.") same exact symptoms with the package "quazip." what am i missing? <ekaitz>Chwoka: i think you are missing the name of the app <Chwoka>like i'm consistently misspelling it? <ekaitz>Chwoka: confirmed, it's called chromium <ekaitz>bad news for me, libxml2 makes it explode at runtime <ekaitz>apteryx: i sent you an email about Nlnet in the thread about taler, they just shared today they target also business <ekaitz>but as I said, it's better to apply as a persona <ekaitz>you have until October 1 for the proposal <apteryx>for tax purposes, I think Guixotic can be as tax efficient as individuals, with some extra burden on the reporting side and assuming dual taxation treaties (it's Estonia-registered) <apteryx>ekaitz: I should have read their https://nlnet.nl/taler/faq/: "You can apply as an individual, or as a formal or informal organisation of any type. Or even a collaboration of the two." :-) <ekaitz>apteryx: heh! they document everything pretty well :) <ekaitz>apteryx: also, if you need help, please let me know. I'd be happy to help. <drewverlee>guix system container produces a executable that when it's run prompts me to extract a PID if i want to enter the running container, is there a way to make that PID explicit so another process can either set it (through a name) or get it (using a function)? <mange>Sorry, I don't fully understand. What do you mean by "explicit"? What is the result you're looking for? <drewverlee>when i run guix system container -L ... container ... it produces an executable, when i run that, it starts a container, it also drops this message: `sudo guix container exec 3987248 /run/current-system/profile/bin/bash --login`. Which is fine for a person to read and copy paste, but it's not ideal for a machine to do a regex parse on to extract that PID if it wants to enter that container. I'm not sure the ideal way to set this up, but <drewverlee>i assume it's by naming the running container, so another process can refer to that name. <drewverlee>The word explicit might have been a distraction. I'm just describing that instead of a random PID, their is an ID/name the user can set, so another program/process can use it. <mange>Hmm. I don't know of a way to get the PID of the container, except by parsing the output of the command. That said, the generated command is a Guile script and the explain procedure handles that printing - you could modify the script itself to extract the PID to some other location. <mange>If you want to patch Guix itself, the script is defined in linux-container.scm. You could add a new --pidfile option and modify explain to print the pid to that file? <mange>Turns out I'm not so good at remembering the names/arguments of things. :P <Serentty>I am trying to set up GNU Childhurd. I have the VM running, but can’t log in because it asks me for a root password. Is there a default root password, or a place where I can set it? <identity>Serentty: (info "(guix) Virtualization Services") has an example that allows you to log in over ssh with a key <Serentty>identity: I don’t see that. I only see the part about how to authorize the client’s build key on the host, not how to authorize the host’s SSH key on the client. <identity>Serentty: “;; Modify the SSH configuration to allow login as "root" and as "charlie" using public key authentication.”? <Serentty>I don’t see those words anywhere on this page. <identity>ah yes, the outdated manual strikes again <identity>switch to the devel version of the manual <kestrelwx>Gooberpatrol66: Are you on a foreign distro? elogind system service has an option to kill user processes. <ArneBab>civodul: I only realized today how deeply you are digging into debugging fibers for the past months already. Thank you very much for that! <civodul>ArneBab: thanks for the kind words! it is quite an effort, but it’s needed <civodul>speaking of which, if anyone would like to step up and (co-)maintain it, that’d be great! <civodul>overall i’m on a quest for stability in Guix/Guile land <ArneBab>I’m just now looking into the sleep re-export again and I use it in a small game. What is needed for maintenance? <civodul>processing issues and pull requests, fixing bugs, etc. <civodul>(for Shepherd i did one stable release per month) <civodul>it’s that sort of thing we need, more than new features <ArneBab>That’s something I might be able to do. I’m using fibers in a small online text-game and have hit quite a few subtleties - and would likely be affected if something breaks backwards compatibility. <lactose>the power button doesn't seem to work in my guix system vm, does anyone know why that is? <ArneBab>civodul: I won’t be able to match your experience right away, though. <jbnote>Hi, for a guix package, are we supposed to build in "developer mode" -- or can we make do with simpler compilation modes? <mange>What does "developer mode" mean? <jbnote>In some packages, it refers to a mode where you have more dependencies, but regenerate more files. In the autotools, for instance, you may need more tools (yacc, bison) to be able to run a "make dist". If you're a "standard user" using the dist tarballs, you won't need yacc or bison to compile, because those files will have been pre-generated. In a cmake project i'm looking at, some files can be regenerated but take more dep <jbnote>-- it looks to be the same kind of concept that some files can be regenerated (typically by the maintainer) or taken as-is. <jbnote>I'm asking because I need to patch those generated files *sigh*. <identity>regenerating the files is the way to go, i assume <jbnote>exactly the answer I didn't want to hear ;) <mange>I feel like the advice in the past has been "use upstream release tarballs", but these days things are shifting more towards "pull directly from their repo and build everything". I imagine if you're patching the generated files then that pushes you more to the latter, too. <mange>That said, I think it also depends on the practical factors - lots of packages still build from release tarballs, so if the patching isn't too intense you could probably go for it. <mange>What sort of patching do you need to do? <identity>if the patching is just a substitute*, then put that in a phase after 'unpack and be done with it <jbnote>a python wrapper to a .so file has specific code for dlopening the file. I need to patch in a hardcoded path to the store. The wrapper itself is committed to git but *can* be regenerated by a python generator by passing specific flags to cmake (which are not set by default). I think i'll make a PR, raise the issue and let people comment. <mange>That's a bit more annoying because it presumably would have be done in a phase to get the right store path, but the as a precedent: vulkan-headers and vulkan-volk packages do exactly that. <mange>Well, sorry, not in a generated file, but in a .c file. <jbnote>OK. I have some time left, i'll try to amend the generator itself. <Deltafire>afaik it's now part of the mesa-updates branch <Deltafire>imo this has been quite a serious issue. The original update stopped a default installation from booting into Gnome, subsequent updates have fixed that but still many problems <Deltafire>i've pinned guix to a commit prior to the libxml2 grafting for now, waiting for a proper fix <gabber>where (or how) can i find an example of a package that downloads additional sources (and prevents the build process to do some `git clone` on its own)? <Rutherther>What does that mean that it 'prevents' git clone, why would you use git-fetch in the first place if you didnt want it to fetch through git? <gabber>Rutherther: i of course obtain the main source tree through our git-fetch, but during build in some make rule the package tries to additionally get some more sources. since this doesn't work in our build env i want to disable that make rule and provide the sources through our store. <gabber>i know i've seen this before but have a hard time finding examples i can copy from <gabber>i guess it's just an additional (origin)? <klm`>Do AMDs integrated GPUs work with GUIX/Linux-libre the same way that integrated Intel GPUs do? I'm having trouble finding info online about what needs nonfree firmware and what doesn't. <klm`>identity: I'd love to, but I'm looking to buy new hardware, and I have no AMD CPUs to try on! <apteryx>klm`: in my experience, they don't (they require nonfree firmware just to output a signal) <mroh>gabber: stockfish loads its neural network from another origin. <gabber>that was exactly what i was looking for! <m4xxed>Hey, can someone clear something up for me, that I might misunderstand?: <m4xxed>I noticed that "guix home describe", "guix describe" and "guix system describe" can all have different commits for the guix channel. <m4xxed>Now I am trying to have my "guix system" fixed to a specific commit, and my "guix home" fixed to another specific commit. I tried "guix-home-channels-service" but found that this actually just manages the "~/.config/guix/channels.scm" file which is not the one used for "guix home reconfigure"... and even with this service, the "(commit ...)" is not <m4xxed>Is there a way I can use my guix-home-configuration to actually fix the commit my "guix-home" uses? <m4xxed>*I meant `home-channels-service-type` <mroh>gabber: an important hack for stockfish was to remove/substitute a Makefile target/depend that wants to download that net. I guess, this might be similar in other projects. <jbnote>what license to use when the source contains a mix of licenses (in this case, ncsa + MIT) <jbnote>the license field for package definition can be a list? <futurile>jbnote: yeah, and basically the purpose is to show all the licenses they've used. So it's often worth spot-checking that it's correct - not every project does it but I often check the headers on a bunch to see that they didn't just click their way through the github buttons <gabber>mroh: that's exactly what i need to do <jbnote>Hi, when submitting a PR, it is not very clear to me if i'm in charge of putting crosses in checkboxes, or if this the responsibility of the reviewer. This is especially true for subjective appreciation (conformance to the guidelines, for instance). I'm very wary of being over-confident and notoriously bad at judging my own work. I can definitely checkbox what i've done though -- like compiling on such or such architecture. <jbnote>tell me how I should handle the rest? <futurile>jbnote: you click the ones you've done, so the reviewer/committer knows what you've attempted. It's trying to tell you to do the things the manual explains that you should do. <futurile>jbnote: I don't personally do things on different architectures - that's what CI is for <futurile>jbnote: but not running guix lint is just lazy heh <apteryx>civodul: I'm trying ot create a token to run sync-codeberg-team, but the doc lacks a bit of guidance: "... where TOKEN is a token created on the Codeberg interface granting access to the relevant settings." <apteryx>what are these relevant permissions settings I need to enable for the generated token? <cmack>I'm seeing a "Git error: object not found - no match for id (...)" when I try to system reconfigure. I've tried deleting the ~/.config/guix/checkouts and running guix pull again but I get the same error with a different id. Is this a known issue? Is there something else I should try? <htgoebel>I'm about to mere my first pull-request after the move to Codeberg. <htgoebel>After rebasing my changes and pushing them to master, how to close the pull-request (while marking it as '"merged")? <futurile>htgoebel: there should be a 'manually merged ..' button. Hit that and cut-n-paste in the commit that you pushed to master. It will close the PR automatically (I think). <futurile>htgoebel: so you push first, then go hit the button <cmack>( I meant ~/.cache/guix/checkouts) <apteryx>civodul: looks like it wants just the 'organization' read/write permission <apteryx>civodul: clarified with commit b03b8d23e0c <ampinga>Hi, I updated my Guix System OS yesterday and couldn't run my VM on gnome-boxes anymore. Does anyone have the same issues or know how to solve it? I need it urgently <ieure>ampinga, No idea, why don't you roll back? <ieure>If you need it urgently, you should roll back and figure out the problem later, when you have more time. <ampinga>I have tried and it didn't work also. It shows the "no KVM" on the GUI <ieure>What did you run that broke things, and what to try rolling back? <ampinga>I use the guix pull then sudo guix system reconfigure command and it began unusable. After I use the sudo guix system switch-generation 29. <ampinga>after the guix pull and guix system reconfigure yes and after the switch-generation command also but still the same <htgoebel>pushing my changes fails with "unknown introductory commit and signer". What am I missing in my setup? <futurile>htgoebel: you probably haven't updated your keyring branch recently <htgoebel>Solved it: I never ran "guix git authenticate" on my clone. Doing so solved the issue. <futurile>htgoebel: then try guix git authenticate oh heh <htgoebel>futurile: While this worked locally, codeberg says "branch master is protected from unverified commit"..Commit is signed, signing key is in keyring. Hmm? <ieure>htgoebel, Codeberg doesn't know about the keyring branch. Likely you haven't added your signing key to your Codeberg user. <abbe>i guess guix system reconfigure is broken ? <cmack>abbe: I'm having troubles with it, myself... so far I thought it was just me. <htgoebel>ieure: Thanks, this was the case. After adding it, I was able to push. <abbe>Git error: object not found - no match for id (d9e2ee3e99475cfa5caa7c9ee7f2f54e3f71215f) <abbe>^ commit signed with key: 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 <abbe>it does not exist in keyring <abbe>cmack: are you also having trouble with that particular commit ? <cmack>abbe: no, my current one is c8201111... but I have tried deleting .cache/guix/checkouts and then guix pull'd and had same error. The commit exists in the checkouts directory. <abbe>strange though guix pull is stuck at <ieure>abbe, "object not found" means a specific commit was referenced, but isn't in the repo. Possible your channels are pinned to a non-master branch? <Rutherther>so where are you referencing that commit in your system configuration? <ieure>abbe, Hm, yeah, I just pulled and I can reproduce your problem. <abbe>Rutherther: not referencing anywhere, it's in the error message <abbe>guix pull is stuck at that commit for me <Rutherther>I don't understand what it means that guix pull is stuck at that commit <ieure>Rutherther, That's not what's happening. Paste incoming. <abbe>while my private mirror's git HEAD is at b03b8d23e0 <abbe>guix pull doesn't seem to fetch new commits and is stalled at that particular commit <Rutherther>oh, I thought you were using guix system reconfigure since you said 'i guess guix system reconfigure is broken?' <ieure>`guix pull' seems fine, `guix system reconfigure' doesn't work. <cmack>ieure: that is my experience too <abbe>Rutherther: the error happens in 'guix system reconfigure' but noticed that guix pull is stalled at that commit <ieure>abbe, `guix pull' gives me the latest commit to master. <abbe>i guess then something in libgit or something <abbe>update-cached-checkout function <ieure>It's check-forward-update that's breaking. <Rutherther>is it skipping the git repo fetch as root somehow? <ieure>Issue seems to be with htgoebel's commit, I was wondering if these were related. <ieure>"Git error: object not found - no match for id (7679fdc8d42be26311db67ffc3a15418624989a1)" <ieure>I think this is a libgit bug, haven't we seen this happen before. <Rutherther>I don't think it's related to that commit. That commit just happens to be the one you pulled to, so it's the one used in the check forward update <Rutherther>I think that if you pulled now, it would move to Ludo's commit that has been pushed like 6 minutes ago <cmack>Yeah, I had problems with c82011112e9b556e73915d85aaf16da9c1e9a40b <Rutherther>I wouldn't be surprised if this was related to 66463356ce5868d3551ea7014acb34543972a5d8, anyway I have to investigate problem in my own software now, so I cannot debug this further now xD <gabber>i cannot reconfigure my system with a current pull either <gabber>with the same error as ieure posted above (about commit 7679fdc8d4) <Rutherther>my guess is that if you do sudo -E, it will work <ieure>I recall this cropping up recently and I think it was a libgit issue. <cmack>deleteing /root/.cache/guix/checkouts also seems to be working for me, who has stopped using sudo -E <Rutherther>sudo -E is dangerous, it can leave your user's cache with root owned files <ieure>futurile, Yes, that's the original date the commit was made, it doesn't reflect rebases or merges. <ieure>I think it's literally a Date: header in the commit object. <ieure>futurile, Yeah, what the check is doing is making sure that the commit of the new generation is ahead of the current one (that the current commit exists in the history of the new one). Those use commit pointers, which use SHAs; the dates don't matter at all. <Rutherther>doesn't symref-list in update-cached-checkout end up with '() when you put commit to ref? Then remote-fetch is not called, because it's under condition that symref-lists is not null... <Rutherther>it would match the symptom that the root's repo is not updated <Rutherther>I don't really understand why this condition has been added in the first place, though <Rutherther>okay I think this condition has been added to prevent unnecessary network traffic <Rutherther>but there must've been an oversight that it won't work if you're pulling to something that is not a symref <Rutherther>this is also the reason why guix pull is staying at the same commit then <Rutherther>because it doesn't update the checkout, so it picks up the old commit <Rutherther>(although I haven't tested it locally yet I am quite convinced this is actually the root cause) <untrusem>hello guix, long time no see. I didn't have my machine. <Rutherther>ieure, futurile: this new bug is very unfortunate though. Because anyone who updated, got no errors at all. And they won't be able to update to the fixed version! <untrusem>rutherther, are you talking about the libxml issue? <gabber>untrusem: failing at multi-tasking while my body hurts, so same fun different day (: hbu? <untrusem>just opened my machine after 20 days, just catching up on things and fixing my guix packages pull requests <ieure>untrusem, T480 is a great machine. I like to buy used and refurbish myself. :) <gabber>so, am i now just stuck on my 7679fdc checkout? <gabber>guix pull does not do the trick and neither does `guix time-machine`? <gabber>ah, maybe i should roll-back and pull again? <untrusem>ieure, you really should, I am also looking into refurbished smart phone. <untrusem>also need to get a old-school camrecorder I wanna make videos on peertube <Rutherther>gabber: yes, it's a bug. You will stay stuck forever if you keep pulling. :))) <ieure>untrusem, I bought my last phone new (Pixel 8, running Graphene), but my last couple before that were ~2-year-old refurbs. <gabber>i pulled into 7679fdc and was unable to pull newer guix checkouts. thankfully rolling back does the trick <ieure>untrusem, Makes it a lot easier to swallow that they're unrepairable bricks when I'm spending $150-$200 for a phone I use 3-4 years, instead of $1000+ for a phone I use 1-2. <untrusem>ieure, my current phone which have lineageOS in it is now 4.5 years old, it works super fine but now the hardware is acting finicky, like the power button, the headphone jack etc <untrusem>gabber, ohh I am on d9e2ee3e99475cfa5caa7c9ee7f2f54e3f71215f <gabber>untrusem: i guess if you pulled now then you might be stuck <gabber>Rutherther, ieure have we tried pinging ludo? after all it's their change that broke the pulls (and i guess they both want to know and have ideas on how to fix it) <Rutherther>I've pinged ludo on the PR and also sent an e-mail <abbe>Rutherther: thanks, with that patch applied in a local guix checkout: ./pre-inst-env guix pull now pulls new commits. <gabber>Rutherther: should i push or shall we wait? <gabber>not super keen on pushing but leaving the project in a somewhat broken state is far from desireable <Rutherther>gabber: I don't know tbh. Zimoun is commenting that my change breaks QA, but I don't really understand how that could be. But I agree their change is better in the long term, I will test it shortly as well <gabber>Rutherther: i guess the right thing to do were to roll-back the offending commit and open an issue <Rutherther>that I cannot agree with as that will indeed break QA <gabber>then we can push again when the introduced breakage is resolved <gabber>Rutherther: sorry, i meant reverting <Rutherther>I know, reverting it will break QA (again), it's supposed to be alright for the day it was applied :) though I haven't really checked if it is actually alright <Rutherther>maybe you could say that since it's been broken for some time, and now alright for a day, it might not matter that it will get broken again <levenson>I have couple of updates to dvd related packages and was wondering if I can send them as a one PR? in particular add lsdvd, update libdvdnav and dvdbackup fix to build with libdvdread 6.10+ <gabber>i don't understand how this would affect QA <gabber>levenson: if they are related (meaning: all changes work on the same goal) you can <gabber>but adding packages and updating some others are single commits <gabber>but you can (of course) use many collected in a single PR <Rutherther>see the etc/committer.scm script for automatically committing package updates <levenson>gabber: absolutely. 3 different commits. <Rutherther>gabber: okay changed my mind after understanding what zimoun was afraid of. I think both PRs do the same thing in the end, so I don't think zimoun's change is better than mine anymore <Rutherther>when's the no major changes period for the upcoming release, does someone know? <futurile>Rutherther: I don't know if efraim managed to move forward, but AFAIK we haven't actually kicked off <futurile>I think baleine sent an email in August, I was going to touch-base and see if they still had bandwidth <Rutherther>yep, I saw it and just replied to it as it seems there is not much activity. Seems that we're already behind schedule, at least if sticking to the template <klm`>apteryx: oh gosh. good to know. I will buy a new Intel-based machine then. thanks for letting me know. <futurile>Rutherther: yeah, guess the template is going to turn out to be aspirational <loquatdev>ieure, I installed Guix on a new drive and put it into the build machine. I built the package again and it still has the exact sames series of hashes. I'm not home at the moment, so I can't test it on that third machine, but I'm beginning to suspect that there's either something wrong with my secondary machine or something non-deterministic about my package. <loquatdev>ieure, I know it's been a day since I messaged you about this, so I apologize if this is out of nowhere <Elouin>Hi, since today i am getting `guix deploy: error: while setting up the build environment: getting attributes of path `/etc/services': No such file or directory <Elouin>when trying to run `guix deploy`. <Elouin>Is that because on my host system its at /usr/etc/services? <Rutherther>Elouin: yeah, /etc/services is currently expected to exist, and I am not even sure if the tools used by guix would try to look for it at /usr/etc/services if that was added to the container instead <Elouin>Hmm, okay. Would be nice if it would look for that as well or it would be possible to provide it via an cli option. <Rutherther>this requirement has been there for some time, so I don't think 'since today' is related to Guix. But I might be missing something <Elouin>Dont think opensuse moved it just now... <Rutherther>it could also be that you have never had to build any fixed output derivation since you could always substitute the results or substitute the source <Elouin>Hmm, true. Or maybe they patched it in the guix from the suse repos and removed the patch in the last update or soh <Elouin>Would like to deploy and really dont like linking system stuff in /etc... <Rutherther>I am not sure (sym)linking would work anyway. Maybe a bind mount (or a hard link, but there you will end up with differing files if /usr/etc/services changes) <attila_lendvai>my guix is sending a dhcp request every minute. it's using NetworkManager on Gnome. any quick ideas? <Rutherther>Elouin: symlinking could work if you added --chroot-directory=/usr/etc to the daemon. But I would rather not do that as exposing any more files to the chroot asks for non-reproducible builds <attila_lendvai>hrm... the lease file /var/lib/NetworkManager/internal-[...].lease only has a single ADDRESS= entry; i.e. no lease is stored <attila_lendvai>the NetworkManager.conf in the store has a single dns=dnsmasq entry under [main] <Elouin>Rutherther: Thanks, will try this. <futurile>guess civodul has gone home for the evening and Simon says he doesn't have commit access <simendsjo>I get Git error: object not found - no match for id (c33db8571ae46feb457917327db8f6f91599e997) when trying to reconfigure, but I have this commit in the channel as stated by guix describe (it's the latest commit in nonguix atm). Any idea what's happening here? <Rutherther>for workaround for now, do sudo -E to pass your user's cache that already has the commit available (while the root's doesn't) <Rutherther>after a fix is merged, you will have to revert guix / remove the cache prior to the problem as you won't be able to pull (pull will stay at the same commit) <simendsjo>Rutherther: Thanks. Looks like I can pull with --commit, but you're saying it wont actually work? <Rutherther>pulling with --commit to an already existing commit will work. To a new one not <Rutherther>the only way to trigger fetch of the checkout is with a symref (or manually) <simendsjo>I pulled the commit before the offending commit and reconfigured successfully. I'll keep an eye out for the fix before pulling again ;) <ieure>Rutherther, This PR is ready for merge? I can push if needed. <Rutherther>futurile: has self assigned it 22 minutes ago, so maybe he is already planning on pushing it <futurile>My dev env was in a mess so I'm literally just building a new worktree <futurile>if civodul wants a different fix in the morning then fair enough, but having broken users that will never move forward is bad <jlicht>lol I was already thinking I’m crazy, with my guix pull refusing to move forward. Anything I can do to help verify the fix? <simendsjo>I was able to pull and reconfigure my system and home. <jlicht>ieure, Rutherther: thanks for being on top of this stuff \o/ <Rutherther>why do I always realize I could've written something much more clearly only after I hit send? xD <Deltafire>because if you'd realised before you would have already re-written it <jlicht>"ship it, we'll fix it in prod" applied to email :-) <Deltafire>i had to look-up what the @ function did, neat :) <jlicht>Did @@ work for exported symbols as well? <ttz>Hi, I am trying to write a new OpenSSL derivation by inheriting the one from gnu packages tls. I cannot remove the patches line without the final derivation referencing perl, causing an installation failure. Could someone help me figure out why? My code is here: https://paste.debian.net/1397859/ <civodul>ttz: hi! that’s because the patch you’re removing is precisely about not having a dependency on Perl <civodul>that no-dependency rule is enforced via #:disallowed-references <ttz>oh thank you very much, I wasn't able to find out where to look for this patch <ttz>so that I fully understand, what is this patch exactly modifying? <ieure>ttz, I'm not sure what answer would be helpful to you; the patch itself shows exactly what it's modifying, as well as why it's doing that. <ieure>Is there some part of that which is unclear? <ttz>does the modified file belong to openssl sources? <ieure>It's a patch in the openssl package definition, that's the only thing it can be applied ti. <ttz>I wonder if that makes using the produced binary invalid when using the certified version of OpenSSL is required... <ttz>since the build process actually tempers with the sources <ieure>ttz, Are you talking about the FIPS validation? <ieure>Seems like "yes," the OpenSSL docs say "In order to be FIPS compliant you must only use FIPS validated source code." And the Guix patches are not FIPS validated. <ttz>that's what I was thinking <ttz>Would there be a way I could build without this patch? <ttz>I see the line #:disallowed-references (list (canonical-package perl)) in the v1.1 definition <ttz>Could I remove it to remove the patch, even if it means depending on perl ? <ieure>I'm not sure, the removal of the perl reference might be a nice-to-have which reduces the openssl closure size; or it might be required for bootstrap ordering, like there's a perl->openssl->perl dependency cycle which this breaks. <ieure>ttz, You will have to experiment. <ttz>okay, I will tried some things then <ttz>Unrelated question, but why isn't a newer version of OpenSSL packaged? Guix only packages v3.0 while the new v3.5 LTS version was released. <ieure>Because nobody's done it yet. <ieure>Unsatisfying answer, but Guix is a small volunteer project, updates rely on people being motivated to do them. If something hasn't been, it's because nobody has been motivated to. <ieure>Work on Guix is very loosely organized. <ttz>okay, I thought there was a technical issue with upgrading <ieure>There might be, I don't know. <ieure>There are often technical issues lurking in work nobody has looked at. <vagrantc>openssl is also probably low on the bootstrap chain, so might trigger a lot of rebuilds, which tend to be put off as long as reasonably possible <ieure>Yes, was just going to mention that as well. <ttz>okay, I will see if inheriting the v3.0 definition with updated URLs is enough <vagrantc>merge commits have been discouraged for a while, although there was a recent discussion about rethinking that... <ieure>I personally loathe merge commits and avoid them wherever possible. <vagrantc>seemed like the direction of the conversation was to rebase and do fast-forward merge commits ... getting some of the best of both <ieure>Merge commits make tools like bisect much, much harder to use. <vagrantc>git rebase and git merge --no-ff ... largely solve that problem <vagrantc>e.g. do a merge commit even if it is fast-forwardable <vagrantc>leaves a marker that something was merged ... while still keeping a linear history <ieure>vagrantc, Not sure how that works? Any merge commit means non-linear history, because merge commits have >1 parent. So traversing from HEAD to an arbitrary commit requires choosing which path to follow any time it encounters a merge commit. <vagrantc>ieure: i think it just makes a basically no-op commit on an otherwise fast-forward history <ttz>In the build of v3.0.8, the OPENSSLDIR variable (displayed with openssl version -a) is set to OPENSSLDIR: "/gnu/store/50j99apijrp9fgdlw718d6bkg32fxapj-openssl-3.0.8/share/openssl-1.1.1u", which references v1.1.1u. Is this a bug? <ieure>ttz, Genuinely no idea, seems suspect though.