bug#29337: Bash reads system-wide bashrc unconditionally.

[Ludovic Courtès]

Heya,

Roel Janssen  skribis:

> Roel Janssen  skribis:
>
>>> On CentOS 7, the following happens (yes, I added the echo-statement to
>>> /etc/bashrc on CentOS as well):
>>> $ env - bash --init-file <(echo "echo \"Goodbye, world\"") -i
>>> Goodbye, world
>>>
>>> On GuixSD:
>>> $ env - bash --init-file <(echo "echo \"Goodbye, world\"") -i
>>> Hello, world
>>> Goodbye, world

> Well it seems that it isn't ignored when it ought to be ignored -> when
> specifying --init-file.  This is a difference between how Bash works on
> CentOS 7, and how Bash works on Guix(SD).  I can't find a
> user-configurable option to make it work the same as on CentOS 7.

Now, we’re compiling Bash with "-DSYS_BASHRC='\"/etc/bashrc\"'".  I
wonder if removing that flag solves the --init-file case.

Ludo’.

bug#29363: Single test failure building Guix

[Rutger Helling]

Commenting out that line still made the test fail for me. 

On 2017-11-21 08:47, l...@gnu.org wrote:

> Hello,
> 
> Marius Bakke  skribis:
> 
> Rutger Helling  writes:
> 
> when building Guix with 'guix build guix' I keep running into a single 
> test failure. I've attached the test-suite.log. 
> Is this a Btrfs system by any chance, possibly on an SSD?
> 
> test-name: dead path can be explicitly collected
> location: 
> /tmp/guix-build-guix-0.13.0-10.0b4c385.drv-0/source/tests/store.scm:178
> source:
> + (test-assert
> +   "dead path can be explicitly collected"
> +   (let ((p (add-text-to-store
> +  %store
> +  "random-text"
> +  (random-text)
> +  '(
> + (let-values
> +   (((paths freed) (delete-paths %store (list p
> +   (and (equal? paths (list p))
> +(> freed 0)
> +(not (file-exists? p))
> actual-value: #f
> result: FAIL 
> I can reproduce this error on two different systems that have
> Btrfs+LUKS+SSD, and the problem is that freed == 0.

If you comment out (> freed 0), does the test pass?

> I suspect it's related to Btrfs' "lazy" reporting of disk space, but
> haven't dug very far.
> 
> Until we figure out what's going on, I suggest applying the patch
> below.  Can you confirm that it works on your system?
> 
> From bdc7b5310111e21801529ea57e290f6eb72ac6ed Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Tue, 21 Nov 2017 00:27:08 +0100
> Subject: [PATCH] gnu: guix: Disable test that fails on Btrfs.
> 
> Works around .
> Reported by Rutger Helling .
> 
> * gnu/packages/package-management.scm (guix)[arguments]: Rename
> 'disable-container-tests' phase to 'disable-failing-tests' and add 
> substitution
> to disable "dead path can be explicitly collected" test.

Alternately, we could comment out (> freed 0) if that's enough, with a
comment explaining why, and do "make update-guix-package".  That way
we'd avoid the extra build phase.

WDYT?

Thanks for finding out the root cause!

Ludo'.

bug#29363: Single test failure building Guix

[Ludovic Courtès]

Rutger Helling  skribis:

> Commenting out that line still made the test fail for me. 

Could you figure out which of the conditions in the ‘and’ is failing?

> +   (and (equal? paths (list p))
> +(> freed 0)
> +(not (file-exists? p))

TIA,
Ludo’.

bug#25958: missing cursor icons in Gnome

[Ludovic Courtès]

Hello,

Catonano  skribis:

> If you try to drag an application to the floating bar on the left in Gnome,
> the Gnome Shell will crash, it will be started again and you will have to
> login again
>
> I first reported this here
> https://lists.gnu.org/archive/html/help-guix/2017-02/msg00128.html
>
> Installing adwaita-icon-theme didn't help

This was fixed in commit ce3801506652dcfeec983a66c4cba88c270891e8 last
month.  See .

Ludo’.

bug#26048: Use absolute file names in NEED instead of adding many entries to RUNPATH

[Ludovic Courtès]

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

> As Andy just noted on IRC, shared library lookup is inefficient in Guix,
> because there’s one entry per library in RUNPATH.  So we get:
>
> open("/gnu/store/y8ppqsxiki39n4mqpb4mab6bgwqsnnp7-libgc-7.4.2/lib/libm.so.6", 
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/gnu/store/w0bkj9qh7iqcklm5ld8ghg1ynnzqyv00-libffi-3.2.1/lib/libm.so.6",
>  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/gnu/store/d5gw4i6bnyznmbr55ba39bl3pgrhsyp0-libunistring-0.9.6/lib/libm.so.6",
>  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/gnu/store/6k08nkddnrb15h5pwp1s0fa94mr1qas9-gmp-6.1.1/lib/libm.so.6", 
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/gnu/store/9yn89bkl8vcg5rh9dmw3jijciwgrwjls-libltdl-2.4.6/lib/libm.so.6",
>  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24/lib/libm.so.6", 
> O_RDONLY|O_CLOEXEC) = 3
>
> An alternate approach would be for ld-wrapper to replace “-lfoo” with
> “/gnu/store/…/libfoo.so”, which would add the absolute file name as
> NEEDed in the ELF file.

This is actually impossible, as discussed at
:

  Per the ELF v1.2 spec¹ (page 82), setting DT_NEEDED to
  an absolute file name would prevent overriding via LD_LIBRARY_PATH,
  which is not desirable.

  It turns out we cannot even set DT_NEEDED to an absolute file name in
  the first place, because ld records the DT_SONAME of the library, when
  it’s available (which is the case most of the time), rather than its
  file name.

  ¹ http://refspecs.linuxbase.org/elf/elf.pdf

Ludo’.

bug#25958: missing cursor icons in Gnome

[Catonano]

Thanks!

Il 21 nov 2017 2:27 PM, "Ludovic Courtès"  ha scritto:

> Hello,
>
> Catonano  skribis:
>
> > If you try to drag an application to the floating bar on the left in
> Gnome,
> > the Gnome Shell will crash, it will be started again and you will have to
> > login again
> >
> > I first reported this here
> > https://lists.gnu.org/archive/html/help-guix/2017-02/msg00128.html
> >
> > Installing adwaita-icon-theme didn't help
>
> This was fixed in commit ce3801506652dcfeec983a66c4cba88c270891e8 last
> month.  See .
>
> Ludo’.
>

bug#29363: Single test failure building Guix

[Rutger Helling]

I think commenting out (> freed 0) does work after all. When I ran 'guix
environment --pure guix' and 'make check TESTS=tests/store.scm' against
my git checkout the test passed. 

On 2017-11-21 13:53, l...@gnu.org wrote:

> Rutger Helling  skribis:
> 
>> Commenting out that line still made the test fail for me.
> 
> Could you figure out which of the conditions in the 'and' is failing?
> 
>> +   (and (equal? paths (list p))
>> +(> freed 0)
>> +(not (file-exists? p))
> 
> TIA,
> Ludo'.

bug#29363: Single test failure building Guix

[Marius Bakke]

Rutger Helling  writes:

> I think commenting out (> freed 0) does work after all. When I ran 'guix
> environment --pure guix' and 'make check TESTS=tests/store.scm' against
> my git checkout the test passed. 

Thanks for confirming.  I pushed a revised patch that only removes the
test for freed space as per Ludos suggestion.


signature.asc
Description: PGP signature

bug#29363: Single test failure building Guix

[Marius Bakke]

Ludovic Courtès  writes:
> Alternately, we could comment out (> freed 0) if that’s enough, with a
> comment explaining why, and do “make update-guix-package”.  That way
> we’d avoid the extra build phase.
>
> WDYT?

Oh, I just re-read this message and realized you mentioned doing this in
tests/store.scm rather than working around it in the "guix" package.

Sound good to me.  I will do this and remove the workaround.  Sorry for
the confusion.


signature.asc
Description: PGP signature

bug#29358: guile2.0-guix times out

[Marius Bakke]

Marius Bakke  writes:

> Hello!
>
> Since the Guix snapshot update to 0.13.0-9.ff23b47, "guile2.0-guix"
> fails to build due to a test timeout:
>
> https://hydra.gnu.org/job/gnu/master/guile2.0-guix-0.13.0-9.ff23b47.x86_64-linux

I bisected this down to this commit:

commit a2985bb101faac9f085176e0329488b91b81dfb5
Author: Ludovic Courtès 
Date:   Thu Nov 9 23:29:39 2017 +0100

ui: Provide hints for unbound-variable errors.

* guix/ui.scm (known-variable-definition): New procedure.
(report-load-error): Handle 'unbound-variable'.

I also noticed that when compiling (guix ui), I get this warning:

warning: unknown warning type `macro-use-before-definition'

...which is helpfully annotated with "new in 2.2" in (guix build compile).

So it seems to be a case of the unbound variable handler failing to
handle this unbound variable, when running tests/guix-package.sh:335.

Any ideas for how to progress?  I'm a little out of my depth here :-)


signature.asc
Description: PGP signature

bug#27284: [PATCH 0/8] 'guix pull' creates several derivations

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

> This patch set leads us to a ‘guix pull’ that creates several
> derivations instead of just one: “guix-core” (38 files), “guix-extra”,
> “guix-packages” (388 files), “guix-cli”, “guix-system”.
>
> The idea is that we should be able to have substitutes for at least some
> of them, for instance because “guix-core” doesn’t need to be rebuilt
> very often.  Most of the time, users will just have to build
> “guix-packages”, which is still a bit slow, but will hopefully get
> better as Guile incorporates those long-awaited fixes.

I’ve just pushed this, let me know how ‘guix pull’ works for you!

In addition to this, I’ve created a Hydra job to build this new
“modular Guix”:

  https://hydra.gnu.org/jobset/guix/modular

If everything goes well, this should give us substitutes for at least
“guix-core” and “guix-extra”.  We have yet to see how long it takes to
evaluate it on hydra.gnu.org and adjust the evaluation frequency
accordingly.

> The ‘reload-guix’ procedure there is here to fix that: we reload all the
> Guix modules of the target checkout, and run the build procedure from
> that context.  Unfortunately, it’s not fully baked yet because reloading
> leads to incompatibilities: the (guix scripts pull) module remains in
> the “old world” and manipulates the old  and 
> record types, which is different from the new ones.  That should be
> fixable, but requires some more time and fiddling.  Help from Guilers is
> very much welcome!  :-)

This part is currently commented out, it needs more work.  The main
issue is performance: we end up evaluating or building a lot of modules,
notably package modules, and again we hit the performance issues of the
compiler in Guile 2.2.2.

Ludo’.

bug#27284: [PATCH 0/8] 'guix pull' creates several derivations

[Ludovic Courtès]

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

> Ludovic Courtès  skribis:
>
>> This patch set leads us to a ‘guix pull’ that creates several
>> derivations instead of just one: “guix-core” (38 files), “guix-extra”,
>> “guix-packages” (388 files), “guix-cli”, “guix-system”.
>>
>> The idea is that we should be able to have substitutes for at least some
>> of them, for instance because “guix-core” doesn’t need to be rebuilt
>> very often.  Most of the time, users will just have to build
>> “guix-packages”, which is still a bit slow, but will hopefully get
>> better as Guile incorporates those long-awaited fixes.
>
> I’ve just pushed this, let me know how ‘guix pull’ works for you!

On IRC Marius reported that it doesn’t work, so I reverted (a very
short-lived commit!).

The issue is that we can’t really get away with module reloading, I’m
afraid.

Ludo’.

bug#29368: Unreliable failing tests / segfaulting guile

[Martin Castillo]

Hi,
> It’s seems to be the Guile running ‘list-runtime-roots’ that’s
> segfaulting.  Could you try running it manually to see what happens?
> (The expected behavior is to write a list of store file names on
> standard output.)

When running in a loop, I see the expected output. However, after a file
I get the segfault!

;; sorry, I'm new to scheme, what would be a better way? without
;; reloading the file again and again?
scheme@(guile-user)> (while #t (load-from-path "list-runtime-roots"))
... ;; skipping repeated expected output
srfi/srfi-1.scm:592:17: In procedure map1:
srfi/srfi-1.scm:592:17: In procedure fport_read: Kein passender Prozess
gefunden ;; No matching process found

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

scheme@(guile-user) [1]> ,bt
 102 (primitive-load-path "list-runtime-roots")
In list-runtime-roots:
   145:47101 (_)
In srfi/srfi-1.scm:
   679:15100 (append-map _ _ . _)
   592:29 99 (map1 _)
   592:29 98 (map1 _)
   592:29 97 (map1 _)
   592:29 96 (map1 _)
   592:29 95 (map1 _)
   592:29 94 (map1 _)
   592:29 93 (map1 _)
   592:29 92 (map1 _)
   592:29 91 (map1 _)
   592:29 90 (map1 _)
   592:29 89 (map1 _)
   592:29 88 (map1 _)
   592:29 87 (map1 _)
   592:29 86 (map1 _)
   592:29 85 (map1 _)
   592:29 84 (map1 _)
   592:29 83 (map1 _)
   592:29 82 (map1 _)
   592:29 81 (map1 _)
   592:29 80 (map1 _)
   592:29 79 (map1 _)
   592:29 78 (map1 _)
   592:29 77 (map1 _)
   592:29 76 (map1 _)
   592:29 75 (map1 _)
   592:29 74 (map1 _)
   592:29 73 (map1 _)
   592:29 72 (map1 _)
   592:29 71 (map1 _)
   592:29 70 (map1 _)
   592:29 69 (map1 _)
   592:29 68 (map1 _)
   592:29 67 (map1 _)
   592:29 66 (map1 _)
   592:29 65 (map1 _)
   592:29 64 (map1 _)
   592:29 63 (map1 _)
   592:29 62 (map1 _)
   592:29 61 (map1 _)
   592:29 60 (map1 _)
   592:29 59 (map1 _)
   592:29 58 (map1 _)
   592:29 57 (map1 _)
   592:29 56 (map1 _)
   592:29 55 (map1 _)
   592:29 54 (map1 _)
   592:29 53 (map1 _)
   592:29 52 (map1 _)
   592:29 51 (map1 _)
   592:29 50 (map1 _)
   592:29 49 (map1 _)
   592:29 48 (map1 _)
   592:29 47 (map1 _)
   592:29 46 (map1 _)
   592:29 45 (map1 _)
   592:29 44 (map1 _)
   592:29 43 (map1 _)
   592:29 42 (map1 _)
   592:29 41 (map1 _)
   592:29 40 (map1 _)
   592:29 39 (map1 _)
   592:29 38 (map1 _)
   592:29 37 (map1 _)
   592:29 36 (map1 _)
   592:29 35 (map1 _)
   592:29 34 (map1 _)
   592:29 33 (map1 _)
   592:29 32 (map1 _)
   592:29 31 (map1 _)
   592:29 30 (map1 _)
   592:29 29 (map1 _)
   592:29 28 (map1 _)
   592:29 27 (map1 _)
   592:29 26 (map1 _)
   592:29 25 (map1 _)
   592:29 24 (map1 _)
   592:29 23 (map1 _)
   592:29 22 (map1 _)
   592:29 21 (map1 _)
   592:29 20 (map1 _)
   592:29 19 (map1 _)
   592:29 18 (map1 _)
   592:29 17 (map1 _)
   592:29 16 (map1 _)
   592:29 15 (map1 _)
   592:29 14 (map1 _)
   592:29 13 (map1 _)
   592:29 12 (map1 _)
   592:29 11 (map1 _)
   592:29 10 (map1 _)
   592:29  9 (map1 _)
   592:29  8 (map1 _)
   592:29  7 (map1 _)
   592:29  6 (map1 _)
   592:29  5 (map1 _)
   592:29  4 (map1 _)
   592:29  3 (map1 _)
   592:29  2 (map1 _)
   592:29  1 (map1 _)
   592:17  0 (map1 ("8947"))

I'm running this in qemu with 2 cores and 2.4GB ram.

Martin