Re: [PATCH 1/4] guix: build/glib-or-gtk-build-system: Add support for GIO and XDG theming.

[宋文武]

Federico Beffa  writes:

> I added support for GIO and theming data according to the XDG specifications.
>
> https://developer.gnome.org/gio/stable/running-gio-apps.html
> http://www.freedesktop.org/wiki/Specifications/
>
> Regards,
> Fede
> From c726b525111ff2f8055f7f2be98b7a5e61a8a96e Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Thu, 18 Dec 2014 20:58:18 +0100
> Subject: [PATCH 1/4] guix: build/glib-or-gtk-build-system: Add support for GIO
>  and XDG theming.
>
> * guix/build/glib-or-gtk-build-system.scm (data-directories): Rename
>   'schemas-directories' to 'data-directories' and add support for XDG theming
>   data.
>
> * guix/build/glib-or-gtk-build-system.scm (gio-module-directories): New
>   function.
>
> * guix/build/glib-or-gtk-build-system.scm (wrap-all-programs): Update names to
>   reflect that we are dealing with more types of data and not only with
>   schemas.  Add handling of GIO modules.
>
> * guix/build-system/glib-or-gtk.scm (lower): Import the 'bin' output of GLib
>   instead of 'out'.  This was an error since we need the program
>   'glib-compile-schemas'.  Update the description.
> ---
>  guix/build-system/glib-or-gtk.scm   | 11 ++--
>  guix/build/glib-or-gtk-build-system.scm | 99 
> ++---
>  2 files changed, 84 insertions(+), 26 deletions(-)
>
> diff --git a/guix/build-system/glib-or-gtk.scm 
> b/guix/build-system/glib-or-gtk.scm
> index 8091311..ff95ca5 100644
> --- a/guix/build-system/glib-or-gtk.scm
> +++ b/guix/build-system/glib-or-gtk.scm
> @@ -38,11 +38,10 @@
>  ;;
>  ;; 'glib-or-gtk-wrap' phase:
>  ;;
> -;; a) This phase looks for GSettings schemas by verifying the existence of
> -;; path "datadir/glib-2.0/schemas" in all input packages.  If the path is
> -;; found in any package, then all programs in "out/bin" are wrapped in 
> scripts
> -;; where the environment variable "XDG_DATA_DIRS" is set and points to the
> -;; list of found schemas directories.
> +;; a) This phase looks for GSettings schemas, GIO modules and theming data.
> +;; If any of these is found in any input package, then all programs in
> +;; "out/bin" are wrapped in scripts defining the nedessary environment
> +;; variables.
>  ;;
>  ;; b) Looks for the existence of "libdir/gtk-3.0" directories in all input
>  ;; packages.  If any is found, then the environment variable "GTK_PATH" is
> @@ -95,7 +94,7 @@
>`(("source" ,source))
>'())
>  ,@inputs))
> - (build-inputs `(("glib:bin" ,glib)
> + (build-inputs `(("glib:bin" ,glib "bin")
>   ,@(if implicit-inputs?
> (standard-packages)
> '())
> diff --git a/guix/build/glib-or-gtk-build-system.scm 
> b/guix/build/glib-or-gtk-build-system.scm
> index 9351a70..712087e 100644
> --- a/guix/build/glib-or-gtk-build-system.scm
> +++ b/guix/build/glib-or-gtk-build-system.scm
> @@ -41,6 +41,9 @@
>(fold (lambda (s p) (or (string-ci=? s directory) p))
>  #f directories-list))
>  
> +;; We do not include $HOME/.guix-profile/gtk-v.0 (v=2 or 3) because we do not
> +;; want to mix gtk+-2 and gtk+-3 modules.  See
> +;; https://developer.gnome.org/gtk3/stable/gtk-running.html
>  (define (gtk-module-directories inputs)
>"Check for the existence of \"libdir/gtk-v.0\" in INPUTS.  Return a list
>  with all found directories."
> @@ -64,20 +67,68 @@ with all found directories."
>prev)
>  (fold gtk-module '() inputs)))
>  
> -(define (schemas-directories inputs)
> -  "Check for the existence of \"datadir/glib-2.0/schemas\" in INPUTS.  Return
> -a list with all found directories."
> -  (define (glib-schemas input previous)
> +;; We include $HOME/.guix-profile/share so that if the user installs a
> +;; desktop, a sound or an icon theme, the application should be able to see
> +;; it, without having to add the theme to the application inputs.  See
> +;; http://www.freedesktop.org/wiki/DesktopThemeSpec
> +;; http://freedesktop.org/wiki/Specifications/sound-theme-spec
> +;; http://freedesktop.org/wiki/Specifications/icon-theme-spec
FYI, every apps will install icons into 'hicolor-icon-theme',
for it to work, we need regenerated the 'icon-theme.cache'
by `gtk-update-icon-cache`.
> +;; 
> +;; Currently desktop themes are not well supported and do not honor
> +;; XDG_DATA_DIRS.  One example is evince which only looks for desktop themes
> +;; in $HOME/.themes (for backward compatibility) and in XDG_DATA_HOME (which
> +;; defaults to $HOME/.local/share).  One way to handle these applications
> +;; appears to be by making $HOME/.themes a symlink to
> +;; $HOME/.guix-profile/share/themes.
> +;;
> +;; Note however that GLib's schemas added in $HOME/.guix-profile/share by the
> +;; installation of a library or application will not necessarily work.  This
> +;; is because GLib only looks for compiled schemas (in a file called
> +;; 

Avoiding threads in the daemon

[Ludovic Courtès]

Nix commit 524f89 changed libstore to use fork + unshare instead of
clone(2).  The problem is that, in doing so, it also removed use of
CLONE_NEWPID and thus, (1) the build process no longer has PID 1, and
(2) build processes end up in the global PID space.

Adding CLONE_NEWPID to the unshare(2) call appears to break things (for
instance, future calls to pthread_create by that process fail with
EINVAL, other calls to clone(2) fail with ENOMEN) which may be why
CLONE_NEWPID isn’t used here.

The stated reason for this commit is this:

 commit 524f89f1399724e596f61faba2c6861b1bb7b9c5
 Author: Eelco Dolstra 
 Date:   Thu Aug 21 14:08:09 2014 +0200

 Use unshare() instead of clone()

 It turns out that using clone() to start a child process is unsafe in
 a multithreaded program. It can cause the initialisation of a build
 child process to hang in setgroups(), as seen several times in the
 build farm:

 The reason is that Glibc thinks that the other threads of the parent
 exist in the child, so in setxid_mark_thread() it tries to get a futex
 that has been acquired by another thread just before the clone(). With
 fork(), Glibc runs pthread_atfork() handlers that take care of this
 (in particular, __reclaim_stacks()). But clone() doesn't do that.

 Fortunately, we can use fork()+unshare() instead of clone() to set up
 private namespaces.

 See also 
https://www.mail-archive.com/lxc-devel@lists.linuxcontainers.org/msg03434.html.

The more general issue is that fork should not be used in a
multi-threaded process, unless the child immediately calls exec* after
fork (POSIX clearly specifies that if a multi-threaded program forks,
the child must only call functions that are async-signal-safe.)  IOW,
the daemon should not use threads in the first place.

Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which
uses std::thread just for convenience) should be reverted, along with
the subsequent commits to that file; then commit 524f89 can be reverted.

WDYT?

Thanks,
Ludo’.

Re: [PATCH] services: xorg: Make SLiM sessions configurable.

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>> * gnu/services/xorg.scm (%default-xsessions): New variable.
>>   (xsessions-directory): New procedure.
>>   (slim-service): Add #:sessions parameter.
>>   [slim.cfg]: Honor #:sessions.
>>   (xinitrc): Adjust accordingly.
>
> Nice!
>
>> -;; Then try a pre-configured session type.
>> -(let ((ratpoison (string-append #$ratpoison "/bin/ratpoison"))
>> -  (wmaker(string-append #$windowmaker "/bin/wmaker")))
>> -  (match (command-line)
>> -((_ "ratpoison")
>> - (exec-from-login-shell ratpoison))
>> -(_
>> - (exec-from-login-shell wmaker))
>> -
>> +;; Then run the selected session.
>> +(exec-from-login-shell (cadr command-line
>
> Please keep ‘match’ instead of ‘cadr’.
OK.
>
> Also, the line above should be (cadr (command-line)) instead of (cadr
> command-line).
>
> Lastly, there’s a problem when #:auto-login? is #t because
> (command-line) returns a 1-element list.  This will be naturally fixed
> when the ‘match’ form above is reinstated.
Thanks for pointing out.

I want to make this auto-login-session configurable too, so I endup
with add it as a parameter to slim-service.
>
>> +(define %default-xsessions
>> +  (list (text-file* "wmaker.desktop" "
>
> Add a comment below ‘%default-xsessions’, like
>
>   ;; List of monadic values denoting for .desktop files blah blah
>
>> +(define (xsessions-directory sessions)
>> +  "Return a directory contains SESSIONS, which should be a list of monadic
>
> s/contains/containing/
>
> Other than that, it looks fine to me.  Could you send an updated
> version?
>From 144bf00b86f6884615d986598ccc62a3c4747eef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Tue, 16 Dec 2014 00:21:46 +0800
Subject: [PATCH] services: xorg: Make SLiM sessions configurable.

* gnu/services/xorg.scm (%default-xsessions): New variable.
  (xsessions-directory): New procedure.
  (slim-service): Add #:sessions and #:auto-login-session parameters.
  [slim.cfg]: Honor #:sessions.
  (xinitrc): Adjust accordingly.
---
 gnu/services/xorg.scm | 71 ---
 1 file changed, 50 insertions(+), 21 deletions(-)

diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index fbf96c7..37f3753 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -36,7 +36,7 @@
   #:use-module (srfi srfi-26)
   #:use-module (ice-9 match)
   #:export (xorg-start-command
-
+%default-xsessions
 %default-slim-theme
 %default-slim-theme-name
 slim-service))
@@ -136,9 +136,10 @@ EndSection
 
 (define* (xinitrc #:key
   (guile (canonical-package guile-2.0))
-  (ratpoison ratpoison)
-  (windowmaker windowmaker))
-  "Return a system-wide xinitrc script that starts the specified X session."
+  fallback-session)
+  "Return a system-wide xinitrc script that starts the specified X session,
+which should be passed to this script as the first argument.  If not, the
+FALLBACK-SESSION will be used."
   (define builder
 #~(begin
 (use-modules (ice-9 match))
@@ -155,20 +156,14 @@ EndSection
   (execl shell shell "--login" "-c"
  (string-join (cons command args))
 
-;; First, try to run ~/.xsession.
-(let* ((home (getenv "HOME"))
-   (xsession (string-append home "/.xsession")))
-  (exec-from-login-shell xsession))
-
-;; Then try a pre-configured session type.
-(let ((ratpoison (string-append #$ratpoison "/bin/ratpoison"))
-  (wmaker(string-append #$windowmaker "/bin/wmaker")))
-  (match (command-line)
-((_ "ratpoison")
- (exec-from-login-shell ratpoison))
-(_
- (exec-from-login-shell wmaker))
-
+(let ((home (getenv "HOME"))
+  (session (match (command-line)
+ ((_ x) x)
+ (_ #$fallback-session
+  ;; First, try to run ~/.xinitrc with the specified session.
+  (exec-from-login-shell (string-append home "/.xinitrc") session)
+  ;; Then starts the specified session directly.
+  (exec-from-login-shell session
   (gexp->script "xinitrc" builder))
 

@@ -176,6 +171,35 @@ EndSection
 ;;; SLiM log-in manager.
 ;;;
 
+(define %default-xsessions
+  ;; Default xsessions available for log-in manager, representing as a list of
+  ;; monadic desktop entries.
+  (list (text-file* "wmaker.desktop" "
+[Desktop Entry]
+Name=Window Maker
+Exec=" windowmaker "/bin/wmaker
+Type=Application
+")
+(text-file* "ratpoison.desktop" "
+[Desktop Entry]
+Name=Ratpoison
+Exec=" ratpoison "/bin/ratpoison
+Type=Application
+")))
+
+(define (xsessions-directory sessions)
+  "Return a directory containing SESSIONS, which should be a list of monadic

Re: [PATCH] gnu: Add bowtie.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> PS: This depends on the Perl module "Clone" for which I sent a patch
> previously.  Although you said it was applied I haven't yet seen it in
> the git repository.

My bad: I applied it and then forgot to push.  Sorry!

> From 96f31057ba6bb17c1801f87d4bbae70dd3539576 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Tue, 16 Dec 2014 17:52:44 +0100
> Subject: [PATCH] gnu: Add bowtie
>
> * gnu/packages/bioinformatics.scm (bowtie): New variable.

Applied, thanks!

Ludo’.

Re: [PATCH 3/4] gnu: Add cairocffi.

[Ludovic Courtès]

Mark H Weaver  skribis:

> I hope to eventually add some mechanism to detect and/or avoid these
> problems in the future.  In the meantime, we'll just have to accept that
> this problem will occasionally bite us.  I don't think it's reasonable
> to expect people to do a "make clean-go && make" every time they add a
> package.  IMO, that cure would be worse than the disease.

Right.  And yes, we’ll need a better solution.

> This commit breaks the Guix build for me.
>
> Due to complications arising from circular module dependencies, we can't
> use 'package-with-python2' from gtk.scm.  For now, I suggest moving it
> to python.scm, where all other uses of 'package-with-python2' are
> currently located.
>
> If you'd like to understand the reasons, read on (optional).

Thanks for catching it, for explaining, and to Federico for the quick
fix!

Ludo’.

Re: Avoiding threads in the daemon

[Eelco Dolstra]

Hi,

On 18/12/14 17:32, Ludovic Courtès wrote:

> Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which
> uses std::thread just for convenience) should be reverted, along with
> the subsequent commits to that file; then commit 524f89 can be reverted.

I really don't want to get rid of threads because they're useful and I want to
use them more in the future (e.g. build.cc would be much simpler if it used
threads rather than the current event-driven approach; nix-daemon could handle
client connections with a thread rather than a process; etc.).

I see a few ways to get PID namespaces back:

* Do a regular fork followed by clone(... | CLONE_NEWPID | CLONE_PARENT) (after
which the intermediate process can exit).

* Call setuid/setgid via syscall() to bypass the locking in the Glibc wrappers.
However, there might be other problematic functions so this is not a great 
solution.

* Get the Glibc folks to provide a way to run at-fork handlers with clone().

Clearly the first option is the easiest.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/

Re: [Nix-dev] Avoiding threads in the daemon

[Shea Levy]

Can't you unshare in the parent then setns back after fork?



> On Dec 19, 2014, at 18:20, Eelco Dolstra  wrote:
> 
> Hi,
> 
>> On 18/12/14 17:32, Ludovic Courtès wrote:
>> 
>> Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which
>> uses std::thread just for convenience) should be reverted, along with
>> the subsequent commits to that file; then commit 524f89 can be reverted.
> 
> I really don't want to get rid of threads because they're useful and I want to
> use them more in the future (e.g. build.cc would be much simpler if it used
> threads rather than the current event-driven approach; nix-daemon could handle
> client connections with a thread rather than a process; etc.).
> 
> I see a few ways to get PID namespaces back:
> 
> * Do a regular fork followed by clone(... | CLONE_NEWPID | CLONE_PARENT) 
> (after
> which the intermediate process can exit).
> 
> * Call setuid/setgid via syscall() to bypass the locking in the Glibc 
> wrappers.
> However, there might be other problematic functions so this is not a great 
> solution.
> 
> * Get the Glibc folks to provide a way to run at-fork handlers with clone().
> 
> Clearly the first option is the easiest.
> 
> -- 
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
> ___
> nix-dev mailing list
> nix-...@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Avoiding threads in the daemon

[Eelco Dolstra]

Hi,

On 19/12/14 19:41, Shea Levy wrote:

> Can't you unshare in the parent then setns back after fork?

In a multi-threaded program, that sounds incredibly racy :-)

(Though it's not clear to me whether unshare() works on the current process or
the current thread. Manpage says process...)

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/

Re: [PATCH] services: xorg: Make SLiM sessions configurable.

[Ludovic Courtès]

宋文武  skribis:

> From 144bf00b86f6884615d986598ccc62a3c4747eef Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
> Date: Tue, 16 Dec 2014 00:21:46 +0800
> Subject: [PATCH] services: xorg: Make SLiM sessions configurable.
>
> * gnu/services/xorg.scm (%default-xsessions): New variable.
>   (xsessions-directory): New procedure.
>   (slim-service): Add #:sessions and #:auto-login-session parameters.
>   [slim.cfg]: Honor #:sessions.
>   (xinitrc): Adjust accordingly.

LGTM.  However, please leave .xsession (instead of .xinitrc) in this
patch.  The change to .xinitrd should be done separately.

> +  ;; First, try to run ~/.xinitrc with the specified session.
> +  (exec-from-login-shell (string-append home "/.xinitrc") session)
> +  ;; Then starts the specified session directly.
> +  (exec-from-login-shell session

s/Then starts/Then try to start/

OK to push with these two changes.

> In additation, I pass session to ~/.xinitrc (replace ~/.xsession, since
> it's what to expect from slim according to [1][2]).

[...]

> [1] https://wiki.archlinux.org/index.php/Slim#Environments
> [2] https://lists.gnu.org/archive/html/guix-devel/2014-12/msg00282.html

I wasn’t sure about .xsession vs .xinitrc, so I did some research.

 reads:

  Your login script, .xinitrc, works with startx, but graphical login
  managers like GDM do not look for .xinitrc.  Instead, they look for a
  file named .xsession in your home directory.

Likewise,  reads:

  Note that ~/.xinitrc is only for configuring the initialization of
  xinit.  If you want the script to be called when ever an X Session is
  started, then you should instead use ~/.xsession.

Someone at

writes:

  If you log in in graphical mode on an X display manager (xdm, gdm,
  kdm, wdm, lightdm, …), traditionally, what is executed after you log
  in is some scripts in /etc/X11 then ~/.xsession.

Citing the ‘startx’ man page on Debian at
:

  Keep in mind that .xinitrc is used only by xinit(1) and completely
  ignored by xdm(1).

So it seems that the Right Thing is to use ~/.xsession in our case.
WDYT?

(I think we should provide a ‘startx’ command as well eventually, and it
will have to read .xinitrc.)

Thanks,
Ludo’.

Re: Avoiding threads in the daemon

[Ludovic Courtès]

Hi,

Eelco Dolstra  skribis:

> On 18/12/14 17:32, Ludovic Courtès wrote:
>
>> Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which
>> uses std::thread just for convenience) should be reverted, along with
>> the subsequent commits to that file; then commit 524f89 can be reverted.
>
> I really don't want to get rid of threads because they're useful and I want to
> use them more in the future (e.g. build.cc would be much simpler if it used
> threads rather than the current event-driven approach; nix-daemon could handle
> client connections with a thread rather than a process; etc.).

Hmm, I’m not convinced about the whole threads-for-convenience approach
à la Java.  (I think the ideal is a single-threaded event loop; of
course we want to avoid IoC, and this is where FRP or monads come in.)

> I see a few ways to get PID namespaces back:
>
> * Do a regular fork followed by clone(... | CLONE_NEWPID | CLONE_PARENT) 
> (after
> which the intermediate process can exit).

Hmm.

> * Call setuid/setgid via syscall() to bypass the locking in the Glibc 
> wrappers.
> However, there might be other problematic functions so this is not a great 
> solution.

Surely.

> * Get the Glibc folks to provide a way to run at-fork handlers with clone().

Hmm.

> Clearly the first option is the easiest.

Yeah.

I think threads are a can of worms anyway and may cause other problems
eventually.

Thanks,
Ludo’.

Re: [Nix-dev] Avoiding threads in the daemon

[Luca Bruno]

On Fri, Dec 19, 2014 at 10:31 PM, Ludovic Courtès  wrote:

>
> Hmm, I’m not convinced about the whole threads-for-convenience approach
> à la Java.  (I think the ideal is a single-threaded event loop; of
> course we want to avoid IoC, and this is where FRP or monads come in.)
>

It is instead for this case. It's not that you have to handle thousands of
connections. Threads simplify a lot compared to an event loop in C/C++.
Don't be fooled by the trends, it doesn't apply here.

Nix subset merged

[Ludovic Courtès]

Until now there was a ‘nix-upstream’ Git submodule, which pointed to the
upstream Nix repository.  The ‘sync-with-upstream’ script would copy
from nix-upstream/ to nix/ the subset of the code that we need, and
patch a couple of things.

With commit 3645756, the Nix code needed for the daemon has been
directly merged into our repo.  This will make it easier to make local
modifications.

In addition, the branch ‘nix’ contains the Nix code filtered by the
attached script (not in the sense of ‘git filter-branch’, because that
would prevent merges with the upstream repo.)  It can quite easily be
merged with the upstream Nix repo.

Feedback & bug reports welcome!

Ludo’.

#!/bin/sh

#set -x
shopt -s nullglob

[ -f AUTHORS ] && [ -d src ] && mv AUTHORS src/

for i in *
do
case "$i" in
src) : ;;
*)   rm -rf "$i";;
esac
done

for i in src/*
do
case "$i" in
src/libstore|src/boost|src/libutil|src/nix-daemon)
:;;
*)
rm -rf "$i";;
esac
done

find -name Makefile\* -or -name local.mk -or -name .gitignore -exec rm {} \;

if [ -d src ]
then
mv src nix
else
true
fi

Re: [PATCH] services: xorg: Make SLiM sessions configurable.

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>> From 144bf00b86f6884615d986598ccc62a3c4747eef Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
>> Date: Tue, 16 Dec 2014 00:21:46 +0800
>> Subject: [PATCH] services: xorg: Make SLiM sessions configurable.
>>
>> * gnu/services/xorg.scm (%default-xsessions): New variable.
>>   (xsessions-directory): New procedure.
>>   (slim-service): Add #:sessions and #:auto-login-session parameters.
>>   [slim.cfg]: Honor #:sessions.
>>   (xinitrc): Adjust accordingly.
>
> LGTM.  However, please leave .xsession (instead of .xinitrc) in this
> patch.  The change to .xinitrd should be done separately.
>
>> +  ;; First, try to run ~/.xinitrc with the specified session.
>> +  (exec-from-login-shell (string-append home "/.xinitrc") session)
>> +  ;; Then starts the specified session directly.
>> +  (exec-from-login-shell session
>
> s/Then starts/Then try to start/
>
> OK to push with these two changes.
Done, thanks for review!
>
>> In additation, I pass session to ~/.xinitrc (replace ~/.xsession, since
>> it's what to expect from slim according to [1][2]).
>
> [...]
>
>> [1] https://wiki.archlinux.org/index.php/Slim#Environments
>> [2] https://lists.gnu.org/archive/html/guix-devel/2014-12/msg00282.html
>
> I wasn’t sure about .xsession vs .xinitrc, so I did some research.
>
>  reads:
>
>   Your login script, .xinitrc, works with startx, but graphical login
>   managers like GDM do not look for .xinitrc.  Instead, they look for a
>   file named .xsession in your home directory.
>
> Likewise,  reads:
>
>   Note that ~/.xinitrc is only for configuring the initialization of
>   xinit.  If you want the script to be called when ever an X Session is
>   started, then you should instead use ~/.xsession.
>
> Someone at
> 
> writes:
>
>   If you log in in graphical mode on an X display manager (xdm, gdm,
>   kdm, wdm, lightdm, …), traditionally, what is executed after you log
>   in is some scripts in /etc/X11 then ~/.xsession.
>
> Citing the ‘startx’ man page on Debian at
> :
>
>   Keep in mind that .xinitrc is used only by xinit(1) and completely
>   ignored by xdm(1).
>
> So it seems that the Right Thing is to use ~/.xsession in our case.
> WDYT?
OK, it seem that only SLiM use ~/.xinitrc instead of ~/.xsession.
IMO, It's fine to stick with ~/.xsession if we add other login
managers later.
>
> (I think we should provide a ‘startx’ command as well eventually, and it
> will have to read .xinitrc.)
>
> Thanks,
> Ludo’.

New xorg-updates branch pushed

[Mark H Weaver]

Hello Guix!

I've pushed a new branch 'xorg-updates' which updates almost every
package in xorg.scm, as well as mesa, dbus, glib, pixman, cairo,
poppler, inkscape, and a few others.

My original purpose was to apply security fixes mentioned here:

  http://www.x.org/wiki/Development/Security/Advisory-2014-12-09/

but I decided it was a better use of my time to upgrade xorg-server to
the latest pre-release (which contains the fixes) than to try to
backport them to our old xorg-server.  This required updating the *proto
packages, which in turn forced a rebuild of the X libraries and
everything built on them, so I decided I might as well update most of
xorg.scm while I was at it.

I've been running with these patches on my own system for the last day
or so, and it's working very well so far.  The X server now uses
xf86-input-evdev, which among other things enables hotplugging of input
devices.  xf86-video-modesetting also now works.  I was also able to
resurrect xf86-video-geode, thanks to a new upstream release.

Two drivers no longer compile: xf86-video-ast and xf86-video-newport.
They both try to include xaa.h, which has apparently been removed from
the server, although I confess I didn't look too deeply into it.

Most of the commits are fairly straightforward, but I wanted to call
attention to a few points:

* Wherever possible, I changed the source URIs to
  mirror://xorg/individual/.  For most of the package updates this was
  required, and then for consistency, in the final commit I changed all
  of the URIs for the packages I didn't update.  I made it the last
  commit so it will be easy to remove if there are objections :)

* Many video drivers needed patches.  Most of the patches are for two
  recurrent problems:

   * mibstore.h has been removed in the X server, and 10 of the video
 drivers haven't yet been updated.  Fixing this requires patches
 like this:

 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/xf86-video-nv-remove-mibstore.patch?h=xorg-updates

   * There's an incompatibility between glibc-2.20 and the os.h header
 in the xorg-server package.  Until they fix this properly, a
 simple workaround is to include  before including
 the headers for the internal X driver API, as done here:

 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/xf86-video-intel-glibc-2.20.patch?h=xorg-updates

   * Related to the problem above, some video drivers checked for the
 exa.h header in their configure scripts, and the test compilation
 fails for the same reason as above.  My workaround was to hack the
 configure script to include  in the test program,
 using patches like this:

 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/xf86-video-mach64-glibc-2.20.patch?h=xorg-updates

I've asked Hydra to build this new branch, and when it's done building
(or close to it) I plan to merge it into master.

In the meantime, if anyone feels inspired to review these 116 commits,
your comments and suggestions are welcome.  Testing would also be very
helpful, as I was only able to test on my Libreboot X60 laptop with
intel graphics.

   Mark