bug#21410: Environment containers

[Ludovic Courtès]

Alex Vong  skribis:

> FAIL: tests/guix-environment-container
> ==
>
> + set -e
> + guix environment --version
> guix environment (GNU Guix) 0.9.0
> Copyright (C) 2015 the Guix authors
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> + tmpdir=t-guix-environment-29930
> + trap 'rm -r "$tmpdir"' EXIT
> + mkdir t-guix-environment-29930
> + guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile 
> -c '(exit 42)'
> guix environment: error: cannot create container: unprivileged user cannot 
> create user namespaces
> guix environment: error: please set 
> /proc/sys/kernel/unprivileged_userns_clone to "1"

Oh I see, that part fell through the cracks.

Could you confirm that the test is skipped with the attached patch?

TIA!

Ludo’.

--- a/tests/guix-environment-container.sh
+++ b/tests/guix-environment-container.sh
@@ -24,6 +24,12 @@ set -e
 
 guix environment --version
 
+if ! guile -c '((@@ (guix scripts environment) assert-container-features))'
+then
+# User containers are not supported; skip this test.
+exit 77
+fi
+
 tmpdir="t-guix-environment-$$"
 trap 'rm -r "$tmpdir"' EXIT
 

bug#20255: 'search-paths' should respect both user and system profile.

[Alex Kost]

Ludovic Courtès (2015-11-21 11:57 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-11-20 01:32 +0300) wrote:
>>
>>> -# Load the system profile's settings.
>>> +if [ -x /run/current-system/profile/bin/guix ]
>>> +then
>>> +  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from 
>>> the
>>> +  # profiles' individual 'etc/profile'.  Thus, combine both profiles when
>>> +  # computing the search paths.
>>> +  #
>>> +  # This may take a few hundred milliseconds, but it's OK because this is
>>> +  # performed for log-in shells only.
>>> +  eval `/run/current-system/profile/bin/guix package \\
>>> +  -p /run/current-system/profile \\
>>> +  -p \"$HOME/.guix-profile\" --search-paths`
>>
>> Sorry, but it's not OK for me.  As a user, I'm *strongly* against
>> running 'guix' (or any other program) in /etc/profile.
>
> Why?  (Honest question.)

At first, because of the slowdown: it may be a few hundred milliseconds
for you, but it's several seconds for me.  But actually, even if it was
several milliseconds, I still wouldn't like it, as (IMHO) /etc/profile
should only set variables, and not run external programs.

>> I would really like to have an option to avoid this.  Is it possible?
>
> Not that I know of.  Please read .

What about making some environment variable which will be honored by
'operating-system-etc-service' procedure.  So depending on this variable
that 'eval ...' command will or will not be added to "/etc/profile"
during 'guix system ...' process.

For example, when I do:

  GUIX_IGNORE_SYSTEM_PROFILE_ENV=1 guix system build my-config.scm

the "etc/profile" of the built system will not contain those 'eval ...'
lines.  WDYT?

-- 
Alex

bug#20255: 'search-paths' should respect both user and system profile.

[Alex Kost]

Ludovic Courtès (2015-11-21 23:10 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-11-21 11:57 +0300) wrote:
>>
>>> Alex Kost  skribis:
>>>
 Ludovic Courtès (2015-11-20 01:32 +0300) wrote:

> -# Load the system profile's settings.
> +if [ -x /run/current-system/profile/bin/guix ]
> +then
> +  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing 
> from the
> +  # profiles' individual 'etc/profile'.  Thus, combine both profiles when
> +  # computing the search paths.
> +  #
> +  # This may take a few hundred milliseconds, but it's OK because this is
> +  # performed for log-in shells only.
> +  eval `/run/current-system/profile/bin/guix package \\
> +  -p /run/current-system/profile \\
> +  -p \"$HOME/.guix-profile\" --search-paths`

 Sorry, but it's not OK for me.  As a user, I'm *strongly* against
 running 'guix' (or any other program) in /etc/profile.
>>>
>>> Why?  (Honest question.)
>>
>> At first, because of the slowdown: it may be a few hundred milliseconds
>> for you, but it's several seconds for me.
>
> Really?  Can you show the output of:
>
>   time guix package -p /run/current-system/profile \
> -p ~/.guix-profile --search-paths

real0m2.634s
user0m0.568s
sys 0m0.080s

Of course, on the second run the real time reduces (for me it's about
0.5), as HDD already "knows" what I want, but since it is for login
shell, it will always be 2-3 seconds because of HDD.

>> But actually, even if it was several milliseconds, I still wouldn't
>> like it, as (IMHO) /etc/profile should only set variables, and not run
>> external programs.
>
> I don’t buy this “principle”: /etc/profile is a program, and the output
> of --search-paths is trusted to contain only environment variable
> setting.

