IRC channel logs


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?
<PurpleSym>I think so, rekado.
<rekado>has the hash changed too?
<rekado>since guix only cares about the hash you’d only need to *somehow* get the sources into the store
<PurpleSym>You mean the guix hash or the git hash?
<rekado>guix hash
<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
<PurpleSym>Thanks, I’ll give it a shot.
<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
<civodul>rekado: yup, quite unusual
<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.
<civodul>flypaper-ultimat: hi! here's a draft about the package/channel hack that we were talking about one or two weeks ago:
<civodul>feedback welcome!
<civodul>i'll probably publish later today
<flypaper-ultimat>civodul: cool! i'll have a look!
<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)
<civodul>ACTION notes
<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>ACTION reads on
<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”?
<rekado>ACTION –> lunch
<civodul>enjoy your meal!
<flypaper-ultimat>ah sorry did not mean to send f
<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)
<civodul>rekado: did you have more comments?
<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, one automatically gets substitutes for it from”
<civodul>rekado: colleagues of mine run Guix on GitLab-CI, but it's our own instance, not
<civodul>so yeah, optimistic maybe
<civodul>ACTION notes
<rekado>you introduce cuirass in a way that makes it seem like it’s more work, but compared to running Guix on (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’s as simple as that.”
<civodul>ah ok, removed
<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>“dot files are sprinkled”
<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”)
<civodul>i'd remove "hopefully" too
<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
<civodul>you're really nice
<civodul>thanks again!
<rekado>you’re welcome!
<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>good stuff!
<rekado>I’ll polish my mouse button clicky finger to share it as soon as it’s published!
<civodul>heheh, lemme push the changes
<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>longest URL ever
<drakonis>that's a really good post.
<civodul>PurpleSym: found the bug re guix-cran: r-future-tests depends on itself
<civodul>i'm disappointed
<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?
<flypaper-ultimat>here is a minimal example, with explanation what i think is the cause
<flypaper-ultimat>(as a patch file for your r-guix-install package)
<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?
<flypaper-ultimat> actually, i made a patch for r-build-system
<rekado>I misunderstood and thought this is about guix.install
<rekado>oh, good
<flypaper-ultimat>(i guess i'll have to find an email-address now that i feel comfortable having on bugtracker)
<rekado>thanks for the patch
<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>okay, I’ll go with “flypaper”
<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”
<civodul>ACTION sent a patch for package cycle detection: