IRC channel logs


back to list of logs

<davexunit>will the guix distro being rolling-release or periodic stable release?
<ggrant>davexunit: I'd imagine rolling.
<ggrant>davexunit: What leads you to believe that it might be perodic/stable?
<davexunit>ggrant: nothing. :)
<davexunit>I was asking on behalf of someone in #gnu that was interested in guix but didn't like rolling release distros because of security issues.
<ggrant>davexunit: I can't see it not being rolling to be honest, but yeah some might fear that. :^P
<ggrant>Nevertheless I can't wait for the installable image -- my motivation for packaging will go way up.
<davexunit>yeah, definitely.
<ggrant>Really most of my day-to-day software stack is already packaged, just with a few gotchas. Wicd would be nice, for example.
<davexunit>I think there's a few more things that I would like, but the important stuff is there.
<ggrant>davexunit: Hear, hear.
<cantstanya>guix will have a distribution?
<cantstanya>will it include dmd?
<ggrant>cantstanya: Tmk, with the release of 1.0 there is a planned installable image that yes, will include DmD.
<ggrant>There is a VM floating around, but it's not too useful atm.
*zacts is going to install guix.
<zacts>I think that once I'm done with my FreeBSD guile-2.0 port, I'll start working on guix.
<phant0mas>glibc needs to be built in a different folder
<phant0mas>so if I create a build folder before configure, and change into that, how can I tell guix to configure and build the source from the parent folder?
<mark_weaver>phant0mas: include #:out-of-source #t in the arguments, and it will take care of it automatically.
<mark_weaver>it will automatically make a "build" directory as a sibling to the source directory and run configure the right way, etc.
<phant0mas>btw good morning :-)
<mark_weaver>sorry, I forgot the question mark. it should be: #:out-of-source? #t
<phant0mas>don't worry
<mark_weaver>you can see examples of its use in gcc.scm, texlive.scm, and base.scm
<phant0mas>glibc has a problem with make 4.0 and I tried to use the same patch used in the existing glibc
<phant0mas>(patches (list (search-patch "glibc-make-4.0.patch")))
<phant0mas>is this right?
<mark_weaver>you'll need to import the (gnu packages) module for 'search-patch'
*mark_weaver --> zzz
<rigelk>hi there. When using the `make sync-descriptions` I get the following error concerning a package definition I wrote: `;;; ERROR: no code for module (gnu packages gnu-make)`. Any ideas ?
<phant0mas>normally (patches ..) should be placed in (source ...) but as it is from git and not a tar, it won't work
<phant0mas>I get the error "...-git-checkout: Cannot read: Is a directory"
<phant0mas>How should I patch it now?
<phant0mas>there is no example in other recipes with git-fetch and patchinhg...
<phant0mas>mark_weaver: do you know how to patch source from git-fetch in the recipes?
<mark_weaver>phant0mas: I would have expected 'patches' to work. can you show me what you wrote?
<mark_weaver>*what you tried that failed
<mark_weaver>rigelk: sounds like you're trying to import (gnu packages gnu-make) from somewhere, but that module doesn't exist.
<rigelk>mark_weaver: i still try to understand how the whole thing works ^^' so to be know to guix, a package has to have a .scm, a line in and then a .go generated through `make sync-descriptions` ?
<davexunit>or just 'make'
<mark_weaver>more than one package can exist in a module. each module has a .scm file.
<mark_weaver>I wouldn't worry about sync-descriptions for now. first get your package working to build it.
<mark_weaver>you don't need the line in at first either, or the .go file.
<rigelk>davexunit: true. make output the same error : `In procedure scm_i_lreadparen: gnu/packages/doxygen.scm:58:1: end of file`
<mark_weaver>the line in is needed to ensure that the module is automatically included in the guix release tarball, and installed when running "make install" in the guix build directory, etc.
<mark_weaver>but when you're first working on a package, all you need is the *.scm file in gnu/packages/
<mark_weaver>rigelk: sounds like your parens are mismatched or there's a syntax error in the file.
<davexunit>^ yeah
<rigelk>mark_weaver: i see. i began by the end :/
<davexunit>also: yay for packaging doxygen!
<davexunit>that's a missing dependency for one of my packages.
<rigelk>I know, that's why I am working on it now. I saw your patch ;)
<rigelk>however, i'm afraid it's my first .scm. How can i check the syntax ?
<rigelk>just... `make` ? ^^'
<phant0mas> the (source ...) part
<mark_weaver>rigelk: can you show me what you have? maybe using a paste service?
<phant0mas>without patches it works as expected with the rest of the recipe
<phant0mas>and it stops at make
<phant0mas>mark_weaver: here is the whole recipe
<mark_weaver>rigelk: your 'define-module' form is missing a close paren.
<mark_weaver>also, the (gnu packages gnu-make) module doesn't exist. that module name is mapped to the filename gnu/packages/gnu-make.scm, which doesn't exist.
<mark_weaver>gnu-make is declared in (gnu packages base)
<mark_weaver>since the variable name is 'gnu-make', that's what you need to put after the comma in the inputs line.
<rigelk>seems like the define form was also missing a close parenthesis.
<rigelk>yay ! it works. thanks for reviewing my code, mark_weaver :)
<mark_weaver>btw, are flex and bison really needed? usually tarballs come with the generated files already, and flex/bison are only needed for devs who change the flex/bison code.
<rigelk>mark_weaver: i blindly followed the requirements on the doxygen main page :
<mark_weaver>btw, for the sake of supporting cross-compilation, there's a distinction between 'inputs' and 'native-inputs', depending on whether the package will be run at package-build-time or run-time.
<mark_weaver>'make' is in the default set of native-inputs, fwiw, so it probably doesn't need to be explicitly specified.
<mark_weaver>(unless doxygen uses 'make' when the program is run by the user)
<rigelk>mark_weaver: i'm gonna check that, but imho doxygen doesn't use make.
<rigelk>is there any documentation concerning the different kinds of inputs ?
<mark_weaver>rigelk: have you looked at ?
<mark_weaver>(I don't remember off-hand if it talks about the distinctions between inputs and native-inputs, but it's currently the best overview I know of on writing guix packages)
<mark_weaver>guix is a work-in-progress, and more documentation is needed.
<phant0mas>mark_weaver: did you check my recipe? :-)
<mark_weaver>on the plus side, response times to questions are typically quite fast here on #guix and on
<rigelk>yes, i've read it. but it should be considered and intro and not a guide, as commands are not explained nor up-to-date.
<mark_weaver>phant0mas: I suspect it's a bug in the new git-fetch stuff.
<mark_weaver>rigelk: agreed
<mark_weaver>phant0mas: for now, you could apply patches "the old way"
<mark_weaver>phant0mas: mit-krb5.scm still has to apply a patch the old way. you make the patch a native-input (see "patch/init-fix" in that file)
<mark_weaver>and then add a phase after unpack that runs patch
<mst>this may be a slightly odd question, but to what level does guix abstract away the channel concept?
<mst>actually, lemme clarify why I'm asking
<mark_weaver>in that mit-krb5 recipe, the unpack phase had to be completely replaced, but you shouldn't need to do that here. it'll be better to add a phase instead.
<mst>so far as I understand the guix/nix system, if I ask for package X, it resolves dependencies D1, D2, D3 against the current channel C
<mst>which is basically a mapping of package names to 'current version'
<mst>I'm working towards resolving dependencies against a full set of *available* versions, of which there may be more than one, with a policy to decide which one to select
<mark_weaver>phant0mas: something like: (alist-cons-after 'unpack 'apply-patch (lambda _ (zero? (system* "patch" "-p1" "-i" (assoc-ref %build-inputs "patch/???")))) %standard-phases) [UNTESTED]
<mst>so I'm wondering how viable it is to get guix to let me 'hook' the resolution part somehow
<phant0mas>okay, going to expreriment with it
<mark_weaver>mst: I'm sorry, I don't really understand a lot of what you wrote there. I think you're assuming that I'm familiar with some other distro that has channels, and I don't have the needed knowledge to fill in the rest.
<mst>I thought 'channel' was the nix term and had been adopted by guix
<mark_weaver>but in guix, inputs are specified not against a package name, but rather a package object.
<mark_weaver>oh, possibly so. I'm not very familiar with nix, I confess :)
<mark_weaver>(I probably would be using it by now, if guix hadn't come along)
<mst>I've read all of the papers published by the authors; I considered that to be basic research before looking at guix lest I make a fool of myself with the questions I asked
<mst>apparently I've instead made a fool of myself by assuming the knowledge from there :D
<mst>communication is hard!
<mark_weaver>mst: that's good! I'm probably the one that's made a fool of myself here :)
<mst>ok, so, basically, let me invent a slightly contrived example
<mst>if I have package X, which requires package D 2.0.1
<mark_weaver>I don't claim to be particularly knowledgable about Guix, although when no one else more knowledgable is around, I try to help as best I can.
<mst>and package Y, which requires package D 1.x+
<mark_weaver>(I'm a core dev of guile though, so I can usually find the answers I need by reading the guix source code)
<mst>and I install them both, normally it'll give me "whatever the channel provided" AFAIK
<mst>so the channel provides me the 'current version' of each package
<mst>IFF 2.0.1 contains a bug that affects Y
<mst>I want to be able to build Y against 2.0.0 instead
<mst>but so far as I'm aware, the definition for 2.0.0 went away when I updated my package versions and got given 2.0.1
<mst>(note - the definition - I know if I've already got it installed it'll still be there)
<mark_weaver>mst: the way that's currently handled in Guix is that we include the older version that's needed.
<mst>could you expand on what 'we include' means specifically
<mark_weaver>for example, I just recently packaged bitlbee, which needs an old version of libotr.
<mst>inline the definition of the older version?
<mark_weaver>mst: see
<mark_weaver>there, I define 'libotr' with the latest version (4.0.0).
<mark_weaver>below that, I define a variable 'libotr-3' with an older version.
<mark_weaver>they both have the same "name" field though, so from the "guix package" command they are both called "libotr", but you can install either version.
<mark_weaver>and then the 'bitlbee' package at the bottom uses
<mark_weaver>'libotr-3' as an input.
<mark_weaver>maybe there's a better way to handle this stuff, but that's how we're doing it currently.
<mst>so, basically, it's possible, but gross and manual
<mst>this is a 100% improvement on "not possible at all" :)
<mark_weaver>well, can you outline a better approach?
<mark_weaver>(I'm not saying there isn't one, just curious what you'd suggest)
<mark_weaver>how could we make it "automatic"? I don't know the answer off-hand.
<mst>I suspect I do, and integrating that with guix is what I'm pondering trying to do :)
<mst>but, yeah, your current model is marginally less restrictive than nix, I think - or nix has the same feature and I just didn't find it successfully
<mst>note: while I believe I have a better approach, I'm not entirely sure I can *outline* it in any sensible number of lines
<mst>hence my answering out of order :)
<mark_weaver>okay, no worries.
<mst>basically, I'd separate out the rest of the package info
<mst>and the concept of 'known version'
<mst>so a known version is just the version, plus the relevant sha256
<mst>and then the bitlbee build could simply say 'libotr 3.x'
<mst>and something else that has an incompat with a particular point release could e.g. say '3.x, !3.2.0' or so
<mark_weaver>well, the URL changes also, and it's not uncommon for the set of patches to be applied to change from version to version.
<mst>um. the URL is your package is strictly derivable from the version so while the output of the URL-generating *expression* changes the URL itself doesn't
<mark_weaver>but also: each input is specified as an arbitrary scheme expression, which is much more powerful than looking up a name and version number.
<mst>I mean, 'the URL expression generator doesn't'
<mst>but also: none of that is relevant to the approach I'm describing
<mst>my point is to be able to select a variant of an input from among the set of known variants
<mark_weaver>well, civodul is a better person to talk to about this. he's the one who designed guix, and has vastly more knowledge than I do about both guix and nix.
<mst>the reason people usually don't do that is because you get into all sorts of trouble with transitive dependencies later
<mark_weaver>would you like to post your ideas to ?
<mark_weaver>civodul prefers the ML for these kinds of discussions, and usually responds quickly.
<mst>any idea when the scheme expression for the input is evaluated?
<mark_weaver>I suppose you could write a procedure that automatically selects a package object from a list of specifications (name, version number constraints, etc), and then use that as an input.
<mark_weaver>those expressions for the inputs are evaluated when the (gnu packages X) module is loaded.
<mst>right, that's far too early to be useful if you need to solve the transitive dependency problem
*mst grumbles
<mst>"build systems are almost never designed for this"
<mark_weaver>the thing is, in almost all cases, what we want is for every package to be built against the latest version.
<mark_weaver>fortunately, the number of cases where we need two versions of a given package is rather small.
<mark_weaver>and IMO, that's good. I'd rather than the number was 0.
<mst>yes. that's why nothing ever solves this. it's pretty much always more effective to hack around it.
<mark_weaver>well, my opinion is that using old versions of software is the hack. the proper solution is to fix things so that the latest versions of everything work well together.
<mark_weaver>IMO, anyway.
<mark_weaver>of course, that doesn't mean that we shouldn't work on improving Guix's ability to support cases where this ideal is not achievable.
<mst>that's a great policy when everything's open source, all the relevant maintainers are sane, and available time is unlimited
<mst>I'm interested in situations where none of those three are particularly likely :)
<davexunit>mst: well the first item on the list is taken care of because the guix distro only contains free software
<davexunit>and I don't think we're interested in any use-cases that involve nonfree software. the security benefits of nix/guix go right out the window, no?
<mst>you're not? so you're telling me that if I want to be able to run nonfree software on a system that also runs guix, I'm not welcome?
<mst>in that case I should leave before I waste my time trying to contribute, but that doesn't seem like a particularly constructive policy to me
<mark_weaver>no one is saying that. you can do what you want on your own machine.
<mst>then I don't believe davexunit's comments were relevant to what I was discussing
<davexunit>mst: perhaps not. sorry for the confusion.
<mst>my interest here is achieving uniform, robust deployment of applications
<mst>some of those applications will be proprietary
<mst>since I only consult under a contract that allows me to contribute back to the relevant open source projects anything that is *not* considered by the customer to be part of their 'secret sauce', I've no problem with them paying me to fix the open source stuff until it can handle their use case
<mst>but that means that *I* have to care about non-free software with politics, asshole maintainers and limited available time
<mst>and the free-ness of guix-the-base-distro doesn't change that, sadly
<mst>davexunit: does that make a bit more sense?
<mark_weaver>I believe what davexunit meant (if I may) is that we're not going to be particularly interested in adding features whose sole purpose is to support the use of non-free software.
<mark_weaver>we are primarily interested in creating a 100% free distro.
<mst>right. I'm primarily interested in having a really good build system that I can use to deploy both free and nonfree software on a range of OSes
<mst>or: I'm interested in guix-as-a-better-nix more than guix-as-a-better-nixos
<mst>if you see what I mean
<mst>the current most likely alternative is that I use either nix itself, or netbsd pkgsrc
<mst>but guix seems to me to be potentially better
<mst>and it's guile's fault that I ended up as an open source contributor at all
<mark_weaver>heh :)
<mst>however, all of the technical issues that I want to be able to deal with can easily exist in the real world for a pure free software system
<mark_weaver>well, the other thing is that we're only targetting GNU userland.
<mark_weaver>(i.e. glibc-based)
<mark_weaver>we plan to support other kernels such as the hurd, and maybe kFreeBSD.
<mst>I was under the impression that guix, like nix, could be used to build out a tree of software in an arbitrary directory tree and didn't actually *need* to own /
<mark_weaver>but iiuc we don't plan to support systems with non-GNU userland, e.g. Solaris, BSD (other than maybe its kernel), etc.
<mark_weaver>well, that's true. it doesn't need much from the host system, other than to build guix itself, and its daemon.
<mst>almost every solaris box I've ever seen has already had half a GNU userland installed because the linux kids had CADTed something they needed and it was easier than porting it
<mst>lemme put this another way -
<mst>does anybody actually care about the build system itself, or only the OS?
<mark_weaver>I think we care about the build system, yes, but I don't think we plan to support as diverse a set of host OSes as you have in mind.
<mark_weaver>My understanding is that Guix is specifically targetting GNU systems, and I don't think we plan to expend much (if any) effort trying to make it portable to other systems. But maybe I'm wrong. Better to ask on guix-devel. I really feel that I'm not in a position to answer all of your questions.
<mst>to be honest, the fact that the inputs are evaluated when the .scm module is loaded suggests that it's probably too late to make guix capable of doing the things I want without radically re-architecting it
<mst>it seems to be just as un-dynamic as nix on that front
<mark_weaver>if I were you, I'd come up with a list of your requirements, and post them to guix-devel, and someone more knowledgeable than me can determine whether Guix is a good fit for your use case.
<mark_weaver>mst: no, it's more powerful than you think.
<mark_weaver>mst: packages are dynamic objects, they can be created dynamically.
<mst>if you were me, you wouldn't have a working mail setup for handling lists either and would be under your desk screaming at the thought of subscribing to another one
<rigelk>could someone give me an hint about how to test any further my package definition ? The syntax has been checked and the .go file generated. Next step should be to build, right ? any ideas on how to build ? -> at the moment it tells me it's an unknown package.
<mark_weaver>for example, instead of simply having a static top-level package definitoin, you can have a procedure that takes some parameters and dynamically generates a package object.
<mark_weaver>and then you can have other packages that call these procedures to generate the input packages.
<davexunit>rigelk: paste the module and I'll take a look
<mark_weaver>mst: for example, take a look at cross-base.scm
<rigelk>thx davexunit ; here you go :
<mark_weaver>the inputs don't have to be generated at module load time, but they are in the common cases. the more general answer is that they are evaluated when the package object is created.
<davexunit>rigelk: it's the error I expected. you need to export the doxygen variable
<davexunit>in the define-module form, on a new line after the last #:use-module, add: #:export (doxygen)
<mark_weaver>or use 'define-public' instead of 'define', which is what is usually done.
<davexunit>that too.
<davexunit>is define-public the preferred way to do it?
<mark_weaver>(fwiw, I'm sympathetic to davexunit's preference for an explicit export list, but 'define-public' is what is used almost everywhere in guix)
<davexunit>I will start using define-public for consistency.
<rigelk>yeah, i deleted #:export because i saw form without it ; they were certainly public forms :/ thx to you both :)
<mark_weaver>you're welcome!
<davexunit>rigelk: you're welcome.
<rigelk>and after which command(s) does the package become known to guix ?
<davexunit>you shouldn't have to do anything else for the pre-inst-env
<davexunit>./pre-inst-env guix package -A doxygen
<davexunit>should output your package
<rigelk>it doesn't :x
<davexunit>does 'make' run successfully?
<mark_weaver>rigelk: can you show me the complete file?
<mark_weaver>and tell me its name and location in your git checkout tree?
<davexunit>rigelk: your module name is incorrect
<davexunit>you have (gnu package doxygen) but it should be (gnu packages doxygen)
<mark_weaver>ah, indeed!
<mark_weaver>(nevermind my questions)
<davexunit>totally missed that the first time through. subtle.
<mark_weaver>good catch
<rigelk>oh :/ i realise i should give extra-care to 's' and parenthesis, obviously !
<davexunit>rigelk: do you use paredit? I find it essential to keep my lisp in proper form.
<mark_weaver>paredit is *great* (I don't know how I ever lived without it), but it has a bit of a learning curve, for sure.
<rigelk>i downloaded it according to the 'hacking' file, but not sure if i've activated it in emacs
<rigelk>gotta check that.
<davexunit>rigelk: it's okay for now. one thing at a time.
<mark_weaver>you can't really learn paredit a little bit at a time. I found it very frustrating until I knew a decent chunk of its most important commands.
<mark_weaver>so yeah, maybe not something to learn today, while you're also trying to learn guix. but when you have an hour to spare on just paredit, it will be time well-spent.
<rigelk>once i'm out with that package, i will. promise ;)
<rigelk>what does 'spurious SIGPOLL' means exactly ?
<mark_weaver>I'm not sure, to be honest, but it happens to all of us. it's inherited from Nix.
<rigelk>when building, i have an error `couldn't write no space left on device`. What could cause such a problem ? (considered i have more than enough free disk space at the moment)
<mark_weaver>rigelk: the builds are done in /tmp. I guess you have a small /tmp.
<mark_weaver>also, the built packages go in /nix/store by default, so if you have a small / and big /usr, that's another possible issue.
<phant0mas>mark_weaver: patched succesfully :-D
<mark_weaver>phant0mas: ah, good!
<mark_weaver>phant0mas: can I see what you wrote?
<mark_weaver>rigelk: Long ago, there were substantial performance advantages to putting /tmp on a ramdisk, but afaik that's not been the case for many years on Linux.
<phant0mas>I had to replace unpack phase though
<phant0mas>git fetch demands :P
<phant0mas>wrong link
<phant0mas>one sec
<phant0mas>a ok it is the right one
<mark_weaver>phant0mas: why did you have to replace unpack?
<mark_weaver>seems fishy to me.
<phant0mas>check web.scm
<phant0mas>normally unpack phase assumes a tarball
<phant0mas>so when it gets a folder all hell break loose
<mark_weaver>phant0mas: hmm, okay.
<mark_weaver>I have to go afk for a while. happy hacking!
<phant0mas>see ya
*rigelk has extended his /tmp dir to 4GB and rebuilds
<mark_weaver>rigelk: btw, when building new packages, it's a good idea to pass the -K option to guix build. that causes the build directory to be kept in /tmp if the build fails.
<mark_weaver>sometimes when debugging problems in recipes, it's useful to look in the build directory.
<rigelk>mark_weaver: ok, i shall use it ; for now i'm still compiling and... well, waiting in awe.
<rigelk>I don't recall, does guix always compile from source its packages, or are there binaries for the end user ?
<mark_weaver>there are binaries, but the server that hosts those binaries is currently being revamped somewhat, and is down.
<mark_weaver>(we got some new machines to improve the build farm, and are switching the prefix from /nix/store to /gnu/store, etc)
<mark_weaver>also we're in the process of applying crypto to verify the authenticity of the binaries over the wire.
<mark_weaver>so far, those binaries are not authenticated, so I always build everything from source anyway.
<mark_weaver>(by passing --no-substitutes to guix-daemon)
<rigelk>mark_weaver: will you use signatures ?
<mark_weaver>yes, we're not too far from having those.
<mark_weaver>but so far, there are two things that aren't properly authenticated: guix pull, and binary substitutes. so I don't do either of those.
<mark_weaver>other things that are downloaded are verified against SHA256 hashes that are included in the guix git repo and tarballs.
<rigelk>mark_weaver: how do you compile not to spend hours a day compiling ? ^^'
<mark_weaver>rigelk: well, the bulk of it only has to be done every few months, when the "core-updates" branch is merged into the master branch, with new toolchain and core stuff.
<mark_weaver>once you have the C library, GCC, binutils, etc, bootstrapped, then all of that will be cached and you won't have to build them again very often.
<mark_weaver>and of course, once hydra is back up, you can use the binary substitutes if you like.
<mark_weaver>(hydra being our build farm and binary distribution mechanism)
<mark_weaver>just beware of "guix gc", which by default will delete all that stuff you needed to build things. that command needs a new mode for people who prefer to avoid substitutes (people like me :)
<rigelk>anyway, it reminds me of my old gentoo install :] good times.
<rigelk>when do you use `guix gc` ?
<mark_weaver>well, over time you'll build up a bunch of built packages in /nix/store/*
<mark_weaver>when a package gets updated or modified, it doesn't replace the old one in the store; it has a new hash in its directory name and sits alongside the old one.
<mark_weaver>so these build up over time, and you need to invoke the garbage collector periodically to clean out the ones you don't use anymore.
<rigelk>oh, i see. it deleted the last version of a given package name ?
<mark_weaver>you have your "profile", i.e. the packages that are merged into the symlink tree referenced in ~/.guix-profile.
<mark_weaver>(as well as older versions of your profile that you could --roll-back to)
<mark_weaver>and those profiles form the root set, i.e. the set of things you need.
<mark_weaver>and those things you need directly can refer to other things in the store, e.g. a /nix/store/* directory for a normal program refer to the libraries it needs.
<mark_weaver>and so the GC finds all of the things you still need, directly or indirectly. anything else is fair game to be deleted.
<mark_weaver>so the idea is that you run "guix gc" every once in a while, to get rid of the old stuff you no longer need.
<mark_weaver>unfortunately, it does not yet include the things you will probably need to build new packages from source code in the future.
<mark_weaver>so that part still needs to be written.
<mark_weaver>it works well for people who use binary substitutes though..
<rigelk>hum. What is the difference of behavior gc has between substitutes and sources ?
<mark_weaver>well, if you use binary substitutes, you don't have to build your toolchain from scratch, and all the programs you need to do the builds, etc.
<mark_weaver>if you are a user installing a new package, you can just download the package in most cases.
<mark_weaver>if you need to build from source, then you can just download the compiler and the libraries/programs you need to do the build.
<rigelk>next time i shall use a precompiled toolchain ; it's already been 2h compiling libc :/
<phant0mas>don't forget to use the -c argument on guix build
<phant0mas>to use all your cores
<rigelk>phant0mas: i'm using an atom, so it may not be of much use ;)
<phant0mas> mark_weaver: how could I pass both mach and hurd headers to glibc configure at the same time?
<mark_weaver>I don't really understand why this is a complication.
<mark_weaver>if you include both of them as inputs, they will both be put in CPATH automatically.
<mark_weaver>if you need to pass them as arguments to configure, I don't see why having two of them is any different than having one.
<mark_weaver>maybe I don't understand something :)
<phant0mas>the linux headers are passed like this
<phant0mas>(string-append "--with-headers="(assoc-ref %build-inputs "linux-headers") "/include")
<phant0mas>normally mach and hurd headers would be in the same include folder which here is not the case as they are different recipes
<phant0mas>so I am not sure on how to pass to it 2 different include folders
<phant0mas>maybe I haven't understand how guix manages this
<rigelk>a curiosity phant0mas : what does assoc-ref ?
<phant0mas>rigelk: in the example above it returns the include folder, produced from the linux-headers recipe
<phant0mas>but mark can explain it much better than me :P
<rigelk>i see ; may i be of any help anyway ? i have a toolchain compilation running, thus spare time :)
<mark_weaver>oh well, just missed him...