Sure, it's just my opinion (OK, let call it "faith"): I consider running
external programs in "/etc/profile" malicious.

> In the discussion of this bug, we tried hard to avoid resorting to
> invoking a program, but ultimately no other solution came out.

I don't need a solution for this bug, I just want to have an option to
avoid invoking "guix package --search-paths" in my "/etc/profile".

 I would really like to have an option to avoid this.  Is it possible?
>>>
>>> Not that I know of.  Please read .
>>
>> What about making some environment variable which will be honored by
>> 'operating-system-etc-service' procedure.  So depending on this variable
>> that 'eval ...' command will or will not be added to "/etc/profile"
>> during 'guix system ...' process.
>>
>> For example, when I do:
>>
>>   GUIX_IGNORE_SYSTEM_PROFILE_ENV=1 guix system build my-config.scm
>>
>> the "etc/profile" of the built system will not contain those 'eval ...'
>> lines.  WDYT?
>
> This would be unreasonable.  We’re talking about a basic feature here.
> If basic features are broken to the point that we prefer to offer ways
> to bypass them, and have a semi-broken system, then there’s a problem,
> IMO.

Sorry, but I would really like to bypass this feature, as I don't like
it.  For me, what you suggest sounds: «We'll not give a freedom to a
user to disable this feature, because we know better what is good for
him/her».  All I ask is to give me such a freedom.

Using --search-paths with several profiles is a great feature (thank you
for it!) and I like it, but consider the following use-case: for some
reason I like to manage several profiles instead of a single
"~/.guix-profile", so I can put:

eval `guix package -p /run/current-system/profile \
   -p ~/.guix-profile \
   -p ~/my-guix-profiles/foo \
   -p ~/my-guix-profiles/bar \
   --search-paths`

in my "~/.bash_profile".  So I don't like to have the same command but
only for 2 profiles in my "/etc/profile".  Please, give me an option to
disable this feature.

-- 
Alex

bug#21976: error when building vlc-2.2.1 (sha mismatch of a dependency)

[Jan Synáček]

I'm getting the following error:

[...]
Starting download of
/gnu/store/c0kix7cn1pvdq5r563r97kxm66ldnf87-ladspa_sdk_1.13.tgz
>From http://www.ladspa.org/download/ladspa_sdk_1.13.tgz...
 ladspa_sdk_1.13.tgz  10.5MiB/s 00:00 | 3KiB transferred
output path `/gnu/store/c0kix7cn1pvdq5r563r97kxm66ldnf87-ladspa_sdk_1.13.tgz'
should have sha256 hash
`0srh5n2l63354bc0srcrv58rzjkn4gv8qjqzg8dnq3rs4m7kzvdm', instead has
`0dmh3k49yl8ii96bz32vlgc8w1fz99295h93aghfb2q1myx81lqv'
cannot build derivation
`/gnu/store/ig427gsrfqybnpjmjcb53lh6mfvi7zpk-ladspa-1.13.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/lak2kjr7rf76myk6z0h91r05q6rl09rk-ffmpeg-2.8.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/gh3g0c310b6h1d9145zha9gv1fj3n5dl-vlc-2.2.1.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/10d780zc7bj43f71cf0pl9dl2p4q7s01-profile.drv': 1
dependencies couldn't be built
guix package: error: build failed: build of
`/gnu/store/10d780zc7bj43f71cf0pl9dl2p4q7s01-profile.drv' failed

I'm using guix-0.9.0.

-- 
Jan Synáček

bug#21976: error when building vlc-2.2.1 (sha mismatch of a dependency)

[Efraim Flashner]

On Sat, 21 Nov 2015 21:36:28 +0100
Jan Synáček  wrote:

> I'm getting the following error:
> 
> [...]
> Starting download of
> /gnu/store/c0kix7cn1pvdq5r563r97kxm66ldnf87-ladspa_sdk_1.13.tgz
> From http://www.ladspa.org/download/ladspa_sdk_1.13.tgz...
>  ladspa_sdk_1.13.tgz  10.5MiB/s 00:00 | 3KiB 
> transferred
  ^^^
download size is way too small
> output path `/gnu/store/c0kix7cn1pvdq5r563r97kxm66ldnf87-ladspa_sdk_1.13.tgz'
> should have sha256 hash
> `0srh5n2l63354bc0srcrv58rzjkn4gv8qjqzg8dnq3rs4m7kzvdm', instead has
> `0dmh3k49yl8ii96bz32vlgc8w1fz99295h93aghfb2q1myx81lqv'
... 
> I'm using guix-0.9.0.
> 

