bug#37533: waybar fails to build

[Efraim Flashner]

On Sun, Oct 06, 2019 at 12:52:28AM -0500, Bradley Haggerty wrote:
> This issue has persisted across a few guix updates now, but I would
> like to add that I am running Guix System. My current guix version is:
> guix (GNU Guix) 5a54baf67cfb91ad5062a4a061bc6d083096f9d8
> 
> This program is a customizable panel for use on wayland, possibly
> comparable to polybar. I haven't gotten around to switching to it from
> Sway's default "swaybar" yet, but I've kept it installed for a rainy
> day. I know we don't have many wayland users, so I fear if I just
> uninstall it to make updates less annoying, it may go unsolved for a
> long time. Let me know if more info is needed here. I am bdju on the
> guix irc.
> 

I'm not exactly sure where it was looking for fmt/time.h, but I updated
waybar to 0.8.0 and it now builds correctly. I'll leave the bug open for
now so you can test out the update and see if it works correctly. I
don't have a wayland system to test it on.

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


signature.asc
Description: PGP signature

bug#37586: Import cycles in unrelated packages should not be an error

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> I am annoyed by another import cycle similar to
>  in an unfinished package I’m
> writing.  They needlessly complicate packaging and make packagers
> split modules that logically should not be split.

I agree that this is annoying.

> Is it possible to make import cycles not an error in Guix packages?

