Graphical login broken on core-updates

Graphical login broken on core-updates

[Andreas Enge]

Hello all,

first the good news: On my x86_64 machine, most of what I need is available
from core-updates. I just updated my system and one user. This includes
- xfce4 (gnome also builds)
- openjdk
- ghc-pandoc
- calibre (with qt@5, python and python-pyqt)
- unison (so also ocaml)
- icecat
- ungoogled-chromium
wine cannot be compiled, which reflects the worse state of i686 compared
to x86_64, which is an area of work for the weekend!

The first annoying thing: locales are broken, mutt does not show accented
characters any more.

Worse:
I cannot log in to xfce4 with gdm: gdm starts, I can enter my user name and
password, then I end up with a black screen with a graphical mouse pointer
that reacts to moving the mouse, but nothing more. Ctrl-alt-f1 followed by
ctrl-alt-f7 brings me back to the gdm login screen. I tried to delete a few
random directories in .config and .cache, but to no avail; maybe they were
not the right ones... I also rolled back just the user profile, which was
also not enough. During this time, logging into xfce4 with a second user,
whose profile was still on master, was possible.

I could "solve" the problem by rolling back both the user and the system.
So at least the Guix killer feature still works ;-)

Do you have an idea what is happening? Is there anything I can do? Are
there bugs in core-updates? Is there anything we should tell users before
merging? Thanks for your enlightenment!

Andreas

Julia and Ocaml (was Re: Graphical login broken on core-updates)

[Simon Tournier]

Hi Andreas,

On mer., 12 avril 2023 at 15:57, Andreas Enge <andreas@enge.fr> wrote:

> first the good news: On my x86_64 machine, most of what I need is available
> from core-updates. I just updated my system and one user. This includes

[...]

> - unison (so also ocaml)

Well, OCaml is not in good shape.  The update of grep breaks
ocaml-ppxlib-0.25.1 and so many OCaml packages.

core-updates:
https://ci.guix.gnu.org/build/823639/details

master:
https://ci.guix.gnu.org/build/345262/details


Well, from <https://ci.guix.gnu.org/eval/390508/dashboard> we see some
broken ecosystem, as Julia or Tryton or Python.

About Julia [1], it comes from the update of mpfr and I have no clue how
to fix that.  Any idea?

--8<---------------cut here---------------start------------->8---
Error in testset mpfr:
Test Failed at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/test/mpfr.jl:664
  Expression: string(nextfloat(BigFloat(1))) == str
   Evaluated: "1.0" == "1.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000012"
Error in testset mpfr:
Test Failed at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/test/mpfr.jl:667
  Expression: string(parse(BigFloat, "0.1")) == "0.10000002"
   Evaluated: "0.1" == "0.10000002"
Error in testset mpfr:
Test Failed at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/test/mpfr.jl:669
  Expression: string(parse(BigFloat, "-9.9")) == "-9.9000015"
   Evaluated: "-10.0" == "-9.9000015"
Error in testset mpfr:
Test Failed at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/test/mpfr.jl:672
  Expression: string(parse(BigFloat, "0.1")) == "0.10000000000002"
   Evaluated: "0.1" == "0.10000000000002"
Error in testset mpfr:
Test Failed at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/test/mpfr.jl:674
  Expression: string(parse(BigFloat, "-9.9")) == "-9.8999999999942"
   Evaluated: "-10.0" == "-9.8999999999942"
--8<---------------cut here---------------end--------------->8---

1: https://ci.guix.gnu.org/build/826760/log/raw


Cheers,
simon

Re: OCaml (was Re: Graphical login broken on core-updates)

[Simon Tournier]

Hi,

On mer., 12 avril 2023 at 17:39, Simon Tournier <zimon.toutoune@gmail.com> wrote:

> Well, OCaml is not in good shape.  The update of grep breaks
> ocaml-ppxlib-0.25.1 and so many OCaml packages.

Fixed by v2 of <https://issues.guix.gnu.org/62796>.

The only still broken packages is ocaml-uring which is not blocking for
the merge, IMHO.

Cheers,
simon

Re: OCaml (was Re: Graphical login broken on core-updates)

[Csepp]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On mer., 12 avril 2023 at 17:39, Simon Tournier <zimon.toutoune@gmail.com> wrote:
>
>> Well, OCaml is not in good shape.  The update of grep breaks
>> ocaml-ppxlib-0.25.1 and so many OCaml packages.
>
> Fixed by v2 of <https://issues.guix.gnu.org/62796>.
>
> The only still broken packages is ocaml-uring which is not blocking for
> the merge, IMHO.
>
> Cheers,
> simon

I'm pretty sure I added uring for Mirage stuff, which no one uses yet
except me, so yeah, not blocking.
Although I'm not looking forward to fixing it on my next rebase.

Re: OCaml (was Re: Graphical login broken on core-updates)

[pukkamustard]

Csepp <raingloom@riseup.net> writes:

> I'm pretty sure I added uring for Mirage stuff, which no one uses yet
> except me, so yeah, not blocking.
> Although I'm not looking forward to fixing it on my next rebase.

