IRC channel logs
2023-06-05.log
back to list of logs
<PurpleSym>I’m having issues building old versions of our RStudio package, because the tag was renamed upstream. Is there anything I can do to build them nontheless? <rekado>PurpleSym: is this just about getting the sources? <rekado>since guix only cares about the hash you’d only need to *somehow* get the sources into the store <PurpleSym>Ah, let me check. So in theory I could guix download the correct data into the store? <PurpleSym>(I’m also having issues with an OpenSSL test failure ☹️) <rekado>yes, “guix download” should be sufficient <rekado>I’ve done this in the past when I wasn’t able to get the bcl2fastq sources via FTP <rekado>copy them to the target, guix download file://…, and then build it <rekado>civodul: oh, official retirement announcements for free software seem rare. <rekado>I guess we’ll just keep offering it in Guix until it fails building with the rest of R+CRAN <rekado>the output of “guix refresh -l r-rgdal” is surprisingly short <rekado>I expected it to be much more popular <PurpleSym>rekado: Ah, no, `guix download` expects a single file, not a directory. (The source was a git clone.) <PurpleSym>I guess I’ll have to manually call add-to-store with #:recursive? #t <PurpleSym>Hm, nope, add-to-store does not work either. The guix hash is the same, but not the hash in /gnu/store/hash-xxx. <flypaper-ultimat>i've also seen people use specification->package for inputs in the guix.scm, is one preferred over the other? with using the variables you are being more specific and better for upstreaming, but using specification->package things dont break in the future if the location of packages change is the feeling of tradeoffs i got ? <civodul>flypaper-ultimat: i've changed my mind about this <civodul>specification->package is nice because it works regardless of the module name <civodul>but it's ambiguous because of that, too <civodul>so if someone's pulling additional channels, (specification->package "foo") might return something very different from what you as a channel author had in mind <civodul>and that's a problem, also security-wise <flypaper-ultimat>ah, i see. and the user would still be able to transform with e.g. --with-input if they wanted to use a different foo. <rekado>civodul: “missive” sounds a bit odd. It’s correct but I’d prefer something more specific like “article” or “blog post”. <rekado>(it’s not rational, but “missive” is so close to “dismissive” that it invariably ends up in my bin for words with negative association.) <rekado>“This post describes a set of files and conventions developers can follow in their repository” — this sounds odd because “set of files” cannot be “followed”. <rekado>“at the root of the repository we’re interested in” —> “the repository in question”? (“interested in” sounds a bit like it’s not *our* respository) <civodul>"a convention file layout developers can follow"? <civodul>"a conventional file layout developers can follow"? <civodul>or "a set of files developers can add" <rekado>yes, either of these would be better <rekado>the “vcs-file?” definition is a bit confusing because of the (or … (const #t)) <rekado>“Here’s what we changed: 1. We add” –> “We added” <rekado>(because the other steps are all using simple past tense as well) <rekado>I wonder if the code snippet and the three steps should be swapped <rekado>because the confusion I got from reading vcs-file? is gone now that I’ve read point 2 <rekado>at the end of “Level 2” perhaps you could mention “guix pack” as well, because that’s a significan yet non-obvious benefit from having Guix build stuff. <rekado>though mentioning this might break the flow, don’t know <civodul>i'd leave the snippet with vcs-file? above the bullet list; i feel i need to see the code before the explanation <civodul>re "guix pack", i only mention it later because i realized you cannot do "guix pack -f guix.scm" <civodul>('-f' is for '--format' and there's nothing equivalent) <rekado>I don’t understand the reason for this sentence: “Granted, our Git repository is one package definition lost in a sea of code” <rekado>I’d remove it and the paragraph break. <rekado>(or maybe keep the paragraph break) <civodul>ACTION keeps the break, removes "Granted [...]" <rekado>“delivered in the hands” –> “delivered into the hands”? <civodul>in the blog post i was considering adding a couple of lines about channel dependencies <civodul>(not going into much detail because Guile doesn't use it) <rekado>sorry, was out for a little while; just got back <rekado>“or plain tarball of the software” –> “or a plain tarball”, or “or plain tarballs” <rekado>in the package variant example I’d find #~'() to be rather difficult to parse with the eyes of a newcomer <rekado>I find the use of “list” clearer, personally, but tastes differ obviously <rekado>“Return the package object define above” –> should be “defined above” <rekado>“or, if we have a checkout of Guile” – this confused me a little, because I didn’t realize that “checkout of Guile” is the checkout of this repository to which we’ve added the guix.scm file. <rekado>“make sure you run jobs into a Docker image” —> “into” should be “in” <rekado>the gitlab CI example is perhaps a little too optimistic, as it will only work with an installation of Guix inside gitlab CI, which sounds like it would be tricky to set up <rekado>(I haven’t done this before, so I’m just guessing) <rekado>this sentence is a little clunky: “As an example, our `guile` jobset being built on ci.guix.gnu.org, one automatically gets substitutes for it from ci.guix.gnu.org” <civodul>rekado: colleagues of mine run Guix on GitLab-CI, but it's our own instance, not gitlab.com <rekado>you introduce cuirass in a way that makes it seem like it’s more work, but compared to running Guix on gitlab.com (or self-hosting gitlab) I think it’s not much more work <rekado>personally, I’m not a fan of sentences like “It’s as simple as that.” because they often make me feel stupid :) <rekado>I’d replace it with a sentence that reiterates that no *more* work needs to be done here <rekado>conveys the same sentiment of surprise that it isn’t any harder <rekado>though in a real deploymnent one *would* need to do a little more work to run “guix publish” and share signing keys, no? <rekado>“insufficiently expressive”, neat :) <civodul>sorry which sentence about more work? <rekado>it essentially says that we’re already done and no more work is required to distribute substitutes <rekado>if that’s the intent then saying this explicitly would probably be better <rekado>now reading the manifest; big code block! <rekado>“This is it!” —> perhaps note that the only change here is that we use that manifest with '(manifest "the-file") instead of '(channel guile)’ <rekado>it wasn’t immediately obvious to me because I didn’t remember the previous cuirass example from above <rekado>“splattered with dot files” — I think “splattered” is wrong here <rekado>or maybe it’s the passive voice that sounds wrong <rekado>maybe “peppered with dot files”? <rekado>this also sounds a little off: “all the rage is on specialized tools building on one another” <rekado>while we could come up with a replacement for this fragment, I think the flow would benefit from removing it <rekado>because the last sentence refers back to “it” (= “unified tool set”) <rekado>might be better not to have a last second detour <rekado>overall impression: this is really good! <rekado>I really like the summary at the end <rekado>the previous sections go pretty deep, so there’s lots of cool stuff to mine from it <rekado>and the summary ties it all back together to drive the point home <rekado>I’ll polish my mouse button clicky finger to share it as soon as it’s published! <civodul>we should implement web hooks for the web site stuff, for Cuirass, etc. <civodul>all these things periodically polling for changes are ridiculous <civodul>PurpleSym: found the bug re guix-cran: r-future-tests depends on itself <civodul>i started looking at tricky things and it's just that <rekado>that’s something we can fix in the importer <civodul>rekado: maybe filter it in cran-package-inputs, so that the fix also works for the updater? <flypaper-ultimat>rekado: btw, the r-builder doesn't fail with failing tests, is this intentional? <rekado>flypaper-ultimat: it’s probably unintentional <rekado>I’m not sure I understand the example, but I’ll test it later and apply your patch <flypaper-ultimat>rekado: well, the example is just to illustrate a case that _should_ fail, and does with R interactively, but doesn't with guix. <rekado>oh, so the r-build-system doesn’t do the right thing here? <rekado>I misunderstood and thought this is about guix.install <flypaper-ultimat>(i guess i'll have to find an email-address now that i feel comfortable having on bugtracker) <rekado>you don’t need an email address; I could apply it like that <rekado>but for attribution I’d need some identifier you’d be comfortable with appearing in the source files / git <flypaper-ultimat>i guess `flypaper' would work here? because these logs are public anyway. <flypaper-ultimat>also, thanks for all your hard work on `bioinformatics.scm`, its a great resource of how to work around all kinds of weirdness in packages. <rekado>bioinformatics.scm sure is a collection of weird packages! <rekado>so, I just tried your patch and ran guix build r-genomation; BiocGenerics already fails but there’s no test output: “find-files: BiocGenerics-tests: No such file or directory”