Their website seems to be down atm, which means their downloads are also
down.  As a workaround, download from archive.org here:
https://web.archive.org/web/20150427072109/http://www.ladspa.org/download/ladspa_sdk_1.13.tgz
and then do `guix download file:///path/to/file` and that should at least
help for right now.

-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


pgpetUC0RQHFT.pgp
Description: OpenPGP digital signature

bug#20255: 'search-paths' should respect both user and system profile.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-11-21 11:57 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> Ludovic Courtès (2015-11-20 01:32 +0300) wrote:
>>>
 -# Load the system profile's settings.
 +if [ -x /run/current-system/profile/bin/guix ]
 +then
 +  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from 
 the
 +  # profiles' individual 'etc/profile'.  Thus, combine both profiles when
 +  # computing the search paths.
 +  #
 +  # This may take a few hundred milliseconds, but it's OK because this is
 +  # performed for log-in shells only.
 +  eval `/run/current-system/profile/bin/guix package \\
 +  -p /run/current-system/profile \\
 +  -p \"$HOME/.guix-profile\" --search-paths`
>>>
>>> Sorry, but it's not OK for me.  As a user, I'm *strongly* against
>>> running 'guix' (or any other program) in /etc/profile.
>>
>> Why?  (Honest question.)
>
> At first, because of the slowdown: it may be a few hundred milliseconds
> for you, but it's several seconds for me.

Really?  Can you show the output of:

  time guix package -p /run/current-system/profile \
-p ~/.guix-profile --search-paths

?

> But actually, even if it was several milliseconds, I still wouldn't
> like it, as (IMHO) /etc/profile should only set variables, and not run
> external programs.

I don’t buy this “principle”: /etc/profile is a program, and the output
of --search-paths is trusted to contain only environment variable
setting.

In the discussion of this bug, we tried hard to avoid resorting to
invoking a program, but ultimately no other solution came out.

>>> I would really like to have an option to avoid this.  Is it possible?
>>
>> Not that I know of.  Please read .
>
> What about making some environment variable which will be honored by
> 'operating-system-etc-service' procedure.  So depending on this variable
> that 'eval ...' command will or will not be added to "/etc/profile"
> during 'guix system ...' process.
>
> For example, when I do:
>
>   GUIX_IGNORE_SYSTEM_PROFILE_ENV=1 guix system build my-config.scm
>
> the "etc/profile" of the built system will not contain those 'eval ...'
> lines.  WDYT?

This would be unreasonable.  We’re talking about a basic feature here.
If basic features are broken to the point that we prefer to offer ways
to bypass them, and have a semi-broken system, then there’s a problem,
IMO.

Ludo’.

bug#21974: can't build guix without 'makeinfo'

[Jan Synáček]