Unfortunately no, it’s fundamentally impossible.  When you have:

  (define-module (a) #:use-module (b))
  (define-public var-a 42)

and:

  (define-module (b) #:use-module (a))
  (define-public var-b (+ var-a 1))

you can understand that it will or will not work depending on whether
(b) or (a) is loaded first.  This is what’s happening here.

> These errors do not surface during module compilation but only when
> running guix show or guix build or similar.  I suppose that means
> changing the way they are evaluated could make packages not care about
> dependencies in unrelated packages that just happen to be in the same
> module, could it?

When you use ‘guix show’ or similar, that goes through the package cache
created during ‘guix pull’, which allows Guix to load directly the
module that contains the package.  That order could be different from
the one you have in your checkout.

Thanks,
Ludo’.

bug#37586: Import cycles in unrelated packages should not be an error

[pelzflorian (Florian Pelz)]

On Sun, Oct 06, 2019 at 12:00:27PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)"  skribis:
> > Is it possible to make import cycles not an error in Guix packages?
> 
> Unfortunately no, it’s fundamentally impossible.  When you have:
> 
>   (define-module (a) #:use-module (b))
>   (define-public var-a 42)
> 
> and:
> 
>   (define-module (b) #:use-module (a))
>   (define-public var-b (+ var-a 1))
> 
> you can understand that it will or will not work depending on whether
> (b) or (a) is loaded first.  This is what’s happening here.
> […]
> When you use ‘guix show’ or similar, that goes through the package cache
> created during ‘guix pull’, which allows Guix to load directly the
> module that contains the package.  That order could be different from
> the one you have in your checkout.
> 

Thank you for the explanation.  I now understand that eliminating the
error is not possible within define-module.  Currently, all packages
rely on define-module’s “global” #:use-module form.  How about adding
an alternative per-package, “local” use-module, to load and unload the
dependent module just for this one package?  It appears to be
preferrable to splitting modules.  Is it worth it?

Regards,
Florian

bug#32770: Packaging SLIME/SWANK as Common Lisp library

[Pierre Neidhardt]

Fixed with 2026204a13515aaa9b7814f9a6f0a60b65493bd1.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#37569: Mount does not honor 'user' option.

[Ludovic Courtès]

Hi,

Diego Nicola Barbato  skribis:

> I've tried adding "mount" and "umount" to `setuid-programs' in my
> operating-system config:
>
> (setuid-programs (cons*   
>   #~(string-append #$util-linux "/bin/mount") 
>   #~(string-append #$util-linux "/bin/umount")
>   %setuid-programs))
>
> Mounting as an unprivileged user now works as expected (even the fancy
> 9p stuff).

Cool!

> Is there any rationale for not adding "mount" and "umount" to
> `%setuid-programs' by default?

No, especially since they perform the right checks and error out with
“only root can do that” when needed.

I added them in commit 19944227528502e3619a6d1557bc735224f6fef6.

Thanks!

Ludo’.

bug#37449: Bug when using non-trivial inferiors/channel setup

[Ludovic Courtès]

Hi Carl,

Ludovic Courtès  skribis:

> Carl Dong  skribis:
>
>> building path(s) `/gnu/store/myrl5p8fy3qhpdv7376sak8wmhdsrl5f-profile'
>> Backtrace:
>>2 (primitive-load "/home/dongcarl/.config/guix/current/bi…")
>> In guix/ui.scm:
>>   1692:12  1 (run-guix-command _ . _)
>>623:13  0 (_ srfi-34 #)
>>
>> guix/ui.scm:623:13: Throw to key `wrong-type-arg' with args 
>> `("condition-has-type?" "Wrong type argument")'.
>
> With commit e773b3918f51231f28363905b64ca164b172b47a, you should be able
> to see the actual error condition.
>
>>From there, we should have clues as to why some inferior packages in
> your manifest are problematic.

[...]

> Actually commit 71507435225f10d8d944ba183cbcc77ef953e0e5.

IIRC you mentioned on IRC that the problem is solved, so I’m closing
this bug.  Please reopen it if anything’s wrong!

Thanks,
Ludo’.

bug#37588: Installation error 'emacs-matrix-client'

[Ludovic Courtès]

Hola,

SuarezMiguelC  skribis:

> I'm unable to install emacs-matrix-client, the error is:
>
> guix install: error: el perfil contiene entradas en conflicto para emacs-f
> guix install: error:   primera entrada: emacs-f@0.20.0 
> /gnu/store/7fkbx880319n416nwmdk4mvxn6vlb4xc-emacs-f-0.20.0
> guix install: error:... propagada desde 
> emacs-matrix-client@0.0.0-4.a062366
> guix install: error:   segunda entrada: emacs-f@0.20.0 
> /gnu/store/1qbr9ay0w8ggk9h6ghna52sjah6vnzkf-emacs-f-0.20.0
> guix install: error:... propagada desde emacs-all-the-icons@3.2.0
> guix install: error:... propagada desde 
> emacs-all-the-icons-dired@1.0-1.980b774
> consejo: Intente actualizar `emacs-matrix-client' y 
> `emacs-all-the-icons-dired', o borre uno de ellos del perfil.

This indicates that your profile contains packages that were installed
from different revisions of Guix.

If the advice given above doesn’t work, another option is to do:

  guix upgrade
  guix install emacs-matrix-client

Let me know if that works for you!

Thanks,
Ludo’.

bug#37545: epiphany and next broken after webkitgtk upgrade to 2.26.1

[Marius Bakke]

Vagrant Cascadian  writes:

> On 2019-10-02, Ludovic Courtès wrote:
>> Vagrant Cascadian  skribis:
>>
>>> Ok, a little further ...
>>>
>>>   guix environment --ad-hoc epiphany
>>
>> It works for me on ‘core-updates’
>> ece22ac8ccb6744eaec0320f0c7c9b6680fffa46, but note that my system and
>> user profile were already on ‘core-updates’, so presumably that avoids
>> problems with XDG_*.
>>
>>> Still fails in the same way... but!
>>>
>>>   guix environment --pure --ad-hoc epiphany
>>>
>>> Works fine!
>>
>> This works fine for me too:
>>
>>   guix environment -E DISPLAY -E XAUTHORITY --ad-hoc epiphany --pure -- 
>> epiphany
>>
>> So… problem solved?
>
> It breaks running under wayland, and unsetting WAYLAND_DISPLAY it works
> fine:
>
>   WAYLAND_DISPLAY= epiphany
>
> Or switching to an x11 session rather than wayland also worked fine.
>
> Does it work for other people under wayland, or just x11?
>
> More specifically, I'm running a "sway (wayland)" session from sddm as
> the login manager.

I believe this is fixed by 1714edc3d4e8d6da1b0cdef300ae882d0885f182.
Can you confirm?

Thanks!


signature.asc
Description: PGP signature

bug#37501: [core-updates] Entropy starvation during boot

[Marius Bakke]

Ludovic Courtès  writes:

> Hi,
>
> Marius Bakke  skribis:
>
>> I tried it, but it did not make any discernible difference in the
>> available entropy right after boot, nor did it aid the CRNG seeding.
>
> Bah, too bad, though it still doesn’t sound right to consume this much
> entropy right from the start.  I’m surprised it doesn’t make any
> difference when you remove that bit.

I guess generating 512 random bytes does not cost a lot of entropy.
Writing that made me curious, so I tested it:

$ cat /proc/sys/kernel/random/entropy_avail
3938
$ head -c 512 /dev/urandom > /dev/null && !!
3947

Wait, what?  Trying again...

$ head -c 512 /dev/urandom > /dev/null && cat 
/proc/sys/kernel/random/entropy_avail 
3693
[...typing this section of the email...]
$ head -c 512 /dev/urandom > /dev/null && cat 
/proc/sys/kernel/random/entropy_avail 
3898

> Perhaps we should print the value of /proc/…/entropy_avail in several
> places during boot time to get a better understanding.

That could be useful.  My understanding is that we were waiting for the
kernel to be absolutely certain that the entropy pool is sufficiently
random, i.e. "state 2" from this overview:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33

Once it is initialized, we get an "endless" stream of good random data
thanks to the entropy pool and ChaCha20(?).

See also this article for an overview of the discussions that lead to
Torvalds' patch:

https://lwn.net/SubscriberLink/800509/de787577364be340/

Anyway, I pushed the upstream fix in
dd6989711370c43676edc974f86c8586f21f80f6.


signature.asc
Description: PGP signature

bug#37593: [core-updates] Linux-Libre fails to build on aarch64-linux

[Marius Bakke]

Gábor Boskovits  writes:

> Hello Marius,
>
> Marius Bakke  ezt írta (időpont: 2019. okt. 5., Szo,
> 14:40):
>
>> Pierre Langlois  writes:
>>
>> > Hi Marius,
>> >
>> > Marius Bakke writes:
>> >
>> >> Berlin fails to build "linux-libre" for AArch64 on the 'core-updates'
>> >> branch.  Here is a recent attempt:
>> >>
>> >> https://ci.guix.gnu.org/build/1758844/details
>> >>
>> >> Log file for the latest build:
>> >>
>> >>
>> https://ci.guix.gnu.org/log/aq2rnrmjsgnyk8vmsm7aa3mgdj39dcwh-linux-libre-5.2.17.drv
>> >>
>> >> This seems to be the salient bit:
>> >>
>> >> CC [M]  arch/arm64/lib/xor-neon.o
>> >> In file included from
>> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/stdint.h:34:0,
>> >>  from
>> /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
>> >>  from ./arch/arm64/include/asm/neon-intrinsics.h:33,
>> >>  from arch/arm64/lib/xor-neon.c:11:
>> >>
>> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/bits/stdint-intn.h:27:19:
>> error: conflicting types for 'int64_t'
>> >>  typedef __int64_t int64_t;
>> >>^~~
>> >> In file included from ./include/linux/list.h:5:0,
>> >>  from ./include/linux/module.h:9,
>> >>  from arch/arm64/lib/xor-neon.c:10:
>> >> ./include/linux/types.h:114:15: note: previous declaration of 'int64_t'
>> was here
>> >>  typedef s64   int64_t;
>> >>^~~
>> >> In file included from
>> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/stdint.h:37:0,
>> >>  from
>> /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
>> >>  from ./arch/arm64/include/asm/neon-intrinsics.h:33,
>> >>  from arch/arm64/lib/xor-neon.c:11:
>> >>
>> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/bits/stdint-uintn.h:27:20:
>> error: conflicting types for 'uint64_t'
>> >>  typedef __uint64_t uint64_t;
>> >> ^~~~
>> >> In file included from ./include/linux/list.h:5:0,
>> >>  from ./include/linux/module.h:9,
>> >>  from arch/arm64/lib/xor-neon.c:10:
>> >> ./include/linux/types.h:112:15: note: previous declaration of
>> 'uint64_t' was here
>> >>  typedef u64   uint64_t;
>> >>^~~~
>> >> make[1]: *** [scripts/Makefile.build:285: arch/arm64/lib/xor-neon.o]
>> Error 1
>> >> make: *** [Makefile:1073: arch/arm64/lib] Error 2
>> >> make: *** Waiting for unfinished jobs
>> >>
>> >> Not sure what's going on here.  Ideas?
>> >
>> > Ha, that looks familiar, the same issue happened back in July:
>> > https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00175.html
>> >
>> > I don't think we worked out what was the problem exactly though :-/
>>
>> So I was able to build it with this patch:
>>
>>
>> It's not very pretty though.  Thoughts?
>>
>
> I believe that we encountered similar CPATH related problems earlier, which
> were fixed by pathes like this, so it looks good to me. Maybe it would
> worth investigating the pattern though, and create some generic mechanism
> to deal with it. Wdyt?

I don't think we've had to remove libc from CPATH before.  We could do
that in gnu-build-system if it becomes a pattern.

A more general solution to the CPATH vs C_INCLUDE_PATH problem could be
to present GCC a union of all the inputs as C_INCLUDE_PATH, because I
suspect the main problem is having multiple entries in arbitrary order.
Not sure if that would help this particular issue though.

In any case I pushed the fix as
c5ceec4150f6a6cdc1b64781afa2d05547cf8542.  Thanks for the feedback!


signature.asc
Description: PGP signature

bug#37501: [core-updates] Entropy starvation during boot

[Marius Bakke]

Marius Bakke  writes:

> Ludovic Courtès  writes:
>
>> Hi,
>>
>> Marius Bakke  skribis:
>>
>>> I tried it, but it did not make any discernible difference in the
>>> available entropy right after boot, nor did it aid the CRNG seeding.
>>
>> Bah, too bad, though it still doesn’t sound right to consume this much
>> entropy right from the start.  I’m surprised it doesn’t make any
>> difference when you remove that bit.
>
> I guess generating 512 random bytes does not cost a lot of entropy.
> Writing that made me curious, so I tested it:
>
> $ cat /proc/sys/kernel/random/entropy_avail
> 3938
> $ head -c 512 /dev/urandom > /dev/null && !!
> 3947
>
> Wait, what?  Trying again...
>
> $ head -c 512 /dev/urandom > /dev/null && cat 
> /proc/sys/kernel/random/entropy_avail 
> 3693
> [...typing this section of the email...]
> $ head -c 512 /dev/urandom > /dev/null && cat 
> /proc/sys/kernel/random/entropy_avail 
> 3898
>
>> Perhaps we should print the value of /proc/…/entropy_avail in several
>> places during boot time to get a better understanding.
>
> That could be useful.  My understanding is that we were waiting for the
> kernel to be absolutely certain that the entropy pool is sufficiently
> random, i.e. "state 2" from this overview:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33
>
> Once it is initialized, we get an "endless" stream of good random data
> thanks to the entropy pool and ChaCha20(?).

Answering a question I got from reading my own email: I guess the reason
we can read from /dev/urandom before getrandom(2) works, is that
/dev/urandom does not require the CRNG to be in "state 2".


signature.asc
Description: PGP signature

bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page

[Jan Wielkiewicz]

Okay, never mind. Running "guix environment guix" instead of "guix
environment guix --pure" lets preserve the environment variables needed
for X.509 certificates to be available for git in the environment.
If that's not the correct way of doing this please let me know, but
now I'm able to run "guix refresh", so the issue can be closed.

Thank you all for suggestions.


Jan Wielkiewicz