IRC channel logs


back to list of logs

***midnight is now known as midnight_
***civodul` is now known as civodul
***midnight_ is now known as midnight
<zimoun>rekado_: Bioconductor 3.12 is released. Do you think it is affordable to try to upgrade before the Guix release?
<rekado_>… go for it :)
<rekado_>what I recommend (and usually do myself) is to upgrade all Bioconductor packages first, without upgrading the release number
<rekado_>then upgrade the release number and do the whole thing again.
<rekado_>push in between
<rekado_>so that the CI gets to fetch the latest tarballs
<zimoun>do you upgrade manually all the Bioconductor packages?
<rekado_>I do ‘./pre-inst-env guix refresh -t bioconductor -u’
<rekado_>I then review the list of proposed changes
<rekado_>many of them are useless
<rekado_>some I know to be wrong
<rekado_>(like adding r-knitr to a dependency of r-knitr)
<rekado_>and others are optional inputs that it tells me to remove
<rekado_>once all proposals have been checked I transform the output to a list of packages and I build them all.
<rekado_>if packages are affected that contained JavaScript files I check that their bundled JS is still removed and rebuilt from sources.
<rekado_>some upgrades I undo, because I know that they are too difficult to complete
<rekado_>e.g. r-mosaic, which depends on r-leaflet, which contains massive amounts of minified JavaScript for which there are no easily accessible sources.
<rekado_>there’s another Bioconductor package that now requires keras or a similar ML framework, which we don’t have.
<rekado_>this is all a day’s worth of work
<rekado_>unfortunately, I know now that I can’t commit that much time
<rekado_>but it’s really pretty straight-forward
<zimoun>thanks for all the explanations. I will try to go for it. Well, few distractions in Paris (curfew) and soon lockdown, again! The variable will be the extra-work at work because this again lockdown…
<rekado_>I’ve not been paying attention to any of tis
<rekado_>I don’t even know what the current status is in Berlin
<rekado_>probably bad
<rekado_>but I decided to work an hour every night on apple tree wood that I cut from a tree in our garden
<rekado_>if only I never needed to return to work!
<rekado_>the chunks of time are not enough for concentrated computer work, but they are enough for brute force: sawing wood, breaking off bark, carving, etc
<rekado_>weirdly enough, in all my lethargy and lack of progress in the Guix world I feel oddly successful
<rekado_>even though all I’ve done so far is strip bark off a log of wood and deep fry (!) a chunk of it
<rekado_>gotta love wood
<rekado_>but back to Guix: we can do this together
<rekado_>I could do the CRAN upgrades
<rekado_>push all of this to a new wip-r branch
<rekado_>then rebase onto master, let ci build it, then merge
<zimoun>yeah I was fine the previous lockdown (based on Millau south of France). Even if I was recovering from bad sport’s accident… Right arm dysfunctionnal. Sweating to recover. Well I understand your point. :-) Whatever!
<rekado_>my right wrist is pretty useless these months
<rekado_>I don’t recommend carrying a baby needlessly
<rekado_>they are portable humans, but only barely so
<zimoun>yeah the wip-r seems the good thing to do. If the merge can happen before the release, fine. Otherwise, it will be later and it will be fine too. :-)
<zimoun>hehe! When in Nov. would you be back to “office”?
<rekado_>Nov 21
<zimoun>I gave a look to D4. It could be interesting. I do not know how easy it would be easy to package, because of Rust.
<zimoun>And speaking about new thing I would like to try,
<rekado_>“Python-compatible language” smells like trouble
<rekado_>first thing I noticed: “print n”
<rekado_>so it’s Python-2-compatible…?
<rekado_>I think this may come back to bite them one day
<zimoun>rekado_: do you commit the upgrade package by package or all at once?
<rekado_>I use ./etc/committer.scm
<rekado_>it creates one commit per upgrade
<rekado_>for packages with lots of changes you may need to edit the commit message to reflow it
<zimoun>thanks, I was not aware about ./etc/committer.scm
<rekado_>it’s great!
<rekado_>I wrote it because I got tired of how slow magit gets when there are tens of changes, and I need to select one hunk at a time
<rekado_>one caveat: committer.scm will not do the right thing when the diff contains new packages
<rekado_>it’s only good for package updates
<rekado_>it figures out the changed inputs and records them in the expected format
<rekado_>doesn’t do anything for other changes and it gets confused when there are completely new packages in the diff
<rekado_>other than that it’s really well-suited for CRAN/Bioconductor upgrades
<zimoun>yeah all the only version+hash changes. It already saves a lot of time.
<rekado_>input changes too!
<rekado_>I’m not proud of the implementation, because it’s rather crude
<rekado_>but it works