On Sat, Nov 21, 2015 at 9:40 PM, Ludovic Courtès  wrote:
> Jan Synáček  skribis:
>
>> The build fails with an error if the 'makeinfo' binary is missing on
>> the system. The configure script should check for 'makeinfo' and fail
>> if not found (or maybe warn that the docs won't be built?).
>
> ‘makeinfo’ is necessary when building from a checkout or otherwise
> modifying the manual, but it’s not necessary when building from a
> tarball.  See
> .
>
> Can you confirm you were building from a checkout?

Yes, I was building from a checkout. Maybe it would make sense to make
it optional,
as 'help2man' is? I was only trying to test the latest version of guix
and wasn't really
interested in the documentation changes.

-- 
Jan Synáček

bug#21410: Environment containers

[Mathieu Lirzin]

l...@gnu.org (Ludovic Courtès) writes:

>
>> FAIL: tests/guix-environment-container
>> ==
>>
>> + set -e
>> + guix environment --version
>> guix environment (GNU Guix) 0.9.0
>> Copyright (C) 2015 the Guix authors
>> License GPLv3+: GNU GPL version 3 or later 
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> + tmpdir=t-guix-environment-29930
>> + trap 'rm -r "$tmpdir"' EXIT
>> + mkdir t-guix-environment-29930
>> + guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile 
>> -c '(exit 42)'
>> guix environment: error: cannot create container: unprivileged user cannot 
>> create user namespaces
>> guix environment: error: please set 
>> /proc/sys/kernel/unprivileged_userns_clone to "1"
>
> Oh I see, that part fell through the cracks.
>
> Could you confirm that the test is skipped with the attached patch?

this test was failing on my system too, and it is skipped successfully
with this patch.

--
Mathieu Lirzin

bug#21978: tbb broken on mips64el but tests always pass

[Ricardo Wurmus]

The “tbb” package appears to be broken on mips64el but both the build
phase and the check phase always pass.  This means that “tbb” is built
“successfully”, which results in downstream build failures.

Debian patches the sources of “tbb” such that the build fails on bad
tests:


https://sources.debian.net/src/tbb/4.3~20150611-0.1/debian/patches/failonbadtests.patch/

We should do the same.

bug#21976: error when building vlc-2.2.1 (sha mismatch of a dependency)

[Jan Synáček]

On Sat, Nov 21, 2015 at 9:51 PM, Efraim Flashner  wrote:
> On Sat, 21 Nov 2015 21:36:28 +0100
> Jan Synáček  wrote:
>
>> I'm getting the following error:
>>
>> [...]
>> Starting download of
>> /gnu/store/c0kix7cn1pvdq5r563r97kxm66ldnf87-ladspa_sdk_1.13.tgz
>> From http://www.ladspa.org/download/ladspa_sdk_1.13.tgz...
>>  ladspa_sdk_1.13.tgz  10.5MiB/s 00:00 | 3KiB 
>> transferred
>   ^^^
> download size is way too small
>> output path `/gnu/store/c0kix7cn1pvdq5r563r97kxm66ldnf87-ladspa_sdk_1.13.tgz'
>> should have sha256 hash
>> `0srh5n2l63354bc0srcrv58rzjkn4gv8qjqzg8dnq3rs4m7kzvdm', instead has
>> `0dmh3k49yl8ii96bz32vlgc8w1fz99295h93aghfb2q1myx81lqv'
> ...
>> I'm using guix-0.9.0.
>>
>
> Their website seems to be down atm, which means their downloads are also
> down.  As a workaround, download from archive.org here:
> https://web.archive.org/web/20150427072109/http://www.ladspa.org/download/ladspa_sdk_1.13.tgz
> and then do `guix download file:///path/to/file` and that should at least
> help for right now.

Oh, I didn't notice that the download wasn't complete. The workaround helped.

Sorry for the noise,
Jan

bug#21958: 'guix environment --container' fails upon exiting

[Ludovic Courtès]

Fixed in 82e64fc.

Ludo’.

bug#21410: Environment containers

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>>
>>> FAIL: tests/guix-environment-container
>>> ==
>>>
>>> + set -e
>>> + guix environment --version
>>> guix environment (GNU Guix) 0.9.0
>>> Copyright (C) 2015 the Guix authors
>>> License GPLv3+: GNU GPL version 3 or later 
>>> 
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> + tmpdir=t-guix-environment-29930
>>> + trap 'rm -r "$tmpdir"' EXIT
>>> + mkdir t-guix-environment-29930
>>> + guix environment --container --ad-hoc --bootstrap guile-bootstrap -- 
>>> guile -c '(exit 42)'
>>> guix environment: error: cannot create container: unprivileged user cannot 
>>> create user namespaces
>>> guix environment: error: please set 
>>> /proc/sys/kernel/unprivileged_userns_clone to "1"
>>
>> Oh I see, that part fell through the cracks.
>>
>> Could you confirm that the test is skipped with the attached patch?
>
> this test was failing on my system too, and it is skipped successfully
> with this patch.

Thanks, pushed as 6493fd0.

Ludo’.

bug#21974: can't build guix without 'makeinfo'

[Ludovic Courtès]

Jan Synáček  skribis:

> The build fails with an error if the 'makeinfo' binary is missing on
> the system. The configure script should check for 'makeinfo' and fail
> if not found (or maybe warn that the docs won't be built?).

‘makeinfo’ is necessary when building from a checkout or otherwise
modifying the manual, but it’s not necessary when building from a
tarball.  See
.

Can you confirm you were building from a checkout?

Thanks,
Ludo’.

bug#20255: 'search-paths' should respect both user and system profile.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-11-20 01:32 +0300) wrote:
>
>> -# Load the system profile's settings.
>> +if [ -x /run/current-system/profile/bin/guix ]
>> +then
>> +  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from 
>> the
>> +  # profiles' individual 'etc/profile'.  Thus, combine both profiles when
>> +  # computing the search paths.
>> +  #
>> +  # This may take a few hundred milliseconds, but it's OK because this is
>> +  # performed for log-in shells only.
>> +  eval `/run/current-system/profile/bin/guix package \\
>> +  -p /run/current-system/profile \\
>> +  -p \"$HOME/.guix-profile\" --search-paths`
>
> Sorry, but it's not OK for me.  As a user, I'm *strongly* against
> running 'guix' (or any other program) in /etc/profile.

Why?  (Honest question.)

> I would really like to have an option to avoid this.  Is it possible?

Not that I know of.  Please read .

Ludo’.