I'm using ocaml-uring via ocaml-eio. I'll have a look at the build
issue.

-pukkamustard

Re: OCaml (was Re: Graphical login broken on core-updates)

[pukkamustard]

Hm, it seems to build: https://ci.guix.gnu.org/build/891468/details

pukkamustard <pukkamustard@posteo.net> writes:

> Csepp <raingloom@riseup.net> writes:
>
>> I'm pretty sure I added uring for Mirage stuff, which no one uses yet
>> except me, so yeah, not blocking.
>> Although I'm not looking forward to fixing it on my next rebase.
>
> I'm using ocaml-uring via ocaml-eio. I'll have a look at the build
> issue.
>
> -pukkamustard

Re: OCaml (was Re: Graphical login broken on core-updates)

[Andreas Enge]

Am Thu, Apr 13, 2023 at 07:33:49AM +0000 schrieb pukkamustard:
> I'm using ocaml-uring via ocaml-eio. I'll have a look at the build
> issue.

Hm, whatever happened, maybe Simon's patch also solved this problem,
maybe it was a non-deterministic build failure, but I am getting
ocaml-uring through the build farm now.

Andreas

Re: OCaml (was Re: Graphical login broken on core-updates)

[Simon Tournier]

Hi,

On Thu, 13 Apr 2023 at 08:05, pukkamustard <pukkamustard@posteo.net> wrote:

> Hm, it seems to build: https://ci.guix.gnu.org/build/891468/details

On Thu, 13 Apr 2023 at 10:09, Andreas Enge <andreas@enge.fr> wrote:

> Hm, whatever happened, maybe Simon's patch also solved this problem,
> maybe it was a non-deterministic build failure, but I am getting
> ocaml-uring through the build farm now.

Arf, it does not build on my machine.  And not on master too; the same
error.

Well, it is not blocking for the core-updates merge.

Still, I will open a bug report because it means something is not
reproducible and to be honest I find that a bit scary because it
potentially mean the output would depend on the Linux kernel of the
host.

Cheers,
simon

OCaml4.07 (was Re: Graphical login broken on core-updates)

[Simon Tournier]

Hi,

Well, ocaml-4.07.1 is broken [1] on core-updates, mainly because [2]:

--8<---------------cut here---------------start------------->8---
building of `/gnu/store/mc6cbczwjlsnc3hlqj3kqlyhgfc8yk0c-camlboot-0.0.0-1.45045d0.drv' timed out after 3600 seconds of silence
@ build-failed /gnu/store/mc6cbczwjlsnc3hlqj3kqlyhgfc8yk0c-camlboot-0.0.0-1.45045d0.drv - timeout
cannot build derivation `/gnu/store/vyhk28gzjng5va9n3k22g1qz3ikk36pl-ocaml-boot-4.07.1.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/0vwlmbqc6nq64bmwi9qnc0fvldwkflcp-ocaml-4.07.1.drv': 1 dependencies couldn't be built
--8<---------------cut here---------------end--------------->8---

1: https://ci.guix.gnu.org/build/752949/details
2: https://ci.guix.gnu.org/build/752949/log/raw


Well, the package ’camlboot’ already have:

