Re: PYTHONPATH - let's systematically tame the baest

[宋文武]

Hartmut Goebel  writes:

> Hi,

Hello!

>
> let's pick up on this issue and systematically design the test-cases to
> benchmark the proposed solutions. I already prepared a test-script to
> simplify this and will provide a full description as later.
>
> **Please comment if any relevant case is missing or if any case can be
> skipped**
>
> 1) Test-cases
>
> For all environments (see below) these cases must give the expected
> output - which is defined by what a "foreign distribution's" python
> would do:
> - "installed" python
> - venv with and without --system-site-packages
> - stacked venv with and without --system-site-packages

We should consider both python2 and python3, and virtual environments
created by the 'virtualenv' package.

>
> 2) Environments to be tested.
>
> The proposed solution must pass the test-suite in all of these environments:
>
> 2.1 guix environment:
>
>  guix environment --ad-hoc python -- python3 testit
>   --> Expected outcome: site-packages from GUIX_ENVIRONEMENT
>
> 2.2 guix environment with container:
>
>  guix environment -C --ad-hoc python -- python3 testit
>   --> Expected outcome: site-packages from GUIX_ENVIRONEMENT
>
> 2.3 Installed package *without setting the environment variables!*
>
>  guix package -i python && ~/.guix-profile/bin/python3 testit
>     --> Expected outcome: site-packages from ~/.guix-profile/
>     --> Shall this work, too? Is it nice-to-have or useless?

Yeah, it's nice to have (to avoid introducing an environment variable),
but not necessary.

>
> 2.4 running from /gnu/store (directly)
>
>     $(readlink -f ~/.guix-profile/bin/python3) testit
>     --> Expected outcome: site-packages from /gnu/store
>     --> What is the expected outcome? What is the expected

I think if we use environment variable to specify all the site-packages,
it should be the same as running from profile.  It maybe different if we
resolve site-packages by the executable location...

>
> 2.5 running from /gnu/store (via link)
>
>     ln -s $(readlink -f ~/.guix-profile/bin/python3)
> /tmp/test-guix-pythonA.exe ;
>     /tmp/test-guix-pythonA.exe testit
>     --> Expected outcome: site-packages from /gnu/store

True when we're not use the environment variable.

>
> 2.6 Installed in GuixSD
>
>     --> Do we need to test this? Or is this already covered by one of
> the other cases?

For this, there is nothing special about GuixSD.


Had you review my 'GUIX_PYTHON_X_Y_SITE_PACKAGES' patch?  I think it's
enough to support both python2 and python3 in the same profile:

http://lists.gnu.org/archive/html/guix-devel/2018-03/msg00238.html


Thanks!

Re: 05/06: gnu: rust: Don't build for "native" arch on ARM.

[Mark H Weaver]

Hi Efraim and Danny,

dan...@scratchpost.org (Danny Milosavljevic) writes:

