<mckinley_>I'm a bit new to using "guix environment"; I'm trying to get the 'jdk' output of the 'icedtea-8' package in an environment. After running 'guix environment icedtea:jdk', I seem to have the 'jdk' output of the 'icedtea-7' package in the environment <lfam>We version icedtea based on the icedtea version rather than the openjdk version. So, to get openjdk@8, you use icedtea@3 <lfam>The @ character is how separate package names from versions on the command line <lfam>So, you could try this `guix environment icedtea@3:jdk`. I didn't let the command finish for me since I didn't want to wait for things to build <mckinley_>lfam: strange thing is, running 'guix package -i icedtea:jdk' seems to install iced-8 in my profile; 'java -version' reports 'openjdk version "1.8.0_91"' <lfam>Yes, I was wondering why you got openjdk-7. Usually the tools select the latest version if no version is specified <lfam>If you're sure that's what happened, you might send email to help-guix@gnu.org or bug-guix@gnu.org <mckinley_>lfam: running `guix environment icedtea@3:jdk`, then running `java -version` gives output 'java version "1.7.0_101"' <lfam>mckinley_: How about `guix environment --pure icedtea@3:jdk`? <lfam>Also, are you setting things like PATH in your .bashrc? <lfam>That can also break `guix environment` <mckinley_>lfam: I am in my zshrc; I'll try removing that <lfam>Okay, those things should only be set in .profile, .zprofile, .bash_profile, etc. Whatever gets sourced by login shells <lfam>I'm building whatever is required to test this <mckinley_>lfam: cleared everything from zshrc; thanks! <mckinley_>lfam: running `guix environment --pure icedtea@3:jdk`, then running `java -version` gives 'command not found: java' <lfam>mckinley_: That command sets up a development environment for icedtea@3:jdk. If you want an environment that contains icedtea@3:jdk itself, then you need to put --ad-hoc, like this `guix environment --pure --ad-hoc icedtea@3:jdk`. I don't know if that addresses your comment because I know almost nothing about Java <lfam>Should the development environment contain a `java` command? <lfam>mckinley_: Let me know if you resolved the problem. If so, I can cancel this compilation that is making my computer's fan howl ;) <mckinley_>lfam: it creates an environment with just the icedtea@3:jdk output in it, right? that package provides the java binary, I think <lfam>mckinley_: With --ad-hoc? That should be what happens. <mckinley_>lfam: with `guix environment --pure --ad-hoc icedtea@3:jdk`, `java -version` gives "command not found" <lfam>mckinley_: Unfortunately I don't really know anythinb about Java and how all the parts fit together. rekado_ might have some insight <lfam>What about if you leave off the :jdk part? <mckinley_>lfam: I've been reading the documentation on the pure option; I might be misinterpreting. using command `guix environment --pure icedtea@3:jdk` I thought would result in an environment with only the binaries icedtea@3 provides (java being one of them) on PATH <lfam>mckinley_: If you want to add foo in your PATH, then you should do `guix environment --ad-hoc foo`. If you want only foo in your PATH, then you should add the --pure option <lfam>If you want a development environment for building foo, then you do not use --ad-hoc <lfam>That is, without --ad-hoc, you get the dependencies of foo, but not foo itself <lfam>--pure can go with either method. --container is like --pure but purer ;) <davexunit>--pure clears environment variables, whereas --container makes a chroot and uses namespaces to completely isolate the process from the rest of the host system <davexunit>which one you want to use depends on just how isolated you want to get. :) <lfam>Is it expected that we have no substitute for nss-certs? <lfam>Or perhaps, it's nss, I'm not sure <lfam>nss does not have a substitute for recent HEAD <mckinley_>lfam: ah, I'd totally misunderstood what `guix environment icedtea@3` did. I thought it was putting the output of the package in the environment; what I understand now is that it puts all the package inputs in the environment <lfam>mckinley_: Exactly. It's to set up an environment to do some hacking on icedtea@3 <davexunit>use the --ad-hoc flag to add the packages themselves <davexunit>--ad-hoc is positional so you can do cool things like: <davexunit>guix environment icedtea --ad-hoc git strace <davexunit>which would get you the dependencies of icedtea, but also git and strace themselves <mckinley_>yeah... I feel foolish. I read "The purpose of guix environment is to assist hackers in creating reproducible development environments without polluting their package profile" and interpreted its use to be more general development than to those hacking on guix itself and thought it applied directly to my use case (wanting to be able to use and switch between multiple versions of the jdk) <mckinley_>--ad-hoc definitely satisfies my use case, though <lfam>I use --ad-hoc for your use case all the time. It's especially nice for things that I *know* I don't care if they get garbage collected later on. That's what the "profile pollution" refers to, since the contents of old profiles aren't garbage collected until you delete the profiles. <lfam>To be honest, it took me a little while to grok the difference, too <lfam>I should clarify, the contents of profiles aren't garbage collected until you delete the profiles and run `guix gc`. Deleting the profile itself doesn't delete the packages the profile referred to <davexunit>mckinley_: 'guix environment' definitely was designed with general development in mind <kristofer>I use --ad-hoc every day :) -- though I didn't know all the details lfam provided <Kooda>Hey there. :) Installed guix on my devuan system to get started with it. :D <efraim>I had to read it twice before I realized it was a poem <Kooda>I was wondering if it is possible to make a package and specifying it’s an alternative implementation for an other. <ng0>Kooda: like inherit? <ng0>search the gnu/packages/ for "inherit" <ng0>it is likely that you want inherit <efraim>texlive hasn't released 2016-final yet so I'd let the debian folks poke them first <ng0>Kooda: take the base of one package and fill in what you want to change <Kooda>ng0: I’m not sure inherit is what I’m looking for. <efraim>some changes are doable from the command line, others require having a separate git branch <efraim>so I could make ffmpeg to target my hardware, but when mpv uses ffmpeg it'll use the one in guix by default <Kooda>My current problem is that I have packages in my profile that depend on libGL, but the mesa one would not work as I (sadly) use the proprietary implementation. <ng0>Kooda: could you describe what you mean and what you try to achieve <efraim>ng0: also we don't build a lot of the documentation <Kooda>So I have to use the libGL provided by nvidia. <ng0>who was it I was talking with about SELinux and GrSecurity? I am not so sure if we want GrSec. I have know about the behavior of GrSec since Gentoo dropped stable and had to offer the cut down, instable outputs.. and do we want to support yet another bully on the playground? I'll certainly try and test for it, but SELinux seems more favorable for the moment.. I still include GrSec in the things I want to add to <ng0>guix, but I want to do musl etc first. <ng0>Kooda: I think I can't help you at the moment <ng0>maybe someone else can <civodul>ng0: the texlive SOURCE_DATE_EPOCH change would be useful <Kooda>No problem, I’m not in a hurry. :) <civodul>ng0: GrSec would be very welcome too <ng0>having GrSec means we need to have at least 1+ people to maintain its implementation continious, like gentoo-hardened does (or any distro I imagine) <ng0>some people will always grab packages I wanted to do, but i think there's more value in doing services etc <ng0>at least for me, so that I can move a server from gentoo-hardened to guixsd one day <civodul>i'd make the "toolchain" item very low priority, but the rest sounds cool <ng0>I'd be cool if I could just setup the homeserver with hiawatha, tor, git-daemon and maybe gitolite on guixsd now but there hasn't been much progress on any of these other than tor, right? <civodul>ng0: i think it'd be easier to add these services than to "wait for progress" ;-) <ng0>yes. my time is limited though, and I can start to work on all of this once portage is happy with the ebuilds for gnunet suite and it will be "just" maintenance from then on <roelj>Is there a way to upgrade packages in a profile, but instead put the upgraded version in a new profile? <cbaines>roelj, out of interest, are you aware that the previous "generations" of profiles are stored? <cbaines>from your question, this might be what you are looking for. <roelj>cbaines: Yes I am aware of that. <roelj>cbaines: However, I'd like to perform an upgrade without disturbing the current profile contents.. <roelj>bavier: Does the new patch for llvm, clang and clang-runtime compile for you? Mine fails. <civodul>roelj: not really, but you could upgrade, then rename the new generation's symlink, and then rollback <roelj>civodul: Ok. This should work too: guix package --install `guix package --list-installed | awk '{ print $1 }' | tr '\\n' ' '` -p upgraded-version <civodul>or: guix package -p new-profile -i `guix package -I | cut -f1` <efraim>favorite phase: (add-before 'install 'fail #f) <civodul>alternately, if you used --manifest, that'd be trivial <roelj>civodul: I noticed you like 'cut' years ago when I suggested changing the output of guix package --list-installed ;) <ifur>tr and cut is two of my crutches preventing me from learning more proper tools :) <davexunit>yay, I have packaged all of the emacs extensions I use now. no more MELPA. <civodul>i still use several of them, i should check whether i can switch now <davexunit>I noticed some issues with the importer that I'd like to fix <davexunit>it puts things in 'inputs' that should be 'propagated-inputs', for example. <davexunit>also, I have to change the source information for everything I get from MELPA, and I thought of a heuristic that may work for common cases where the source is available on GitHub. <civodul>davexunit: yeah, it should avoid putting melpa URLs <davexunit>I found that using tarballs on github for things that are single .el files on MELPA leads to outputs with a bunch of unnecessary stuff in them <davexunit>so the patches I just pushed use github's raw file interface to get single files where necessary instead <cbaines>I have a custom pytest package that I am trying to build with Guix, and I have encountered an error when trying to build it: <cbaines> /gnu/store/vpvbinksr8ac2g9xaw4nk33bry9xdq7f-pytest-2.9.2.tar.xz-builder:1:1967: In procedure module-lookup: Unbound variable: substitute* <ng0>but in this case it is emacs :) <cbaines>I'm not particularly sure where to start debugging this, as the code looks to be generated, and I've not macro system before <adfeno>Reminds me of wingo's article on Conway's Law. <adfeno>One of the projects there seems to be contributing to Apertium.... <cbaines>(think I have solved my problem, was missing the modules field in the origin record) <janneke>running guix system reconfigure for the first time...now at: <janneke>guix system: loading new services: file-system-/home urandom-seed ntpd avahi-daemon ssh-daemon... <janneke>shepherd: Evaluating user expression (register-services (primitive-load "/gn...") ...). <janneke>Hmmm, probably a long time. shepherd.log says the above, and then s last line: <janneke>2016-06-01 19:28:39 Enter `,help' for help. <notadrop>Sometimes, the touchpad on my Macbook works. sometimes, it doesn't. I'm still trying to figure out why... <Walakea>what filename extension do guix packages have? <ifur>looks like boost should be in propagated inputs in the cgal package? /gnu/store/...-cgal-4.6.3/include/CGAL/config.h:85:28: fatal error: boost/config.hpp: No such file or... <ifur>asking, as im not sure :) but not finding boost _seems_ to be the reason for failing to build against cgal <ifur>and cant find any other packages atm in the repo that actually uses cgal <ifur>sorry, all inputs it seems? <ifur>yeah, adding boost, gmp and mpfr as inputs solved that issue for me.. <davexunit>I may just been given permission to use Guix to build software for a production server. <ifur>changes like that can be hard... <ng0>Walakea: it is in guile, in gnu/packages/ all relevant files end in .scm <civodul>ifur: yeah, that a CGAL public header #includes Boost is a reason for propagating Boost <civodul>i thought i used CGAL at work, but maybe not, or maybe i'm lucky ;-) <civodul>sneek: later tell your 'guix system reconfigure' bug is interesting, send bug-guix@gnu.org all the details! :-) <civodul>sneek: later tell janneke your 'guix system reconfigure' bug is interesting, send bug-guix@gnu.org all the details! :-) <sneek>Welcome back your, you have 1 message. <sneek>your, civodul says: 'guix system reconfigure' bug is interesting, send bug-guix@gnu.org all the details! :-) <civodul>the one in my 2016-05-03 generation works <sneek>Welcome back janneke, you have 1 message. <sneek>janneke, civodul says: your 'guix system reconfigure' bug is interesting, send bug-guix@gnu.org all the details! :-) <janneke>my first reconfigure, and it failed. i suspect that changing my /home was a bit tricky to do <emyles>hi, I am trying to build a package and get "ERROR: missing interface for module (gnutls)" <emyles>do I need to install gnutls into my profile or add it to the package definition somewhere? <emyles>Ah, it says it is "following redirection to https", so I think I just need to correct the url <emyles>yes that works now that I corrected http -> https ***calher is now known as Emacsite