<cnmne>I was looking at the packaging for sage-math and I found a checklist on hackmd.io (i think) that had a checklist of packages that were necessary so far and whether they had build recipes or not; I wanted to try to make progress on that but have lost the link !! does anyone know about that list (i can't seem to search it right), or where to find a more updated resource ? <wdkrnls>I didn't see it in the licenses.scm file <wdkrnls>when packaging, is it good practice to change $DESTDIR/usr/bin/program to $DESTDIR/bin/program since it doesn't seem like /usr/bin is on path? <lfam>wdkrnls: Yeah, or maybe set $PREFIX <wdkrnls>okay, cool. thanks, lfam. I was able to change $PREFIX for my last package, but the one I'm trying to package now doesn't seem to have such a variable in the make file. I bet there is some kind of sed-like magic scheme function to do a search an replace. <lfam>Usually these sorts of things are automagically fixed <lfam>usr generally doesn't exist in Guix <wdkrnls>oh, so this probably needs to be an additional build phase then? *apteryx tries fixing python-parso <apteryx>hmm, it isn't broken... why isn't there a substitute for it according to guix weather (core-updates branch)? <apteryx>guix weather returns some oddly named package such as: python2-python2-attrs-bootstrap. Is this a known issue? <nexgen>what do you think about R, Stallman incident? <nexgen>I am just afraid of spending learning efforts on GUIX if it loosed sponsorship <iv-so>hi! do you know that `/gnu/store/d0h872knqpjizgrfd96qm4758qwazaq3-elixir-1.8.2' does not work? <rekado_>nexgen: the FSF holds some of our funds; RMS stepping down has no impact on that. <nexgen>rekado_, what about further investments? <nexgen>I found on the forums that different trolls (most likely sponsored by agencies) are very unhappy about your distro <nexgen>they try to name GUIX users schizophrenic <nexgen>they prefer everyone would use Windows <nexgen>and binary non reproducible packages with backdoors <rekado_>nexgen: the FSF does not invest in projects. <rekado_>the funds we have are due to donations. <nexgen>good, at least that it is not alone source if it even would be <nexgen>they get money from users (corporate and anonymous) <nexgen>At least Stallman step would not influence on GUIX future significantly, it is enough for me <nexgen>do you have a roadmap for future versions? <gnu_srs>Hi again: guix: offload: command not found;guix build: error: unexpected EOF reading a line. I do have the guix-daemon running: ./guix-daemon --debug --build-users-group=guixbuild <gnu_srs>Solved: Also the guix-daemon needs GUILE_LOAD_PATH. <g_bor[m]>It has a comment on it that when pushing a new branch the check will fail, and the user will have to disable the hook to push the new branch. Why doesn't fail the hook early? Does it give useful information also in this case? <g_bor[m]>We could also print a hint that it was detected that a new branch is pushed, the failure is expected, and you will have to disable the hook, when pushing a new branch. Wdyt? <davidl>Im running GuixSD in a qemu VM with btrfs filesystem, and have started to get a new error as the last output line when I reconfigure: shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) # ?) ?). <rekado_>it looks like gibberish, but it’s not an error. <davidl>mhm. previously it was always ending with shepherd: Service user-homes has been started. or similar which provided some confidence that things completed successfully now it seems like upgrading the shepherd services does not complete. <Parra>hey guys this is what I have been done in relation to what I was asking the other day <Parra>it uses docker with buildkit and travis in order to build an updated version of guix inside docker <Parra>my idea now is to push it to dockerhub and implement automated builds + packaging for my software <rekado_>Parra: I wonder if you could use the official installer script instead of performing the installation steps manually. <rekado_>Parra: I also wonder if perhaps you could start off of a Guix Docker image instead of Alpine. <rekado_>(because Guix can build Docker images with “guix pack”) <Parra>I was thinking about start from scratch with it <roptat>it's possible to send a docker image built with guix pack to dockerhub <Parra>I just want a base image to work with <roptat>I did it already, because I wanted to use it with gitlab-ci <roptat>well, it was just a test, so the result was not very useful <Parra>but for me it's interesting, I want to use it later for generating self contained distributables <roptat>and actually it was a guix pack thing, so guix was not running inside the image, that's not what you want, right? <Parra>another option is to use the builder pattern <Parra>but I think it wont work because guix may need enviroment variables <roptat>well, I just ran "guix pack bash coreutils -f docker -s bin=/bin" or something <rekado_>“guix system docker-image” could be of interest <Parra>it's better if guix itself generates it <roptat>I was thinking of guix system docker-image too, but haven't experimented with it yet <Parra>by the way, it's just a matter of optimization in terms of image size <Parra>right now I achieved what I want <Parra>next step is to start building the automated builds for distributables <roptat>but there's really no information in there <roptat>although I didn't save how I built the container... <Parra>how do you generate donketon/guix-file-test ? <roptat>I think I had to add more than just findutils, because gitlab-ci runs other commands before what I define in .gitlab-ci <roptat>something like "guix pack -f docker findutils (other packages ...) -S /bin=bin" <roptat>which outputs the path to a tar.gz that contains the filesystem for the docker <Parra>I will think about it, the only difference will be optimization in terms of file size <roptat>most likely, a guix pack will be bigger than alpine <Parra>plus env vars, I suppose, right? <roptat>I suppose you could add -S /etc=etc to get /etc/profile (which would probably be loaded by gitlab-ci) <roptat>etc/profile contains every env vars that guix knows of <roptat>but that container is not an operating system, a guix pack won't give you services and stuff, you'll need guix system docker-image for that <roptat>I don't know if it's supported by gitlab-ci though <roptat>that's probably the reason why I used guix pack <Parra>guix uses only /gnu and $HOME/profile/.. ? or there are more paths involved? <Parra>so I will keep using the current image by now, until I'm able to generate a self contained docker image, maybe using builder pattern inside docker or maybe avoiding docker or generating the image inside docker and extracting it later on <Parra>as I use buildkit you can do a lot of magic there <Parra>now I'm going to follow bitcoin implementation <janas>in the guix system, I'm trying to figure out how pulseaudio is started on login - it's being started by the shepard, but I don't see an explicit pulseaudio service <janas>Does anyone know where I should look? <roptat>I don't think it's started by the shepherd, isn't it started by applications through dbus instead? <roptat>is there a common name for (lambda (a) a)? <janas>roptat: The parent process id is 1, doesn't that mean that the shepard is starting it? <iyzsong>not necessary (and not the case here i believe), pulseaudio forked, so its parent is 1. <janas>iyzsong: ahh thanks, did't know about tat ***emyles``` is now known as emyles
<janas>for context I was trying to figure out why the mpd service couldn't find pulseaudio on startup <janas>and I thought that maybe it hadn't been started yet. But it sounds like pulse should autostart whenever a process tries to ues it <janas>iyzsong: thanks, i'll look into it. <janas>Otherwise I might remove the mpd service and try starting it from my i3 config <iyzsong>yes.. for a desktop, it's better to run as your main user. <rekado_>I think we should merge wip-texlive soon <rekado_>I’ll merge master into that branch first <truby>is it possible to get an environment where the package I'm asking for was built with a sepcific gcc version? e.g. I tried `guix environment --with-input=gcc-toolchain=gcc-toolchain@9 --ad-hoc clang` but I still get clang pointing to gcc 5 <roptat>truby, the input is gcc, not gcc-toolchain I think <truby>so, I feel like I'm working my way towards something :) if I do `guix environment --with-input=gcc=gcc-toolchain@9 --ad-hoc clang` I get input lib not found in gcc, and if I do `guix environment --with-input=gcc=gcc@9 --ad-hoc clang` I get gcc package not found for version 9. <truby>it seems that (gnu packages gcc) isn't "imported" by default? I'm quite new to guix so I'm not sure how to get it to be visible <pkill9>truby: the gcc packages have been hidden because people were using them instead of gcc-toolchain, so that's the problem <roptat>truby, you'll have to export that gcc in a file that you would load (with -L or -l) <pkill9>roptat, truby: you'll need to remove the "hidden? = true" property from the package, as that's how it's been made hidden <truby>So I can download the gcc.scm file, remove the hidden line, -L that and use that in --with-inputs? <pkill9>the gcc package (and subsequent gcc packages that inherit the initial one) is created with the "hidden-package" function, which sets the property "hidden?" to #t (see guix/packages.scm) <pkill9>truby: what you need to do is inherit the gcc package in a new file and set hidden to false, and put that file in your load path <truby>Am I overthinking this? I don't actually need clang built with a specific gcc, I need it to pick up a specific gcc to get the standard library from. Possibly there's an easier way to do this? <pkill9>dunno, but it's simpler than it sounds now i think about it, just need to cargo-cult the hidden-package function and change it so it sets hidden? to false <civodul>Parra: i have colleagues at work doing CI of their software in an image built with 'guix pack', FWIW <civodul>that is, they build a Docker image with "guix pack" that corresponds to dependencies of their software <civodul>they send that to GitLab-CI, and then they run their "cmake . && make" stuff in there <civodul>not sure if that's what you're looking for <pkill9>truby: this works, put it in "unhidden-gcc.scm" in a directory, then run `guix environment -L <directory-with-unhidden-gcc.scm> --with-input=gcc=gcc --ad-hoc clang` <truby>I'm looking in to this at work as well, we need to test building with lots of different combinations of clang/libstdc++/libc++ and gcc and I feel like guix is really close to making this super easy <truby>All I really need is for the clang derivation to be able to take libstdc++ as a parameter to use, that's what I'm really trying to achieve here <civodul>what if you create an environment with clang and libstdc++, isn't it enough? <civodul>rekado_: yay for merging wip-texlive! <truby>No, clang's wrapper specifies a libstdc++ to use. So possibly building it with a specific gcc like I was asking might not even work :) <roptat>it's like the user-services we have in the roadmap, except it doesn't use the service infrastructure from guix directly, because it's slightly different <roptat>instead of having a service that can be extended, I have services that have multiple named or anonymous extension points <roptat>when extending, you have to specify the service type and the point name <roptat>each extension point has its own compose and extend functions, and the extend functions are folded in the order the are declared to produce the final value <roptat>when the extension specifies a service type, it is automatically instantiated if it's not yet declared, otherwise, it extend any declared (or automatically instantiated) service that provides that extension point <roptat>I still need to write documentation :) <AndreasL>I try to install it with guix package -f python-jinja2-cli.scm <AndreasL>guix package -I python-jinja2 I got nothing <AndreasL>Tried to set verbosity at 2 but didn't change anything <AndreasL>If someone can put me on the right direction it would be really helpfull <civodul>AndreasL: "guix package -f" takes a file that must return a <package> object <civodul>however, your file returns "nothing" (more precisely, it returns "the unspecified value") <civodul>instead, you probably want to do something like: guix package -L . -i python-jinja2-cli <civodul>where "-L ." instructs guix to look for packages in ./*.scm <quiliro>Giksujo....estas la plej lando libera. <truby>pkill9: that works perfectly and didn't even rebuild clang, just redirects the standard library :D thanks! <truby>any chance of getting a parameter into the llvm package to select gcc like this without having to load in a .scm file to unhide it though? that would be really ideal <truby>I think wanting to ask for a specific gcc stdlib with clang isn't an unusual requirement <civodul>truby: you can always access hidden packages with -e, like -e '(@ (gnu packages gcc) gcc-9)' <truby>yeah, I saw that, the issue here is that I need to access the hidden package in --with-inputs <civodul>but yeah, we should make it easier to select the toolchain <AndreasL>civodul: I tried to install the package via -L . option but now I got this error <truby>also, I may have spoken too soon ^^ it doesn't seem to work, it can't find the standard library headers. <civodul>truby: what do you mean by "standard library" tho? <AndreasL>guix package: avertissement : échec lors du chargement de « (guix-manifest) » : <AndreasL>In procedure module-lookup: Unbound variable: specifications->manifest <AndreasL>guix package: avertissement : échec lors du chargement de « (python-jinja2-cli) » : <AndreasL>guix package: erreur : python-jinja2-cli : paquet inconnu <truby>it doesn't find any C++ standard library headers. But clang doesn't seem to in any case, is there a gcc-toolchain equivalent for clang that I'm missing? <pkill9>civodul: the gcc package is hidden by having the "hidden?" property set to #t, it's still a public variable <truby>e.g. if I do guix environment --ad-hoc clang, then clang++ some basic hello world, it doesn't find <iostream> <AndreasL>civodul: sorry I got another file called guix-manifest.scm <AndreasL>thank you I didn't notice the difference <truby>also, same issue if I have clang and libc++ and use -stdlib=libc++. I can't seem to get clang to find the c++ headers at all <AndreasL>sorry I tried different approch from various documentation so I got a bit lost <AndreasL>guix package: erreur : python-jinja2-cli.scm : paquet inconnu <AndreasL>when I run guix package -i python-jinja2-cli.scm <AndreasL>And when I run guix package -L. -i python-jinja2-cli.scm <AndreasL>I got : no code for module (python-jinja2-cli) <AndreasL>Is there a way to have more information on what's going on ? <rekado_>(did someone step up to take over maintenance of the linux-libre package in Guix?) <AndreasL>civolud: I trid to copy/paste code in --load-from-file example in the doc and install it with "guix package -i hello.scm" and it didn't work <AndreasL>guix package: erreur : hello.scm : paquet inconnu <roptat>if nobody steps up before then, I might have more time to take care of linux-libre (and icecat) from the beginning of next month <AndreasL>I must do something wrong but I can't see what <roptat>AndreasL, you need "guix package -f hello.scm" <rekado_>roptat: your leadership is greatly appreciated! Let’s try to make sure you aren’t left alone with this task. <roptat>-i is for "install" so it's natural, but its argument is a package name, not a file name :) <roptat>what does “recursive derivations” mean? (from the roadmap) <civodul>rekado_: i think it was partially merged <civodul>Timothy did a great job with that, but i think it's not complete <civodul>it's hard to find volunteers for review <civodul>roptat: "recursive derivations" means being able to compute a derivation from within the build process of a derivation <AndreasL>Now I want this package to add jinja executable file available through command line <AndreasL>I tried to use (define-module (gnu packages jinja) <rekado_>civodul nckx: The MDC firewall has now ports open for dmitri and sergei. <roptat>"executable file" or "package name"? <roptat>define-module gives a name to a scheme module, and it's unrelated to packages <roptat>see for instance how (gnu packages package-management) defines a guix package <roptat>or (gnu packages ocaml) has more than just the ocaml package <roptat>you indeed need to define a module as you did, but this time, instead of returning a package value, your file should define packages (for instance with the define-public syntax) it doesn't need to return anything *rekado_ wonders if merging wip-texlive may have been a mistake… *rekado_ builds pulseaudio from source… <Minall>rekado_: Why build pulseaudio from source? <roptat>AndreasL, then, you place the module to a corresponding directory, so for instance (gnu packages jinja) needs to be in a file named gnu/packages/jinja.scm <roptat>and finally, you can load it with "guix package -L . -i jinja" (if you defined a jinja package, and the current directory contains the gnu subdirectory) <AndreasL>That's why I wasn't able to install the package with -L . option <roptat>the package needs to be named jinja (not the variable name, but the package name, as in (package (name "jinja") (version ...) ...)) *rekado_ tries to make “octave” use “texlive-union” <AndreasL>thank I was facing problem with the package name <AndreasL>but "jinja" is still not accessible through command line <truby>anyone had any luck using clang from guix? I can't get it to find the C++ headers and I also can't get libomp to build :( <AndreasL>to be exact I still got "jinja" which refer to "/usr/local/bin/jinja" <truby>(this is on ubuntu not guixsd) <AndreasL>How can it be added to my guix profile ? <rekado_>truby: are you working on a package for libomp? <truby>no, there exists one already, it just doesn't build :( <truby>it seems to try and run the libomptarget test suite, without fetching that <rekado_>truby: indeed, the build failed on ci.guix.gnu.org <truby>basically, I'm working on f18 (the llvm fortran compiler), it's currently a bit finicky with what compiler versions and standard library combinations it builds with so I want to try and comprehensively test loads of different versions/combos. Guix seems really really close to making that almost trivial <AndreasL>Oh ! roptat it seems that the binary name was jinja2 and not jinja which is logical ! <AndreasL>but I though that by defining a package name it would influence the executable name <rekado_>no, the package name is just for use with “guix” commands. <truby>rekado_: libomptarget tests are only enabled when you built with clang. So, if we can switch libomp to build with clang instead of gcc it should "just work" <AndreasL>hum ok, so maybe I should let python-jinja2-cli <rekado_>truby: I’ll try to reproduce the error first; then we’ll see how to fix it. <rekado_>truby: generally, we just build with GCC, so I’d like to keep it this way if possible. <rekado_>“-- LIBOMPTARGET: Can only test with Clang compiler in version 6.0.0 or later.” <AndreasL>Thanks everybody for your help. I was able to build my first guix package and I am very glad ! <rekado_>but the package definition has a comment saying that the build with clang would fail, so we don’t do that. <rekado_>we do pass -DOPENMP_TEST_C_COMPILER=clang, though, so for the tests Clang should be used. <rekado_>looks like the build system changed a little, so now the test target isn’t even made available <truby>it's worth noting that some parts of the offload library don't get built at all if you don't build with clang, not just the tests but actual parts of the library <truby>(I used to work on the target offload stuff in LLVM) <rekado_>truby: I see. Let’s try to build it with clang. <rekado_>FWIW the comment says this: Note this gets built with GCC because building with Clang itself fails (missing <atomic>, even when libcxx is added as an input.) <truby>I think that's an old bug from clang 5ish? I reckon it should work with a newer clang. <truby>basically libomptarget needs PTX codegen to be available to build parts of the library, so if it's not available you only get a semi-functioning offload library. Which I assume is also why it won't run the tests <truby>rekado_: thinking about it, could the above be related to my other issue? which is that clang can't find any C++ library headers <rekado_>(I guess more env vars are needed to fix linking when building with clang/llvm) ***Server sets mode: +cnt
<rekado_>erudition: I don’t think there’s an HTML version yet. I only just pushed the cookbook today. <rekado_>erudition: but you can read it on your own machine’s info reader as it is built with Guix. <zacts>is Guix participating in GSoC? <zimoun>the commit 74e7465c9b reverts the use of %bioconductor-version introduced in 41ca406fa54e69f6 <zimoun>the commit message say it was reported by Hao Chen. I am not able to find a bug report or email. There is? <zimoun>because the change of 41ca406fa54e69f6 is nice :-) And so the bug should be tracked. <zimoun>rekado_: the error message is a bit cryptic to me <erudition>rekado_ Ohhh okay. I'm actually on mobile right now so I guess I won't be reading it. Either way I'm guessing making local edits to the underlying code file is the only way to contribute, so it's not quite the solution I was thinking of (which would actually be accessible to non-coders) <zimoun>rekado_: but it is strange, isn't it? <erudition>I'll definitely check it out when it's ready though <bavier>rekado_: I like the "cookbook" idea, thanks for starting that <rekado_>erudition: we accept contributions in various formats. If you’re not comfortable with texinfo markup that’s fine. Just send plain text then. <erudition>rekado_: yeah I'm sure! It's not really about me though - it's about easing the path to contribution for anyone - as Wikimedia learned the hard way when they realized their new contributors were stagnating and would continue to do so until they built the visual editor. It seems that every little barrier counts, including having to send things to people to fix a typo. <rekado_>since we want to perform quality control, I think it’s fine to have email as the only barrier. <rekado_>the Octave manual can actually be built with texlive-union, but the phase fails when trying to build octave.dvi. Not sure why. ***jonsger1 is now known as jonsger
<vagrantc>hrm. i haven't been able to build guix from source lately ... usually i do: guix environment --pure guix ... make clean-go && ./bootstrap && ./configure --localstatedir=/var && make check <vagrantc>guix daemon appears to be failing to build <erudition>jackhill: sure, as the article opines "people don't trust wiki content nor explore it" has been my experience as well, for software documentation specifically. The Ubuntu wiki, for example, is sometimes helpful but often out of date, so I try not to rely on it. But again, that's software documentation (not a cookbook), as opposed to the "general knowledge base" use case, where wikis really shine (and MediaWiki has done all <erudition>jackhill: The article also says that since people see files as part of the project, they're more comfortable sending a PR. Again, this is so specific to software and documentation that "contributing" is called "sending a PR". Nothing to disagree with there. The reality of the general case, though, is that if the contributor need to know what a "PR" is (let alone how to send one), you've already lost a significant portion of <erudition>potential contributions from lay-people who may be willing to do some of the dirty work that devs are not, like spelling corrections, translations, using more accessible language, etc. <vagrantc>wikis are good for quick development of an idea, but suffer when it comes to long-term maintenance <erudition>jackhill: In most software there is a strict separation between the three categories they mention in the article (maintainers, contributors, and readers). The hoops to jump through to get from "reader" to "contributor" are always the largest on the first try - but once they learn who to email, or learn how VCS works, or have their git setup, etc. it's easy to contribute again. The realization WM had is that reducing that <erudition>initial friction, however, between reader -> contributor, is what makes the biggest difference in the number of willing new contributors. <vagrantc>requires a lot of editorial effort for that to work, though <dongcarl>vagrantc: could we run CI on the manuals? If I recall correctly LFS people do that <vagrantc>dongcarl: i thought there was an auto-built manual somewhere <vagrantc>dongcarl: if that's what you meant by CI ... <erudition>vagrantc: if we're talking about something that constantly needs to be maintained, then yeah, I agree a wiki is not best. It's best when the topic can be written once and valid for a long time, such as the encyclopedia articles on Wikipedia. The guix cookbook as a wiki would be meant for example set ups, how to accomplish niche desire xyz, etc. If the public API of Guix is breaking all the time such that those pages would <erudition>break, then uh, yeah that's an issue. Otherwise, we're talking about something different from "documentation" here. <vagrantc>erudition: well, despite having released 1.0 ... guix does seem to be changing quite rapidly to my eye <vagrantc>but it depends on exactly what you're documenting/cookbooking <erudition>But to my knowledge that isn't supposed to mean "existing solutions break left and right" <erudition>So if that's what's happening, I was unaware <vagrantc>e.g. some things are pretty stable ... some things are moving faster. <erudition><jackhill "Adroit: this doesn't nessisarily"> The most telling quote, to me, is "Since our target audience is developers, and developers already know how to send pull requests, this just feels natural." <jackhill>How do question/answer sites play into this (is there a question/answer site free software?)? <erudition>Yeah exactly. Different audience, to the extent that Guix doesn't want to be an OS that's only for developers (I hope not! The masses want reliability too!) <erudition><jackhill "How do question/answer sites pla"> Good question, I think there's software to deploy your own, but obviously plenty of libreware is on StackExchange <rekado_>I don’t agree that our target audience is developers. <rekado_>the project tries to make it easy for people who don’t consider themselves “software developers” to extend Guix and hack on it. <rekado_>(hence the moniker “the Emacs of distros”) <erudition>Well that's good, because no one said that haha <erudition>No one said it was only for developers. Above, I said that it's what Guix *doesn't* want. <rekado_>I’m just stating the Guix project’s position in contrast with the above statement. <rekado_>(guess I shouldn’t have written “I don’t agree” then, eh?) <erudition>Though It's definitely a point that might need bringing up more often, because as of right now I wouldn't bother introducing GuixSD to anyone that's not a developer - - but of course that will hopefully change <rekado_>I’m working with a lot of people who are not software developers <rekado_>Guix has already come a long way compared to the time when I joined the project. <erudition>We already have a better graphical installer than Nix, so there's that! 😏 <rekado_>but there’s still a lot that we can do to improve it <rekado_>dongcarl: thanks for bug report 37449! <zacts>cool. it looks like the issue tracker is in guile scheme. that's pretty neat <gnu_srs>vagrantc: Hi, I see that you have created Debian packages that build-depends on guix (and guix itself). Anything I can help you with? <vagrantc>gnu_srs: biggest blockers are the guile-gnutls bindings, really <vagrantc>debbugs is the backend, and it was nice to see a prettier web frontend to debbugs :) <zacts>it's cool whenever I see lisp or scheme being used for actual production code. <zacts>I really like how guix chose guile for its codebase. I also like shepherd too. <dongcarl>civodul rekado_: No problem, let me know if there are any details I can provide <quadrillion>hi guix guys! I've got a few questions. First of all, which font should I install to have unicode icons on icecat and the system? <vagrantc>quadrillion: i think the norm around here is to avoid using gendered language, so instead of "guys" try "folks" or something. :) <jackhill>quadrillion: I use font-google-noto. Also stylistic comment: probably best to use gender-nutral folks or people rather than guys :) <vagrantc>sorry i don't know my way around the fonts in guix to be more help <pkill9>i like that you can get all fonts from the repository with `guix package -A "^font-"` <jackhill>but I eventually installed all the font packages in my profile. It was cool that I didn't have to list them all in my manifest but could find them programatically. Down side is building the font-cache and profile take a really long time, but I don't have to think about which packages I need. <quadrillion>hm... english isn't my native language, so I use to say "guys" gender-neutrally <quadrillion>isn't guy = men, guys = everybody? ok, doesn't matter... <pkill9>jackhill: nice :) I would put a `^` at the beginning of the regex so it matches packages that start with "font-", instead of packages with "font-" in the middle <jackhill>quadrillion: For some people it is gendered. I wouldn't worry about it to much, but now you know for the future :) <Formbi>quadrillion: guys is men or everybody <jackhill>quadrillion: oh, I should add, while I started with font-google-noto for full unicode support, it may not be the only option, I don't know. <jackhill>yeah… I'm fortunate to have a big disk. Let us know if you find something better. <quadrillion>jackhill: disk isn't an issue - i'm on 10MBit internet right now. But 700M+ is still better than nothing, so I waiting for installation :) <jackhill>oh, ouch. I think the good news it will hopefully change rarely :) <quadrillion>...while it downloading, there a few more questions: I've installed font-ibm-plex package, but still can't use the font on emacs on elsewhere <truby>quadrillion: fwiw guys is kinda considered gender-neutral in British English (I wouldn't have thought about it if someone didnt say and I am a native speaker) but there's never harm to using other words if it makes people more comfortable imo :) <jackhill>truby: neat, I'm from the United States, and didn't know that. I'm also from a part of the states where y'all is more common than guys <quadrillion>to truby and all who find my "guys" sexist: I didn't mean any gender when wrote it and didn't mean to harm anybody. But I'm still has no to sorry about. It's software chat, why do we talk about linguistic? <rekado_>please drop this and let’s get on topic <rekado_>truby: do you happen to know what needs to be done to force cmake to use the LLVM linker instead of ld from binutils? <truby>I'm going to take a look now and see if I can solve the problems with the llvm packages that I was having earlier <rekado_>because as it is I cannot pass the libomp configure phase as it fails to link a simple test program <truby>LDFLAGS="-fuse-ld=lld" or -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=lld" <truby>it should have exactly the same behaviour modulo performance though <rekado_>tried that, but that didn’t work. (where’s lld?) <truby>is there an easy way to browse the guix source code online? (savannah I guess?) <truby>doesn't look like lld is packaged in the llvm package <truby>it should not be too hard to add <rekado_>the problem with the ld linker is that it can’t find crt1.o and crti.o <rekado_>we use a wrapper script that eventually calls ld itself <truby>lld won't help with that, it will have exactly the same behaviour as bfd when given the same flags <rekado_>it usually works just fine when used with GCC, though <truby>at least, if it doesn't then that's a bug :) <rekado_>some search path or env var problem I guess. <truby>can you try passing the full path to the linker wrapper to -fuse-ld=.../// <rekado_>I *know* already that it is calling the ld wrapper <rekado_>(because I set GUIX_LD_WRAPPER_DEBUG, so I’m seeing some verbose output) <divansan`>I have guix git checked out. I'm running guix system too. I then run guix environment guix --pure --ad-hoc help2man git strace . Then ./bootstrap but I get this error ./bootstrap: line 19: exec: autoreconf: not found . What Am I doing wrong? <truby>does guix use a wrapper around all the compilers like nix does, or just around the linker? <rekado_>divansan`: can you show us the output of “env” inside of that environment? <rekado_>I’m guessing that perhaps you do some environment modification in ~/.bashrc (not in ~/.bash_profile), which undoes the work done by “guix environment”. <rekado_>divansan`: yes, your PATH looks wrong. Are you setting it in ~/.bashrc? <truby>rekado_: is gcc just tricked into thinking the linker wrapper script is a normal ld? <divansan`>rekado_:yes, in .zshenv . Let me see where it's going wrong. Will revert it don't come right - thanks. <rekado_>truby: nothing fancy happens. The wrapper is installed as “ld” and it augments the arguments with rpath flags before calling the actual “ld”. <truby>and gcc isn't a wrapper or anything? just the actual gcc binary? <rekado_>the problem we have now is that clang+llvm doesn’t know where to find libc objects <rekado_>GCC does know this – but I’m not entirely sure why <truby>(I always forget that you have to actually put the ld you want earlier in the path with gcc... we have a patch that makes gcc take an absolute path with -fuse-ld just like clang does :P) <truby>interesting that gcc gets it but clang doesn't <truby>I mean, it should be invoking the linker in exactly the same way..... right?? <rekado_>I’ve seen the problem with GCC before. That’s usually when people installed the plain “gcc” package (now hidden) instead of the “gcc-toolchain” package, which combines GCC with glibc. <rekado_>I bet that’s how GCC finds the objects. <rekado_>they just happen to be in the same file system tree. <rekado_>we could probably do the same for the clang+llvm toolchain <truby>ahhh. Yes gcc does search in its own tree for things <rekado_>or we could try to set some env var or option to tell the toolchain where to find libc objects <truby>so, what I'd like to see with a clang toolchain (tell me if I'm mad): I'd like to be able to pick clang(+llvm) and say "I want to use libc++" or "I want to use this specific libstdc++", and say which linker I want to use as well. As different combinations. <truby>because upstream these are things that clang supports <rekado_>tmssgn: (dependencies %fs-quercus-root) is wrong <truby>as an aside, the package currently tracks 8.0.0, there's a bugfix 8.0.1 but the download links have changed (yes, they've previously been the same going way back to pre-3...) <rekado_>(dependencies (list %fs-quercus-root)) looks correct <truby>and as another aside, the structure of the llvm build system is changing soon (post-9 release). Not sure what the best way of handling these two things is in the package. <truby>I mean the build system change is a future problem not a "now" problem :P <rekado_>truby: this could probably be done with a make-clang-toolchain procedure that takes different packages as arguments and returns a toolchain package. <truby>rekado_: that sounds great. as in, I could do `guix environment -e "(make-clang-toolchain 'libstdc++@9 'clang@8 'lld@8)" ` (or something similar) <rekado_>so… we already patch clang so that it can find these libc objects <rekado_>but the patch targets clang 7 (and older) <tmssgn>anyone know what is meant by 'guix system: error: service 'file-system-/boot' requires 'file-system-/', which is not provided by any service' when the root fs is defined? it's from the previous config <truby>is there no way to solve this on the ld-wrapper side? I feel like patching the compiler is fragile. Also if we want to add packages for new compilers we would have to patch those too? <truby>(I'm thinking ahead to me writing a package for f18 once it's actually useful heh) <tmssgn>I guess, will anything be mounted without root? <tmssgn>cause my error goes away if I remove the dependency on root... <rekado_>truby: the patch is fine, but the clang-from-llvm procedure only overrides LibDir it for version 6 and 7. <rekado_>truby: I added an 8 there; now I’m waiting for clang to be rebuilt. Will test this shortly <truby>rekado_: sounds good let me know what happens :) but I'm just thinking ahead about adding other compilers. The more compilers that are packaged the higher the burden of patching all of them so I'm just wondering if there's another place we can do this <rekado_>many compilers have some hardcoded FHS directories where they look for “system” libraries. <rekado_>we just patch these directory lists, usually <rekado_>to include our glibc package’s “/lib” directory <truby>I see. Is there a sensible way of sending this patch upstream? Or is it incredibly specific to guix <truby>(I mean, even if it is it's possible that would be acceptable upstream) <rekado_>I’m not sure. Our directory name (which changes whenever the inputs to glibc change) is not a useful thing for upstream to have. But maybe a more generic mechanism such as an environment variable would be a useful thing to send upstream. <rekado_>But I think it would be hard to make our case, because FHS distros simply don’t need it. <truby>I don't think that is something that would stop it tbh, I mean we support OSX and Windows upstream and they certainly don't follow the FHS <quadrillion>yet another question: I've installed arc-theme and numix-theme, but they aren't appear in lxappearance app as I've expected. what do I do wrong? <rekado_>quadrillion: I don’t know where lxappearance looks for themes, but it probably doesn’t know about your user profile where you installed the themes. <rekado_>there might be an environment variable to inform lxappearance about your themes, but I don’t know the details. <rekado_>(perhaps this wouldn’t be necessary if both themes and lxappearance were installed globally, i.e. via the operating system configuration’s “packages” field) <gnu_srs>vagrantc: apt-get install -t experimental guile-json is needed, why is it not in sid/stable? <rekado_>I was going to reply about the distinction between user profile and the profile of “guix pull”, but then I wondered what it would look like if “guix pull” would just add a new generation to the user’s profile. <gnu_srs>vagrantc: Do you have patches to re-instate guile-gnutls from gnutls28. I do, did you submit a bug report for that package? <rekado_>after imagining this for a while it seems to me that the behaviour would be much more confusing than what we have now <rekado_>and it wouldn’t be clear what the correct behaviour would be <rekado_>(it would have to behave like “guix install”, which would lead to profile generations that could be difficult to reproduce) <gnu_srs>civodul: Just a dumb question: Why does guix build --target=i586-gnu bootstrap-tarballs create and build an enormous amount of glibc, gcc, etc versions? Is that by construction? <rekado_>gnu_srs: yes. To better understand this I recommend playing with “guix graph”. <gnu_srs>That build has now been going on for almost 24 hours?? <gnu_srs>Yes, I've seen that picture. Still I don't understand why e.g. linux-libre is needed?? <civodul>rekado_: yeah, rollback would also roll back the very tool you're using for roll back <rekado_>it’s not building the kernel. it just needs the headers. <civodul>i think we want these two things to evolve on separate dimensions <gnu_srs>You need linux headers to cross-build for GNU/Hurd? <rekado_>I wonder if we can make it easier for new users to understand the difference between these profiles. It seems to me that quite a few people are confused when they encounter both profiles. <rekado_>One problem in my opinion is that “guix pull” prints the usual environment variable hint that I don’t think is appropriate for “guix pull”. <gnu_srs>civodul: rekado_Seems like a little too much, except just doing plain cross-builds?? <rekado_>civodul: it suggests to set “GUIX_PROFILE="/home/rwurmus/.config/guix/current"”, which seems wrong. <rekado_>(and then to source $GUIX_PROFILE/etc/profile) <civodul>technically it's a shell variable, not an environment variable :-) <civodul>it's meant to be used by the etc/profile file <rekado_>gnu_srs: what does the graph say where linux-libre is used? Perhaps a well-placed “cond” or “if” statement could remove it. <gnu_srs>I'm just making a log of the build. Why numerous versions of e.g. gcc? <rekado_>civodul: would a user actually ever have to source the “guix pull” profile’s etc/profile file? I thought that’s never needed as long as they use that profile’s bin/guix. <civodul>rekado_: it's just to set PATH in practice <zacts>hello #guix. should I install emacs packages via the emacs package manager, or should this be done within guix? <quadrillion>nope, global installing doesn't help - lxappearance still empty. <rekado_>zacts: I recommend installing them via Guix <rekado_>quadrillion: do you happen to know how lxappearance finds themes? Where does it look? <gnu_srs>Well, I could easily compile cross-build versions outside of guix: binutls, gcc, glibc, ..., etc. What's the deal?? <rekado_>(I’d look at the source code with “tar xf $(guix build lxappearance)”) <rekado_>gnu_srs: I don’t understand your question. Why use Guix at all…? We’re using Guix to build the bootstrap binaries that Guix uses. <rekado_>truby: I fixed the clang toolchain, but I do actually get the error that the comment in the libomp package definition warned me about. <gnu_srs>Still, why build all versions available of gcc, glibc, etc just for the bootstrap-tarballs? <rekado_>truby: I get this: /tmp/guix-build-libomp-8.0.0.drv-0/openmp-8.0.0.src/runtime/src/kmp_os.h:19:10: fatal error: 'atomic' file not found <rekado_>also: /tmp/guix-build-libomp-8.0.0.drv-0/openmp-8.0.0.src/libomptarget/src/device.h:17:10: fatal error: 'cstddef' file not found <gnu_srs>Are these versions needed to trace back to old generations? <truby>I suspect that clang just isn't finding any C++ headers at all <truby>which would need patching in a similar way to finding libc <gnu_srs>Maybe I have to problematic questions. I'll be quiet for now until the cross-built packages are built :( Let's hope for the best ;) <truby>I also couldn't get it to work when passing --gcc-toolchain=/path/to/gcc/root though, which should work regardless of whether you're following the FHS (it just expects that gcc root to contain include/c++/version_number) <truby>no problem, thanks for the help :) I'll take a further look tomorrow <rekado_>we’re setting CPLUS_INCLUDE_PATH, but maybe it needs another variable :-/ <truby>rekado_: that's the include path for the C++ compiler to check, rather than the actual include path to look for the C++ library in. I had a look at the directory the gcc-toolchain gets installed in and it seems like the headers go straight in include/c++/{iostream,atomic,etc} rather than being prefixed by a version number. Could be that clang needs patching to look straight in there rather than subdirectories of it (which imo it <truby>should anyway). But that's just a thought I have without looking at how clang tries to find libstdc++. *civodul fearlessly reconfigures laptop on core-updates <gnu_srs>civodul: rekado_: Are my questions not relevant? Sorry for bothering you if not so :( <vagrantc>gnu_srs: yes, there's a link to the guile-gnutls bugs from the top of the guix one with a patch on one of them <vagrantc>gnu_srs: needs to be updated again, probably <vagrantc>gnu_srs: but have received no comment from the maintainer <vagrantc>gnu_srs: i haven't updated guile-json in experimental because upstream has so far only released a tarball but no corresponding git history... <vagrantc>gnu_srs: and figured may as well update to guile-json 3.2 rather than simply re-uploading to unstable <vagrantc>gnu_srs: originally uploaded 3.1 to experimental while guix still depended on the older version <gnu_srs>vagrantc: I can send an updated set of patches if you don't mind to the gnutls28 bug? <vagrantc>gnu_srs: i would love the additional support :)