***Server sets mode: +nst
<civodul>pjotrp: are you in CEST these days? :-) <civodul>though perhaps a more recent gcc would do? <civodul>it can be tricky and time-consuming to package old compilers <PurpleSym>I mean, we have 4.7 in Guix as part of the bootstrap process. <PurpleSym>Nope, gfortran.info says g77 is only included prior to GCC 4. <zimoun>civodul: hi! I am a bit late... Coffee mistake, whatever! :-) <zimoun>Well, it is the first time for me, and especially on IRC. :-) <bonz060>civodul: Perhaps look for a submission that's easy to follow? And maybe someone (maybe?) stream on their end while we provide feedback, suggestions et al here. Wdyt? <bonz060>And while we are figuring how to set it up, we could discuss what to work on. <zimoun>civodul: So if you looked at issue#39, you could quickly explain how was your attempt. <zimoun>PurpleSym: I have started to look at issue#41 about g77. *efraim probably needs more coffee mrining ~ morning <civodul>zimoun: do we have videoconf at 9:30 to get started? <khinsen>is this channel logged anywhere? It looks like you have already discussed what you want to do, but I can't see the history. <khinsen>Then how about setting up an Etherpad with more permanent information for latecomers? <zimoun>well, I am trying to save the buffer with ERC :-) <civodul>i can even hear your keyboard, zimoun :-) <zimoun>we could share more easily the work, the camera can be turned off <civodul>do you want to set one up? framapad? <efraim>it sounds like someone's playing in traffic <khinsen>No Jitsi for me this morning, sorry, I am sharing my home office with my wife! <zimoun>khinsen: ok. I am trying to take some note on the PAD <khinsen>civodul pjotrp You both picked the same color on the pad! <zimoun>khinsen: I did a mistake with named an uname with my name <khinsen>zimoun You will have to work for two then ;-) <bonz060>I'm there. I think my microphone has problems. <khinsen>zimoun Do we have RStudio in Guix now?? I can't find it. <zimoun>khinsen: well, it is long story :-) <civodul>zimoun: i can hear your keyboard :-) <civodul>that could be a 10-year rescience paper, or perhaps piece of software <civodul>the whole point is also to help each other of course <civodul>so each one of us can ask for guidance here <civodul>zimoun: i'm talking, but you're the master of ceremony, right? :-) <khinsen>I am going to tackle the history of Python/SciPy. <zimoun>civodul: you type faster than me :-) <civodul>khinsen: that's in connection with a specific rescience submission, or more of a general effort? <zimoun>khinsen: efraim adds Python 2.4 to the channel guix-past <khinsen>efraim Thanks for the pointers, I will have a look at that! <efraim>khinsen: most of them can have the #:use-setuptools? #f set to false I think <civodul>bonz060: anything that helps reproducing in particular potentially old scientific work is welcome! <efraim>I don't know if numarray helps with matplotlib or numpy but I have that packaged there <civodul>there are rough guidelines in its README.md <civodul>you can send pull requests and all :-) <khinsen>efraim At the time of the split, many packages left the choice between Numeric and numarray as a build-time choice. If we want to support both paths, we have to agree on some naming scheme for the packages. <pjotrp>I tried installing Ricardo's R/studio a few months back, it did not work <wdkrnls>zimoun, PurpleSym: that looks great! Of course, I would love for rstudio-server to be in guix proper :) <khinsen>civodul We can send pull requests only if we have an account at gitlab.inria.fr, right? Even an account with project creation rights, to clone the repository. <efraim>with the benefit of hindsight we can make the more popular one python24-foo and the other one python24-foo-suffix <civodul>khinsen: right, i believe anyone can create an account on gitlab.inria.fr, and then you can clone and send pull requests <wdkrnls>I personally am quite happy to stick with Emacs though. <khinsen>civodul I actually do have an account, but I can't create projects, nor forks. Only push to repositories where I happen to have write access (basically the RR MOOC repositories). <PurpleSym>wdkrnls: I don’t think that’s going to happen. RStudio bundles tons of other projects and unbundling these is not really feasible imo. <efraim>khinsen: but I'm happy to follow your lead, I don't know much about the python ecosystem <khinsen>civodul I just tried cloning: "You reached your project limit". <civodul>khinsen: oh, hmm; what we could do is grant access to the repo but have people use separate branches <civodul>(the goal was to require signed commits for the main branch of guix-past, but i'm not going to ask that to everyone of you) <bonz060>Hmmm... I see nowhere for creating an a/c on INRIA. <zimoun>khinsen: you want to clone without login? Otherwise, you can create an account and clone, well I did some days ago without an issue. <paul-g>Good morning, everyone. I will take a look at the rescience #43 (ODP-PIV) paper. The original software was written in C in this case. <khinsen>zimoun I have an account there, and I did log in, but I cannot clone because I have reached my project limit (which must be zero). <khinsen>Hi paul-g. That looks like a nice project. <bonz060>civodul: Yeah. What I had in mind doesn't really align to the scientific reproducibility theme. So I'm poring over the issue list for something I think I can do. From what I see on https://gitlab.inria.fr, external members need to request an external a/c. I could send e-mail patches though <bonz060>Also, perhaps the channel op could set the topic for ^^ to point to the pad <civodul>bonz060: sure, patches by email work fine <zimoun>khinsen: we are talking about guix-past? <civodul>somehow i can't seem to make myself op for this channel, let's see <civodul>if anyone else needs it, please let me or efraim know <khinsen>civodul Thanks, I will try as soon as I have something to push! <khinsen>civodul I am looking at the instructions for enabling substitutes on guix-past. That's not for Guix System, right? /etc/systemd looks suspect ;-) <efraim>even without substitutes python-2.4 builds pretty quickly <zimoun>khinsen: it depends if you want to have them permanently or not, otherwise just restart the daemon with the option --substitute-urls, I guess. <khinsen>civodul I get the idea, but it's exactly the "somewhere" that I don't know ;-) Not really important for today, I need to work at the source level anyway. <civodul>like zimoun writes, you can pass --substitute-urls to "guix build" & co., that's the easiest way <khinsen>The real question for today: what's the best setup to hack on a channel? <civodul>i just check it out and run "guix build -L . foo" <civodul>(where "-L ." instructs guix to look for modules in the current directory) <zimoun>guix build -L . foo --substitute-urls= I guess <zimoun>Sorry I miss who is Lars here? :-) <zimoun>PurpleSym: does modern gfortran not support the 77 norm? <PurpleSym>I have no idea. Never used Fortran before. The manual says something about “most programs should work”. <khinsen>civodul zimoun Well, what is '.', then? I tried at a few levels, no success. <zimoun>It is a long time I have used Fortran... time flies. :-) Maybe khinsen can says us: does modern gfortran support old 77 morm? <zimoun>khinsen: the path where guix-past is <khinsen>zimoun PurpleSym All compilers still support Fortran 77. It's a subset of later versions of the standard. <khinsen>zimoun PurpleSym The reason why g77 matters is for C-Fortran interfacing. That's undefined by the Fortran 77 standard, so every compiler has its own conventions and code written for g77 doesn't work with other compilers. <PurpleSym>Yeah, that’s what the reproduction paper is saying as well. <khinsen>zimoun Ahhh... thank... got it. I was asking for python@2.4, but it's python2@2.4 Compiling now! <khinsen>zimoun PurpleSym What I find interesting in this paper is that it's a two-level reproduction failure. The application code doesn't work with gfortran, AND g77 cannot be compiled under Debian. That's where a fully recursive build-from-source approach as with Guix really shines. I don't know how hard it is to get g77 packaged, but at least it should <khinsen>be possible, whereas with other distributions you cannot even consider it. <civodul>well that doesn't cover all the history <efraim>1.16 was in 2013, it might be in guix's history <rekado>feel free to take whatever you want from that module and add it to guix-past <civodul>PurpleSym: if you don't mind creating a gitlab.inria.fr account, you can get premium access to guix-past, too <PurpleSym>civodul: Thanks, for now I’m fine with sending patches. Is that ok? <zimoun>rekado: guix-bimsb has it substitutes available? <pjotrp>we had gsl1 support in guix-bioinformatics. Should be in history - Efraim? <pjotrp>or maybe I used the one in Guix. Can't remember ;) <civodul>if anyone's still struggling to find what to work on or how to get something done, make yourself known! <bonz060>People working on Python, I've gone through some of the papers, and most of the code points to reproducibility attempts that leverages new modern code that's already packaged... <bonz060>I'm trying to figure out a package to hack on. <bonz060>Is there anything anyone needs packaged in the Python ecosystem(or even any lisp like language) <zimoun>rekado: it remembers me that we do not have yet a documented solution to use Guix with the GitHub/GitLab CI. <efraim>pjotrp: indeed we do have a gsl1 in guix-bioinformatics <rekado>zimoun: I had set up cuirass on a VM here, but that was before it got a web interface, so it wasn’t really all that useful <zimoun>rekado: which builds guix-bimsb? <civodul>bonz060: khinsen and efraim are working on Python-related things <civodul>perhaps there's some work sharing that could be done in this area <civodul>because there's quite a lot of code there <PurpleSym>zimoun: So, what I’m trying first is building this “circles” software with a recent gfortran, seeing how it fails. <efraim>i'm mostly working on octave-3.4.3 right now actually <civodul>bonz060: so if you want to look into python, perhaps let's sync with khinsen <rekado>civodul: I see that you recommend specification->package to be used in some cases. I think that’s a good idea and I’ve been meaning to switch my channels to using that instead of plain variable references. <rekado>Should *all* additions to guix-past use specification->package or are there criteria to help decide <khinsen>bonz060 I am working on adding NumPy and numarray to the Python 2.4 in guix-past. Would you be interested in doing Python 2.5? We could then sync and add numarray and NumPy to Python 2.5 as well. <civodul>rekado: informally, i thought about using specification->package for packages not in the "parallel" module <civodul>so in autotools.scm, you can refer to (gnu packages autotools) variables <civodul>i guess it would also make sense to use only specification->package, but it's a bit cumbersome and error-prone <zimoun>Is it expected that "guix environment --container --ad-hoc hello -- which ls" returns nothing. I was expecting an error. What could be wrong on my machine? <khinsen>Policy question to everyone: what do you think of putting the release date of packages in guix-past into the synopsis and/or description? The idea is to facilitate finding the version that was current when a paper was published. <zimoun>khinsen: or maybe add (properties `(date . "xxxx")) <civodul>so far i added it as a comment in the code, but that's less convenient <khinsen>@zimoun Same behavior on my machine. <civodul>zimoun: problem is there's no UI to view properties <rekado>civodul: but it can be filtered by code <khinsen>civodul The point is to make it accessible from the command line. Is tha tpossible with properties? <rekado>… should there be a UI to view properties? <zimoun>civodul: I agree with rekado. See upstream in cran.scm :-) <khinsen>Note that I don't mind putting the date both in a property and the synopsis if that what it takes. <zimoun>but we could adapt how the package is shown. And display the properties if they are. <khinsen>zimoun True, but that's some effort and I think it's worth it only if we envisage adding dates all over Guix one day. If it's just for guix-past, something simpler should be sufficient. <civodul>khinsen: let's do that: synopsis + property :-) <zimoun>civodul, khinsen: yeah both seems fine. :-) <khinsen>bonz060 I don't mind, but matplotlib requires NumPy or numarray! <khinsen>civodul zimoun OK, I'll do both, we can still revise the policy later. <rekado>what format should wte use for the property? An actual date object? <zimoun>rekado: I think a string is easier with the format YYYY or YYYY-MM or YYYY-MM-DD. <zimoun>but then it can be converted to a clean date or time. <bonz060>What would you suggest I work on in that python ecosystem? Some thing that's not dependent in sth else. I'm finding a hard time on picking sth to hack around with ':( <khinsen>rekado zimoun Right, I propose an ISO date string. We may not have the full date, so it's important to be able to say just "2008", which is better than nothing. <khinsen>@bonz060 Earlier or later Python releases would be independent. <khinsen>bonz060 Or Python packages without any dependency on NumPy/numarray. <zimoun>civodul: why "guix environment --container --ad-hoc hello -- ls" does not fail, but "guix environment --container --ad-hoc hell RET then ls" fails. The latter is expected, not the former. <bonz060>khinsen: ah yes. I kinda avoided that cause I saw efraim mention on the pad that he'd be working on that. I can pick that up. I'm sure he won't mind since I see he's working on Octave. <efraim>bonz060: you can go ahead and work on it <efraim>I was going to get around to it later™ <civodul>zimoun: "guix environment --container --ad-hoc hello -- ls" exits with code 1 (should rather be 127) <efraim>return value from 'guix environment'? <paul-g>PIV progress: I have found the repository for the original code and the images. <paul-g>PIV status: I am now searching for the original LaTeX source <efraim>well, ls returns 127, which causes guix environment to return 1, is how I'd understand it <zimoun>civodul: ok. Another question. :-) "guix environment -C --ad-hoc hello RET echo $GUIX_ENVIRONMENT" display the profile. But not guix environment -C --ad-hoc hello -- echo $GUIX_ENVIRONMENT" <civodul>zimoun: in the second command, you see the value of GUIX_ENVIRONMENT in the parent shell <wdkrnls>I guess, there was one question I was wondering about: to what extent can guix guile apis be exposed through C++? (if at all). <wdkrnls>I was procrastinating on my tasks by musing about the possibility of embedding guix inside an R package. <zimoun>do we do a progress video chat before lunch break? Or do we wait that old simgrid is ready? ;-) <civodul>i only have a few minutes to offer this time :-) <khinsen>I was kicked out and probably missed the latest news... I am taking a lunch break, after finishing numarray (just a cleanup of the code from guix-bioinformatics). Will tackle NumPy after lunch. <civodul>khinsen: we briefly talked about what each one is up to <civodul>and then we have a meeting there at 6PM CEST to wrap up! <zimoun>civodul: you really type faster than me. :-) <khinsen>civodul zimoun OK, thanks for the status update! <zimoun>khinsen: civodul pushed old simgrid to guix-past <zimoun>PurpleSym: how is going the compilation? Fail or success? :-) <PurpleSym>zimoun: I’ve got all the dependencies of circles, but it’s failing to compile: coco.f:56: multiple definition of `main' <efraim>I'm going to have to take a break for a few hours, not sure if/when I'll be back later <zimoun>efraim: ok. Hope to see you later <zimoun>PurpleSym: well, my Fortran is a bit rust but I am not sure to see why. So it almost pass with gfortran? <PurpleSym>Yeah, looks like the final linking step fails. <PurpleSym>I have to put this aside for now though and do some work-related work xD <zimoun>PurpleSym: ok Good luck with the work-related work :-) <zimoun>PurpleSym: cool! What was the issue? <wdkrnls>hmm... I was going through the ReScience paper and trying to rebuild it. I got a numerical overflow. <PurpleSym>zimoun: Apparently the `program` implicitly creates a main function. I just removed it. <PurpleSym>Now the circles program fails at runtime: Fortran runtime error: Expected INTEGER for item 4 in formatted transfer, got LOGICAL <zimoun>PurpleSym: that's more annoying. <zimoun>did you package the dependency cosmdist? <rekado>I just pushed (past packages maths) with gsl-1.16 <rekado>I enabled the tests and found that there are two failures related to fscan <rekado>don’t know what the problem is; I disabled them. Figured it’s better than disabling the whole test suite. <zimoun>rekado: the old gsl-1.16 in Guix pass the tests, I guess <zimoun>rekado: commit 487da565703c34ae3b57977b0b6e31dada77a129, see arguments <zimoun>rekado: nice, now 2 gsl@1.16 show up when "guix search". The naming of modules appears clear. <khinsen>PurpleSym The first question is of this is really an error, or a behavior that compilers back then accepted and that programmers expected to work. <PurpleSym>khinsen: I’m not enough of a Fortran expert to answer this question. I don’t see any g77-compatibility options except for -ff2c – and that’s just ABI as far as I can tell. <paul-g>PIV progress: the original C code compiles successfully using the system gcc. <zimoun>khinsen: yeah probably an old Fortran behaviour. I am looking at. <paul-g>What would be the best way to repeat the compilation using Guix gcc? <zimoun>PurpleSym: from my old memories, files with .f77 or .f90 was compiled with gfotran with the norm 77 resp. 90. But I do not remember what for .f. And I remmeber an option like -x f77 but I am not sure. <civodul>paul-g: for PIV, it's up to you: you can add it to Guix-Past, or you can create a separate repo if you think it's too arcane or whatever <civodul>but i guess quite a few things will be arcane in Guix-Past, so it's okay <paul-g>civodul: the author describes the code as obsolete in the ReScience paper. <bonz060>When doing package dev, do you run create a container, and then when inside it, continue your work. I think I'm inefficient at this. I've created another profile where I'm installing things and testing things out abit manually. What's your "efficient" workflow? <khinsen>paul-g civodul I vote for addition to guix-past. Even if the code itself is of limited interest, it can serve as inspiration for others who would like to package old stuff. <civodul>khinsen: it can still serve as inspiration if it's in another repo, though <civodul>no strong opinion, but perhaps longer-term we'll have to clarify the scope of Guix-Past <paul-g>khinsen civodul: ok, I will use Guix-Past for the PIV code. <civodul>d'oh! i just realized i need to package Qt 3 <civodul>the first version that made it into Guix was 5.11 <rekado>zimoun: ah, thanks for the hint; disabling parallel testing is sufficient here <zimoun>civodul: ahah! always an issue with License. :-) ***e sets mode: +o nckx
***nckx changes topic to 'GNU Guix in high-performance computing | hack with us: https://hpc.guix.info/blog/2020/06/reproducible-research-hackathon/ https://mensuel.framapad.org/p/guix-hackathon-9hlj?lang=en https://meet.jit.si/guix-hpc-repro'
<zimoun>libopenblas is it not aliased to libblas? <zimoun>I do not know if my question makes sense but often code look for -lblas <civodul>openblas does not provide libblas.so, no <civodul>in general blas libraries use a different name <civodul>libblas is "reserved" for the netlib reference implementation <zimoun>hum? but openblas is not fully API compatible with blas (netlib) and so drop-in replacement. Same for atlas, and other variants. It is my remember. ***zap1 is now known as zzappie
***ChanServ sets mode: -s+c
<khinsen>zimoun It's not uncommon for people to keep several BLAS libraries around, e.g. with different performance characteristics. That's why each implementation has a distinct name, even if the APIs are the same. <bavier1>I'm probably a bit late to the party <khinsen>Status update: I have NumPy 1.0, 1.1, and 1.2 packaged for Python 2.4, but suspect there is a problem with Python 2.4 itself which I will now try to explore. <zimoun>bavier1: never late for a party :-) <bavier1>anyone need help with anything in particular? *nckx PSA: this channel has been registered with the authorities and civodul, rekado, apteryx, lfam now have ops. ***ChanServ sets mode: -o nckx
***ChanServ sets mode: +o nckx
***ChanServ sets mode: -o nckx
<zimoun>khinsen: about BALS, sometimes it is painful, depending on how it is hard-coded. And I rememebr old time playing with update-alternative on Debian. <nckx>Is this channel logged yet? Seems like a place where valuable info is spoken 🙂 <zimoun>well, today I did C-x h M-w and save in another buffer <zimoun>which package provides the well-known "find" tool? <civodul>nckx: it's not logged, could be useful if we keep using it! <civodul>zimoun: was saying something about BLAS, netlib, openblas, and all that <nckx>civodul: Oh, I thought it was intended to be as permanent as the HPC subproject itself. I'll wait then. <civodul>maybe it'll be that way, who knows ;-) <bavier1>wrt BLAS, we've tried to just pick the best implementation available ;) <civodul>i think we don't have netlib, but there's software out there that wants it (for some reason) <bavier1>I've been trying to name the input "blas" in case someone wants to do package rewriting to replace it <civodul>because each implementation provides its own subset/superset of BLAS/LAPACK <bavier1>yes, right, some projects rely on dark corners <bonz060>khinsen: Thanks! I'd love to. My pace is a bit slower compared to some folks here. I'll keep at it for the rest of my day. These stuff is interesting <bavier1>my use of BLAS has not gone very high in the package tower, so I'm not as familiar with integration strategies. <civodul>bonz060: don't worry about the pace, but feel welcome to ask for guidance if you stumble upon issues <zimoun>bavier1, civodul: I do not know if my memories are accurate enough. But I have vaporous remembering of playing with update-alternatives on Debian switch from atlas, openblas and probably netlib blas for some perfomance comparisons. Maybe the configuration tools was smart enough to figure out which implemetation... well, I do not know. <civodul>we should definitely look at how they deal with that <civodul>khinsen: tell efraim or rekado or myself when we should apply your changes to the main branch <bavier1>from what I recall, the update-alternatives switch was not "smart", you still needed to switch to an alternative that satisfied your needs. <zimoun>I will try to dig in my backup archives (which means a big mess!). <zimoun>bavier1: I had in mind the configuration tool such CMake or configure. :-) <zimoun>from my memories, update-alternatives just do a symlink to libblas pointing to e.g. libopenblas <bavier1>ah, right :) usually those are smart enough to check for required symbol definitions <zimoun>PurpleSym: still around? I hit some issues with "multiple definition" in isolat. Did you have the same? <PurpleSym>zimoun: Yeah, still here. I haven’t had any issues with that in isolat. <PurpleSym>For astromics I solved it as follows: (substitute* "astromisc/lib/coco.f" (("program testcoco") "function testcoco()"))) <zimoun>bavier1: I will play this week-end or next week with update-alternatives for refreshing my memories. :-) <zimoun>PurpleSym: ok. Weird. I have "packaged" isolat. Maybe configure is confused. ***services. sets mode: +o ChanServ
<zimoun>PurpleSym: have you used something special with ./configure? <khinsen>Guix experts: can I tell the gnu-build-system to use a different version of gcc? <rekado>can’t you just override the GCC input? <rekado>that’s what we do for a few packages <rekado>see alsa-modular-synth for example <khinsen>Background: I suspect that some compiler optimization breaks Python 2. The symptom is that "2**64" returns 0, rather than correct result as a Python Long integer object. <rekado>what doesn’t work is to override it with the recursive input rewriting mechanism AFAIK <rekado>I’m going to upload my logs to bayfront, and then enable #guix-hpc in goggles <PurpleSym>No, the idea was to use the original, untouched code, right? <khinsen>@rekado Thanks, I will look into that! <zimoun>PurpleSym: yeah. Well, I have not read all the paper and I thought that the code linked to the submission would be easier. :-) <khinsen>efraim rekado civodul I doubt I'll add anything more today, as I have to leave in 15 minutes for another meeting. If you want to merge my branch, go ahead. I will explore the Python compilation issue later. <zimoun>rekado, khinsen: yes but it will not apply to the dependencies, so you have issues. <PurpleSym>zimoun: From what I read in the paper the code in this new repository received some fixes/changes. <khinsen>zimoun Thanks, that's good to know. For my subject that shouldn't be an issue. <zimoun>khinsen: give a look to packge-with-python2 <khinsen>zimoun That's a different issue - my problem is compiling Python 2.4.6 itself. <zimoun>khinsen, for rewritte with another "compiler" all the dependencies. To be exact package-with-explicit-python <zimoun>you can write package-with-explicit-gcc and then provide the version toolchain you want and so recompile everything with old GCC <khinsen>zimoun Thanks, that looks like what I want. Will try... later! <khinsen>Got to go... See you on the mailing list! <zimoun>Yes! and I am already there, if everything is right <zimoun>yes, I think send an email. What could be nice is to collect all the commits and all the experience, what works, fails, is difficult and so on <zimoun>Some are still around? For a quick outro? <civodul>i felt like there's a satellite connection between Bordeaux & Paris :-) <zimoun>because Sud-Ouest is so far from Paris :-) <bavier1>or Jitsi's poor performance with Firefox clients? *civodul was using ungoogled-chromium <civodul>IME it doesn't/didn't work at all with IceCat :-/ <zimoun>rekado: do you plan to add #guix-hpc to logs.guix.gnu.org? <jonsger>bavier1: I think it's a problem of Jitsi itself and the instance. I used it multiple times in meetings up to ten persons and it was never a pleasure... <bavier1>that could be, but apparently it has to do special things for FF clients that doesn't scale as well <rekado>zimoun: it’s already there, but I need to reconfigure bayfront to get the goggles update <rekado>I use ungoogled-chromium as my jitsi client :-/ <rekado>specification->package does not work for hidden packages, so I can’t use it to select a lower version of GCC. <civodul>OTOH (gnu packages gcc) can be considered stable ***nckx is now known as ProboskissesXOXO
<jonsger>do you have an inferrior for chromium or do you build it everytime? ***ProboskissesXOXO is now known as nck
***nck is now known as nckx
<rekado>hmm, the gitlab notifications are funny: /builds/ZfZ6t9Nk/0/guix-hpc/guix-past/modules/past/packages/maths.scm:30:13: gsl@1.16: can be upgraded to 2.6 ***zap1 is now known as zzappie
<rekado>logs are now available at logs.guix.gnu.org <bonz060>I'm trying to build matplotlib but it's failing because: https://paste.debian.net/1155059/. From `less setupext.py`, I think my sys.platform should just be `linux`, but I can see the error spews: `linux5 is not in the list of basedir`. Any ideas? <bonz060>I do not want to add a `linux5` somewhere, because the point of guix-past is to work on all future platforms <civodul>bonz060: "linux5" is a reference to libc5, the linux libc from back in the day? <civodul>oh do you think it's from the output of "uname -r"?