<cogrendel>Can someone shed some light on how this works for me? Are there different module namespaces in one package declaration? If so why?
<buenouanq>functionality beyond the very core is contained in modules
<buenouanq>you read modules to be able to utilize the things they define
<cogrendel>buenouanq: Hello, thanks for responding. I understand the purpose of modules. What I meant by my question was that it appears that modules loaded at the beginning of the scheme file are not available in certain portions of the package declaration. I was unable to find documentation on this behavior and am looking to learn more.
<cogrendel>For instance in the gnuzilla file I linked above (ice-9 match) is loaded in the top of the file, then separately in (arguments ...)
<cogrendel>Futhermore I am unable to find documentation on the `#:modules` keyword for `(arguments ..)`. I am assuming that it makes these packages available in the `#:phases` arguments, but I haven't seen this documented. I am just guessing.
<cogrendel>buenouanq: No problem, thanks for trying to help.
<buenouanq>qtox is missing a bunch of gui icons on gnome
<buenouanq>is this a qt problem, a gnome problem, or a the guix packaging of qtox itself problem?
<mbakke>cogrendel: the reason why some packages specify #:modules explicitly is because they need modules not implicitly provided by the build system.
<mbakke>buenouanq: try installing qtsvg. The lack of qt icons is a known problem.
<cogrendel>mbakke: Thanks for the reply. Sure, some packages need additional modules. My question is not why modules exist, it is how the namespacing works. It was a surprise to me that modules imported at the top level are not available anywhere in the package declaration.
<cogrendel>I gave an explicit example above from the gnuzilla module.
<mbakke>cogrendel: I see. The reason is that package builders are evaluated in a different context. The resulting .drv needs to declare imports up-front because the store does not know anything about the module the package was declared in (only how to build it).
<buenouanq>mbakke: thank you! took a restart, but it worked
<mbakke>I suppose it may be possible to make module imports implicit inputs.
<mbakke>sneek: later tell buenouanq glad it worked :) there is an ancient bug to make search paths of dependencies available to the "end package". I know "krita" has specific provisions to work around this problem.
<sneek>buenouanq, mbakke says: glad it worked :) there is an ancient bug to make search paths of dependencies available to the "end package". I know "krita" has specific provisions to work around this problem.
<buenouanq>other package managers no longer need to exist (-‿‿ - )
<NewToGuix>Hello All, is it possible to package & distribute commercial software binaries to the customers via Guix?
<efraim1>NewToGuix: if yout mean proprietary sofware, not in the main repository, but it should be possible in your GUIX_PACKAGE_PATH, but we don't discuss packaging and distributing proprietary software on this channel
<CharlieBrown>NewToGuix: Yes. Just charge them money before giving them the source code and the Guix recipe.
<CharlieBrown>I love commercial free software. I use it every day. It's way better than commercial proprietary software.
<Parviz>I was very happy to meet you, Hope I learn more from you in the future
<adfeno>I think there's still work to be done for the GNU Health package definition, but the message I gave still holds: currently the only hope for being sure that you are using mostly free/libre software in Raspberry Pi (and perhaps even version 3), is to install the Guix package manager on top of an existing distro.
<thomassgn>buenouanq: derp, just rebooted and remembered and found there is something that takes away keyboard and trackpad input. Not sure what it is, but trying to fix it. Will let you know what how I fix it if I figure it out. :) no time right now though.
<apteryx_>like, the gcc producing x86 binaries will be used, but through some QEMU layer magic it will be turned to ARM, say?
<efraim>qt-5.9.4 released, that sounds like a fun update
<efraim>means I can put off figuring out the 5.10 sqlite issues
<bavier`>apteryx_: binaries for system are run directly on the native machine on top of qemu
<apteryx_>I think I can understand the run part (instruction are translated through binfmt support in QEMU/kernel?), but I still don't get how the binaries produced targetting say ARM without a cross-compiler?
<apteryx_>*binaries can be produced for ARM (when the host is x86) without a cross-compiler
<apteryx_>is QEMU detecting that GCC is outputting x86 instructions and translating those to ARM on the fly?
<bavier`>rumplestiltskin: I've only tried this once: 1) use 'guix environment --container --ad-hoc ...' with all the packages/libraries required, 2) `echo $GUIX_ENVIRONMENT && exit`, then 3) do 'guix envrironment' again and use the --expose option to bind the profile to /usr or such