> dannym pushed a commit to branch master
> in repository guix.
>
> commit 67ca98ec7818f5b63fe041bfee4ef10826635685
> Author: Efraim Flashner 
> Date:   Thu Mar 22 09:14:53 2018 +0200
>
> gnu: rust: Don't build for "native" arch on ARM.
> 
> * gnu/packages/rust.scm (rust-1.23)<#:phases>[dont-build-native]: New 
> phase.
> ---
>  gnu/packages/rust.scm | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
> index 8c5abfc..0df649c 100644
> --- a/gnu/packages/rust.scm
> +++ b/gnu/packages/rust.scm
> @@ -351,6 +351,12 @@ safety and thread safety guarantees.")
>   (substitute-keyword-arguments (package-arguments rust-1.19)
> ((#:phases phases)
>  `(modify-phases ,phases
> +   (add-after 'unpack 'dont-build-native
> + (lambda _
> +   ;; XXX: Revisit this when we use gcc 6.
> +   (substitute* "src/binaryen/CMakeLists.txt"
> + (("ADD_COMPILE_FLAG\\(\\\"-march=native\\\"\\)") ""))
> +   #t))
> (add-after 'patch-tests 'patch-cargo-tests
>   (lambda _
> (substitute* "src/tools/cargo/tests/build.rs"

If it would be beneficial, you might consider using gcc-7 to compile
'rust', by adding 'gcc-7' to native-inputs.  We're already using gcc-7
to compile a few other packages, including linux-libre on x86_64.

   Mark

New Spanish PO file for 'guix-packages' (version 0.14.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-packages' has been submitted
by the Spanish team of translators.  The file is available at:

http://translationproject.org/latest/guix-packages/es.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

http://translationproject.org/latest/guix-packages/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/guix-packages.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Cross-compiling bootstrap tarballs fails on core-updates

[Marius Bakke]

Hello!

Building 'bootstrap-tarballs' for other architectures fails on
core-updates.  Here is the comparison to the previous core-updates
evaluation in December:

https://hydra.gnu.org/eval/109945?compare=109875#tabs-now-fail

There seems to be a couple of different problems here.

'patch' fails to build due to a conflicting declaration of
'__mktime_internal':

--8<---cut here---start->8---
  CCLD patch
/gnu/store/9v09kidvqykyk2kh26q297di3lkjc8vy-glibc-cross-arm-linux-gnueabihf-2.27-static/lib/libc.a(mktime.o):
 In function `__mktime_internal':
/tmp/guix-build-glibc-cross-arm-linux-gnueabihf-2.27.drv-0/glibc-2.27/time/mktime.c:353:
 multiple definition of `__mktime_internal'
../lib/libpatch.a(mktime.o):/tmp/guix-build-patch-2.7.6.drv-0/patch-2.7.6/lib/mktime.c:317:
 first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:1230: patch] Error 1
--8<---cut here---end--->8---

Note that there is a warning about __mktime_internal earlier:

--8<---cut here---start->8---
In file included from timegm.c:20:0:
   
timegm.c: In function 'rpl_timegm': 
   
../config.h:1974:25: warning: implicit declaration of function 
'__mktime_internal' [-Wimplicit-function-declaration]
 #define mktime_internal __mktime_internal

timegm.c:30:28: note: in expansion of macro 'mktime_internal'
 # define __mktime_internal mktime_internal

timegm.c:39:10: note: in expansion of macro '__mktime_internal'
   return __mktime_internal (tmp, __gmtime_r, _offset);
--8<---cut here---end--->8---

Then we have 'ncurses' failing in the install phase with:

--8<---cut here---start->8---
make[1]: Entering directory 
'/tmp/guix-build-ncurses-6.1.drv-0/ncurses-6.1/progs'
mkdir -p /gnu/store/553j76738bh6bcr31vsyri0wpxir2wkw-ncurses-6.1/bin
/gnu/store/63gkgnixg6xj3m9cgl25ib2zxl51ngw0-coreutils-8.29/bin/install -c -s 
tic /gnu/store/553j76738bh6bcr31vsyri0wpxir2wkw-ncurses-6.1/bin/`echo tic|  
 sed 's/$//'|sed 's,x,x,'|sed 's/$//'`
strip: Unable to recognise the format of the input file 
`/gnu/store/553j76738bh6bcr31vsyri0wpxir2wkw-ncurses-6.1/bin/tic'
/gnu/store/63gkgnixg6xj3m9cgl25ib2zxl51ngw0-coreutils-8.29/bin/install: strip 
process terminated abnormally
make[1]: *** [Makefile:201: install.progs] Error 1
--8<---cut here---end--->8---

The error message here is odd: /gnu/store/.../bin/tic is not installed
yet at this point.  The built binary looks fine however.  Quoth `file`:

/dev/shm/guix-build-ncurses-6.1.drv-0/ncurses-6.1/progs/tic: ELF 32-bit LSB 
executable, ARM, EABI5
version 1 (SYSV), dynamically linked, interpreter 
/gnu/store/jiw5wrjvcipfxnpl56572x4bf6gdvypf-glibc-cross-arm-linux-gnueabihf-2.27/lib/ld-linux-armhf.so.3,
 for GNU/Linux 2.6.32, with debug_info, not stripped

I'm not sure why these failures happen only when cross-compiling.  The
respective native builds are okay.  Thoughts?

For those following along at home, you can reproduce these failures by
checking out the core-updates branch, and then run:

./pre-inst-env guix build --target=arm-linux-gnueabihf bootstrap-tarballs

(or any other target triplet, they fail in the same way)


signature.asc
Description: PGP signature

Re: Guix-based build tool

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello!
>
> Pjotr Prins  skribis:
>
>> Indeed, I love working with Guix and developing with Guix. Guix takes
>> care of my deployment and configuration requirements.
>>
>> I have written some time in the past that with Guix you don't need
>> autotools. The main thing autotools solve is configuring the build for
>> an environment. At the same time, with Guix you get a predictable
>> environment, so a make file (or similar) suffices. It is what I do in
>> all my development projects - I don't use autotools to develop and
>> deploy them. It greatly simplifies my existence :). Indeed, I have
>> never liked autotools (essentially a nasty hack) and only used them
>> before Nix/Guix. So, my approach is the same as yours :) 
>
> +1!
>
> If we could provide tooling with an abstraction level close to that of a
> makefile, that’d help a lot.
>
> Actually, just like we have ‘emacs-build-system’, we could very much add
> ‘guile-build-system’ for simple Guile packages that don’t need/use
> Autoconf & co.
>
> ‘guile-build-system’ would automatically run ‘guild compile’,
> ‘makeinfo’, etc. pretty much like we do here:
>
>   https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n870
>
> Once we have that, developers of Guile packages can simply drop a
> ‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
> build’, and ‘guix package’.
>
> That’s coarser-grain than a makefile, of course, but would be a good
> first step to providing tooling for people working on Guile code.
>
> Any takers for ‘guile-build-system’?
>
>
> A next step could be to add a tool that understands a syntax like that
> of the guildhall, which gets us closer to the makefile/Makefile.am level
> of abstraction:
>
>   https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121
>
> Ludo’.

While this is a fun idea, I'd still much rather have a guile-based
DSL replacement for autotools type things that's standalone (but maybe
also which can export to shell if need be).

