<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: 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: 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 ;)
<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>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
<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