IRC channel logs


back to list of logs

<rekado>civodul: FYI I’m currently finishing up a CRAN update
<rekado>I just realized that this probably interferes with your last commit on the refresh patches
<civodul>rekado: that should be fine, these are very local changes
<rekado>I’m still working on r-dt’s javascript
<civodul>that one looks tricky
<rekado>it’s a slog trying to figure out what upstream versions the minified blobs correspond to
<civodul>i can imagine
<civodul>you should write about what it takes to package r-dt "correctly"
<rekado>the best hint is that it’s all done in one commit
<rekado>so it’s likely whatever version is currently available at the time of the commit
<rekado>that’s for all datatables extensions
<rekado>it would be better if I could figure out a way to build the extensions right from the git repository instead of downloading the plain javascript files from the CDN one by one
<rekado>looks like it would be possible without too much work
<civodul>terrible that we have to second-guess what code upstream carelessly picked
<rekado>it’s extremely common in the packages in the rstudio pond
<rekado>they are very popular but also seem to repackage JavaScript things without the slightest care about provenance or building the files from source
<civodul>rekado: maybe i'll push v2 of the 'guix refresh' patches once you've pushed your R updates?
<rekado>civodul: sounds good!
<rekado>I’m still building everything on my laptop
<rekado>will likely push in an hour or two
<civodul>sounds good, no rush!
<rekado>pushed it
<rekado>I just ran “guix build --tune=cascadelake salmon” because I want salmon to use a tuned version of eigen
<rekado>yet that gives me the same output as a plain “guix build salmon”
<rekado>am I holding it wrong?
<rekado>does salmon itself need to be tunable?
<rekado>oh, eigen itself is not tunable
<rekado>so I’ll add the property to salmon
<rekado>that also doesn’t seem to help
<rekado>I have (package (inherit salmon) (properties '((tunable? . #true))))
<rekado>oh, silly me
<rekado>actually forgot to add --tune in this case…
<civodul>rekado: eigen is not tunable because it's header-only, so there's nothing to tune
<civodul>however, we could/should mark all its dependents as tunable
<civodul>not just eigen-benchmarks :-)
<civodul>guix graph -t reverse-package -M1 eigen |xdot -f fdp -
<rekado>got it
<rekado>not sure what to expect, but I created a variant of salmon and marked all its direct inputs as tunable
<rekado>I wonder if this makes much of a difference.
<rekado>what should we do about packages where we specifically patch out -march=native or remove SSE* flags?
<civodul>rekado: if they were using -march=native or similar, that's hopefully an indication that they can benefit from vector extensions
<civodul>alas not necessarily, because some always use -march=native
<civodul>so i think we should check whether it plausibly makes sense
<civodul>if it's linear algebra, good; if it's a text editor, not good
<rekado>do we need to make patching conditional then? Depending on whether the package is tunable?
<rekado>or would making it tunable automatically do the right thing?
<rekado>I saw that when “--tune” is used Guix uses a different compiler variant
<rekado>(a wrapper, I assume)
<rekado>will that always add the right flags?
<civodul>ACTION pushed
<civodul>yes, the wrapper always adds the right flag
<civodul>we should keep patching out -march=native from makefiles & co.
<civodul>that doesn't change
<civodul>but when we do that, we should consider adding the tunable property
<ennoausberlin>Hello guix-hpc
<ennoausberlin>Is there any graph db packaged for guix?
<civodul>ennoausberlin: hi! i'm not knowledgeable in this area, but you can try
<ennoausberlin>civodul: I tried, but sometimes the names not necessary reflect, what you are looking for. Maybe there is none.
<rekado>PurpleSym: I’d like to start packaging RStudio Server; I got myself the npm importer and … don’t know how to start.
<rekado>do you remember how you approached the import?
<PurpleSym>rekado: You’re probably going to hunt for package.json(?) files, which indicate a JavaScript package and I think the old importer had a stdin option that I used to import all dependencies in that file.
<PurpleSym>I have no idea where that panmirror thingy they’ve been building went in the source tree though 😕 It was in src/gwt/panmirror previously.
<PurpleSym>rekado: Did you look at the guix-cran patches to keep the channel alive once I lose access to the server?
<rekado>ah, sorry, I forgot about those
<rekado>will apply them tonight
<rekado>PurpleSym: pushed as 4be0947783d230eca8b4d1ca336a7227b6ed7102
<rekado>I had some problems applying it for some reason
<rekado>so I applied it manually
<rekado>hope I didn’t introduce any mistakes
<PurpleSym>rekado: Hm, weird. Could you generate an SSH key for the guix-cran user and send it to me, so I can authorize it in GitHub?
<PurpleSym>(Not sure if I can give you access to that GitHub account somehow.)
<rekado>PurpleSym: okay, will send you a key later
<rekado>civodul: the updater did something funny to r-rsubread: turned (inputs (list zlib)) into (inputs (list))
<civodul>rekado: yeah it cannot actually remove the field, so it does just that
<civodul>i guess it cannot guess that zlib is necessary, right?
<civodul>ACTION tried "guix import cran subread", doesn't work
<civodul>got it: guix import cran -a bioconductor Rsubread
<civodul>that one lacks zlib too
<civodul>so i guess it's case where we can either (1) improve the importer to it guess that zlib's needed, or (2) add updater-extra-inputs
<rekado>yes, I’m checking to see if I can make the importer find it
<rekado>I just thought the (inputs (list)) looks odd, but it makes sense if it can’t remove the field.
<rekado>src/Makevars has -lz
<rekado>We’re only looking at* and configure.*
<rekado>easy fix
<rekado>hmm, it produces “r-zlib” as an input instead of “zlib”
<rekado>that’s because source-dir->dependencies maps “upstream-input” over the correct result of needed-libraries-in-directory
<civodul>awesome, thanks for fixing my bugs :-)