--8<---------------cut here---------------start------------->8---
      (properties
       ;; 10 hours, mostly for arm, more than 1 expected even on x86_64
       `((max-silent-time . 36000)))
--8<---------------cut here---------------end--------------->8---

and Lars pointed [3] that Cuirass does not honor this property.

WDYT?


Cheers,
simon


3: https://yhetil.org/guix/ZDkvrxC77+LoqzKn@noor.fritz.box

Re: OCaml4.07 (was Re: Graphical login broken on core-updates)

[Maxim Cournoyer]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> Well, ocaml-4.07.1 is broken [1] on core-updates, mainly because [2]:
>
> building of `/gnu/store/mc6cbczwjlsnc3hlqj3kqlyhgfc8yk0c-camlboot-0.0.0-1.45045d0.drv' timed out after 3600 seconds of silence
> @ build-failed /gnu/store/mc6cbczwjlsnc3hlqj3kqlyhgfc8yk0c-camlboot-0.0.0-1.45045d0.drv - timeout
> cannot build derivation `/gnu/store/vyhk28gzjng5va9n3k22g1qz3ikk36pl-ocaml-boot-4.07.1.drv': 1 dependencies couldn't be built
> cannot build derivation `/gnu/store/0vwlmbqc6nq64bmwi9qnc0fvldwkflcp-ocaml-4.07.1.drv': 1 dependencies couldn't be built
>
>
> 1: https://ci.guix.gnu.org/build/752949/details
> 2: https://ci.guix.gnu.org/build/752949/log/raw
>
>
> Well, the package ’camlboot’ already have:
>
>       (properties
>        ;; 10 hours, mostly for arm, more than 1 expected even on x86_64
>        `((max-silent-time . 36000)))
>
> and Lars pointed [3] that Cuirass does not honor this property.

I think it does, nowadays.  We'd have to cross-check in Cuirass source
to confirm.

-- 
Thanks,
Maxim

Re: Julia and Ocaml

[Andreas Enge]

TLDR: Solution for julia in the last paragraph.


Am Wed, Apr 12, 2023 at 05:39:23PM +0200 schrieb Simon Tournier:
> About Julia [1], it comes from the update of mpfr and I have no clue how
> to fix that.  Any idea?

Well, mixing base 10 and base 2 calls for trouble... I will try to go
through this, maybe we can get an idea of the cause. But it depends on
the Julia functions parse and string, so it could mean quite some work
to go through their source code.

> Error in testset mpfr:
> Test Failed at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/test/mpfr.jl:667
>   Expression: string(parse(BigFloat, "0.1")) == "0.10000002"
>    Evaluated: "0.1" == "0.10000002"

This comes from the following code:
    setprecision(21) do
        @test string(parse(BigFloat, "0.1")) == "0.10000002"
...
I assume that means that we are working with 21 bit floating point
precision.
0.1 lies between 1677721*2^-24 and 1677722*2^-24, but is closer to the
latter. So with rounding to nearest, I would expect the result of
parse(BigFloat, "0.1")) to be 1677722*2^-24. Now one would need to know
what the string function does. MPFR, for instance, has a function that
either allows the user to fix the number of digits, or (by passing 0)
outputs a few extra digits so that, when reading the number again into
a variable of 21 bits, one is sure to recover the same number 1677722*2^-24.
Of course here "0.1" would be a good output; but the semantic does not
specify the output, anything sufficiently close to 0.1 would also be
considered correct. Here 0.10000002*2^24 = 1677721.93554432, and it
would also be read in again as 1677722*2^-24.
(Otherwise said, the equivalent functions of parse and string from mpfr
satisfy parse o string == id; instead of checking whether string o parse
outputs a specific value, I think it would have been better to test
whether parse o string o parse == parse on some values).

I looked at the source code of julia, but am not sufficiently familiar with
it to understand where and how parse and string are defined. I think they
might use mpfr_set_str for parse and mpfr_asprintf for string. At least
I see this in base/mpfr.jl:
function string_mpfr(x::BigFloat, fmt::String)
    pc = Ref{Ptr{UInt8}}()
    n = ccall((:mpfr_asprintf,libmpfr), Cint,
              (Ptr{Ptr{UInt8}}, Ptr{UInt8}, Ref{BigFloat}...),
              pc, fmt, x)
...
function _string(x::BigFloat, fmt::String)::String
    isfinite(x) || return string(Float64(x))
    _prettify_bigfloat(string_mpfr(x, fmt))
end
_string(x::BigFloat) = _string(x, "%Re")
_string(x::BigFloat, k::Integer) = _string(x, "%.$(k)Re")

The format string "%Re" means output an mpfr ("R") and use the precision
convention as detailed above ("e").

I tried to mimick this with pure mpfr code; both libraries, the 4.1.0 we
have in Guix master and 4.2.0, read in 0.1 as 1677722*2^-24, then output
it again as 1.0000002e-01. The julia function _prettify_bigfloat from
mpfr.jl probably transforms this into 0.10000002.

So I have no idea why in the test apparently string(parse(BigFloat, "0.1"))
yields "0.1".

Oh, I do; here is a change:
-_string(x::BigFloat) = _string(x, "%.Re")
+_string(x::BigFloat) = _string(x, "%Re")
With the . in the format string, mpfr@4.2 indeed prints out 1e-01,
whereas mpfr@4.1 used to print 1.0000002e-01. (News item from MPFR:
"Bug fixes: In particular, for the formatted output functions (mpfr_printf,
etc.), the case where the precision consists only of a period has been
fixed to be like .0 as specified in the ISO C standard, and the manual has
been corrected and clarified.")

This is part of a larger commit
commit 1e5fdb29f8858f3244f6aff116ee12e4c8247f3a
Author: Simon Byrne <simon.byrne@gmail.com>
Date:   Tue Jan 10 14:52:36 2023 -0800
    update MPFR to 4.2.0 (#48165)
    Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>

This should be part of the upcoming 1.9.0 release of julia.
You could try to apply this commit in isolation, or update to 1.8.5 and
apply the commit then if it does not apply otherwise.

Good luck!

Andreas

Re: Julia

[Simon Tournier]

Hi Andreas,

On Wed, 12 Apr 2023 at 19:39, Andreas Enge <andreas@enge.fr> wrote:
>
> TLDR: Solution for julia in the last paragraph.

Thanks for the detailed explanations, I am learning. :-)


> commit 1e5fdb29f8858f3244f6aff116ee12e4c8247f3a
> Author: Simon Byrne <simon.byrne@gmail.com>

[...]

> You could try to apply this commit in isolation, or update to 1.8.5 and
> apply the commit then if it does not apply otherwise.

Considering your explanations and the source of the failure, I will
try one or the other to fix Julia build.

Thanks a lot!

Cheers,
simon