David Thompson has made many comments before on the mistake of mixing
build systems and package managers... I'm a bit worried that we might be
encouraging going down that same path?

staging evaluation in progress

[Marius Bakke]

Hello!

I just started a 'staging' evaluation:

https://hydra.gnu.org/jobset/gnu/staging

Fairly minor changes this round, highlights include Wayland 1.15 and
GStreamer 1.14.  We narrowly missed Mesa 17.3.9 which was scheduled for
today but delayed, hopefully 17.3.8 doesn't introduce any new bugs.

Results should start ticking in tomorrow.

Efraim Flashner (2):
  build-system/meson: Use 'target-arm32?' for armhf-linux case.
  Revert "build-system/meson: Use 'target-arm32?' for armhf-linux case."

Marius Bakke (15):
  gnu: gtk+: Update to 3.22.29.
  gnu: libxkbcommon: Update to 0.8.0.
  gnu: mesa: Update to 17.3.7.
  gnu: meson: Update to 0.45.1.
  gnu: gstreamer: Update to 1.14.0.
  gnu: nss, nss-certs: Update to 3.36.1.
  gnu: mesa: Update to 17.3.8.
  gnu: alsa-lib: Update to 1.1.6.
  gnu: alsa-utils: Update to 1.1.6.
  gnu: alsa-plugins: Update to 1.1.6.
  gnu: atk: Update to 2.28.1.
  build-system/meson: Don't override LDFLAGS if already set.
  gnu: gdk-pixbuf: Update to 2.36.12.
  gnu: libinput: Update to 1.10.3.
  gnu: eudev: Update to 3.2.5.

Rutger Helling (2):
  gnu: wayland: Update to 1.15.0.
  gnu: wayland-protocols: Update to 1.13.


signature.asc
Description: PGP signature

PYTHONPATH - let's systematically tame the baest

[Hartmut Goebel]

Hi,

let's pick up on this issue and systematically design the test-cases to
benchmark the proposed solutions. I already prepared a test-script to
simplify this and will provide a full description as later.

**Please comment if any relevant case is missing or if any case can be
skipped**

1) Test-cases

For all environments (see below) these cases must give the expected
output - which is defined by what a "foreign distribution's" python
would do:
- "installed" python
- venv with and without --system-site-packages
- stacked venv with and without --system-site-packages

2) Environments to be tested.

The proposed solution must pass the test-suite in all of these environments:

2.1 guix environment:

 guix environment --ad-hoc python -- python3 testit
  --> Expected outcome: site-packages from GUIX_ENVIRONEMENT

2.2 guix environment with container:

 guix environment -C --ad-hoc python -- python3 testit
  --> Expected outcome: site-packages from GUIX_ENVIRONEMENT

2.3 Installed package *without setting the environment variables!*

 guix package -i python && ~/.guix-profile/bin/python3 testit
    --> Expected outcome: site-packages from ~/.guix-profile/
    --> Shall this work, too? Is it nice-to-have or useless?

2.4 running from /gnu/store (directly)

    $(readlink -f ~/.guix-profile/bin/python3) testit
    --> Expected outcome: site-packages from /gnu/store
    --> What is the expected outcome? What is the expected

2.5 running from /gnu/store (via link)

    ln -s $(readlink -f ~/.guix-profile/bin/python3)
/tmp/test-guix-pythonA.exe ;
    /tmp/test-guix-pythonA.exe testit
    --> Expected outcome: site-packages from /gnu/store

2.6 Installed in GuixSD

    --> Do we need to test this? Or is this already covered by one of
the other cases?

-- 
Regards
Hartmut Goebel

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