IRC channel logs


back to list of logs

<rgc>can I install an old version of a package?
<mark_weaver>it's possible to support old versions of packages, and we do that where it makes sense, e.g. for guile, texinfo, gcc, libotr, python, and others.
<mark_weaver>and of course, if you'd installed an old version previously, you can always roll back.
<mark_weaver>what version of what package do you need?
<mark_weaver>take a look at gnu/packages/texinfo.scm, for example. I recently added version 4.13a because it's much faster than 5.2, and my machine is slow.
<mark_weaver>also, if the package is already in your store, you can install it in your profile by passing the absolute store directory name as an argument to "guix package -i", although that's a bit hacky and has some disadvantages.
<rgc>The thing is that I see use cases for development, when there's a dependency on an old version. I need lua 5.1 for example ...
<mark_weaver>if something needs lua 5.1, then we should add it.
<mark_weaver>what needs lua 5.1?
<rgc>nono, it's that I need it. It's a project I work on
<mark_weaver>well, if you need it, then maybe others in a similar situation need it too. is it just for testing purposes? can you help me understand?
<rgc>well, there are some differences in lua 5.1 and lua 5.2 that make that some libraries work just in one or the other.
<mark_weaver>but in any case, if you need local packages that you think won't be of interest to others, or any modifications to guix that you prefer, the best way I know is to create a local git branch of guix, and use that. git makes it easy to merge the upstream changes into your local branch.
<mark_weaver>rgc: well, it sounds like we should add lua 5.1 then.
<rgc>aha, true
<rgc>in fact, lua is kind of pathological case , even ubuntu has lua5.0, lua5.1 and lua5.2
<mark_weaver>rgc: would you like to submit a patch to add lua 5.1? take a look at what I did in texinfo.scm, except that in your case you probably won't need to have an 'inputs' field.
<rgc>yup. I'll take a look at it.
<mark_weaver>the variable name (the thing after 'define-public') will have to be different than 'lua'. 'lua-5.1' might be a good choice.
<mark_weaver>but the package name will be the same, so from the user-level commands it will still be 'lua', just a different version.
<mark_weaver>the variable name is what you use when you specify the input to another package, however.
<mark_weaver>so if another package depends on lua-5.1, you'd put ("lua" ,lua-5.1) in the inputs.
<mark_weaver>just (inherit lua), override the 'version' and 'source', and you should be done.
<mark_weaver>(unless there's some difference in how the thing has to be built)
<rgc>probably it'll be the same
<mark_weaver>from the user-level commands, you'd do something like "guix package -i lua-5.1" or "guix build -K lua-5.1"
<mark_weaver>note that the "lua-5.1" does not refer to the variable name. rather, the user-command looks for a package named "lua" with version number "5.1".
<mark_weaver>and if you do "guix package -A lua", you'll see all the available version.
<rgc>ah, didn't know about the -A option
<phant0mas>good morning guix
<phant0mas>maybe I should set the env vars before calling configure so I can bypass the problem
<phant0mas>or change the part in glibc configure that handles the addons
<phant0mas>I must solve this today
<phant0mas>btw where is civodul? didn't see him online from yesterday morning
<civodul>Hello Guix!
<mark_weaver>hi civodul!
<civodul>howdy mark_weaver
<mark_weaver>civodul: should we upgrade guile to 2.0.11 in core-updates?
<mark_weaver>If you'd prefer, I can do it, but I wasn't sure if you were waiting on it for some reason.
<civodul>mark_weaver: yes, go ahead :-)
<mark_weaver>civodul: okay, will do.
<mark_weaver>civodul: regarding building 'shadow' from git, I was thinking of making a separate package the builds the tarball using 'make dist', and then using that as the 'source' for the existing 'shadow' package. does that make sense? I'm reluctant to muck up the 'shadow' package definition itself, especially since the tarballs might become available again at some point.
<mark_weaver>civodul: do you mind if I merge 'master' into core-updates? I just did it on my local system, and there were no conflicts. seems straightforward.
<civodul>mark_weaver: fine with me!
<mark_weaver>okay, here goes!
<civodul>mark_weaver: regarding shadow, i dunno, maybe making a tarball as a separate package is overkill?
<civodul>OTOH, 'dist-package' from (guix build-system gnu) should make that easy
<mark_weaver>oh, I didn't know about that.
*mark_weaver looks
<mark_weaver>one thing is that the standard 'unpack' phase in gnu-build-system assumes that 'source' is a tarball.
<mark_weaver>and of course, we'd have to add a bunch of native inputs, a pre-configure phase, etc.
<civodul>that's no longer the case in core-updates
<mark_weaver>oh, sorry, let me look again :)
<civodul>seems to me it would be quicker to just add a pre-configure phase that runs autoreconf
<mark_weaver>okay, fair enough :)
<mark_weaver>btw, I recently learned that bitlbee now supports the latest libotr, but they haven't bothered to cut a new release. I got on IRC with them and tried to convince them to release, but they don't seem to care much. Debian has a package based on a later revision from their subversion repo that they recommend to all users who aren't building from source :-/
<mark_weaver>so I'm thinking of adding a new origin type for fetching from subversion, and upgrading that as well.
<civodul>yes, sounds like we'll need that
<phant0mas> civodul: I did the make clean-go and make but still I am getting Unbound variable: glibc
<phant0mas>the problem is with the lines in base.scm that inherit from glibc
<phant0mas>does #:export (glibc) work for the instanses of glibc in base as well?
<civodul>phant0mas: yes, it needs to be exported
<phant0mas>I do have #:export (glibc) in base
<phant0mas>I will send the current patch so you can have a better look
<phant0mas>civodul: just sent the patch so you can have a better look
<civodul>phant0mas: ok, i'll look at it, but leave me a bit of time
<phant0mas>okay okay
<phant0mas>I am working on the configure issue now
<phant0mas>it came to my attention than in the cpath of my build I can find the linux libre headers as well
<phant0mas>I overide the propagated-inputs on my glibc/hurd recipe so why that happens?
<phant0mas>civodul: I think I found what I will do, I will configure libpthread in a phase and then patch the glibc configure script to only build it
<phant0mas>or patch the glibc configure to pass the flags to it
<phant0mas>here is where it finds the addon's configure scripts
<civodul>phant0mas: i talked to youpi regarding libpthread-as-an-addon
<civodul>you need to make sure to use the right branch
<civodul>with a that sets libc_add_on_srcdir
<civodul>i have a checkout of the branch 'tschwinge/Peter_Herbolzheimer' that has this
<phant0mas>let me see which branch I am using
<phant0mas>I am using that branch
<phant0mas>and I found libc_add_on_srcdir
<phant0mas>civodul: I think the problem is that it calls the addon configure without passing any flags to it
<phant0mas>what do you think?
<civodul>phant0mas: dunno
<civodul>youpi told me Debian has its own patch, which might be different from what's in the repo
<civodul>a somewhat confusing situation
<civodul>tschwinge: what's the current status of libpthread on Savannah?
<phant0mas>till we get an answer I will try out my idea
<phant0mas>I should just add AC_CONFIG_SUBDIRS in the configure script and make my life easier