IRC channel logs


back to list of logs

***Server sets mode: +nst
<civodul>hey, how's everything?
<civodul>pjotrp: are you in CEST these days? :-)
<pjotrp>much better
<pjotrp>I mean, yes
<PurpleSym>I’ve never written any Fortran code, but sounds interesting. As far as I understand the challenge would be to compile gcc-3.4.6, which includes g77?
<bonz060>Hi \o/
<civodul>PurpleSym: ah ha, could be!
<civodul>though perhaps a more recent gcc would do?
<civodul>it can be tricky and time-consuming to package old compilers
<civodul>hi bonz060!
<PurpleSym>I mean, we have 4.7 in Guix as part of the bootstrap process.
<civodul>does 4.7 have g77?
<civodul>zimoun: you around? :-)
<PurpleSym>I’m inclined to say it does not.
<PurpleSym>Nope, says g77 is only included prior to GCC 4.
<civodul>ah alright
<civodul>so gcc 3.4, so be it!
<civodul>i'm tempted to look at this one:
<civodul>primarily C code AIUI
<zimoun>civodul: hi! I am a bit late... Coffee mistake, whatever! :-)
<civodul>hey zimoun!
<civodul>know should we proceed? :-)
<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>You could use: for streaming...
<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.
<bonz060>That is if we choose to set ^^ up
<bonz060>pjotrp: wassup wassup \o/\o/
<efraim>mrining everyone!
<zimoun>PurpleSym: I have started to look at issue#41 about g77.
<zimoun>hi efraim!
<bonz060>efraim:wassup wassup \o/\o/
<zimoun>is Konrad around?
<PurpleSym>zimoun: Ah, nice. How far have you gotten?
*efraim probably needs more coffee mrining ~ morning
<civodul>hey efraim
<civodul>zimoun: do we have videoconf at 9:30 to get started?
<zimoun>civodul: I was writing that :)
<civodul>not sure if Konrad is here
<zimoun>I propose this video chat
<civodul>zimoun: i haven't done anything yet about but it looked like a reasonable goal for me :-)
<civodul>zimoun: alright!
<civodul>hello khinsen!
<khinsen>Hi everyone!
<zimoun>hi khinsen
<zimoun>civodul, if works, I could send the link on
<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.
<civodul>no it's not logged
<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 :-)
<zimoun>Please join on
<civodul>it's working!
<civodul>i can even hear your keyboard, zimoun :-)
<zimoun>we could share more easily the work, the camera can be turned off
<civodul>khinsen: sounds like a plan, yes
<civodul>do you want to set one up? framapad?
<efraim>it sounds like someone's playing in traffic
<civodul>thanks khinsen
<civodul>ah, too late zimoun :-)
<zimoun>sorry, I miss you khinsen
<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.
<zimoun>Kyle: RStudio related thing in this channel that civodul talked about
<PurpleSym>khinsen: gwt is here: but I did not package it “properly”, i.e. it is using binary dependencies.
<khinsen>zimoun Do we have RStudio in Guix now?? I can't find it.
<civodul>so thanks everyone for joining! :-)
<PurpleSym>khinsen: No, it’s not in guix proper yet.
<civodul>for those who could not make it on, we'll now start the good hack :-)
<zimoun>khinsen: well, it is long story :-)
<zimoun>maybe something in this channel
<civodul>zimoun: i can hear your keyboard :-)
<khinsen>civodul Who is starting what???
<civodul>i'm getting there
<civodul>so each of us can drop a line here and on stating what they would like to work on
<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>or on (chat/video)
<civodul>how does that sound?
<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?
<bonz060>Does that list have to be part of: I had something I'm familiar with in mind that's not part of that list
<zimoun>khinsen: efraim adds Python 2.4 to the channel guix-past
<efraim>I also have some more python2.4 packages here that I'll upstream after cleaning them up a bit
<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>you're all welcome to contribute old packages to
<civodul>there are rough guidelines in its
<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.
*civodul is going to look into getting the software for up and running
<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, 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, 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>to begin with, at least
<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)
<civodul>bonz060: you can add what you had in mind to the list at
<bonz060>Hmmm... I see nowhere for creating an a/c on INRIA.
<civodul>i think it's at
<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.
<zimoun>hi paul-g
<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).
<civodul>hi paul-g, nice
<khinsen>Hi paul-g. That looks like a nice project.
<civodul>paul-g: you can add a line at
<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, 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
<khinsen>zimoun Yes, we are talking about
<civodul>khinsen: i've added you as a member of so i think you can push to any branch but "master"
<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 ;-)
<civodul>khinsen: ah indeed :-)
<civodul>should adjust it
<civodul>but you get the idea: pass --substitute-urls= somewhere ;-)
<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
<civodul>if you want to enable it permanently, see 'guix-configuration' at
<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)
<khinsen>civodul That looks simple, thanks!
<zimoun>guix build -L . foo --substitute-urls= I guess
<zimoun>Sorry I miss who is Lars here? :-)
<PurpleSym>Here, me.
<zimoun>PurpleSym: does modern gfortran not support the 77 norm?
<zimoun>I am looking at g77 too
<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.
<zimoun>khinsen: thanks
<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.
<PurpleSym>Do we have GSL 1.x somewhere?
<civodul>i don't think so
<civodul>well that doesn't cover all the history
<efraim>1.16 was in 2013, it might be in guix's history
<rekado>PurpleSym: I have it!
<civodul>it's not reachable via time-machine
<civodul>yay! :-)
<civodul>hey rekado
<PurpleSym>Ah, nice. Thanks!
<rekado>feel free to take whatever you want from that module and add it to guix-past
<civodul>neat :-)
<civodul>PurpleSym: if you don't mind creating a 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>PurpleSym: yes, sure
<rekado>no, there are no substitutes
<rekado>zimoun: ^^
<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>civodul: I'm one of them
<bonz060>I'm trying to figure out a package to hack on.
<zimoun>rekado: thanks.
<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>ah ok
<civodul>bonz060: so if you want to look into python, perhaps let's sync with khinsen
<bonz060>Cool. Thanks for the pointer.
<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.
<zimoun>PurpleSym: I am doing something similar but with another "simpler" example by khinsen,
<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>but not to anything outside it
<rekado>I see. That makes sense.
<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.
<civodul>khinsen: sounds good
<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.
<bonz060>khinsen: I see you are working on NumPy and also: Do you mind if I have a go at matplotlib for Python2.4?
<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 ':(
<bonz060>khinsen: ^^
<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.
<khinsen>bonz060 For example much of the stuff already in You could clean this up and transfer to guix-past.
<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.
<khinsen>bonz060 Sounds like a good plan!
<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
<civodul>efraim: yes
<civodul>paul-g: neat
<efraim>well, ls returns 127, which causes guix environment to return 1, is how I'd understand it
<civodul>ah yes
*civodul packages old simgrid for
<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
<civodul>that's why
<zimoun>civodul: ah right.
<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>khinsen is not around?
<zimoun>do we do a progress video chat before lunch break? Or do we wait that old simgrid is ready? ;-)
<civodul>old simgrid pushed!
<civodul>let's do quick chat
<civodul>i only have a few minutes to offer this time :-)
<zimoun>fine with me
<civodul>everyone: you can stop by if you want!
<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>taking a lunch break too
<zimoun>khinsen: yeah lunch break.
<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 :-)
<PurpleSym>Now it compiles successfully.
<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?
<PurpleSym>No, using the bundled cosmdist right now.
<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.
<civodul>rekado: good, well done!
<civodul>let's see what says
<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.
<zimoun>I mean in location: :-)
<zimoun>PurpleSym, rekado: now I am rebuilding the package cosmdist dependency of It is really to see how Guix is so flexible :-)
<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?
<paul-g>Would a new channel be needed?
<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>thanks, paul-g!
<civodul>d'oh! i just realized i need to package Qt 3
<civodul>the first version that made it into Guix was 5.11
<civodul>ah no, we had Qt 4.8.5 too
<rekado>zimoun: ah, thanks for the hint; disabling parallel testing is sufficient here
<civodul>nice welcoming message from qt:
<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:'
<civodul>thanks nckx :-)
<zimoun>nckx: thanks for the topic. :-)
<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, no
<civodul>in general blas libraries use a different name
<civodul>libblas is "reserved" for the netlib reference implementation
<civodul>which i think is not in Guix yet!
<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
<bavier1>hi guix!
<zimoun>hi bavier1
<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.
<khinsen>Hi bavier1!
<bonz060>hi bavier1 \o/\o/
<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
<khinsen>bonz060 If you are still interested in matplotlib, you could base it on my NumPy packages at
<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.
<zimoun>nckx: cool!
<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?
<nckx>zimoun: findutils
<zimoun>nckx: thanks
<civodul>nckx: it's not logged, could be useful if we keep using it!
<civodul>hey bavier1!
<civodul>zimoun: was saying something about BLAS, netlib, openblas, and all that
<civodul>dunno if they need help :-)
<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 ;)
<bavier1>as the default.
<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>yeah, but it's complicated
<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>non-standard APIs
<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!).
<khinsen>civodul Will do!
<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>Thanks for the tip of astromics
<zimoun>PurpleSym: have you used something special with ./configure?
<PurpleSym>Nope, let me paste my module somewhere…
<PurpleSym>Without any proper indentation:
<khinsen>Guix experts: can I tell the gnu-build-system to use a different version of gcc?
<zimoun>khinsen: no. sadly
<zimoun>it is a feature request :-)
<zimoun>PurpleSym: thank you
<rekado>can’t you just override the GCC input?
<rekado>that’s what we do for a few packages
<nckx>It's worked for me.
<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>BTW: this channel is now logged
<rekado>I’m going to upload my logs to bayfront, and then enable #guix-hpc in goggles
<zimoun>PurpleSym: ah right, you do not compile the circle code of the link in
<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
<zimoun>PurpleSym: ok. Good to know.
<khinsen>zimoun Thanks, that looks like what I want. Will try... later!
<civodul>khinsen: noted, thanks!
<khinsen>Got to go... See you on the mailing list!
*civodul pushes gtnets
<civodul>zimoun & all: wrapping up on in 5mn!
<zimoun>Yes! and I am already there, if everything is right
<civodul>maybe we can all add links to commits, or short experience reports to
<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> now!
<rekado>(interesting delay times!)
<rekado>gotta get myself a nice headset
<civodul>mine is terrible
<civodul>but it has a mic!
<civodul>i felt like there's a satellite connection between Bordeaux & Paris :-)
<zimoun>mine was not working :-)
<zimoun>because Sud-Ouest is so far from Paris :-)
<civodul>to everyone who couldn't make it to the chat, please add whatever you've been up to to
<civodul>thank you all for joining!
<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
<bavier1>browser detection too strict
<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
<bavier1>even if only for a single FF client
<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.
<rekado>(unless I use “gcc-toolchain”)
<civodul>ah yes
<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
<rekado>well, … yeah.
<zimoun>ah really :-)
***zap1 is now known as zzappie
<civodul>rekado: heh :-)
<bonz060>civodul: cool thanks.
<rekado>logs are now available at
<bonz060>I'm trying to build matplotlib but it's failing because: From `less`, 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>thanks rekado
<civodul>bonz060: "linux5" is a reference to libc5, the linux libc from back in the day?
<civodul>or does that mean something else?
<civodul>oh do you think it's from the output of "uname -r"?
<bonz060>Yeah. That's what I see since it uses GCC 7.5.0. Though in a python24 repl, I can see the output of `sys.platform` to be linux4. Btw, I'm looking at:
<bonz060>civodul: I'll try following this: to figure out what's going on...