Re: Tkinter moved to separate output

[Federico Beffa]

On Sun, Nov 29, 2015 at 11:09 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>
>> On Mon, Nov 16, 2015 at 1:57 PM, Ludovic Courtès  wrote:
>>> Federico Beffa  skribis:
 Yes, given that the back-end currently used by matploblib doesn't
 work, I would change that by using 'Tkinter'.

 Since you are at it, I would also change the default back-end by
 changing 'GTK3Agg' to 'TkAgg' in the following snippet:

 (lambda (port)
   (format port "[rc_options]~%
 backend = GTK3Agg~%")
>>>
>>> OTOH I see that Matploblib already depends on GTK+ 3.x and
>>> python-pygobject, so maybe it’s best to stick to GTK+ by default?
>>
>> Unfortunately, the back-ends based on GTK+ are broken and I didn't
>> manage to find how to fix the problem.
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20888
>>
>> That's why I'm looking forward to get Tkinter :-)
>
> Could you or someone else test this patch on current master?

It does not work. It can't find the tcl/tk header files:

...
 tkagg: no  [The C/C++ header for Tk (tk.h) could not be
found.  You may need to install the development
package.]
...

With the attached patch it does find the headers, but then it fails at
link time.

...
g++ -pthread -shared
-Wl,-rpath=/gnu/store/cxrqlhbr6xqgi08x3amd0lvl6m7sxx57-python-3.4.3/lib
build/temp.linux-x86_64-3.4/src/agg_py_transforms.o
build/temp.linux-x86_64-3.4/src/_tkagg.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_bezier_arc.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_curves.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_image_filters.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_trans_affine.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_vcgen_contour.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_vcgen_dash.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_vcgen_stroke.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_vpgen_segmentator.o
build/temp.linux-x86_64-3.4/extern/CXX/IndirectPythonInterface.o
build/temp.linux-x86_64-3.4/extern/CXX/cxxsupport.o
build/temp.linux-x86_64-3.4/extern/CXX/cxx_extensions.o
build/temp.linux-x86_64-3.4/extern/CXX/cxxextensions.o
-L/gnu/store/ipsq9hlk6k0w1qfiw0y0a03bxkp2clhl-tcl-8.6.4/lib
-L/gnu/store/my9wgryzpfvksng6k7h87xz9rphdwddw-tk-8.6.4/lib
-L/usr/local/lib -L/usr/local/lib
-L/gnu/store/cxrqlhbr6xqgi08x3amd0lvl6m7sxx57-python-3.4.3/lib -ltcl
-ltk -lstdc++ -lm -lpython3.4m -o
build/lib.linux-x86_64-3.4/matplotlib/backends/_tkagg.cpython-34m.so
ld: cannot find -ltcl
ld: cannot find -ltk
collect2: error: ld returned 1 exit status
error: command 'g++' failed with exit status 1
phase `build' failed after 94.8 seconds
...

Looking into the failed build directory, it seems that PKG_CONFIG_PATH
is set correctly. Still, it doesn't get the correct flags.

Regards,
Fede
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 39d0751..4dfe557 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -3190,6 +3190,7 @@ transcendental functions).")
  `(("python-pyparsing" ,python-pyparsing)
("python-pygobject" ,python-pygobject)
("gobject-introspection" ,gobject-introspection)
+   ("python-tkinter" ,python "tk")
;; The 'gtk+' package (and 'gdk-pixbuf', 'atk' and 'pango' propagated
;; from 'gtk+') provides the required 'typelib' files used by
;; 'gobject-introspection'. The location of these files is set with the
@@ -3224,7 +3225,8 @@ transcendental functions).")
;; FIXME: Add backends when available.
;("python-wxpython" ,python-wxpython)
;("python-pyqt" ,python-pyqt)
-   ))
+   ("tcl" ,tcl)
+   ("tk" ,tk)))
 (native-inputs
  `(("pkg-config" ,pkg-config)
("texlive" ,texlive)
@@ -3243,8 +3245,13 @@ transcendental functions).")
 (setenv "HOME" (getcwd))
 (call-with-output-file "setup.cfg"
   (lambda (port)
-(format port "[rc_options]~%
-backend = GTK3Agg~%")
+(format port "[directories]~%
+basedirlist = ~a,~a~%
+~%
+[rc_options]~%
+backend = TkAgg~%"
+(assoc-ref inputs "tcl")
+(assoc-ref inputs "tk"))
 (alist-cons-after
  'install 'install-doc
  (lambda* (#:key outputs #:allow-other-keys)

Re: search-paths and propagated inputs

[Federico Beffa]

Federico Beffa  writes:

> Hi,
>
> the package 'gobject-introspection' declares a
> search-path-specification for the variable GI_TYPELIB_PATH and
> 'matplotlib' uses and propagates said package. I have 'matplotlib' in
> my profile, but "guix package --search-paths" doesn't show anything
> about GI_TYPELIB_PATH.
>
> Is it intentional or an oversight that search-path-specifications of
> propagated-inputs are not considered? Or, am I doing something wrong?
>
> Regards,
> Fede

Bug or feature?

Regards,
Fede

Re: Missing native-search-path for texlive

[Alex Vong]

> I can propose a patch later.
>
Thanks for your help!

> Andreas
>
>

Re: search-paths and propagated inputs

[Ricardo Wurmus]

Federico Beffa  writes:

> Federico Beffa  writes:
>
>> Hi,
>>
>> the package 'gobject-introspection' declares a
>> search-path-specification for the variable GI_TYPELIB_PATH and
>> 'matplotlib' uses and propagates said package. I have 'matplotlib' in
>> my profile, but "guix package --search-paths" doesn't show anything
>> about GI_TYPELIB_PATH.
>>
>> Is it intentional or an oversight that search-path-specifications of
>> propagated-inputs are not considered? Or, am I doing something wrong?
>>
>> Regards,
>> Fede
>
> Bug or feature?

I think it’s a bug.  Right now users of matplotlib have to check the
sources where it says that GI_TYPELIB_PATH must be set.

~~ Ricardo

Re: Lint on line

[Andreas Enge]

On Mon, Nov 23, 2015 at 12:11:13AM +0100, Ludovic Courtès wrote:
> Here’s a new tool!
>   https://www.gnu.org/software/guix/packages/issues.html

Very interesting! How about omitting all the packages with "Nothing to
declare!" from the web page?

Andreas

Re: [PATCH] Add cereal + sparsehash

[Andreas Enge]

Hello,

sorry for being late, I am still catching up.

On Thu, Nov 26, 2015 at 01:53:25PM +0100, Ricardo Wurmus wrote:
> The second patch adds “sparsehash” to the “crypto” module.  It’s
> probably not the best module for this package — can you suggest any
> other location for a hash table library?

If it is not a cryptographically secure hash, it should go anywhere, but
not to the cryptography module. Both are called by the same name in English,
but are completely different things. Could you move it somewhere else?

Andreas

Re: Python updates

[Ricardo Wurmus]

> gnu/packages/python.scm:4221:4: python2-ipython would be upgraded from 3.2.1 
> to 4.0.1

I’m working on this but there are still many problems with IPython.
I’ll try to polish and submit the patches tomorrow.

~~ Ricardo

Re: [PATCH]: Five R packages.

[Andreas Enge]

On Thu, Nov 26, 2015 at 04:46:40PM -0500, Kyle Meyer wrote:
> > * gnu/packages/statistics.scm (r-data-table): New variable.
> It seems data.table was already packaged under a different name in
> 0e4e03f (2015-09-26).

Normally we replace non-alphanumeric characters by "-". So the new name
would be the correct one. If you could modify the package, that would
be nice.

Andreas

Re: Python updates

[Federico Beffa]

Ricardo Wurmus  writes:

>> gnu/packages/python.scm:4221:4: python2-ipython would be upgraded from 3.2.1 
>> to 4.0.1
>
> I’m working on this but there are still many problems with IPython.
> I’ll try to polish and submit the patches tomorrow.

Upgrading 'ipython' to version 4.0 will break 'emacs-ob-ipython'. If you
upgrade the former, could you please also take care of the latter.

We should be careful to check that we don't break dependencies by upgrades...

Thanks,
Fede

[PATCH] gnu: Add myrepos.

[Kyle Meyer]

* gnu/packages/version-control.scm (myrepos): New variable.
---
 gnu/packages/version-control.scm | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index b132663..d7c4f8c 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2014, 2015 Mark H Weaver 
 ;;; Copyright © 2014 Eric Bavier 
 ;;; Copyright © 2015 Efraim Flashner 
+;;; Copyright © 2015 Kyle Meyer 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -925,3 +926,32 @@ any project with more than one developer, is one of 
Aegis's major functions.")
 a history browser.  It can also stage hunks for commit, or colorize the
 output of the 'git' command.")
 (license gpl2+)))
+
+(define-public myrepos
+  (package
+(name "myrepos")
+(version "1.20151022")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://github.com/joeyh/myrepos/archive/;
+ version ".tar.gz"))
+   (sha256
+(base32 "0c93lqsngpsxsca7nygk4qhidr40ijgih86q81x1mfcwbs0gbds8"
+(build-system gnu-build-system)
+(inputs
+ `(("perl" ,perl)))
+(arguments
+ `(#:test-target "test"
+   #:phases (alist-delete 'configure %standard-phases)
+   #:make-flags (list (string-append "DESTDIR=" (assoc-ref %outputs "out"))
+  "PREFIX=")))
+(home-page "http://myrepos.branchable.com/;)
+(synopsis "Multiple repository management tool")
+(description
+ "Myrepos provides the @code{mr} command, which maps an operation (e.g.,
+fetching updates) over a collection of version control repositories.  It
+supports a large number of version control systems: git, svn, mercurial, bzr,
+darcs, cvs, fossil and veracity.")
+(license gpl2+)))
-- 
2.6.2

Re: [PATCH] A couple of Ruby gems.

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> here are some more Ruby gems.  I still have about a dozen or so that
>> follow these.
>
> I skimmed over the patch set and didn’t see anything fishy.  I guess you
> can go ahead and push them.

Thank you.  I’ll push them in a moment.

~~ Ricardo

Re: [PATCH] Add cereal + sparsehash

[Ricardo Wurmus]

Ludovic Courtès  writes:

>> From 19a28042f3839ea23aa13f4973172ca46cfde5f0 Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus 
>> Date: Mon, 9 Nov 2015 14:46:56 +0100
>> Subject: [PATCH 1/2] gnu: Add cereal.
>>
>> * gnu/packages/serialization.scm: New file.
>> * gnu-system.am (GNU_SYSTEM_MODULES): Add it.
>
> [...]
>
>> + (replace 'install
>> +  (lambda* (#:key outputs #:allow-other-keys)
>> +(let* ((out (assoc-ref outputs "out"))
>> +   (doc (string-append out "/share/cereal/docs"))
>> +   (include (string-append out "/include/cereal")))
>> +  (mkdir-p doc)
>> +  (mkdir-p include)
>> +  (copy-recursively "include/cereal" include)
>> +  (copy-recursively "doc/html" doc))
>
> Maybe add a comment about why “make install” isn’t enough.

Okay.  I added a comment explaining that there is no “install” target.

> Otherwise LGTM.
>
>> From 1f8739407dd3f9715005d55befabf894fa98ee10 Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus 
>> Date: Tue, 10 Nov 2015 15:41:04 +0100
>> Subject: [PATCH 2/2] gnu: Add sparsehash.
>>
>> * gnu/packages/crypto.scm (sparsehash): New variable.
>
> LGTM.

Thank you.  I’ll push both in a moment.

~~ Ricardo

Re: [PATCH] openssh: install ssh-copy-id.

[Ricardo Wurmus]

Ludovic Courtès  writes:

>> From baf260ebda0a70ec3c7d6f35e1c1bb64a37f0aac Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus 
>> Date: Fri, 27 Nov 2015 11:35:50 +0100
>> Subject: [PATCH 2/2] gnu: openssh: Install ssh-copy-id.
>>
>> * gnu/packages/ssh.scm (openssh)[arguments]: Install "ssh-copy-id" and
>>   documentation.
>
> Please add “Fixes” and “Reported by” lines.

Done.  I have pushed both commits.

> Could you check whether that increases the size of the closure?  That
> would be the case if ‘ssh-copy-id’ is a Perl script for instance.

This is before the patch:

  store item   totalself
  /gnu/store/xlgw7bx4payq017zcjyrs68hwixybkn0-openssh-7.0p1   77.3 
3.9   5.1%
  /gnu/store/zmqhwsl9vvxr4ihdnhwwpc3dpgmpsgsy-openssl-1.0.2d  73.0
12.3  15.9%
  /gnu/store/54wpn20cik292k5hl4nxsivv614xl8c2-zlib-1.2.7  61.1 
0.3   0.5%
  /gnu/store/zy233badri3sffqi2s2kq8md6qz65iiz-gcc-4.9.3-lib   60.7
22.9  29.6%
  /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22  37.9
36.5  47.2%
  /gnu/store/7jhakv1r1nbs2sr2f7ammq256w7niarh-bash-static-4.3.39   1.4 
1.4   1.8%

and this is after:

  $ guix size /gnu/store/65rd6p154y13dqcbkbimnwjq39k8dnym-openssh-7.0p1
  store item   totalself
  /gnu/store/65rd6p154y13dqcbkbimnwjq39k8dnym-openssh-7.0p1   91.5 
3.9   4.3%
  /gnu/store/zmqhwsl9vvxr4ihdnhwwpc3dpgmpsgsy-openssl-1.0.2d  73.0
12.3  13.4%
  /gnu/store/54wpn20cik292k5hl4nxsivv614xl8c2-zlib-1.2.7  61.1 
0.3   0.4%
  /gnu/store/zy233badri3sffqi2s2kq8md6qz65iiz-gcc-4.9.3-lib   60.7
22.9  25.0%
  /gnu/store/311nvir0pz1mhf0mgsmfrw00qfj7yq0j-bash-4.3.39 52.0 
6.3   6.9%
  /gnu/store/92f66z198h876byrjwwbgzv9rfsdm048-readline-6.345.7 
1.2   1.3%
  /gnu/store/5ljf8bnl2z5ykrrcs8352b9lh8j6139h-ncurses-6.0 44.5 
6.6   7.3%
  /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22  37.9
36.5  39.9%
  /gnu/store/7jhakv1r1nbs2sr2f7ammq256w7niarh-bash-static-4.3.39   1.4 
1.4   1.5%

There are new references to bash, readline, and ncurses.  It’s a bash
script, so a new reference to bash is expected.  I wonder why it also
retains references to readline and ncurses, though.

~~ Ricardo

Re: Adding operating-system field for a custom /etc/profile.

[Alex Kost]

Ludovic Courtès (2015-11-24 23:30 +0300) wrote:

> Alex Kost  skribis:
[...]
>> But still I prefer to have a straightforward way to set my own
>> /etc/profile.  Or maybe it would be good to have even a more general
>> solution: a way to specify any file that goes to "/etc" dir, something
>> like this:
>>
>> (operating-system
>>   ;; ...
>>   (etc-files
>>("hosts"   (local-file "/home/me/guix/etc/hosts"))
>>("profile" (local-file "/home/me/guix/bash/my-favourite-etc-profile"))
>>("fstab"   (local-file "/home/me/guix/etc/fstab"
>
> Please take a look at ‘etc-service’.  It’s essentially what you describe.

Yes I know, I mean this is what I would like to have, but it can't be
used right now.  As ‘operating-system-etc-service’ is a part of
‘essential-services’, it cannot be modified/replaced, right?  I see that
now operating-system services are split into 'essential-services' and
'user-services'.  What about letting a user change any service instead?
I mean to make %essential-services and make it a part of %base-services.
(I didn't look in the details though, so I don't know if it's possible.)

>> Sorry, but this is not what I want.  I would like to have a full control
>> on any aspect of my system.
>
> I think you’re overreacting.  I feel bad because in spite of several
> attempts, I’m failing to get us to focus on concrete proposal to move
> forward.  I don’t know what to add.

I'm sorry for being so emotional; that's because I don't want to return
to "Arch Linux"!  I love GuixSD, but this is a potential blocker for me.
I just tried to explain that users may want to change/replace any
/etc/, but they can't do it (this is essential for me, as I have a
sick wish to control everything).

Sorry, but your proposal is only a solution for this particular
--search-paths thing.  There are (and will be) other places in /etc
files that are not covered by 'operating-system' fields.  Ideally I
would like to have a possibility to override /etc/ if
'operating-system' does not allow me to change it the way I want.

-- 
Alex

Re: Customizing /etc

[Alex Kost]

Ludovic Courtès (2015-11-27 17:58 +0300) wrote:

> Alex Kost  skribis:
[...]
>> I like the idea of separating /etc/environment and /etc/profile, but my
>> main concern is to have a possibility to change /etc files the way I
>> want, as I explained in the reply to Ludovic.
>
> I agree that specifying what goes into /etc is something we want to
> allow (though not directly related to the /etc/profile issue.)

Oof, that's a relief for me!  I had an impression that you are against
giving a user a full control over /etc files.

> What about exposing the name/file-like pairs that are passed to
> ‘etc-service’?  That way, one could write:
>
>   (define os
> (operating-system
>   ;; …
>   (etc-files `(("hosts" ,(local-file "my-hosts-file"))
>("issue" ,(plain-file "Hello!\n"))
>("sudoers" ,(local-file "sudoers"))
>("profile" ,(local-file "myprofile"))
>,@(fold alist-delete
>(default-etc-files os)
>'("hosts" "issue" "sudoers" "profile"))

Yes, changing /etc files is exactly what I want!

> We may remove the ‘hosts-file’ and ‘sudoers-file’ fields, but keep
> higher-level things like ‘name-service-switch’ because they’re more
> convenient.

Yes, I agree; if this will be accepted, keeping '-file' fields (for
hosts, sudoers and future files) is probably not needed.

> The difficulty is that some of the default files, such as /etc/hosts,
> are generated as a function of the ‘operating-system’ declaration.  Thus
> I think we need ‘default-etc-files’ to be a procedure as shown above,
> and the ‘etc-files’ field must be thunked or delayed.  Hmm not fully
> sure this is the right interface.
>
> WDYT?

Yes, this will probably not be an easy-to-use interface, but to have it
is better than to have nothing.  So I am totally for it!

> The bottom line is that /etc is not a great configuration interface
> because it’s all flat and GuixSD has no idea of the meaning of those
> files and their relationship.  So the preferred approach remains
> configuration via services and high-level configuration objects.

Yes, I agree; but if a user is not satisfied by the result of these
high-level services, I think (s)he should have a fallback way to
change/override the resulting /etc file.

-- 
Alex

Re: Adding operating-system field for a custom /etc/profile.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-11-24 23:30 +0300) wrote:
>
>> Alex Kost  skribis:
> [...]
>>> But still I prefer to have a straightforward way to set my own
>>> /etc/profile.  Or maybe it would be good to have even a more general
>>> solution: a way to specify any file that goes to "/etc" dir, something
>>> like this:
>>>
>>> (operating-system
>>>   ;; ...
>>>   (etc-files
>>>("hosts"   (local-file "/home/me/guix/etc/hosts"))
>>>("profile" (local-file "/home/me/guix/bash/my-favourite-etc-profile"))
>>>("fstab"   (local-file "/home/me/guix/etc/fstab"
>>
>> Please take a look at ‘etc-service’.  It’s essentially what you describe.
>
> Yes I know, I mean this is what I would like to have, but it can't be
> used right now.  As ‘operating-system-etc-service’ is a part of
> ‘essential-services’, it cannot be modified/replaced, right?  I see that
> now operating-system services are split into 'essential-services' and
> 'user-services'.  What about letting a user change any service instead?
> I mean to make %essential-services and make it a part of %base-services.
> (I didn't look in the details though, so I don't know if it's possible.)

Yeah it’s not that simple, because  objects
essentially get compiled down to a list of ; some of them are
added as a function of what the  object contains.

But see my other proposal about “Customizing /etc.”

>>> Sorry, but this is not what I want.  I would like to have a full control
>>> on any aspect of my system.
>>
>> I think you’re overreacting.  I feel bad because in spite of several
>> attempts, I’m failing to get us to focus on concrete proposal to move
>> forward.  I don’t know what to add.
>
> I'm sorry for being so emotional; that's because I don't want to return
> to "Arch Linux"!  I love GuixSD, but this is a potential blocker for me.
> I just tried to explain that users may want to change/replace any
> /etc/, but they can't do it (this is essential for me, as I have a
> sick wish to control everything).

Understood!

Please bear with me/us.  This is an iterative process.  Think of what
GuixSD was like 6 months ago.  ;-)  Initially, many things had to be more
or less hardcoded to allow us to get something running, in turn making
it possible to do more development and to refine things.

You’re pointing at limitations that have always been there and that need
to be addressed.  The mere fact that we can have heated discussions over
these features means we’ve already done a lot of progress technically.
:-)

And again, rest assured that there’s no fundamental disagreement between
us on the goals.  It’s just about finding the right approach to satisfy
all the (sometimes contradictory) needs.

Thank you,
Ludo’.

Re: Missing native-search-path for texlive

[Ludovic Courtès]

Alex Vong  skribis:

> Yesterday, I try to use compile some document with context, so I
> install texlive in guix. However, when I run "context --version", I
> get the following error:
>
> mtxrun  | unknown script 'context.lua' or 'mtx-context.lua'
>
> After doing some searching, I find out that the following works:
>
> $ TEXMF=`guix build texlive-texmf` context --version
>
> What should I add to native-search-path to set the TEXMF variable to
> the output path?

It ‘TEXMF’ really a search path, or is it rather a variable that should
point to a single directory?

If the issue is limited to the ‘context’ program, then we may be better
off wrapping ‘context’ such that ‘TEXMF’ is always set appropriately.

Thoughts?  Andreas?

Ludo’.

Re: [PATCH] build: pull: Compile .scm files in one process.

[Ludovic Courtès]

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> After some tinkering around I realized that the problem is that our
> workaround of loading files explicitly causes the package record type to
> be redefined after some packages have already been defined.  More
> generally, we force the top-level of many files to be re-executed after
> they've already been executed as a result of a module import...
>
> It would be great if the whole circular import problem could somehow be
> solved by Guile (no idea how feasible it is).  On the meanwhile, we'll
> have to work around problems introduced by workarounds. :-)

I think we’ve gone way too far in kludgeland.  ;-)

The other idea I had, and which is known to work, it to rely exclusively
on auto-compilation.  By definition, Guile’s auto-compilation mode will
compile things in the right order, thereby allowing us to compile
everything in one process.  Probably not parallelizable though, since
this is under Guile’s control, not ours.

Would you like to play with that?  Otherwise I can give it a try later.

Thank you,
Ludo’.

Re: Missing native-search-path for texlive

[Alex Vong]

On 30/11/2015, Ludovic Courtès  wrote:
> Alex Vong  skribis:
>
>> Yesterday, I try to use compile some document with context, so I
>> install texlive in guix. However, when I run "context --version", I
>> get the following error:
>>
>> mtxrun  | unknown script 'context.lua' or 'mtx-context.lua'
>>
>> After doing some searching, I find out that the following works:
>>
>> $ TEXMF=`guix build texlive-texmf` context --version
>>
>> What should I add to native-search-path to set the TEXMF variable to
>> the output path?
>
> It ‘TEXMF’ really a search path, or is it rather a variable that should
> point to a single directory?
>
I think it is a search path since both
`TEXMF=/gnu/store/gb4y83bvcpkvdmz0dvi9rp507kbdbr5x-texlive-texmf-2015
context --version` and
`TEXMF=/gnu/store/gb4y83bvcpkvdmz0dvi9rp507kbdbr5x-texlive-texmf-2015/share
context --version` works. But otherwise, I don't know how environment
variables in texlive works. I see there are other environmental
variables as well. For instance, TEXINPUTS, TEXMFLOCAL and TEXMFHOME.
But only TEXMF and TEXMFHOME works.

> If the issue is limited to the ‘context’ program, then we may be better
> off wrapping ‘context’ such that ‘TEXMF’ is always set appropriately.
>
> Thoughts?  Andreas?
>
> Ludo’.
>

Re: Missing native-search-path for texlive

[Andreas Enge]

On Mon, Nov 30, 2015 at 02:07:00PM +0100, Ludovic Courtès wrote:
> It ‘TEXMF’ really a search path, or is it rather a variable that should
> point to a single directory?

It is a variable that works like a search path, but with a special syntax:
/gnu/store/gb4y83bvcpkvdmz0dvi9rp507kbdbr5x-texlive-texmf-2015/share/texmf-dist/web2c/texmf.cnf
contains a line
TEXMF = 
{$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFDIST}

The context binary itself is the following shell script:
#!/gnu/store/ibpm6n6706yimzr3967krkxi2ibxq5yh-bash-4.3.39/bin/bash
export 
TEXMFCNF="/gnu/store/gb4y83bvcpkvdmz0dvi9rp507kbdbr5x-texlive-texmf-2015/share/texmf-dist/web2c"
exec -a "$0" 
"/gnu/store/i11ykp24wbgq2lfz7gcz2v0f5h3sg7dg-texlive-bin-2015/share/texmf-dist/scripts/context/stubs/unix/context"
 "$@"

The variable TEXMFCNF gives the directory where texmf.cnf is to be found;
this configuration file contains the definition of TEXMF (composed of the
other variables). So one would expect the wrapper to be already in place,
provided by texlive.

The call in the last line is to the following shell script:
#!/gnu/store/311nvir0pz1mhf0mgsmfrw00qfj7yq0j-bash-4.3.39/bin/sh
mtxrun --script context "$@"

"mtxrun" is the following shell script:
#!/gnu/store/ibpm6n6706yimzr3967krkxi2ibxq5yh-bash-4.3.39/bin/bash
export 
TEXMFCNF="/gnu/store/gb4y83bvcpkvdmz0dvi9rp507kbdbr5x-texlive-texmf-2015/share/texmf-dist/web2c"
exec -a "$0" 
"/gnu/store/i11ykp24wbgq2lfz7gcz2v0f5h3sg7dg-texlive-bin-2015/bin/mtxrun" "$@"

Again, this is a wrapper setting TEXMFCNF.
The mtxrun binary is a lua script.

The following lines in the script could be of interest:
resolvers.criticalvars=allocate { 
"SELFAUTOLOC","SELFAUTODIR","SELFAUTOPARENT","TEXMFCNF","TEXMF","TEXOS" }
resolvers.luacnfname="texmfcnf.lua"

I suppose that the normal behaviour will then be to look for the file
texmfcnf.lua in the directory given by TEXMFCNF, set by the wrapper scripts.
This file seems to be a lua script that is equivalent to texmf.cnf.
We modify texmf.cnf to point to the correct directories, using a single
substitute:
  (substitute* texmfcnf
(("TEXMFROOT = \\$SELFAUTOPARENT")
(string-append "TEXMFROOT = " share)))
which results in the line
TEXMFROOT = /gnu/store/gb4y83bvcpkvdmz0dvi9rp507kbdbr5x-texlive-texmf-2015/share
All further variables depend on TEXMFROOT.

So we should probably also modify texmfcnf.lua in a similar way.
Unfortunately, it contains a lot of selfautoparent and selfautodir;
we should replace them all at the same time.

I can propose a patch later.

Andreas