Re: [PATCH] Add MARS shooter.

[Ricardo Wurmus]

Ricardo Wurmus  writes:

 No, upstream needs to fix their invalid Content-Type header.  We've
 had this problem a few times, most recently with rubygems.org, and in
 all cases we've gotten upstream to fix it.  Strict header parsing can
 seem like an issue at times, but it's really a very good feature that
 the rest of the world seems to ignore. [0]
>>>
>>> I wonder what a correct Content-Type header would look like in this
>>> case.  I would like to submit a helpful report containing what I got and
>>> what it should have been.
>>
>> In this case, application/x-gzip or application/octet-stream would be
>> appropriate.  Less specifically, the media type needs to match the
>> syntax as defined by the W3C spec. [0]
>
> Thanks, I opened a support ticket with Github.com.

And the response from Github is that it won’t be fixed as this is a
deprecated downloads endpont,

   “meaning there wont' be any changes like this made to that.

https://github.com/blog/1302-goodbye-uploads

These endpoints were deprecated on December 12, 2012.”

So, fetching the sources from there won’t work.  That’s okay, though, as
we can continue to use the git reference.

~~ Ricardo

Re: [PATCH] Add MARS shooter.

[Ricardo Wurmus]

Eric Bavier  writes:

>> I could not get sound to work, unfortunately, because /dev/dsp does not
>> exist on my machine.  It’s not a problem with the package, but maybe
>> someone could give me a hint about what kernel module to load to get
>> this device.
>
> Same on my machine.  I learned about the ossdp software, which may
> help.  http://sourceforge.net/projects/osspd/

Yes, this would help, but I think it’s unnecessary.  OpenAL was built
with ALSA and Pulseaudio backends, yet neither seems to work:

~
rekado@banana $  ALSOFT_LOGLEVEL=3 
/gnu/store/hgx7fddl7ss45jhv4bns2837nd4x1h0f-mars-0.7.5-cc855d04409/bin/mars 
AL lib: (II) alc_initconfig: Supported backends: pulse, alsa, oss, null, wave
...
AL lib: (II) GetConfigValue: Key general:rt-prio not found
AL lib: (II) GetConfigValue: Key general:resampler not found
AL lib: (II) GetConfigValue: Key general:trap-al-error not found
AL lib: (II) GetConfigValue: Key general:trap-alc-error not found
AL lib: (II) GetConfigValue: Key reverb:boost not found
AL lib: (II) GetConfigValue: Key reverb:emulate-eax not found
AL lib: (II) GetConfigValue: Key general:drivers not found
AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
AL lib: (WW) alc_initconfig: Failed to initialize backend "alsa"
AL lib: (II) GetConfigValue: Key oss:device not found
AL lib: (II) GetConfigValue: Key oss:capture not found
AL lib: (II) alc_initconfig: Initialized backend "oss"
AL lib: (II) alc_initconfig: Added "oss" for playback
AL lib: (II) alc_initconfig: Added "oss" for capture
...
AL lib: (EE) oss_open_playback: Could not open /dev/dsp: No such file or 
directory
Failed to open the audio device
...
~

I’ll try to get some more information about the failure to initialise
the “alsa” backend, but it seems to me that this is a problem with our
“openal” package.

