Re: Modification for guix installation script.

[Clément Lassieur]

Hi Tatiana,

Tatiana Sholokhova  writes:

> Hello! My name is Tatiana.
>
> I have installed guix for the first time and noticed that the installation
> script at
> https://git.savannah.gnu.org/cgit/guix.git/tree/etc/guix-install.sh did not
> work for me. So, I had to make some modifications.
>
> There was a problem with the path to root user home directory. Below I
> provide diff output for original script and my modified script.

Thank you for working on this!

> 266c266,267
> < ln -sf /var/guix/profiles/per-user/root/guix-profile
> /root/.guix-profile
> ---
>> ln -sf /var/guix/profiles/per-user/root/guix-profile \
>>~root/.guix-profile
> 268c269
> < GUIX_PROFILE="/root/.guix-profile"
> ---
>> GUIX_PROFILE="${HOME}/.guix-profile"
>
> These changes allowed me to install guix via the script.

As I said to Chris (Cc'ed), I don't think it's a good idea to install
Guix in root's home directory.  Instead, we should probably honor the
USER and HOME environment variables, so that the command can be run as a
non-root user (with sudo) in a consistent way.  What do you think?

You can follow the discussion there:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30728.  Every email sent
to 30...@debbugs.gnu.org will appear there.

Clément

Re: XWayland, /tmp/.X11-unix

[Marius Bakke]

Thorsten Wilms  writes:

> On 22.03.2018 14:04, Thorsten Wilms wrote:
>> On 22.03.2018 00:00, Ricardo Wurmus wrote:
>>>
>>> Thorsten Wilms  writes:
>>>
 Initially I thought creation of /tmp/.X11-unix should be tied to the
 xorg-server-xwayland package, but since it is more generic: which
 component should create that dir on Guix SD (based on what)?
>>>
>>> It is needed at run-time (because packages cannot create files outside
>>> of their store prefix at build time), so it should be created by a
>>> system service.  A service is not the same as a shepherd service; we
>>> also have activation services that run once and only create a file or a
>>> directory.
>
> Revisiting, this wasn't too hard, actually:
>
> Using (guix gexp) implied:
>
> ; Create /tmp/.X11-unix and make it writeable to, as required by 
> weston-launch with XWayland enabled:
> (define mkdir-x11-service
>(simple-service 'mkdir-x11
>activation-service-type
>#~(begin (let ((p "/tmp/.X11-unix"))
>(mkdir-p p)
>(chmod p #o777)
>
> Or perhaps rather:
>
> (define mkdir-x11-service
>(simple-service 'mkdir-x11
>activation-service-type
>#~(begin (use-modules (guix build utils))
> (let ((p "/tmp/.X11-unix"))
>(mkdir-p p)
>(chmod p #o777)
>
>
> I can't find anything that suggests a way to automatically add such a 
> service to the operating system, if xorg-server-xwayland (or anything 
> else that would use that dir) is installed.

It could be done with a "profile hook" in (guix profiles).  Although for
the common case I suppose this will be done by a display manager?


signature.asc
Description: PGP signature

'core-updates' spring 2018

[Marius Bakke]

Guix,

'core-updates' has seen a lot of changes recently.  Some of the goodies
include HTTP/2 support in curl, binutils 2.30, glibc 2.27, reproducible
Python bytecode, gnu-build-system will automatically run 'autoreconf' if
necessary, warnings will be issued about snippets and phases not
returning #t, and much more.

Are there other things that should go in?

Let's set a date for "freezing" it, after which it will be started on
Hydra and only bugfixes are allowed.  How about Monday, April 2nd?

Full list of changes:

Alex Vong (1):
  gnu: tar: Update to 1.30.

Arun Isaac (3):
  gnu: boost: Update to 1.66.0.
  gnu: cmake: Update to 3.10.2.
  gnu: cmake: Re-indent.

Efraim Flashner (4):
  gnu: mpfr: Update to 4.0.1.
  gnu: libunistring: Update to 0.9.9.
  gnu: gawk: Update to 4.2.1.
  gnu: gawk: Enable parallel tests.

Leo Famulari (5):
  gnu: libgc: Update to 7.6.4.
  gnu: libatomic-ops: Update to 7.6.2.
  gnu: libgcrypt: Update to 1.8.2.
  gnu: gnutls: Update to 3.5.18.
  gnu: libtasn1: Update to 4.13.

Ludovic Courtès (7):
  gnu: sqlite: Fix source URL.
  gnu: tar: Skip faulty test.
  utils: Add 'false-if-file-not-found'.
  build-system/gnu: Add 'bootstrap' phase.
  build-system/gnu: Dump test suite logs upon 'check' failure.
  build-system/gnu: Fix typo.
  gnu: gcc: Adjust 'strmov' patch for string constants in variables.

Marius Bakke (66):
  gnu: libuv: Update to 1.19.1.
  gnu: util-linux: Update to 2.31.1.
  gnu: glib: Update to 2.54.3.
  gnu: dbus: Update to 1.12.4.
  gnu: sqlite: Update to 3.22.0.
  gnu: libbsd: Update to 0.8.7.
  gnu: gzip: Update to 1.9.
  gnu: gdbm: Update to 1.14.
  gnu: ncurses: Update to 6.1.
  gnu: mpc: Update to 1.1.0.
  gnu: less: Update to 530.
  gnu: libsigsegv: Update to 2.12.
  gnu: bash: Update to patch level 19.
  gnu: libxml2: Update to 2.9.8.
  gnu: graphite2: Update to 1.3.11.
  gnu: libuv: Update to 1.19.2.
  gnu: harfbuzz: Update to 1.7.6.
  gnu: dbus: Update to 1.12.6.
  gnu: util-macros: Update to 1.19.2.
  gnu: xcb-proto: Update to 1.13.
  gnu: libxcb: Update to 1.13.
  gnu: Remove gcc-for-libstdc++.
  gnu: patch: Update to 2.7.6.
  gnu: gdbm: Update to 1.14.1.
  gnu: automake: Update to 1.16.1.
  gnu: glib: Update to 2.56.0.
  gnu: gobject-introspection: Update to 1.56.0.
  gnu: pango: Update to 1.42.0.
  gnu: pango: Explicitly propagate some inputs.
  gnu: python: Update to 3.6.4.
  gnu: binutils: Update to 2.30.
  gnu: glibc: Don't apply upstreamed patch in newer glibc versions.
  gnu: Switch from xproto to xorgproto.
  gnu: Switch from randrproto to xorgproto.
  gnu: Switch from bigreqsproto to xorgproto.
  gnu: Switch from xextproto to xorgproto.
  gnu: Switch from fixesproto to xorgproto.
  gnu: Switch from compositeproto to xorgproto.
  gnu: Switch from kbproto to xorgproto.
  gnu: Switch from inputproto to xorgproto.
  gnu: Switch from fontsproto to xorgproto.
  gnu: Switch from glproto to xorgproto.
  gnu: Switch from dmxproto to xorgproto.
  gnu: Switch from damageproto to xorgproto.
  gnu: Switch from dri2proto to xorgproto.
  gnu: Switch from dri3proto to xorgproto.
  gnu: Switch from videoproto to xorgproto.
  gnu: Switch from windowswmproto to xorgproto.
  gnu: Switch from xcmiscproto to xorgproto.
  gnu: Switch from presentproto to xorgproto.
  gnu: Switch from renderproto to xorgproto.
  gnu: Switch from resourceproto to xorgproto.
  gnu: Switch from recordproto to xorgproto.
  gnu: Switch from scrnsaverproto to xorgproto.
  gnu: Switch from xf86driproto to xorgproto.
  gnu: Switch from xf86dgaproto to xorgproto.
  gnu: Switch from xf86bigfontproto to xorgproto.
  gnu: Switch from xf86vidmodeproto to xorgproto.
  gnu: Switch from xineramaproto to xorgproto.
  gnu: freetype: Update to 2.9.
  gnu: fontconfig: Update to 2.13.0.
  gnu: poppler: Update to 0.63.0.
  gnu: glibc: Update to 2.27.
  gnu: make: Fix compatibility with glibc 2.27.
  gnu: make: End phase on #t.
  gnu: util-linux: Don't build 'nologin'.

Mark H Weaver (162):
  packages: patch-and-repack: Use invoke instead of system*.
  gnu-dist: Use invoke instead of system*.
  build-system/gnu: Use invoke instead of system*.
  build-system/glib-or-gtk: Use invoke instead of system*.
  build-system/cmake: Use invoke instead of system*.
  build-system/perl: Use invoke instead of system*.
  build-system/python: Use invoke instead of system*.
  build-system/texlive: Use invoke instead of system*.
  build-system/scons: Use invoke instead of system*.
  bootstrap: Use invoke instead of system*.
  download: Use invoke instead of system*.
  gnu: linux-libre-headers: Use invoke instead of system*.
  gnu: glibc-u

Re: XWayland, /tmp/.X11-unix

[Thorsten Wilms]

On 26.03.2018 11:33, Marius Bakke wrote:

It could be done with a "profile hook" in (guix profiles).  Although for
the common case I suppose this will be done by a display manager?


But then all X11-supporting display managers would have to care about it.

According to answers in
https://unix.stackexchange.com/questions/196677/what-is-tmp-x11-unix
/tmp/.X11-unix/ is the directory where any X11 server will create the 
unix domain socket X0.


One answer implies that is not necessarily the only way an X11 server 
may communicate with clients on the same machine.


`/gnu/store: grep -iRs X11-unix` only showed results caused by my own 
simple-service, matches in binary files and a comment in a 
slim-sigusr1.patch:
"The problem was that SLiM doesn't pay attention to SIGUSR1.  So in 
practice, if X starts slowly, then SLiM gets ECONNREFUSED a couple of 
time on /tmp/.X11-unix/X0, then goes on trying to connect to 
localhost:6000, where nobody answers; eventually, it times out and tries 
again on /tmp/.X11-unix/X0, and finally it shows up on the screen."


I would think that something must already take care of /tmp/.X11-unix/ 
for an operating-system configuration using plain X11?



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: XWayland, /tmp/.X11-unix

[Marius Bakke]

Thorsten Wilms  writes:

> On 26.03.2018 11:33, Marius Bakke wrote:
>> It could be done with a "profile hook" in (guix profiles).  Although for
>> the common case I suppose this will be done by a display manager?
>
> But then all X11-supporting display managers would have to care about it.
>
> According to answers in
> https://unix.stackexchange.com/questions/196677/what-is-tmp-x11-unix
> /tmp/.X11-unix/ is the directory where any X11 server will create the 
> unix domain socket X0.
>
> One answer implies that is not necessarily the only way an X11 server 
> may communicate with clients on the same machine.
>
> `/gnu/store: grep -iRs X11-unix` only showed results caused by my own 
> simple-service, matches in binary files and a comment in a 
> slim-sigusr1.patch:
> "The problem was that SLiM doesn't pay attention to SIGUSR1.  So in 
> practice, if X starts slowly, then SLiM gets ECONNREFUSED a couple of 
> time on /tmp/.X11-unix/X0, then goes on trying to connect to 
> localhost:6000, where nobody answers; eventually, it times out and tries 
> again on /tmp/.X11-unix/X0, and finally it shows up on the screen."
>
> I would think that something must already take care of /tmp/.X11-unix/ 
> for an operating-system configuration using plain X11?

Interesting.  I assumed SLiM created it, but could not find it with
'grep'.  Maybe libx11?

In any case it should be safe to add an activation script that creates
/tmp/.X11-unix on GuixSD.  I think it can be part of %desktop-services,
or maybe even %base-services.  Would you like to try it?


signature.asc
Description: PGP signature

Re: XWayland, /tmp/.X11-unix

[Ludovic Courtès]

Hello!

Marius Bakke  skribis:

> Thorsten Wilms  writes:
>
>> On 26.03.2018 11:33, Marius Bakke wrote:
>>> It could be done with a "profile hook" in (guix profiles).  Although for
>>> the common case I suppose this will be done by a display manager?
>>
>> But then all X11-supporting display managers would have to care about it.
>>
>> According to answers in
>> https://unix.stackexchange.com/questions/196677/what-is-tmp-x11-unix
>> /tmp/.X11-unix/ is the directory where any X11 server will create the 
>> unix domain socket X0.
>>
>> One answer implies that is not necessarily the only way an X11 server 
>> may communicate with clients on the same machine.
>>
>> `/gnu/store: grep -iRs X11-unix` only showed results caused by my own 
>> simple-service, matches in binary files and a comment in a 
>> slim-sigusr1.patch:
>> "The problem was that SLiM doesn't pay attention to SIGUSR1.  So in 
>> practice, if X starts slowly, then SLiM gets ECONNREFUSED a couple of 
>> time on /tmp/.X11-unix/X0, then goes on trying to connect to 
>> localhost:6000, where nobody answers; eventually, it times out and tries 
>> again on /tmp/.X11-unix/X0, and finally it shows up on the screen."
>>
>> I would think that something must already take care of /tmp/.X11-unix/ 
>> for an operating-system configuration using plain X11?
>
> Interesting.  I assumed SLiM created it, but could not find it with
> 'grep'.  Maybe libx11?

‘_xcb_open_unix’, called by ‘_xcb_open’ in libxcb, creates /tmp/.X11-unix.

Ideally Wayland’s client library would create it as well if it needs it?

> In any case it should be safe to add an activation script that creates
> /tmp/.X11-unix on GuixSD.  I think it can be part of %desktop-services,
> or maybe even %base-services.

Sounds like a good idea.

Ludo’.

Re: Posts in languages other than English on help-guix?

[Ludovic Courtès]

Heya Chris,

Chris Marusich  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Chris Marusich  skribis:
>>
>>> From e817d96b6a52eb6450c2edb4e03ccbfdce30d9d6 Mon Sep 17 00:00:00 2001
>>> From: Chris Marusich 
>>> Date: Sat, 17 Mar 2018 19:40:13 +0100
>>> Subject: [PATCH] website: contacts: Add Japanese translation for help-guix.
>>>
>>> * website/apps/base/data.scm (contact-media): Add "jp" translation.
>>
>> Awesome, please push!
>>
>> (I’ll take care of the CVS sync afterwards.)
>
> I've pushed this as 797a4966befca1ee63d2f1741a3487cf2ae35558.

I’ve synced the web site, thank you!

Ludo’.

Re: Incorrect service documentation?

[Ludovic Courtès]

Hello!

Chris Marusich  skribis:

> Is the description of "compose" correct?  The manual claims that it
> "must return a value that is a valid parameter value for the service
> instance," but I do not think that is actually true.  Judging by the
> implementation of fold-services in (gnu services), it may return any
> single value as long as the extend procedure knows how to handle it.  In
> fact, it is the "extend" procedure which must return a valid parameter
> value for the service.

Yes, you’re right!  Good catch.

> If this is true, then I suggest we change the documentation as follows:
>
>  ‘compose’ (default: ‘#f’)
>   If this is ‘#f’, then the service type denotes services that
>   cannot be extended—i.e., services that do not receive “values”
>   from other services.
>
>   Otherwise, it must be a one-argument procedure.  The procedure
>   is called by ‘fold-services’ and is passed a list of values
>   collected from extensions.  It may return any single value.
>
>  ‘extend’ (default: ‘#f’)
>   If this is ‘#f’, services of this type cannot be extended.
>
>   Otherwise, it must be a two-argument procedure:
>   ‘fold-services’ calls it, passing it the initial value of the
>   service as the first argument and the result of applying
>   ‘compose’ to the extension values as the second argument.  It
>   must return a value that is a valid parameter value for the
>   service instance.
>
> What do you think?

LGTM!

Thank you,
Ludo’.

Re: Modification for guix installation script.

[Ricardo Wurmus]

Hi Clément,

> As I said to Chris (Cc'ed), I don't think it's a good idea to install
> Guix in root's home directory.  Instead, we should probably honor the
> USER and HOME environment variables, so that the command can be run as a
> non-root user (with sudo) in a consistent way.  What do you think?

The script should be run as root as it follows the manual’s
instructions, which tell people to install Guix for the root user and
then make it available system-wide.

This is why I think that it would be correct to install it to the root’s
home directory and not to the sudoing user’s HOME.

Or am I missing something?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: bug#30728: Modification for guix installation script.

[Clément Lassieur]

Hi Ricardo and Marius,

Marius Bakke  writes:

> The binary installation tarball only comes with a profile for 'root'.

Indeed, but it's easy to copy it for any user isn't it?

> The problem is that the installation script assumes $HOME will expand to
> ~root when sourcing the profile, but as you found that isn't always the
> case.
> 
> ~root/.guix-profile is "hard-coded" many other places in the script, so
> Tatianas solution seems sensible to me.

Ricardo Wurmus  writes:

> Hi Clément,
>
>> As I said to Chris (Cc'ed), I don't think it's a good idea to install
>> Guix in root's home directory.  Instead, we should probably honor the
>> USER and HOME environment variables, so that the command can be run as a
>> non-root user (with sudo) in a consistent way.  What do you think?
>
> The script should be run as root as it follows the manual’s
> instructions, which tell people to install Guix for the root user and
> then make it available system-wide.
>
> This is why I think that it would be correct to install it to the root’s
> home directory and not to the sudoing user’s HOME.
>
> Or am I missing something?

Thank you both for your comments. :-)

What I dislike with the present state of things is the need for Guix to
be installed within root's directory.  For two reasons :

  1. I don't think a command should ever install something in another
 user's home directory.  The home directory of a user is for things
 that are specific to that user, I believe.

  2. Users need to update the root profile if they want to update the
 Guix daemon, which is cumbersome.

The systemd configuration file must know where to find the Guix daemon.
If it's not in ~root, it must be in the user's home directory.  Either
way, the Guix daemon, which is system-wide, still depends on a user.

(A way to make the daemon user-independant would be to add a new command
that would update, say, /var/guix/guix-daemon, with the systemd
configuration file pointing to it.)

I personally prefer that the Guix daemon points to my home directory
because I don't want to update root's profile.  Some other people might
prefer that it points to ~root because they might later delete their
profile and want Guix to keep working.

Do we have to take a decision here?  Can't we just let the user decide
by letting them customize their environment variables?  I think it is
the point of environment variables: giving freedom to users.

Re: Why is "append" the activation service's "compose" procedure?

[Ludovic Courtès]

Hello,

Chris Marusich  skribis:

> This is our current definition of the activation-service-type (in (gnu
> services)):
>
>   (define activation-service-type
> (service-type (name 'activate)
>   (extensions
>(list (service-extension boot-service-type
> gexps->activation-gexp)))
>   (compose append)
>   (extend second-argument)))
>
> Note that the the append procedure is used as the "compose" procedure.
> However, fold-services applies the "compose" procedure to a single list.
> What happens when you apply the append procedure to a single list?  You
> get the same list back:
>
>   scheme@(guile-user)> (define mylist '(1 2 3))
>   scheme@(guile-user)> (append mylist)
>   $1 = (1 2 3)
>   scheme@(guile-user)> (eq? mylist (append mylist))
>   $2 = #t
>
> The fold-services procedure always applies the "compose" procedure to a
> single list.  So why does the activation-service-type use the append
> procedure as its "compose" procedure?  Wouldn't it more accurately
> reflect our intent if we used the identity procedure instead?

Yes, you’re right here as well.  :-)

‘boot-service-type’ has the same problem.

Can you fix both?

Thanks!

Ludo’.

Re: Provide python:debug with --with-pydebug switch

[Ludovic Courtès]

Hi Pjotr,

Pjotr Prins  skribis:

> Attached a quick hack I did to get a Python interpreter with full
> debug facilities. It includes the built-in debugging/tracing
> facilities. I think this is a valuable thing to have as a package
>
>   
> https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html
>
> especially when writing native extensions (shared libs)

IIUC --with-pydebug instruments the bytecode interpreter, whereas the
“debug” output allows us to get debugging symbols for libpython.so,
which may be useful but is a separate issue, right?  (I agree both are
useful, though.)

I suppose --with-pydebug incurs some run-time overhead, so I think it
makes sense to make it a separate “python-debug” package.

What do Pythonistas think?

If there are no objections, I’ll push your patch minus “#:tests? #f”.

Thanks,
Ludo’.

Re: 'core-updates' spring 2018

[Ludovic Courtès]

Hello!

Marius Bakke  skribis:

> 'core-updates' has seen a lot of changes recently.  Some of the goodies
> include HTTP/2 support in curl, binutils 2.30, glibc 2.27, reproducible
> Python bytecode, gnu-build-system will automatically run 'autoreconf' if
> necessary, warnings will be issued about snippets and phases not
> returning #t, and much more.
>
> Are there other things that should go in?
>
> Let's set a date for "freezing" it, after which it will be started on
> Hydra and only bugfixes are allowed.  How about Monday, April 2nd?

Sounds good to me!  Save the date!  :-)

For those wondering how to keep the branch active in the meantime ;-), a
useful thing to do would be to put a few key packages on a diet.  For
instance, python and llvm are pretty big and it would be good to see how
we could make them smaller.

For Python specifically, it may be that we can make “python-minimal” the
new python, and build the sqlite, readline, tcl/tk stuff as separate
packages altogether.

Ludo’.

Re: bug#30728: Modification for guix installation script.

[Tatiana Sholokhova]

Hello!

Could you please make that change on top of the current version of the
> Guix sources as a git commit?  Then you can run “git format-patch -1” to
> format it as a patch in a format that we can apply.  You can send the
> resulting patch file as an attachment to a reply to this email.
> This also fixes bug #30728, so please add this line to the commit
> message:
> --
> Ricardo


I have attached the patch file to this email. This patch fixes the
installation process but it place guix within root's directory.

I personally prefer that the Guix daemon points to my home directory
> because I don't want to update root's profile.  Some other people might
> prefer that it points to ~root because they might later delete their
> profile and want Guix to keep working.


> Do we have to take a decision here?  Can't we just let the user decide
> by letting them customize their environment variables?  I think it is
> the point of environment variables: giving freedom to users.


We can further work on the script's flexibility using the environment
variable solution.

--
Tatiana
From f286b6e9c60cba54f3da68428fc034d272ba5ffc Mon Sep 17 00:00:00 2001
From: tsholokhova 
Date: Mon, 26 Mar 2018 18:59:40 +0300
Subject: [PATCH] Fixes 

---
 etc/guix-install.sh | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/etc/guix-install.sh b/etc/guix-install.sh
index 933492a33..b4a9cdf94 100755
--- a/etc/guix-install.sh
+++ b/etc/guix-install.sh
@@ -263,10 +263,9 @@ sys_create_store()
 fi
 
 _msg "${INF}Linking the root user's profile"
-ln -sf /var/guix/profiles/per-user/root/guix-profile \
-   ~root/.guix-profile
+ln -sf /var/guix/profiles/per-user/root/guix-profile /root/.guix-profile
 
-GUIX_PROFILE="${HOME}/.guix-profile"
+GUIX_PROFILE="/root/.guix-profile"
 source "${GUIX_PROFILE}/etc/profile"
 _msg "${PAS}activated root profile at /root/.guix-profile"
 }
-- 
2.14.1

Re: 'core-updates' spring 2018

[Ricardo Wurmus]

Hi Marius,

> 'core-updates' has seen a lot of changes recently.  Some of the goodies
> include […] glibc 2.27 […]
>
> Are there other things that should go in?

I would really like to see a patch applied to glibc that ensures that
the “prlimit64” syscall is not used when running on the RHEL 6 kernel
(2.6.32).  The lack of this syscall on that kernel means that getrlimits
fails, which makes it impossible to start the JVM.

This problem appeared with the upgrade to glibc 2.26 already, and ever
since I’ve been trying to minimize the damage for RHEL 6 systems where
Guix is used as a package manager (such as the MDC).

A work-around for glibc 2.27 that makes things work fine with the RHEL 6
kernel would be very welcome!  I’ve started a branch “rhel6” where the
default glibc has been bumped back to version 2.25 but I really don’t
want it to be a long-lived branch; one of the reasons is that building
all packages for this old glibc version (even just on x86_64) puts our
build farms under extra stress that I would like to avoid.

Another thing that could go in is the new Guile wrapper for wrapped
scripts that I proposed a few months ago.  It requires a change in
build-side code to provide a “wrap-script” procedure (it wouldn’t be
used just yet).

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Provide python:debug with --with-pydebug switch

[Hartmut Goebel]

Hi,

apparently I missed Pjotr's original message.

> I suppose --with-pydebug incurs some run-time overhead, so I think it
> makes sense to make it a separate “python-debug” package.

I'm not a hard-code extension developer, so I can't tell how useful it is.
Since it is a separate package, it does not harm. So go ahead!

I suggest adding/extending the description like this:

This python interpreter is build with '--with-pydebug' to help
debugging. See
https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug.html
for for information.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

[orchestration] AWS public cloud images

[Mark Meyer]

Hi,
I've the beginning of Guix cloud images available over at Github at

  https://github.com/ofosos/guix-packer/

There's a small writeup of what has been done and what's still missing over 
here:

  https://ofosos.org/2018/03/26/guix-images-01/

All in all, I split the heavy lifting between Packer (AWS API calls) and `guix 
system` and that worked remarkably well. There's some integration with EC2 (You 
can inject a pubkey into the image via the console), but there's also a lot of 
stuff missing. In the end, I would like to provide public cloud images in some 
weeks time. Of course you'll have all the tools to rebuild your own images 
(surprisingly simple).

I think there's still a lot of polish we can apply, but at some point we'll 
need some help from AWS. I do have AWS support access at work, but am not 
really comfortable to use company resources for this yet, but I'll probably ask 
if there's some  avenue to get some 'official' help as a free software project, 
when I run across our technical account manager.

Cheers, Mark

-- 
  Mark Meyer
  m...@ofosos.org

Re: XWayland, /tmp/.X11-unix

[Thorsten Wilms]

On 26.03.2018 13:18, Marius Bakke wrote:

In any case it should be safe to add an activation script that creates
/tmp/.X11-unix on GuixSD.  I think it can be part of %desktop-services,
or maybe even %base-services.  Would you like to try it?


I'm looking into it.


--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Provide python:debug with --with-pydebug switch

[Pjotr Prins]

On Mon, Mar 26, 2018 at 09:12:20PM +0200, Hartmut Goebel wrote:
> Hi,
> 
> apparently I missed Pjotr's original message.
> 
> > I suppose --with-pydebug incurs some run-time overhead, so I think it
> > makes sense to make it a separate “python-debug” package.
> 
> I'm not a hard-code extension developer, so I can't tell how useful it is.
> Since it is a separate package, it does not harm. So go ahead!

Bit more than that, it finds memory leaks which can exist in current
extensions. It is very useful Guix provides it as most other
distributions do not and developers have to compile python from
scratch with all hurdles. I'll write down how you can make use of this
out of the box with Guix.

> I suggest adding/extending the description like this:
> 
> This python interpreter is build with '--with-pydebug' to help
> debugging. See
> https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug.html
> for for information.

I would add 'develop and debug extensions'.

Pj.