IRC channel logs
2025-05-28.log
back to list of logs
<jlicht>There's now an ✨AGit✨-based workflow, if patches are not your thing <podiki>tell me more about this agit-based workflow...where can i read about it? (seen it come up but i'm behind) <meaty>it lets you make PRs without creating a clone on your account <bdju>jlicht: I'm not a programmer, I don't want to set unrealistic expectations here and stop anyone else from working on it. <bdju>Reporting issues is about the extent of what I do. <jlicht>bdju: wasn't trying to push any expectations on you, so we are in agreement :) <cobra>is mpdris2 broken for anyone else <graywolf>Hm, quick search suggests that adding setopt +o nomatch into the profile script should suffice <jlicht>cobra: as in, it doesn't build? (It builds for me). Or that it doesn't work? <cobra>this issue hasn't been reported to the github so it might be a guix one <apteryx>hm, the go importer doesn't sort inputs. seems easy to fix <apteryx>any idea why 'guix import go gopkg.in/h2non/gock.v1' fails ? <apteryx>I'm nearly done, just missing two go packages: go-gopkg-in-h2non-gock-v1 and go-gopkg-in-src-d-go-git-v4. <apteryx>oh, this worked: guix import go github.com/h2non/gock <apteryx>what makes a substitute server fast vs slow for substitutes lookup? is it nginx cachig? <apteryx>throughput is great though; it saturates my aging home router's bandwith, at around 14 MiB/s <apteryx>alright! /gnu/store/4pm36yla5l67ldzy95ldfkabcdlp2v73-git-repo-go-1.0.0 built <cbaines>apteryx, latency is the killer for narinfo requests <apteryx>aren't they supposed to be chained on a single connection? <apteryx>or the connection reused; I thought that was a past optimization that was made <cbaines>they are, although the proxy might not do this when proxying the requests <janneke>apteryx: yes! and i can very much appreciate that a feature like this needs to be handled with some care <meaty>how do I close mailing list issues again... <ruther>meaty: e-mail to <ISSUE>-close@debbugs.gnu.org <meaty>was looking around in the mailman docs :p I should get some sleep <apteryx>SSH access to berlin doesn't seem to work <apteryx>actually, already packaged, trying to fix the integration test suite atm <csantosb>By the way, any news on the emacs-team branch merge ? <efraim>janneke: I'm just messing around right now, the installer supports i586-gnu but not x86_64-gnu? <mra>been following the news about the codeberf migration. exciting stuff! <jlicht>mra: the typo made me snort my coffee :') <mra>jlicht: LOL I didn't even notice <janneke>efraim: yes, there's no 64bit installer support yet, we also don't have a 64bit chilhurd yet <janneke>i've been "waiting" (or at least posptoning) work on that until core-packages-team merges <janneke>efraim: and i'm not sure yet how to best proceed; select x86_64-gnu when running on 64bit linux (for installer and childhurd), or offer all choices? should we drop i586-gnu? <efraim>janneke: I think for now we can support both. I was mostly messing around with the release/installer manifest to make sure it covered enough package options <efraim>I figure it makes the most sense to follow whatever upstream is doing <gerogaga>Hello, is there a way to somehow dispatch on the output of a package? <ruther>gerogaga: what do you mean by dispatch? <gerogaga>I have two outputs, "static" and "shared", and would like to change the arguments (#:configure-flags specifically) depending on which output is being installed. <ruther>gerogaga: no, that isn't possible, there is just one argument for the whole build. Everything is built in the process and then copied to output you want <ruther>gerogaga: if you want to change the flags etc, you might rather want to make two packages, the second inheriting from the first one <gerogaga>How do "lib" or "doc" outputs install only their respective part of a package, then? <ruther>gerogaga: as I said, everything is built and then copied to the output you want <ruther>gerogaga: if you mean why install doesn't get all the outputs, that is thanks to substitutes. If you weren't using substitutes, you would need to build all outputs <xelxebar>Is there a way to drop into a shell of the build environment for a package? <ruther>xelxebar: yes, that is what the -D flag is for <PotentialUser-93>with zig build system I get the error: "build.zig.zon:2:14: error: expected string literal", when I build it locally with zig@0.14.0 or zig@0.14.1 it works (so I guess the build system uses an older version) but somehow when I try to pull and install from my repo it doesnt work, I used to be able to select the zig version with "#:zig "zig@0.14.0"" <xelxebar>ruther: Not exactly. Even with --container, it appears we have /tmp and /bin/sh, which are apparently missing in a build env. <PotentialUser-93>yes indeed, for the build it uses zig@0.13.0, but I dont find how to use another version <ruther>PotentialUser-93: I have doubts that ever worked. It is very unusual to support specifications in place like this. You usually put the symbol having the zig package there. <ruther>xelxebar: yes, if you meant you want to replicate the container of guix-daemon, there is not automatic way I know of, you would have to make your own container. <PotentialUser-93>ruther: thanks for the reply, not sure what you mean, where should I put the symbol in the package definition ? I am not very familiar with it yet <ruther>PotentialUser-93: #:zig zig-0.14 <PotentialUser-93>how can I find that "zig-0.14" ? when I do guix shows it usually show something like "zig@0.14.1" <ruther>PotentialUser-93: zig@0.14.1 is a specification. To find the symbol, you can usually just grep the source. Alternatively you can use guix edit to jump to the location direction and usually see the symbol - `guix edit zig@0.14` <PotentialUser-93>I see, thank you so much, hopefully it will finally build xD I am trying to make a very basic "fortune" program in Zig since I couldnt find "fortune" in the repo and I am not super familiar with which license is ok for guix repo (if someday I can push my package on the guix repo) <ruther>xelxebar: rereading your message. I noticed you mentioned /tmp. I think /tmp is in the guix-daemon container. You're right that /bin/sh is not there by default. <xelxebar>ruther: That's exactly what I wanted to check, actually. <xelxebar>Trying to build a package, but tests fail because swi-prolog tries to call out to /bin/sh. <ruther>xelxebar: the build should actually be happening under /tmp in the container, specifically something like /tmp/...-guix-...nameofthepackage...-0, forgot the specific parts. And /tmp should be writable. But note that you won't see the contents when you do --keep-failed, only the /tmp/...-0 folder is kept (and in the base filesystem it can have other number than 0). <xelxebar>Our swi-prolog package doesn't pin the runtime shell, so I've just now patched the package and confirmed it works. <ruther>so imo it is better to just set TMPDIR to something under cwd of the build if the build environment really needs to use TMP for something meaningful <xelxebar>However, the same tests are complaining about trying to create a fifo under /tmp. <xelxebar>ruther: Hrm... Good idea. Hopefully, swipl respects TMPDIR. <cluelessguixer>"No action is needed on your side: `guix pull' will now automatically fetch from the new URL, unless your `channels.scm' files refer to the former URL". Doesn't this imply you can just remove the "guix" channel in channels.scm? <ruther>cluelessguixer: not really remove it, but you can use %default-channels from the guix repo that has guix <xelxebar>Gah! This is maddening. I can build a package just fine in a guix shell --container, but mirroring the same inputs and make-flags in my package causes the bin/exe to do something completely bizzare. <JodiJodington>just as a sanity check, you can do `--verbosity=3` and see if the flags being passed to make (and everything else) are the same as what you used to build it in your container <futurile>migration to Codeberg looks like it's going well so far <ruther>yeah, I think there was just one issue, of broken master - unsigned commit <ruther>does anyone know if the codeberg's rule for pushing signed commits checks if the commits are signed by right people, or just signatures in general? <ruther>fanquake: I suppose. Unfortunately I didn't really find time to debug it further to isolate what issue causes it in my guix home config. <untrusem>I want some setup tips regarding that as guix doesn't have some modules and wiki as archlinux <fanquake>Seems like it was supposedly fixed, but I can clone guix onto a system, and immediately run into the same issur <ruther>Though with my guix home config it is at least consistent. <ruther>fanquake: it was fixed for guix system container <ruther>fanquake: but guix home container / even guix shell -C can still show that issue <fanquake>Yea, I see it was "guix shell -D guix -CPW" <fanquake>or doing builds with our manifest, when pointing to a newer time-machine <ruther>fanquake: do you get it consistently when you rerun it? <ruther>fanquake: can you try with --no-cwd? <ruther>fanquake: for the record I can run guix shell -D guix -CPW without issues on 3 day old guix <fanquake>My guix is ~11 hours old, according to guix --version <fanquake>Adding --no-cwd still gives the same failure. i.e guix shell -C --no-cwd -D guix <ruther>fanquake: thanks for confirming, okay <ruther>fanquake: and the error is really the same as in the issue? - if you're unsure feel free to send it <ruther>fanquake: I think it is the same issue as I reported <ruther>but it is much harder to find out what it is since it seems to be something specific to your setup <ruther>I just tried with latest Guix and it works for me <fanquake>this is just apt installed guix on Ubuntu <fanquake>I see something similar with a manual install on Alpine Linux <ruther>fanquake: have containers worked there previously? <fanquake>Yea. Have been using the same setup(s) for years <ruther>fanquake: okay. I was just asking because I realized I wouldn't know how an error about not supported user namespaces would look like <fanquake>I can try and bisect, just wanted to see if I was missing something <ruther>fanquake: that is probably unnecessary, it is quite likely it is going to be the add lock-mounts commit <ruther>a57ed987ffd1452ba5a4d70feb54893e99b8e076 <Kabouik>What would be the most straightforward way to install an old version of a software that is no longer in the channels? Say for instance I want to show a friend how they can easily use Guix to install R 3.8.0 while the current version in the channel is R 4.4.0. Is `guix time-machine` combined with a manifest and channels.scm containing git hash really the simplest? `guix describe` is by no mean trivial if you just want to install an old release but <Kabouik>don't know much about the git history of Guix. <Kabouik>Package transformations, maybe? But wouldn't they clash with other the dependencies that are not sync with that old version being requested? <ruther>package transformations are unlikely to work with major version updates <ruther>and yes, dependency versions are also a possible problem <Kabouik>So that means the workflow would be to check the git hash of the Guix channels that had the target version, create a channels.scm listing this hash, and then invoking time-machine and shell to install it (and also preparing the work to easily redeploy this shell later if this not a one-time use)? <ruther>Kabouik: yes, although I don't understand what you mean by 'preparing the work to easily redeploy' <ruther>Kabouik: you can also check guix-history channel if it has the package you want <Kabouik>I might have oversold it a bit to colleagues saying they could *just* install the old versions (not mentioning it clearly but kinda implying it would be like `guix install r@3.8.0 and profit`) and then detailing how that would work in terms of user Guix profiles vs /gnu/store. :< <janneke>Kabouik: istm that R 3.8.0 was never packaged for guix? <Kabouik>Re: preparing the work to easily redeploy: I meant creating manifest.scm, channels.scm, and possibly a .sh script with their Guix time-machine -- shell command, and then getting used to using that every time they want the specific older version instead of the system one. <janneke>git log --oneline | grep 'gnu: r-minimal: Update to' <janneke>2490649d0d gnu: r-minimal: Update to 4.5.0. <janneke>d22546cf80 gnu: r-minimal: Update to 3.5.0. <Kabouik>janneke: it was just a random example <ruther>Kabouik: I mean if you are going to use a sh and only guix channel, there is no reason for channels.scm, you can use --commit <janneke>if you'd be wanting to show r 3.5.0, you could do something like: guix time-machine --commit=2490649d0d~ -- shel r r-foo r-bar r-baz? <janneke>you'd have to ask git for what 2490649d0d~ resolves to... <ruther>janneke: 2490649d0d is already fine, git is asked automatically :) <Kabouik>Exactly janneke but invoking time-machine and shell and then listing packages (and therefore probably a manifest file if there are many) differs from their usual workflow, and that implies doing some research before to find the commit (which is not that straightforward if users don't keep a local copy of Guix's git). It's fine, it's great that it's even possible, but I oversold a bit that it would be a piece of cake like `guix install r@3.2.0` would <ruther>Kabouik: every guix user keeps a local checkout of guix in their cache at least <apteryx>csantosb: phew, the integration test suite fully passed <Kabouik>ruther: could you elaborate? Like I inspect Guix's git, find the commit that contains the version I want, then use what janneke posted (instead of a channels.scm containing hashes), correct? <Kabouik>ruther: hos is this local checkout inspected, and previous commits? I have a manually cloned folder on my system, but your comment makes me think this may not be the best approach if `guix` cli already covers that. <ruther>Kabouik: the same way any git checkout is, it is under ~/.cache/guix/checkouts <Kabouik>Ok but then there's no built-in command to inspect old commits and find the hash that contained the software version the user wants <ruther>Kabouik: I don't know what you mean by that, that command is git, janneke already showed how to do it <Kabouik>Alright, I overlooked that the command would return all matches. I don't know why but thought the content of ~/.cache would not have the exhaustive git history and would only contain recent guix pulls. <JodiJodington>you can probably git-blame the version field in the record, but it's not going to be super accurate <ruther>Kabouik: cache contains the whole history <Kabouik>So yeah, that git command would allow finding the hash for the target software, then the user writes their .sh script for `guix time-machine --comit=xxx -- shell r r-foo r-bar` (or manifest.scm)`, and the first run installs it, the next ones just redeploy that shell from /gnu/store. <Kabouik>The git command is not exactly straight forward for untrained users, it would be great to have a guix subcommand doing exactly that to help convincing new Guix users interested in the version management thing (e.g., `guix search --history r` being an alias for `cd ~/.cache/guix/checkouts && git log --oneline | grep 'gnu: r: update to'`) <Kabouik>I can't find the repo of the guix-history channel you've mentioned ruther. Looks interesting. <Kabouik>And thank you both ruther and janneke for the helpful answers! <Kabouik>Oh right, I knew about guix-past (but don't think I needed it so far). <civodul>Kabouik: oh you’re the person who emailed guix-science; hi! :-) <Kabouik>My guix pull was started at 17:14 and is still ongoing, by the way, but my machine is not exactly an HPC. :> <Kabouik>I didn't know some PEPR programs had ties with Guix; that's interesting. PEPR is a magic word that can ne used to mind control some researchers. <ruther>Anyone knows how the device tree blobs are built with the linux-libre kernel? I noticed that for example mnt reform linux-libre has phases that touch the device tree makefiles and it seems the linux package would copy the dtbs if there were some, but the device trees are nowhere to be found in the package output. Can I somehow enable compilation of dtbs? <ruther>or should I just manually create phases calling make with the dtb? <hanker>what happened to gutenprint on guix? <lfam>hanker: Apparently nothing <lfam>It was never part of Guix, although someone did try to add it, the contribution process was not completed <yelninei>killing a build process after 5h never feels great <ieure>I think the only builds that have taken me that long are compiling aarch64 binaries on amd64 with QEmu. <yelninei>gcc-final offloading to a hurd vm and qemu became unresponsive <hanker>> It was never part of Guix, although someone did try to add it, the contribution process was not completed <hanker>Sad. What stopped it? Is there a way to use the driver regardless? <nico_>How do I verify a package install including a patch? My work in progress is here https://codeberg.org/guix/guix/pulls/85 but I don't know how to test it. I tried in the pure shell, but somehow gtk build failed and I cannot seem to get over it. <lfam>Then, read the subsequent chapter Running Guix Before It Is Installed <lfam>Use the './pre-inst-env' script to test your edited package <ieure>nico_, Agree with lfam. You probably want to `./pre-inst-env guix shell ansel' to test it, rather than installing. <lfam>nico: The alternative option is to use `guix time-machine`. Something like `guix time-machine --commit=$the-commit-of-your-pull-request -- install $your-package` <lfam>Or instead of using install with time-machine, you could use shell <ruther>you can install with ./pre-inst-env <lfam>pre-inst-env is great if you plan to keep contributing. It's quick and dirty for testing. Time-machine is more of a complete test but its generally slower <noe>With the move to codeberg, do we keep the convention that patches/pull requests should be rebased instead of adding new commits when making a new version? <lfam>noe: Can you clarify what you mean? <nico_>lfam, I am trying with pre-inst-env, but somehow my gtk build failsed and my package still builds, causing it to fail. Can I reset the pure environment, or it that not necessary? <ieure>noe, I understand what you mean. Yes, you should edit your commits and force-push, rather than adding new ones. <ieure>noe, I have mixed feelings about this. <noe>me too, that’s why I’m asking :P <lfam>nico_: If GTK failed to build, that doesn't really have anything to do with your testing workflow. Either the build is broken and a bug needs to be fixed, or your computer lacks the resources to build GTK. Do you know why it built? <ruther>noe: how would move to codeberg change that? <lfam>nico_: I mean, why it failed to build? <noe>Codeberg shows the full changes diff, so adding a new commit is no different from rebasing now. Where it used to be that sending rebased versions was better to apply them easily. <lfam>We still want a simple linear Git history, which means either rebasing or cherry-picking commits <ruther>noe: I don't think that is the reason why adding new commits has been discouraged <ieure>Correct, it's all about having things clean after the changes get applied to master. <ruther>noe: the reason is that there shouldn't be unnecessary fixes etc. in the history. So if you're adding a package and find out there is an issue with your current definition, why would you make a new commit to fix that, unnecessarily polluting the history? <ieure>We don't want a bunch of "oops fix the thing" commits. <ruther>nico_: you need to look into the log <lfam>nico_: Notice the line that reads: "View build log at '/var/log/guix/drvs/nm/709lr1agm2f2p4dfgpmg08rg7qj96m-gtk-4.16.13.drv.gz'." <nico_>How do I look in .drv.gz, it is a binary file <ieure>Or Emacs will open it transparently. <lfam>nico_: Lots of editors will open it for you, or you can use `gzip -d` on it <lfam>It's compressed with gzip to save space <noe>> noe: the reason is that there shouldn't be unnecessary fixes etc. in the history. So if you're adding a package and find out there is an issue with your current definition, why would you make a new commit to fix that, unnecessarily polluting the history? <noe>Okay, that makes sense. I just thought it was a bit harsh to ask a contributor to do a complex rebasing to put his changes between three commits, when he did nice fix commits with the ChangeLog format. <nico_>Thanks. Have to go, but being able to view logs should help <ieure>noe, "his changes" -> I wouldn't assume gender of contributors. <lfam>noe: It's okay if that task is too complex or confusing. You can just say so and ask the reviewer to help with it. <noe>ieure: my bad, thanks for reminding <lfam>Git rebasing is at least intermediate level Git skills and takes a while to learn <ieure>lfam, Many of the common Unix utilities have "z" prefixed versions for dealing with gzipped files. zcat, zless, zgrep, zdiff, etc. <lfam>We'll get there together :) <lfam>Ultimately, we have standards for this stuff and we can all collaborate to uphold them <lfam>noe: Do you want me to rebase the commits and update the pull request for you? <noe>Yes, sometimes its good to be strict! It improves the level of everyone and makes it easier for later contributors. <noe>lfam: I rebased on my side, I was doing a user review :) <lfam>Okay, great :) We are always happy to help with this kind of stuff <noe>Well, they have already rebased! So all is good :) <noe>Anyone else getting 500 errors when viewing pull requests on the guix repo? <ruther>noe: yes, I suppose the PR might have too many changes so the server cannot process it <Kabouik>So ruther, janneke, I tried running `guix time-machine --commit=4a0b87f0ec5b -- shell rstudio r r-ggplot2` (those packages are from guix-science and guix-cran) on my own machine as an example, more than an hour ago, and it's just endlessly building guile-2.2.4. Is that expected? I tried with `rstudio` as package because most users of the cluster use this IDE, so I wanted to try something realistic. <ruther>Kabouik: I would expect it to finish at one point. But that it is building it? Yeah, that can happen. You would have to pick a commit with substitutes, that is quite hard to do. Just picking a commit in the history will likely end up with one that doesn't have substitutes <ruther>...because it is probably part of patch series and was never HEAD of master <Kabouik>I'm just surprised that it would be so long that one hours later, it's still building one of the first dependencies pulled by the command. I'm concerned this won't fly if I make a demo of the workflow to potential users and the command can't run before the meeting is over. <Kabouik>Of course I could cheat and run it in advance, and then just redeploy the already installed shell, but in reality the issue will show up when they try to do the same. <ruther>Kabouik: you would need to pick closest commit that was built. For that you could use API of cuirass, but it would require a script that I am not sure anyone has done yet <Kabouik>Hum. I understand why it's rebuilding world, but in practice this is going to be an issue, for demoing the workflow as well as in a real world scenario. <ieure>Kabouik, Hmm, I thought we had substitutes for old versions going back several years... I remember civodul mentioning some stuff around this in the last year or so. <Kabouik>Maybe there are, but if I understand well what ruther said, it's likely that the commit I'm targeting doesn't. And also I'm using guix-cran and guix-science, not sure if they also have substitutes? <ruther>that could also be it, but I am assuming guile is coming from guix channel <JodiJodington>you might have better luck using `git grep` on past commits contents instead of just the commit messages so you can find the latest commit before it was updated <JodiJodington>currently trying it out with commit f1fe5283c9f8eb6890b3e6dc3c09a00f4da19472 but guix time-machine is taking a while to pull it, might be faster on your computer <ruther>JodiJodington: there should be no need for that, you can just find the commit it has been updated and go to its parent <cluelessguixer>Is "ps aux | grep "shepherd.conf"" the best way to get current running containers? <vagrantc>there was a thread a while back discussing why to rebase instead of merge, most notably because there are some cases where a merge makes it nearly impossible to tell what actually introduced a change depending on how conflicts were resolved <ieure>Merge commits are awful, I hate them. <vagrantc>but i also hate it when signatures do not match the committer or signed-off-by <ieure>Hmm, I don't think I've run into that. <vagrantc>most times a team branch gets merged, the signatures do not match, as inevitibly it ends up gettin grebased more than a few times by different people <ruther>vagrantc: is rebase not resigning always, and changing the signed-off-by to you? <ruther>(the commits that get commited by the rebase) <vagrantc>re-signing hundreds of commits ... reduces the confidence in the signature <ieure>ruther, It changes the committer to you always, it add Signed-Off-By if you give the --signoff option. <vagrantc>i do not think rebase changes the committer <ieure>The Author remains the person who wrote the commit. <ieure>You might be right about that. It definitely doesn't change the author. <vagrantc>the committer is usually hidden in the interface <ruther>ieure: so should you give --signoff when rebasing or not? Using it would ensure matches between the signatures and the signer, right? <ieure>ruther, Author, signed-off, committer, and GPG signature are all independent things. They can all be associated with different people. <vagrantc>ruther: i would think --signoff should be used in general ... not sure what the docs say off the top of my head ... but i definitely remember reading somewhere that the signature is supposed to match the author or signoff <ieure>ruther, So it's a project standards thing what you want more than a technical one. <ruther>ieure: yeah, I am asking about project the project <ruther>vagrantc: so the mismatch between Signed-off-by and the signer you talked about come from people not using --signoff? <ieure>I've been using --signoff on Codeberg, but purely because it ensures that the commit gets rewritten, which ensures it gets signed with my key. <luca>signoff the thing that adds a Signed-off-by trailed has nothing to do with the cryptographic gpg signing though <ruther>Kabouik: that might also be the reason why guile didn't have substitute in the first place <vagrantc>luca: technically no, but in the guix project it is my impression it should match <vagrantc>e.g. documented policy vs. technical implementation <ieure>I think the from the project perspective, what we want is for the Committer header and GPG signature to match, and the rest doesn't matter. <ieure>But IANAL (I Am Not a Ludovic) <vagrantc>"When pushing a commit on behalf of somebody else, please add a Signed-off-by line at the end of the commit log message—e.g., with git am --signoff. This improves tracking of who did what." ... and all commits must be signed ... so if you push a change, presumably you should not be signing as someone else <ruther>vagrantc: does it improvde tracking though? Since Committer is updated as well with am, isn't it? <vagrantc>and has the side-benefit that ieure mentioned of actually re-signing the commit because the commit message changes <vagrantc>ruther: because git log does not show committer by default <ruther>vagrantc: I think that with git am it will always get signed, but I am not completely sure. It is true that with codeberg where you rebase/cherry-pick instead that is not happening anymore <vagrantc>i have had somme surprisinng situations where rebasing ended up with commits in the middle unsigned <ruther>yeah, that can definitely happen <luca>Well multple people can commit. I once picked up a commit by someone and rebased/fixed-up and signed it off myself, even though I am not a maintainer <vagrantc>with --signoff ... unless it already had your signoff ... it will always change the message and should re-sign <ruther>vagrantc: I was just commenting that specific situation of git am previously <vagrantc>there can only be one committer, but there can be multiple signed-off-by lines <vagrantc>at least, i *think* there can only be one committer, one author, etc. <Kabouik>ruther I think maybe I was trying to redeploy overly old R versions and somehow this proved unreliable. It seems that a real issue if we count on this for reproductibility, but maybe that hash from 2019 was before the Guix shell/time-machien workflow was stable. Anyhow, this is because finding the git hash in the Guix channel version history was based on a grep on "gnu: r: Update to" or "gnu: r-minimal: Update to"… But that doesn't work when the <Kabouik>commit message is "gnu: r-with-test, r-minimal: Update to" for instance, so I was missing more recent commits. <vagrantc>but you can have arbitrary *-by lines in the commit log ... obviously don't want an arbitrary proliferation <Kabouik>I'm trying a more recent commit and it seems to be finding substitutes, although it's still long and not completed yet. <ruther>Kabouik: no substitutes has nothing to do with stability of time-machine/shell, that has to do with that specific commit you're trying to use <Kabouik>All in all, I think this shows a reproducibility issue with very old commits of the Guix channel, and the lack of a trivial workflow to look for git hashes for specific software versions <Kabouik>ruther: I understand but the compilation failed eventually, it's not just that there was no substitute. But maybe it was just bad luck with this commit; I just wonder if it's bad luck or there are more like this. <ruther>Kabouik: you're missing that the substitute was possibly failing because it was not building <Kabouik>But that I can find a commit message for an R update and use that as a source for the git hash I need to deploy that software version in a shell, as seems to be the recommended way, and eventually find out that this commit doesn't build, can be an issue from a reproducibility perspective, no? Or maybe I actually need to find that git hash, and if it's a bad apple, just try another hash between that one and the next that reported another update of the <ruther>Kabouik: it definitely can, but doesn't have to be, because you're not actually trying to reproduce - if nothing was produced initially there is nothing to (re)produce. You would need to know why the failure happened which you didn't investigate <vagrantc>things can also build in certain circumstances and later fail (e.g. time bombs in test suites, cpu-specific feature assumptions, etc.) <ruther>if you want to ensure it will build, look up commits with substitutes and look up how many failing packages there were <vagrantc>so they might have succeeded on the substitute servers in the past, but have since been gc'ed <Kabouik>Yeah you're right if I wanted to reproduce, I wouldn't have to look for the git hash in the first place, it'd be given to me <vagrantc>yeah, you need to know the same hash, otherwise you're just guessing <vagrantc>(you can get lucky, but ideally you get provided the bare minimal information to have a better chance of reproducing... e.g. the commit hash(es) used) <Kabouik>In that case I wanted to use a specific old version of a specific software, and found a hash that had that version in the commit message, but maybe that commit was broken. Using a commit from a few days later (without the target keywords in the commit message) would maybe have built correctly after it was fixed, and before the software I want had been updated again to yet another version. Makes it a little difficult to pinpoint which commit to use <Kabouik>when trying to time-machine something old, though. <Kabouik>This workflow probably only applies to this situation where we're considering moving to a Guix-based approach on the cluster. People have old scripts that probably need old R versions, but they never had Guix, so they also never made a manifest or guix-describe, so we need to guess which old hash we use if we want to create time-machine shells that would work with their scripts. <vagrantc>yeah, a lot of guesswork ... and then you also may have underlying library differences ... e.g. maybe you get the same R version but a different library version somewhere in the stack <vagrantc>unless R is truely hermetic enough to not matter what it was built with... <Kabouik>Yeah absolutely, it wouldn't be the exact same stack they had when they wrote the outdated scripts, but these were written out of any reproducible environment attempt in the first place. <vagrantc>testing how often you can reproduce old results with slightly different stack is useful information ... <Kabouik>Meanwhile, time-machine still trying to install r 4.0.0 and r-ggplot2, I wonder if my machine is particularly slow. <Kabouik>vagrantc: yup, I think I saw a paper about that referenced on guix-hpc. Here it would be simpler though, it's more about a user saying "I have this script I wrote ten years ago, it doesn't work anymore and I'm not interested in reproducing the results, but I'm interested in using it untouched on new data, and the R packages I load in it don't exist anymore". Not that it'd be a particularly good idea to stick to outdated stuff for new analyses, but if <Kabouik>the reply could be "Sure, just find a git hash from 10 years ago then time-machine yadi yada magic and your old package will be available" <Kabouik>So this is really proving to be less trivial than it looked. `guix time-machine --commit=af02327856 -- shell r-minimal r-ggplot2` fetches substitutes for a long time and then hangs on https://0x0.st/83zl.txt (same with another commit I tried). <ruther>Kabouik: that could be caused by savannah being down <ruther>although I don't really understand why is guix being built like that <ruther>I would expect that only if you did shell guix <Kabouik>I don't often see Savannah being down as a good news, but here's I see hope. :P <ruther>Kabouik: can you send the whole output of the command? <Kabouik>I don't know either, this is the full command I tried <Kabouik>Unfortunately I didn't log it so I only have what my terminal buffer still shows <Kabouik>That shouldn't be it, my channels.scm already lists the Codeberg repo as my guix channel <ruther>that revision is definitely revision of the guix package in af02327856. And it is definitely being fetched from savannah <ruther>but I am not sure if it is time-machine part building it or the shell <ruther>not sure why either would be building it <Kabouik>The git.savannah.gnu.org URL is commented out in favor of the codeberg one, is what I meant (and why I thought it was relevant) <ruther>Kabouik: but that is not what is the build doing, the build is building package called guix that is in commig af02327856, in (gnu packages package-management) <ruther>that package has a hard coded url to download from. Your channels.scm is completely unrelated to that <Kabouik>I see, okay. Since I was not using `-c channels.scm`, I assumed my current channels.scm would be used to look for that commit hash in the first place; but yeah I think I understand why this wouldn't make sense <ruther>guix is a package, just imagine package called asdf instead of it, do not think of it like the guix you said to build through time-machine... <ruther>except it's actually called guix, coincidentally having the same name as a package you're trying to make with time-machine. But a different package. <vagrantc>the fact that guix is packaged in guix does occasionally provide some confusing situations :) <vagrantc>Kabouik: might be able to workaround it by making sure softwareheritage.org has a copy of that specific git commit :) <civodul>noe: just saw it; i confirm this is what happened, my bad! <civodul>Kabouik: protip: try ‘guix time-machine -q --commit=af023278567b398207d421b1b05bf4980f272525 --url=http://example.org -- describe’ <meaty>Anyone else getting error 500s on some PR pages? <meaty>ieure: i see, that's why it was only issues with team labels <nmeum>could someone give me a review on https://issues.guix.gnu.org/78231 ? it fixes a bug filled against a package which I added to Guix. Further, it can be easily verified that the bug is fixed by this patch and a similar prior patch for frama-c was already comitted <vagrantc>Kabouik: if it is an old git commit, surely it is in softwareheritage.org ... as unless it is in some weird branch? <vagrantc>oh that is old, v1.0.1-18550-gaf023278567 <civodul>Kabouik: no no, literally what i wrote <Kabouik>(It's running.) Could you tell if http://example.org triggers a specific condition, or does any URL that don't actually contain the requested hash end up being replaced by softwareheritage? <vagrantc>meh. i got a substitute for linux-libre-arm64-mnt-reform yesterday ... but the source is already gc'ed ? <noe>civodul: I suppose the fix might not be rolled out on codeberg’s servers for some time. Any chance the API allows removing those reviews? <civodul>noe: you mean reviewing the review assignment to teams, right? <vagrantc>ACTION spends another 6 hours deblobbing a kernel sources that were built just yesterday 