>> +(define-public mars
>> +  ;; The latest release on SourceForge relies on an unreleased version of 
>> SFML
>> +  ;; with a different API, so we take the latest version from the official
>> +  ;; repository on Github.
>> +  (let ((commit "c855d04409"))
>> +(package
>> +  (name "mars")
>> +  (version (string-append "0.7.5-c" commit ))
>
> I realize we have no guidelines in the manual concerning the version
> field for git checkouts, but I wonder whether we should, as it comes up
> a bit.  Several existing packages use (string-append "1.2.3." commit),
> where "1.2.3" is the version of the corresponding source.  One other
> package uses the (string-append "1.2.3-c" commit) method, and another
> uses (string-append "1.2.3-" commit.  I personally prefer the "-"
> notation, since it distinguishes the commit hash from the version
> number (does it confuse any internal logic that assumes a package
> version number is the last component of the store path following a
> dash?).  In this case, the "-c" seems confusing because the commit hash
> itself begins with a 'c'.

True.  I have no real preference.  If an update to a more recent commit
makes the introduction of an ordering character necessary it could still
be introduced to force a particular ordering.

>> +  (source (origin
>> +(method git-fetch)
>> +(uri (git-reference
>> +  (url "https://github.com/thelaui/M.A.R.S..git;)
>> +  (commit commit)))
>
> guix lint should warn now about the 'file-name' of the origin.

Oh, right.  I’ll fix it.

>> +(sha256
>> + (base32
>> +  "1r4c5gap1z2zsv4yjd34qriqkxaq4lb4rykapyzkkdf4g36lc3nh"))
>> +(patches (list (search-patch "mars-sfml-2.3.patch")
>
> As mentioned on IRC, I had trouble applying this patch because some DOS
> line-endings went missing somewhere.  We just need to make sure they
> are preserved by git.

The patch looks fine when I inspect the commit.  It still has the DOS
line-endings, so I don’t think this will be a problem when I push it.

>> +   (search-patch "mars-install.patch")
>> +  (build-system cmake-build-system)
>> +  (arguments
>> +   `(#:tests? #f; There are no tests
>> + #:phases
>> + (modify-phases %standard-phases
>> +   (add-after 'unpack 'fix-install-path
>> +(lambda _
>> +  (substitute* "src/CMakeLists.txt"
>> +(("\\$\\{CMAKE_INSTALL_PREFIX\\}/games")
>> + "${CMAKE_INSTALL_PREFIX}/bin"
>
> As in the following phase, could you return #t after the 'substitute*'?

Yes, I forgot this when I broke this up into two phases.

>> +   (add-after 'unpack 'fix-data-path
>> +(lambda* (#:key outputs #:allow-other-keys)
>> +  (substitute* "src/System/settings.cpp"
>> +(("C_dataPath = \"./data/\";")
>> + (string-append "C_dataPath = \""
>> +(assoc-ref outputs "out")
>> +

[PATCH] Fix OpenAL backends.

[Ricardo Wurmus]

Hi Guix,

as I tested my new “mars” package I noticed that there was no sound.
Investigating a little showed that the problem is in our “openal”
package, which loads backend libraries by name only, not by path.

The attached patch fixes this by patching in the full paths for
libasound and libpulse, so now I have sound in “mars” :)

~~ Ricardo

>From e8d7f225b8781afbf331733e5f25442bd61b218a Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Sun, 20 Sep 2015 13:03:38 +0200
Subject: [PATCH] gnu: openal: Use full path to audio backend libraries.

* gnu/packages/audio.scm (openal)[arguments]: Add build phase to patch in the
  full paths to backend audio libraries.
---
 gnu/packages/audio.scm | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index a4e5a55..d829a91 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -1053,7 +1053,25 @@ lv2-c++-tools.")
 "0mmhdqiyb3c9dzvxspm8h2v8jibhi8pfjxnf6m0wn744y1ia2a8f"
 (build-system cmake-build-system)
 (arguments
- `(#:tests? #f)) ; no check target
+ `(#:tests? #f  ; no check target
+   #:phases
+   (modify-phases %standard-phases
+ (add-after
+  'unpack 'use-full-library-paths
+  (lambda* (#:key inputs #:allow-other-keys)
+(substitute* "Alc/backends/pulseaudio.c"
+  (("#define PALIB \"libpulse\\.so\\.0\"")
+   (string-append "#define PALIB \""
+  (assoc-ref inputs "pulseaudio")
+  "/lib/libpulse.so.0"
+  "\"")))
+(substitute* "Alc/backends/alsa.c"
+  (("LoadLib\\(\"libasound\\.so\\.2\"\\)")
+   (string-append "LoadLib(\""
+  (assoc-ref inputs "alsa-lib")
+  "/lib/libasound.so.2"
+  "\")")))
+#t)
 (inputs
  `(("alsa-lib" ,alsa-lib)
("pulseaudio" ,pulseaudio)))
-- 
2.5.0

Re: Icecat vs. iceweasel

[Ludovic Courtès]

Andreas Enge  skribis:

> there are a number of sites for which I still need to use iceweasel, since
> icecat will not work on them.

AFAIK the main difference between these two is the set of plugins
installed by default.  Otherwise it’s essentially the same thing.

> the following error message is displayed:
> IceCat has detected that the server is redirecting the request for this 
> address in a way that will never complete.
> This problem can sometimes be caused by disabling or refusing to accept 
> cookies.
>
> Even when accepting third party cookies, the site does not work.
>
> Does anyone have an idea what is happening?

Dunno.  You could try pinging bug-gnuzi...@gnu.org.

Ludo’.

Re: [PATCH] gnu: Add r-qtl.

[Ludovic Courtès]

Pjotr Prins  skribis:

> I checked with the author and he is fine with your version. 

I think upstream authors shouldn’t be bothered with our own choices of
synopses/descriptions; we have our own context, our own guidelines
etc. that they probably don’t care about.  ;-)

Ludo’.

Re: modprobe on guix

[Petter]

I've investigated a bit and have some light to shed on this issue.

First, I've tested printing the value of LINUX_MODULE_DIRECTORY as
suggested previously in this thread, and found it not to be a good test.

$ sudo bash -c "echo $LINUX_MODULE_DIRECTORY"
> /run/booted-system/kernel/lib/modules,
which shows indeed the expected output, but for the wrong reason.

This would be the shell doing the variable expansion while still in the
user's environment. Which makes it in effect similar to:
$ sudo bash -c "echo /run/booted-system/kernel/lib/modules"

Overwriting the variable in the user environment demonstrates this.
$ LINUX_MODULE_DIRECTORY=hello
$ sudo bash -c "echo $LINUX_MODULE_DIRECTORY"
> hello

Testing single quotes instead, which should leave the variable
unexpanded by the first shell.
$ sudo bash -c "echo $USER"
> petter
$ sudo bash -c 'echo $USER'
> root

And so this would be a better test.
$ sudo bash -c 'echo $LINUX_MODULE_DIRECTORY'
>
(empty value.)

As best i can find out  sudo  doesn't source any of the relevant shell
files, like /etc/profile; and so the root environment isn't set up like
if you logged in as root. And variables from the user environment isn't
passed on to it either. Besides using  sudo -E  , which passes on all
the user's environment variables (not recommended), the easiest fix
seems to be to use  sudo -i  . With  -i, --login  shell files will be
sourced, and we get an environment equal to being root user as far as i
can tell.

$ sudo -i bash -c 'echo $LINUX_MODULE_DIRECTORY'
> /run/booted-system/kernel/lib/modules

I don't know what the proper way of handling this is. But i'm using an
alias at the moment  alias sudo='sudo -i'  . With this  sudo modprobe
works fine.

(I've looked at whitelisting environment variables in /etc/sudoers, but
i believe this is for passing on user defined variables, not system
variables.)

Petter
(karhunguixi)

Re: (Not GuixSD) Purpose of ~/.config/guix/ & config. files

[宋文武]

2015-09-21 2:45 GMT+08:00 Vicente Vera :
> Hello.
>
> After running 'guix pull' (as root) with a fresh binary installation
> directory ~root/.config/guix/ was created, which contains a "latest"
> symlink pointing to /gnu/store/...-guix-latest/.
>
> Since I work as a regular user, I noticed that Guix wasn't picking up
> changes from the updated distribution. Creating a ~luser/.config/guix/
> directory with the same "latest" symlink solved the problem. Now after
> every 'guix pull' I have to manually update the symlink.
Yes, by this way, every user can manage his own guix packages distro.
And I have symlink both to a git checkout of guix.
>
> I was wondering if the ~/.config/guix/ directory is used for something
> else apart from the case described above.
I can't find other thing, but only `latest'.
>
> On another note, what's the appropiate, Guix-y way of storing
> configuration files such as dotfiles, etc. (to be read by Guix
> installed programs) when using Guix atop another GNU/Linux distro?
Guix doesn't have any tricks for those files now.

Re: [PATCH] Add MARS shooter.

[Eric Bavier]

On Sun, 20 Sep 2015 17:49:44 +0200
Ricardo Wurmus  wrote:

> On IRC I was told that the description wasn’t quite as neutral as it
> should have been, so here’s another attempt:
> 
>"M.A.R.S. is a 2D space shooter with pretty visual effects and
> attractive physics.  Players can battle each other or computer controlled
> enemies in different game modes such as space ball, death match, team death
> match, cannon keep, and grave-itation pit."
> 
> * “pretty visual effects” rather than “awesome visual effects”.
> * “attractive physics” — I could not think of a more appropriate term; it
>   surely is not “realistic”.
> * “exciting game modes” has become “different game modes such as ...”
> 
> What do you think?

This version seems more appropriate to me.  Thanks!

`~Eric

Re: [PATCH] gnu: Add file-roller.

[Ricardo Wurmus]

Looks good to me!

I have one question about the propagated inputs, though: why are they
needed?  Is it obvious (and I just fail to see it), or could you explain
this in a comment?

~~ Ricardo

Re: [RFC]: Respect /etc/security/limits.conf

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> The attached patch tries to add an entry for pam_limits.so, but I have
> no idea if this actually works or if this is the way it should be done.
> As far as I can tell we only need the pam_limits.so entry for
> “/etc/pam.d/login”, but I could not find where this file is generated.

It is generated based on the ‘pam-services’ field of the service
returned by ‘mingetty-service’.

Maybe it would be best to adjust just that part?

> Also, I wonder how users are supposed to edit /etc/security/limits.conf
> at all.  I suppose they are not to edit anything in /etc anyway.
> pam_limits.so also reads *.conf files in “/etc/security/limits.d/” and
> maybe it would make sense for packages to provide a
> “$out/etc/security/limits.d/$name.conf” file with settings.  For
> example, the “jack” packages could then provide
> “$out/etc/security/limits.d/realtime.conf”, which contains the
> following:
>
> @realtime   -  rtprio 99
> @realtime   -  memlockunlimited
>
> (See http://www.jackaudio.org/faq/linux_rt_config.html)

Is this PREFIX/etc/security/limits.d convention already used?  If not,
I’d rather avoid inventing it.  ;-)

What we could do is add a field in ‘operating-system’ to specify the
limits.conf file to install as /etc/security/limits.conf?

It would be even better to create Scheme data types that mirror the
settings of a limits.conf file (similar to what is done for PAM
settings), and have users fiddle with that rather than with a plain text
file.

> A user in the “realtime” group could then finally use JACK in realtime
> mode.
>
> What is the best way to make this work?  (I really want to run JACK in
> realtime mode.)

(In the meantime I think your patch plus manual fiddling of
/etc/security/limits.conf does the job.)

Ludo’.

Re: [PATCH] gnu: Add TuxGuitar.

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> The
>> SWT tarball does include jars but these are binaries of the library.
>> The package recipe ignores them and only works on the sources in src.zip
>
> OK.  What about adding a snippet that removes all these jars anyway,
> mostly “to be safe” and to not convey the impression that we’re bundling
> pre-built binaries?

I just tried to do this, but I get stuck as Guix seems to think that the
sources are located in the “about_files” directory:

~~
...
Archive:  
/gnu/store/lkk22318a7mrj5m7mx0s574raa4kj7h0-swt-4.4.2-gtk-linux-x86.zip
   creating: about_files/
  inflating: .classpath  
  inflating: .project
  inflating: about.html  
  inflating: about_files/IJG_README  
  inflating: about_files/lgpl-v21.txt  
  inflating: about_files/mpl-v11.txt  
  inflating: about_files/mpl-v20.txt  
  inflating: about_files/webkit-bsd.txt  
  inflating: src.zip 
  inflating: swt-debug.jar   
  inflating: swt.jar 
source is under 'about_files'
...
~~

In fact, the sources are in the “src.zip” archive.  Currently, I just
replace the “unpack” phase to take care of this, but I don’t know how to
fix this in a snippet.  I’d like to repackage just the contents of
“src.zip” as the source tarball, but ‘patch-and-repack’ doesn’t make it
easy.

~~ Ricardo

Re: [PATCH] Add MARS shooter.

[Ricardo Wurmus]

On IRC I was told that the description wasn’t quite as neutral as it
should have been, so here’s another attempt:

   "M.A.R.S. is a 2D space shooter with pretty visual effects and
attractive physics.  Players can battle each other or computer controlled
enemies in different game modes such as space ball, death match, team death
match, cannon keep, and grave-itation pit."

* “pretty visual effects” rather than “awesome visual effects”.
* “attractive physics” — I could not think of a more appropriate term; it
  surely is not “realistic”.
* “exciting game modes” has become “different game modes such as ...”

What do you think?

~~ Ricardo

Re: gnu: guile: Add guile-wisp

[Ludovic Courtès]

Christopher Allan Webber  skribis:

> But if you use guile-2.0 from Guix, you get the following issue:
>
>   scheme@(guile-user)> ,L wisp
>   While executing meta-command:
>   ERROR: In procedure setlocale: Invalid argument

IMO this is a bug in WISP: it should gracefully handle ‘setlocale’
errors (and it shouldn’t call ‘setlocale’ at the top-level in the first
place.)

Ludo’.

Re: [PATCH] Fix OpenAL backends.

[Andreas Enge]

This looks good to me!

Andreas

Re: Service refactoring

[Ludovic Courtès]

Currently that ’wip-service-refactor’ contains a first implementation of
the “service DAG”.  So far I only “converted” services in (gnu services
base); modulo the yet-to-be-converted services, it looks like this:


“Service” here has a much broader meaning than before.

There’s a service for PAM services, one for user accounts, one for dmd
services, one for /etc entries, one for activation snippets, and finally
the “boot” service.

The PAM root service collects PAM services produced by lshd, mingetty,
etc. and turns them into ‘pam.d’ entry for /etc; the /etc service takes
such entries and turns them into a gexp that calls ‘activate-etc’.
Likewise, the guix-daemon service passes user accounts and groups to the
account service, which turns that into an activation snippet.

The nice thing is that it allows us to express things that were not
possible before, and increases separation of concerns.  For instance,
the ‘account’ service takes care of everything related to user accounts
in a single place, whereas before this would be entangled in (gnu
system); ditto for PAM services.

The API defines , , and .  The
“service type” defines how services of this type are “extended” and/or
how services of this type extend other services:

  (define dmd-root-service-type
(service-type
 (name 'dmd-root)
 ;; Extending the root dmd service (aka. PID 1) happens by concatenating the
 ;; list of  provided by the extensions.
 (extend concatenate)
 (extensions (list (service-extension (target boot-service-type)
  (compute dmd-boot-gexp))

  (define guix-service-type
(service-type
 (name 'guix)
 (extensions
  (list (service-extension (target dmd-root-service-type)
   (compute guix-dmd-service))
(service-extension (target account-service-type)
   (compute guix-accounts))
(service-extension (target activation-service-type)
   (compute guix-activation))

The service procedures used in OS declarations can usually remain
unchanged, written like this:

  (define* (guix-service #:optional (config %default-guix-configuration))
(service (type guix-service-type)
 (parameters config)))

There can be several services of a given type.  However, there must be
only one service of a type that can be extended–for instance, there can
be only one service of type ‘dmd-root-service-type’ or
‘etc-service-type’.

The ‘fold-services’ procedure is passed a list of services, propagates
extensions, and returns the root service (typically ‘%boot-service’)
with its ‘parameters’ field changed accordingly.

I’m quite happy with the result, but comments are welcome!  I’ll convert
some more services to see how it goes.

Ludo’.

Re: [PATCH] emacs: Improve 'guix-prettify-regexp'.

[Ludovic Courtès]

Alex Kost  skribis:

> Hello, along with:
>
>   /gnu/store/…-foo-0.1
>
> we have:
>
>   http://hydra.gnu.org/nar/…-foo-0.1
>   http://hydra.gnu.org/log/…-foo-0.1
>
> I think it would be good to "prettify" such things as well, so what
> about the attached patch?

Makes sense.

> From 5914f7007d1b27c0fa8594df4c1cff5fdd35e359 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Sat, 19 Sep 2015 13:55:59 +0300
> Subject: [PATCH] emacs: Improve 'guix-prettify-regexp'.
>
> * emacs/guix-prettify.el (guix-prettify-regexp): Modify to handle "nar"
>   and "log".

[...]

>  (defcustom guix-prettify-regexp
> -  (rx "/"
> -  (or "nix" "gnu")
> -  "/store/"
> +  (rx "/" (or "store" "nar" "log") "/"

Maybe explicitly show in a comment the URLs and file names that we
intend to match.

Otherwise LGTM, thanks!

Ludo’.

Re: [PATCH] Fix OpenAL backends.

[Thompson, David]

On Sun, Sep 20, 2015 at 7:15 AM, Ricardo Wurmus  wrote:
> Hi Guix,
>
> as I tested my new “mars” package I noticed that there was no sound.
> Investigating a little showed that the problem is in our “openal”
> package, which loads backend libraries by name only, not by path.
>
> The attached patch fixes this by patching in the full paths for
> libasound and libpulse, so now I have sound in “mars” :)

Awesome!  This fixed sound in Minetest, too.  Thanks!

- Dave

Re: [PATCH] Fix OpenAL backends.

[Ricardo Wurmus]

Andreas Enge  writes:

> This looks good to me!

Thanks for the review.  Pushed to master.

~~ Ricardo

Version strings for VCS snapshots

[Ludovic Courtès]

Eric Bavier  skribis:

> I realize we have no guidelines in the manual concerning the version
> field for git checkouts, but I wonder whether we should, as it comes up
> a bit.  Several existing packages use (string-append "1.2.3." commit),
> where "1.2.3" is the version of the corresponding source.  One other
> package uses the (string-append "1.2.3-c" commit) method, and another
> uses (string-append "1.2.3-" commit.  I personally prefer the "-"
> notation, since it distinguishes the commit hash from the version
> number (does it confuse any internal logic that assumes a package
> version number is the last component of the store path following a
> dash?).  In this case, the "-c" seems confusing because the commit hash
> itself begins with a 'c'.
>
> I recall some discussion previously about how it would be nice for
> git-checkout package versions to still "sort" nicely.

I think the goal should be to ensure lexicographic ordering, such that
‘guix package --upgrade’ DTRT.

In practice, that means the (string-append "1.2.3." commit) should be
avoided.

Instead we should use (string-append "1.2.3." REV "." commit) where REV
would be an integer we manually increment every time we upgrade to a
newer snapshot.

I don’t think adding “-” or “-c” before the commit is useful, but I
don’t have a strong opinion.

WDYT?

Ludo’.

Re: [PATCH] gnu: Add r-qtl.

[Pjotr Prins]

Well, if he cares, only the better, right? And, actually, I am also
listed as a co-author of this particular software. And I care ;). So
it is a bit more confused than that.

Pj.

On Sun, Sep 20, 2015 at 06:52:19PM +0200, Ludovic Courtès wrote:
> Pjotr Prins  skribis:
> 
> > I checked with the author and he is fine with your version. 
> 
> I think upstream authors shouldn’t be bothered with our own choices of
> synopses/descriptions; we have our own context, our own guidelines
> etc. that they probably don’t care about.  ;-)
> 
> Ludo’.
> 

-- 

Re: [PATCH] Add Shotwell.

[Ricardo Wurmus]

宋文武  writes:
>> * gnu/packages/photo.scm (libraw): New variable.
>> * gnu/packages/gnome.scm (libgee): New variable.
>> * gnu/packages/gnome.scm (gexiv2): New variable.
>> * gnu/packages/gnome.scm (shotwell): New variable.

I pushed those four with the suggested changes (except for adding “vala”
to the native-inputs of libgee).

Thank you!

~~ Ricardo

Re: [PATCH] Full encryption

[Petter]

Happy to help! :)

I've removed the custom initrd and define %linux-modules from my config,
and done:
sudo -i guix pull
sudo -i guix system reconfigure /etc/config.scm

Then rebooted. All ok!

Petter

Re: [PATCH] gnu: Add file-roller.

[Ludovic Courtès]

David Thompson  skribis:

> +(description "File Roller is an archive manager for the GNOME desktop
> +environment.")

In addition to Ricardo’s comment, could you expound on this a little
bit?  I’m not completely sure what it means to manage archives.  :-)

Ludo’.

Re: IBus and different GTK versions

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> 宋文武  writes:
>
 We can set 'GTK_EXE_PREFIX' to the '~/.guix-profile', and generate the
 'immodules.cache' files in a profile hook.  It will work for both gtk2
 and gtk3 applications.
>
>>> Does this mean that GTK needs to be installed in the user’s profile for
>>> this to work?  I thought ‘GTK_EXE_PREFIX’ would change the path of
>>> ‘$libdir’ for *all* of GTK’s libraries.  It can only have one value, not
>>> a list of paths to look for libraries.
>
>> Yes, this require install GTK+ into user's profile.
>> Also, there is a 'GTK_DATA_PREFIX' in a same situation, which I think is
>> the only way to set the GTK+ 2 theme.
>
> Isn’t this a little too high a price to pay?  One can only install one
> (major) version of GTK+ into a profile, so when we begin propagating the
> GTK inputs users will run into conflicts.
>
> I would really like to avoid propagating GTK+ (although it may be a bad
> idea to have software depend on different minor versions of GTK+).  It
> would be very nice if only additional modules—such as explicitly
> installed themes and input method modules—would have to be installed to
> the profile.  Those who do not need themes or input methods would not
> need to be bothered with this at all.

I guess the question is: what would be the uglier fix?  Do we prefer to
force users to have GTK+ installed in their profiles, or are we okay
with patching the GTK+ sources such that additional environment
variables would be respected, allowing users to specify different
module directories for version 2 and version 3?

~~ Ricardo

Re: IBus and different GTK versions

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> Ricardo Wurmus  writes:
>
>> 宋文武  writes:
>>
> We can set 'GTK_EXE_PREFIX' to the '~/.guix-profile', and generate the
> 'immodules.cache' files in a profile hook.  It will work for both gtk2
> and gtk3 applications.
>>
 Does this mean that GTK needs to be installed in the user’s profile for
 this to work?  I thought ‘GTK_EXE_PREFIX’ would change the path of
 ‘$libdir’ for *all* of GTK’s libraries.  It can only have one value, not
 a list of paths to look for libraries.
>>
>>> Yes, this require install GTK+ into user's profile.
>>> Also, there is a 'GTK_DATA_PREFIX' in a same situation, which I think is
>>> the only way to set the GTK+ 2 theme.
>>
>> Isn’t this a little too high a price to pay?  One can only install one
>> (major) version of GTK+ into a profile, so when we begin propagating the
>> GTK inputs users will run into conflicts.
>>
>> I would really like to avoid propagating GTK+ (although it may be a bad
>> idea to have software depend on different minor versions of GTK+).  It
>> would be very nice if only additional modules—such as explicitly
>> installed themes and input method modules—would have to be installed to
>> the profile.  Those who do not need themes or input methods would not
>> need to be bothered with this at all.
>
> I guess the question is: what would be the uglier fix?  Do we prefer to
> force users to have GTK+ installed in their profiles, or are we okay
> with patching the GTK+ sources such that additional environment
> variables would be respected, allowing users to specify different
> module directories for version 2 and version 3?

Looking at the GTK sources it occurred to me that there may be yet
another way we could fix this.  GTK3 no longer searches for modules in
~/.gtk-3.0 but GTK2 still looks in ~/.gtk-2.0 by default.  Symlinking
‘~/.guix-profile/lib/gtk-2.0’ to ‘~/.gtk-2.0’ might be sufficient for
GTK2 applications.

For GTK3 we could use the attached (untested) patch, which makes GTK3
look for additional modules in the path specified by the optional
environment variable “GTK3_PATH”.  This way we could point “GTK3_PATH”
at ‘~/.guix-profile/lib/gtk-3.0’, ensuring that only GTK3 applications
load the GTK3 modules and GTK2 don’t crash.

If we wanted symmetry we could patch GTK2 in a similar manner, making it
respect a “GTK2_PATH” variable instead.

What do you think?

~~ Ricardo

This patch makes GTK+ look for additional modules in a list of directories
specified by the environment variable "GTK3_PATH".  This can be used instead
of "GTK_PATH" to make GTK+ find modules that are incompatible with other major
versions of GTK+.

--- a/gtk/gtkmodules.c	2015-09-20 20:09:05.060590217 +0200
+++ b/gtk/gtkmodules.c	2015-09-20 20:10:33.423124833 +0200
@@ -52,6 +52,7 @@
 get_module_path (void)
 {
   const gchar *module_path_env;
+  const gchar *module_gtk3_path_env;
   const gchar *exe_prefix;
   gchar *module_path;
   gchar *default_dir;
@@ -61,6 +62,7 @@
 return result;
 
   module_path_env = g_getenv ("GTK_PATH");
+  module_gtk3_path_env = g_getenv ("GTK3_PATH");
   exe_prefix = g_getenv ("GTK_EXE_PREFIX");
 
   if (exe_prefix)
@@ -68,7 +70,13 @@
   else
 default_dir = g_build_filename (_gtk_get_libdir (), "gtk-3.0", NULL);
 
-  if (module_path_env)
+  if (module_gtk3_path_env && module_path_env)
+module_path = g_build_path (G_SEARCHPATH_SEPARATOR_S,
+module_gtk3_path_env, module_path_env, default_dir, NULL);
+  else if (module_gtk3_path_env)
+module_path = g_build_path (G_SEARCHPATH_SEPARATOR_S,
+module_gtk3_path_env, default_dir, NULL);
+  else if (module_path_env)
 module_path = g_build_path (G_SEARCHPATH_SEPARATOR_S,
 module_path_env, default_dir, NULL);
   else

(Not GuixSD) Purpose of ~/.config/guix/ & config. files

[Vicente Vera]

Hello.

After running 'guix pull' (as root) with a fresh binary installation
directory ~root/.config/guix/ was created, which contains a "latest"
symlink pointing to /gnu/store/...-guix-latest/.

Since I work as a regular user, I noticed that Guix wasn't picking up
changes from the updated distribution. Creating a ~luser/.config/guix/
directory with the same "latest" symlink solved the problem. Now after
every 'guix pull' I have to manually update the symlink.

I was wondering if the ~/.config/guix/ directory is used for something
else apart from the case described above.

On another note, what's the appropiate, Guix-y way of storing
configuration files such as dotfiles, etc. (to be read by Guix
installed programs) when using Guix atop another GNU/Linux distro?

Re: [PATCH] Full encryption

[Ludovic Courtès]

Petter  skribis:

> To run a fully encrypted GuixSD, Mark and Ludo dictated the following changes 
> for me. And i'm now only using one partition (which includes root and boot).

Thank you & Mark for testing and debugging this!

Commit cc0e575 and 07779d0 incorporate your suggestions.  Let me know if
everything is still fine after ‘guix system reconfigure’ (and you can
now remove the custom initrd from your OS config.)

Ludo’.

[PATCH] Add Blender.

[Ricardo Wurmus]

>From d1d46f01d7aad783f7931be1ea4bbdffb21fd9b7 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Sat, 5 Sep 2015 12:34:09 +0200
Subject: [PATCH 1/2] gnu: Add openimageio.

* gnu/packages/graphics.scm (openimageio): New variable.
---
 gnu/packages/graphics.scm | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/gnu/packages/graphics.scm b/gnu/packages/graphics.scm
index 14badc9..d9d1f26 100644
--- a/gnu/packages/graphics.scm
+++ b/gnu/packages/graphics.scm
@@ -130,6 +130,44 @@ use in computer imaging applications.  The IlmImf C++ libraries support
 storage of the \"EXR\" file format for storing 16-bit floating-point images.")
 (license license:bsd-3)))
 
+(define-public openimageio
+  (package
+(name "openimageio")
+(version "1.5.18")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://github.com/OpenImageIO/oiio/;
+  "archive/Release-" version ".tar.gz"))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"0mn7cz19mn8dcrhkq15h25gl20ammr1wz0j2j3c2vxs6ph7zn8jy"
+(build-system cmake-build-system)
+;; FIXME: To run all tests successfully, test image sets from multiple
+;; third party sources have to be present.  For details see
+;; https://github.com/OpenImageIO/oiio/blob/master/INSTALL
+(arguments `(#:tests? #f))
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(inputs
+ `(("boost" ,boost)
+   ("libpng" ,libpng)
+   ("libjpeg" ,libjpeg-8)
+   ("libtiff" ,libtiff)
+   ("giflib" ,giflib)
+   ("openexr" ,openexr)
+   ("ilmbase" ,ilmbase)
+   ("python" ,python-2)
+   ("zlib" ,zlib)))
+(synopsis "C++ library for reading and writing images")
+(description
+  "OpenImageIO is a library for reading and writing images, and a bunch of
+related classes, utilities, and applications.  There is a particular emphasis
+on formats and functionality used in professional, large-scale animation and
+visual effects work for film.")
+(home-page "http://www.openimageio.org;)
+(license license:bsd-3)))
+
 (define-public ctl
   (package
 (name "ctl")
-- 
2.5.0

>From 6e9eba597d5588f845ccec6507ad1b7e987ba659 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Thu, 3 Sep 2015 14:17:34 +0200
Subject: [PATCH 2/2] gnu: Add Blender.

* gnu/packages/graphics.scm (blender): New variable.
---
 gnu/packages/graphics.scm | 67 +++
 1 file changed, 67 insertions(+)

diff --git a/gnu/packages/graphics.scm b/gnu/packages/graphics.scm
index d9d1f26..573c7e8 100644
--- a/gnu/packages/graphics.scm
+++ b/gnu/packages/graphics.scm
@@ -25,8 +25,10 @@
   #:use-module (guix build-system cmake)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (gnu packages)
+  #:use-module (gnu packages audio)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages bash)
+  ;;TODO this is imported twice
   #:use-module (gnu packages boost)
   #:use-module (gnu packages fontutils)
   #:use-module (gnu packages pkg-config)
@@ -34,10 +36,75 @@
   #:use-module (gnu packages multiprecision)
   #:use-module (gnu packages boost)
   #:use-module (gnu packages gl)
+  #:use-module (gnu packages image)
+  #:use-module (gnu packages jemalloc)
+  #:use-module (gnu packages photo)
+  #:use-module (gnu packages python)
   #:use-module (gnu packages qt)
   #:use-module (gnu packages sdl)
   #:use-module (gnu packages xorg))
 
+(define-public blender
+  (package
+(name "blender")
+(version "2.75a")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://download.blender.org/source/;
+  "blender-" version ".tar.gz"))
+  (sha256
+   (base32
+"09lxb2li70p6fg7hbakin9ffy3b3101c1gdjqi3pykks5q3h9sq4"
+(build-system cmake-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'disable-broken-tests
+  (lambda _
+(substitute* "tests/python/CMakeLists.txt"
+  (("# PLY Import tests") "if(FALSE)")
+  (("# PLY Export")   "endif()"))
+#t))
+ (add-after 'unpack 'fix-broken-import
+  (lambda _
+(substitute* "release/scripts/addons/io_scene_fbx/json2fbx.py"
+  (("import encode_bin") "from . import encode_bin"))
+#t))
+ (add-after 'set-paths 'add-ilmbase-include-path
+  (lambda* (#:key inputs #:allow-other-keys)
+;; OpenEXR propagates ilmbase, but its include files do not appear
+;; in the CPATH, so we need to add "$ilmbase/include/OpenEXR/" to
+;; the CPATH to satisfy the dependency on "half.h".
+(setenv "CPATH"
+