<truby>leoprikler: does what I'm trying to do make sense though? Basically, I spend a lot of time building LLVM and related projects with different compilers; it'd be really great to be able to use guix to manage these compilers and build environments. Unfortunately LLVM's build system sort of assumes you broadly follow the FHS in a lot of places :-(
<truby>If I wrote a patch that implemented something like this as a flag for guix environment (-C) would this be something interesting to other people/something likely to be accpted? :-)
<leoprikler>truby: the guix-y solution would be to patch the build system where necessary and use configuration for everything else
<leoprikler>I think a more helpful patch would be one, that allows setting up an environment and running certain phases, specifically those before build.
<leoprikler>(kinda like guix build -K but without a failing build)
<truby>Yeah, I understand that for writing packages in guix. But I'm trying to use guix to make a build environment as a developer for coding/testing software that isn't going to be distributed as part of guix, like as a sort of much more comprehensive virtualenv. Maybe this isn't what guix is aiming to do but it's so close to being perfect for this use case
<truby>leoprikler: that would work, but would also require the thing you're building (which might be a prototype) to have a guix package first. I guess that's not that much overhead, just approaching it from a different direction to what I'm thinking :-)
<leoprikler>You don't have to have a fully working package for that.
<leoprikler>And you don't have to write packages with the intention to contribute them to Guix itself.
<leoprikler>You can write a rather simple definition for your package in some file and use guix environment -l FILE
<truby>sure, but it's more overhead than what I'm thinking. My dream is to be able to do something like guix environment -C --fhs --ad-hoc gcc-toolchain@8 ncurses ... and git clone -> build a package that only cares that I have gcc 8 and ncurses installed and has no idea I'm using guix
<truby>I'm more approaching this as a user of guix (the package manager) as opposed to guix (the system)
<leoprikler>most use pkg-config or the aformentioned programs
<leoprikler>but even assuming you have hardcoded paths (bad idea)
<leoprikler>you can do sed -e s#/usr/include/something/#/gnu/store/something-else#
<truby>I fear that "most" isn't really true these days, cmake is probably the "standard" in C++ build systems these days, and that doesn't use pkg-config. then you also have waf/scons/custom makefiles :-(
<truby>for a concrete example, part of why I'm asking for this is the patch I posted today :-) While it'd be really great if clang behaved nicely in guix, currently it looks for its headers in very specific FHS locations that obviously don't work here. My patch specifically hardcodes clang to look for headers in /path/to/guix/libstdc++.. but this doesn't cover every use case
<truby>yeah, CMake has a pkg-config module where you can ask in your build system to fetch paths from pkg-config. It's quite rarely used though, e.g. if I was writing a C++ program with a CMake build system I wouldn't ask cmake to give me boost via pkg-config, because CMake knows how to look for boost itself directly and using its built in mechanisms allows my build system to work on non-Unix platforms
<truby>e.g. LLVM asks for zlib from CMake, this doesn't go through pkg-config but rather cmake's mechanisms for finding things, and this fails on Guix (there's a specific patch in llvm.scm to fix this)
<leoprikler>will this built-in mechanism default to pkg-config if nothing else is found?
<truby>It depends on how the FindX.cmake file was written. But at a cursory glance generally not (FindBoost.cmake and FindZLIB.cmake don't)
<leoprikler>and there are no command line options like --with-boost-path=/path/to/boost?
<truby>I feel like we're getting sidetracked from what I'm trying to say here. I totally agree that we want as much stuff in Guix as possible, and I'm more than happy to contribute packages for all the stuff I work on. But if I get a report from a user of my compiler saying "x version of gfortran and y version of flang builds my program but your compiler doesn't, what gives?", it'd be really nice for me to be able to check all this
<truby>without fixing the build system on their code first
<truby>and I have no way of verifying if they've written their build system properly :)
<leoprikler>true, but there seems to be a bigger problem than that
<leoprikler>assume bizzare-cc x.y.z on builds all the code (including fortran and flang stuff, because it's such an awesome compiler) on one distro (e.g. Debian), but not on another (e.g. Arch)
<leoprikler>since neither Debian nor Arch are known for their reproducibility, that may very well happen
<leoprikler>If you now come along with "HAHA, Guix saves the day", with or without proceeding to fix the build system, you will only introduce another build environment and one more vote on the "bizzare-cc works" or "bizzare-cc doesn't work" debate.
<truby>I somewhat disagree, in that "well, if you run guix environment --manifest=... -C --fhs and then build your thing it seems to work, what's different about your system" is a useful datapoint. But it's also orthogonal to what I really mean. I'm saying that sometimes I need to test a code with multiple versions of different compilers, plus my own compiler, and see what they all do differently. Guix makes this really _really_ easy
<truby>right up until the point where the code I'm trying to test's build system uses the FHS :(
<leoprikler>"uses the FHS" or "makes inappropriate assumptions based on the FHS"?
<leoprikler>for instance, the FHS mandates /bin/ls, which indeed is missing in Guix
<truby>The latter is probably correct, but the distinction is not really relevant. I agree that if everyone wrote their build systems correctly then what I'm proposing wouldn't be at all necessary, but unfortunately that's not ever going to be the case
<leoprikler>(it does mandate /usr/bin/python though, which is hilarious given that interpreters use /usr/bin/env python in spite of the FHS)
<leoprikler>Making the world a better place, one build system at a time :)
<truby>clang itself, for example, makes an innapropriate assumption that libstdc++ will be in /path/to/crt0.o/../include/c++ or similar. This obviously doesn't resolve in guix, so we have to patch not only the build system but the source itself of clang. (I have been thinking how we can fix this upstream in clang, and I totally think that's something that should happen, but I haven't got a concrete answer yet)
<vagrantc>and python insists that /usr/bin/python should either point to python 2.x or not exist
<leoprikler>which is funny, because some distros allow it to be set to python3 by default
<truby>unfortunately if all I want is to build someone else's C++ software, but I want to manage all the dependencies with guix (because dependency management with anything else is, lets be honest, vastly inferior), I can't rely on their software not making these assumptions. So my dream would be to have a --fhs flag to go with guix environment -C so that if I do come across someone else's software I can build it :-)
<truby>perhaps the mailing list is a better place for an RFC on this than irc?
<truby>ooo this looks promising, I'll have a look tomorrow! thanks :-)
<leoprikler>it does not seem to work for /bin, but it does for /bin/ls
<leoprikler>you also might have to repeat <stuff>, I haven't tested it more than running some ls
<leoprikler>(which indeed does not work without <stuff>, in my case <stuff> = guix)
<truby>I think I probably also need to sit down with the infrastructure team at work and see what they actually want, I'm not the one working directly on builds I'm just the one pushing guix as the solution to all our problems :-)
<leoprikler>the sad thing is reproducibility on Guix does not guarantee, that it will run on Arch
<truby>but, it should guarantee that it works for someone on arch that runs some guix manifest that I write?
<leoprikler>I trust Arch to break Guix beyond any repair tbh
<leoprikler>jokes aside, if you have guix, things should work out
<truby>the main problem, that guix seems really obviously the solution to in my head, is we have shared systems where everyone needs different compilers/packages/etc and sometimes people sudo apt install things on these systems that break everyone else's workflows
<truby>if everyone was on their own guix profile this problem trivially dissapears
<truby>guix pull takes a really long time on aarch64 compared to x86, even without substitutes :-( which is why I was looking in to performance. It spends a lot of time in e.g. libgc and other guile interpreter functions rather than actually building anything concrete
<truby>and I'm hoping the aarch64 jit in guile 3 will fix this issue :-) but that may be optimistic
<leoprikler>then time ./pre-inst-env guix build <something> vs. guix build <something>
<leoprikler>not really sure, how to measure pull performance though
<truby>I haven't done real concrete measurements but guix pull takes ~30 minutes for me on an AArch64 server and ~30 seconds on my x86 laptop, and it doesn't seem to be a lack of substitutes that causes the problem
<leoprikler>tbh I'm kinda interested in those numbers myself
<olivuser>so, again, after updating, I am prompted that it would be a good idea to "set the necessary environment variables". Can anyone explain to me how that works?
<olivuser>I'm asking because initially I thought that I'd just put the line in .bashrc, but when sourcing, bashrc would get angry and say that the " . " syntax is bad. Thus, I thought I'd have to have both paths exported, with a colon separating both paths (export GUIX_PROFILE="/home/user1/.guix-profile:$GUIX_PROFILE/etc/profile"). But when I had this in my .bashrc, I was still notified to set my environment variables
<leoprikler>olivuser: I don't think .bashrc is the right place for that
<leoprikler>on Guix System, things /should/ work fine if you just spawn a new shell
<olivuser>leoprikler, so essentially I can ignore this message?
<olivuser>I mean the message that I was referring to earlier, which pops up sometimes after I installed stuff.
<leoprikler>yes, but you might want to do those steps if you keep using the shell that you guix updated in
<leoprikler>iirc this message pops up when a new path gets introduced that was not set yet, but i might be wrong about that
<olivuser>or if it works any different than it would on normal machines? I am wondering since the store is not something I should tamper with. but somehow I still have to access the source code or have it in the same place as the config.h by which suckless plugins are configured
<leoprikler>the guix-y way would be to write a package for that, e.g. suckless-tool-with-my-awesome-patch
<olivuser>and to then point to the location of the config.h file?
<olivuser>leoprikler, I have another, "non-technical" question for you. what is your (programming-related) background when going about guix? I'm asking because I'm not a programmer but a very interested and ideologically convinced sociologist willing to learn to program. And whenever I ask something here in the channel I get the feeling that I am about the only person sufficiently harakiri to try to invest time into a project only programmers invest time into
<olivuser>and that I'd have to learn soooo much more before actually profiting from the answers that knowledgeable people like you give to me - or to ask for a very long time before I actually understand
<leoprikler>to answer your question, I'm a Computer Science student, so my experience is certainly different from someone with no background in programming at all.
<leoprikler>However, I am self-taught in both Emacs Lisp and Guile (also Guix by extensions), since you don't get to learn that in universities.
<olivuser>yeah thats what I suppose, these are not the hegemonic languages told in university.
<olivuser>but I guess knowing /a/ language is a big plus when learning guile/elisp. for me it is veeeery difficult to wrap my head around the core concepts of programming
<leoprikler>In my opinion, it should be possible to learn LISP (dialects) easily, once one gets over one's irrational fear of parentheses.
<olivuser>leoprikler, yeah thats what I think too, in principle. but still, I currently feel that my learning progresses like a snail, extremely slowly, because it has not yet clicked. Thus I am very frustrated when I ask someone (like you) and only remotely understand what the hell you are talking about
<olivuser>even though the explanation is probably valid and not too complicated to understand, if it is not for fundamental basics missing
<olivuser>leoprikler, well said, thanks for the headsup :)
<leoprikler>No, that's my fault too, because I'm keeping things brief.
<olivuser>leoprikler, well but who can expect people in irc to explain things in a very verbose fashion. after all, it is freetime that is spent in explaining things to people that they could, in principle, learn on their own
<leoprikler>An overly detailed answer would probably be overwhelming at first sight too, but a proper walkthrough for some packages is the way one actually learns.
<leoprikler>If you have no background in programming, what draws you to suckless tools?
<olivuser>yeah, thats completely true. yet, it is a question who has the resources to do so. especially since I am probably not the only person asking entry-level questions. I already considered talking to guix devs to write an entry-level blog which really walks people through, to a point where it is boring as fck for experienced people, but the right level of verboseness for extreme newcomers
<olivuser>leoprikler, because I like visual and programming minimalism. the former is less distracting on the eyes and the latter enables me to run very very old machines with a graphic interface
<leoprikler>olivuser: For a more generic explanation, you can have a look at the Guix cookbook
<olivuser>I switched to vim/emacs during my masters thesis because my eyes would be too distracted to concentrate on the writing process when using word or texmaker
<leoprikler>For specific questions, e.g. "what is wrong with this package definition", IRC is a better help?
<xd1le>olivuser: regarding learning scheme, sicp is a great book but idk maybe these days it's too old/not modern
<leoprikler>I started with Elisp snippets before they became packages.
<xd1le>but i think more so you would be spending more time learning guix-specific guile things, since scheme itself is arguably pretty minimal
<olivuser>xd1le, I actually bought sicp and I am veeeeeery slowly working my way through it. doesnt really help that Im a lousy mathematician and kind of struggle with implementing mathematic formulae
<olivuser>xd1le, my issue with guix is that my base-level programming knowledge is too limited, I feel. When I read through the manual, it kind of makes sense, but I would know how to do on my own - even when mostly copying from the manual -, and am easily confused in the debugging process
<xd1le>honestly you probably don't need to finish the whole book to make use of guix? but I'm not sure I guess it's hard to assess from the other side.
<olivuser>xd1le, yeah probably. I guess Im just a bit too impatient to accept that learning to program takes time - just as learning any other complicated thing does take time
<xd1le>olivuser: if you like suckless projects, does that mean you know C? I find C much more difficult. But yeah guile debugging and just debugging in general can be tough.
<xd1le>olivuser: ahh. I figured if you knew C I could give a comparison with it for guile.
<olivuser>leoprikler, yeah, thats why I was excited about the suckless thing. but your suggestions, while probably legit, were kind of daunting for me. but then again, a newbs threshold is very low compared to a proper programmer.
<xd1le>Guix using guile I feel is actually a great 'feature' though. But I guess that's easy to say when already knowing guile.
<leoprikler>tbh I think packaging some suckless tool would be a great experience too
<olivuser>anyway, I am very grateful for you to take your time to reply to my questions. thats what makes learning quite a bit less shitty, because you then feel less alone with those problems. I tell you, about no other social scientist I know gives a crap about linux/programming matters
<olivuser>xd1le, so it makes more sense to learn racket instead of scheme? I was unsure, also because I have already bought sicp and thought that, after all, the difficulty to learn shouldnt be too different
<olivuser>leoprikler, I know, it hurts me too. on the other hand, I can play the linux pope when their old computers dont support windows anymore :-)
<leoprikler>Racket, like Guile, is a Scheme dialect, so the basics are the same
<leoprikler>However, they diverge as soon as you consider extra features.
<xd1le>racket isn't all that different from scheme (from what I know), so you can probably apply racket to sicp
<dutchie>I think if you want to learn racket you should also consider How to Design Programs
<olivuser>alright. Then Ill see how long I am able to follow sicp, and if Im no longer able to follow I will see how far I get with racket. I already found two introdutory books, one in english and one in my native language (german)
<dutchie>"As the years have passed the programming language Scheme has evolved. The language #lang sicp provides you with a version of R5RS (the fifth revision of Scheme) changed slightly in order for programs in SICP to run as is."
<leoprikler>perhaps Guile should consider such an environment too
<olivuser>dutchie, thats a good suggestion, I already have that on my "radar" in case sicp fails me (or I fail it, depends...)
<olivuser>leoprikler, I would love this, because it would lower the threshold for people to, for instance, start packaging.
<olivuser>I had already considered to suggest something like a "you have no clue, then read this"-blog for people who are as inexperienced as I am
<olivuser>but I guess it will take me some more time until I am able to explain stuff to other people instead of getting stuff explained by people :D
<leoprikler>btw. have you found programs in SICP that don't work like they should in Guile?
<olivuser>leoprikler, I have not come past chapter 1, so I cant judge this. thing is that I wanted to minimise the chance that I get confused by things working differently in scheme and guile, because I would be unable to differentiate
<xd1le>Guile is a scheme implementation, so it should work same as what the scheme language says
<xd1le>but there are lots of scheme implementations, which is where you'll find many differences
<leoprikler>Scheme is less of a language and more of a family of dialects
<olivuser>xd1le, but a noob cannot differentiate between things not working because of a poorly or wrongly written program and an error related to a different implementation
<leoprikler>given that there is no "standard" implementation whatsoever
<leoprikler>you can ask more experienced people whether that's a bug in your program or of the interpreter
<leoprikler>in fact, if you copy examples from a book and they don't work as expected, that's probably what you should do
<leoprikler>(unless that book has been discredited before, which SICP has not afaik)
<xd1le>Right, leoprikler basically just said what I was going to.
<leoprikler>but even if that book has been discredited, you're not going to find out about that unless you're asking for help
<xd1le>My main reason really for recommending Racket to newcomers is (probably) more internet resources regarding racket dedicated to newcomers. Other than that, should be able to use either Guile or Racket for sicp, but probably guile would be better since it is a scheme whereas racket isn't.
<leoprikler>I'm not a teacher, but my personal gut feeling is to teach something that will later be useful.
<leoprikler>To me it makes little sense to install Racket as a teaching aid if it's not going to be used elsewhere (as part of a project or whatever).
<leoprikler>With the goal of writing simple packages already on the table, learning Guile and some of its specific oddities has its merits.
<leoprikler>That said, I might be biased, because my university forces me to use Scala and I've learned to hate everything in any way related to the JVM.
<olivuser>yeah I thought that sicp might be in a way closer to guile (since it is a scheme).
<xd1le>yeah I was thinking learning racket could translate to scheme easily but I guess it could also trip you up. It's hard for me to judge as well since I don't really use racket anymore, but still use guile for guix.
<leoprikler>Exercise 1.5 tought me something valuable about tail recursion.
<dutchie>olivuser: many many people have posted their solutions online, you can often find them on github or similar
<dutchie>but definitely have a proper try on your own first
<olivuser>dutchie, I have searched for solutions. but some of them were confusing to me and with some of them I was unsure whether they are right or not. Its mainly about having a source of reliable information where I can peek if i REALLY cannot come up with a solution or do REALLY not have ANY idea how to solve the issue. Another sad social scientist story, no one wants to learn scheme with me :>
<dutchie>olivuser: no, it won't load it unless you tell it to. something like (for example) `(use-packge racket-mode :mode "\\.rkt\\'")` should do the trick if you have installed the emacs-racket-mode package
<str1ngs>fps: after installing xfce4-terminal and restarting your X11 session does the problem persist?
<alextee>i'll try to see which packages exactly because i installed a bunch of stuff
<zimoun>Hi, the sources of the package gdsl (gnu/packages/datastructures.scm) are now down because gna.org is down (see bug#25913). Therefore, it is built using the source from ci.guix.gnu.org which currently works but it is not really nice. Given a look at Software Heritage, the sources are already inside. However, I do not know how to proceed: replacing the current source by the SWH one. Any advice or pointer? Thank you in advance.
<bavier>zimoun: SWH will be used as a fallback if other sources disappear; to me it seems like not an immediate issue.
<fps>hmm, is there a way to get access to the "guix describe" command in a package build?
<fps>or some other way for the build process to know what guix version [commit] was used to build a package?
<fps>hmm, maybe i can pass the guix version via #:make-flags in the package description
<fps>but how to get the guix version inside the package code at guix invocation time?
<zimoun>bavier: I am not sure that the store on ci.guix.gnu.org is reliable as source for building package. And the other sources already disappears. From my opinion, we have 2 choices: 1. put somewhere (Gitlab, Github, Savanah, etc) the source of GDSL (only required by the package bwa-pssm) or 2. use archive stuff (archive.org, SWH, etc).
<fps>hmm, ok, so guix repl gives me a repl with guix modules loaded
<fps>and i can actually (use-modules (guix describe))
<fps>but how to make use of that to get the commit string i don't know hyet
<smithras>hi guix! I've got a question about packaging
<smithras>I recently packaged minisat, a 10-year-old SAT solver that I needed for school. I have it in my personal channel at the moment, and I could submit a patch for guix, but I don't know if anyone else uses the package
<smithras>Is there a set of guidelines for what should be packaged?
<leoprikler>you can package anything as long as it's free software
<leoprikler>as for how to package it and submitting patches, there is the Contributing section of the manual
<fps>beware though, it's not the easiest to parse. best look at some example patches on guix-patches mailing list
<roelj>fps: There's %guix-version in (guix config). Maybe you can use that to get the version of Guix in your recipe?
<smithras>leoprikler: Thanks! I'll see if I can get a patch sent later today then, who knows, maybe someone will find it useful!
<leoprikler>(by the way, you may want to add it gnu/packages/maths.scm, z3 is already there)
<fps>roelj: yeah, just stumbled across that one, too. trying now :)
<civodul>fps: you can do (profile-channels (current-profiles))
<civodul>the way i'd do it is by somehow including the output of "guix describe" along with a manifest in the article
<civodul>actually, you can put these two files in a repo, and give the URL of that repo
<pkill9>hmm, would it be a good idea to have guix error if it is asked to install the `guix` package (both from being added to the system config and from the `guix install`/`guix package --install` commands)? Maybe add a flag such as `--allow-install-guix` incase someone wants to install it to a profile for whatever reason? It might help eliminate problems newbies encounter
<vertigo_38>I just added another user to my system through config.scm and reconfigured. I can see the user in /etc/passwd and all the id-information is correct. After giving it a passwd, I also see it at the login screen (gnome), but there was no /home/USER created on the filesystem, so I can't really login. I also can su to the new user, but also from there only the home directory of the initial user is visible. Do I have to create the directory,