Re: [gnome-team] gtk+ on core-updates

[Andreas Enge]

Hello!

Am Tue, Apr 11, 2023 at 02:36:13PM -0400 schrieb Maxim Cournoyer:
> > I am also still questioning whether we should include gnome-boxes into the
> > gnome meta package; it is a bit surprising to have a desktop environment
> > depend on qemu.
> GNOME Boxes is really part of the default GNOME suite though, I think.
> I think it's good to stick to what upstream GNOME thinks should be part
> of GNOME (for consistency), even if that may sometimes feel a bit odd.

Indeed, this kind of decisions should be taken at the discretion of the
Gnome team, and following upstream is a reasonable choice.

> I can now build 'gnome', 
> /gnu/store/4gb42b6wfs316z0p1v9m42v1xapw40gx-gnome-42.4.

Excellent! And all substitutes are available from the build farms
for x86_64. Thanks!

Andreas

Re: Guidelines for pre-trained ML model weight binaries (Was re: Where should we put machine learning model parameters?)

[Csepp]

Nathan Dehnel  writes:

>  a) Bit-identical re-train of ML models is similar to #2; other said
> that bit-identical re-training of ML model weights does not protect
> much against biased training.  The only protection against biased
> training is by human expertise.
>
> Yeah, I didn't mean to give the impression that I thought
> bit-reproducibility was the silver bullet for AI backdoors with that
> analogy. I guess my argument is this: if they release the training
> info, either 1) it does not produce the bias/backdoor of the trained
> model, so there's no problem, or 2) it does, in which case an expert
> will be able to look at it and go "wait, that's not right", and will
> raise an alarm, and it will go public. The expert does not need to be
> affiliated with guix, but guix will eventually hear about it. Similar
> to how a normal security vulnerability works.
>
>  b) The resources (human, financial, hardware, etc.) for re-training is,
> for most of the cases, not affordable.  Not because it would be
> difficult or because the task is complex, this is covered by the
> point a), no it is because the requirements in term of resources is
> just to high.
>
> Maybe distributed substitutes could change that equation?

Probably not, it would require distributed *builds*.  Right now Guix
can't even use distcc, so it definitely can't use remote GPUs.

Re: Time travel accident

[Konrad Hinsen]

Konrad Hinsen  writes:

>building profile with 1 package...
>;;; WARNING: loading compiled file 
> /gnu/store/41zsnwsk02549kqb5njd3fadgnmkzww8-guix-module-union/lib/guile/3.0/site-ccache/guix/ui.go
>  failed:
>;;; In procedure load-thunk-from-memory: incompatible bytecode kind

I tried to track down why this file remains in the store even after
clearing the "inferiors" cache and doing a gc. Tracking the chain of
referrers, I find:

  /gnu/store/41zsnwsk02549kqb5njd3fadgnmkzww8-guix-module-union
  –> /gnu/store/7r72vknkpnpgp143ckh5kfbg5zan3xsp-guix-command
  –> /gnu/store/cwqaas3mwlx2rhc0ckzmqvygmy7n2s7k-guix-ce35dc8
  –> /gnu/store/2h03nwj2r2jywjk5sk7sxn2hgm979v2m-profile

This last item has two referrers:

 1. /gnu/store/9gfmn1yra7rzavxb9wppqi4lpdvqid8c-inferior-script.scm
 2. itself!

The only items I have encountered so far that have themselves as
referrers are gc roots. But this profile item is not in the list of gc
roots.

The inferior-script item has no referrers at all. It's not a gc root
either. Nevertheless, it is on the output of "guix gc --list-live".
According to my understanding of the store, that shouldn't be possible!

Cheers,
  Konrad.

Re: Time travel accident

[Simon Tournier]

Hi Konrad,

On mar., 11 avril 2023 at 17:20, Konrad Hinsen  
wrote:

>Backtrace:
>   5 (primitive-load 
> "/home/hinsen/.cache/guix/inferiors/wisrwo5p2aq7o6r…")
>In ice-9/eval.scm:
>619:8  4 (_ #(#(#) 
> "/home/hinsen/.cache…" …))
>619:8  3 (_ #(#(#)))
>159:9  2 (_ #(#(#)))
>   223:20  1 (proc #(#(#)))
>In unknown file:
>   0 (%resolve-variable (7 . _IOLBF) # 7f7fc35115a0>)
>
>ERROR: In procedure %resolve-variable:
>_IOLBF: unbound variable

I get the same thing without doing anything special.

--8<---cut here---start->8---
$ date
mer. 12 avril 2023 12:09:47 CEST

$ guix time-machine --commit=ce35dc84a10b05dc891bfae03f613b907337945e -- help
;;; WARNING: loading compiled file 
/gnu/store/41zsnwsk02549kqb5njd3fadgnmkzww8-guix-module-union/lib/guile/3.0/site-ccache/guix/ui.go
 failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode kind

[...]

;;; In procedure load-thunk-from-memory: incompatible bytecode version
WARNING: Use of `load' in declarative module (guix ui).  Add #:declarative? #f 
to your define-module invocation.
Backtrace:
   5 (primitive-load "/home/simon/.cache/guix/inferiors/wisrwo5p2aq7…")
In ice-9/eval.scm:
619:8  4 (_ #(#(#) "/home/simon/.ca…" …))
619:8  3 (_ #(#(#)))
159:9  2 (_ #(#(#)))
   223:20  1 (proc #(#(#)))
In unknown file:
   0 (%resolve-variable (7 . _IOLBF) #)

ERROR: In procedure %resolve-variable:
_IOLBF: unbound variable
--8<---cut here---end--->8---

Well, it seems related to the Guile version and not about the host
date.  Hum, wait, is it possible to time-travel to:

ce35dc84a10b05dc891bfae03f613b907337945e
Author: Marius Bakke 
AuthorDate: Thu Mar 29 02:56:00 2018 +0200
Commit: Marius Bakke 
CommitDate: Thu Mar 29 02:56:00 2018 +0200

?  It pre-dates v1.0 from May 2019.  And inferiors had been introduced
around v0.15 from July 2018 [1,2,3].

Well, v1.0 appears to me as the zero for time-travel – soft limit.  And
the introduction of inferiors is the hard limit, so I guess you are
hitting that limit, no?


Cheers,
simon

1: https://guix.gnu.org/blog/2018/gnu-guix-and-guixsd-0.15.0-released/
2: 
https://guix.gnu.org/en/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/
3: https://issues.guix.gnu.org/32115#8

Re: A Joyous Core-Updates Week-End 🎉

[Simon Tournier]

Hi,

On mer., 12 avril 2023 at 00:16, Josselin Poiret  wrote:

> 2) Hack on `core-updates`.

In addition, if you lack inspiration, pick one red bullet! :-)

>From CI , choose the last
evaluation, column Action, click to the “screen” (dashboard) and from
this dashboard, e.g., 

If you prefer to select your preferred package, in the “search for jobs”
bar, just type the name, say ’julia-’.  Oh no, almost all red.

Click one, say the bullet corresponding to ’julia-abstractffts-1.0.1’
.  Status: red triangle
Failed (dependency), therefore click “Show more”, and the red cross is
the one to fix.  Else, recursively click.

Here ’julia-1.8.3’ is failing
.  Let open the ’raw’ Log
file: .  Bottom shows the
failure, here the test suite.

Then checkout the core-updates branch in some Git worktree and try to
fix. :-)


Cheers,
simon

Re: A Joyous Core-Updates Week-End 🎉

[Maxim Cournoyer]

Hi Josselin,

Josselin Poiret  writes:

> Hello everyone,
>
> It's that time of the year again!  Merging core-updates!  Do you *want*
> glibc 2.35, gcc 11 as default, mesa 22, python 3.10, and more?!  Here's
> your chance!

Thanks for the initiative!  core-updates seems to be shaping up well,
it's good to have people test it! :-) I'm trying to get the staging
branch merged into master, after which I'll try a master -> core-updates
merge, hopefully in time for the test weekend so that all efforts can
converge there.

Cheers!

-- 
Thanks,
Maxim

Re: Time travel accident

[Konrad Hinsen]

Hi Simon,

> I get the same thing without doing anything special.

Interesting. Before my clock-changing experiment, the same command line
got me much further: the old Guix started to work and only failed when
building OpenSSL.

> Well, v1.0 appears to me as the zero for time-travel – soft limit.  And
> the introduction of inferiors is the hard limit, so I guess you are
> hitting that limit, no?

Another good question. I have hit it often enough in the past, but the
error message I got looked different. But then, I guess the error
message for illicit time travel is not part of the documented behavior
of Guix.

Cheers,
  Konrad.

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

Re: Time travel accident

[Simon Tournier]

Hi,

On mer., 12 avril 2023 at 12:17, Konrad Hinsen  
wrote:

>   /gnu/store/41zsnwsk02549kqb5njd3fadgnmkzww8-guix-module-union
>   –> /gnu/store/7r72vknkpnpgp143ckh5kfbg5zan3xsp-guix-command
>   –> /gnu/store/cwqaas3mwlx2rhc0ckzmqvygmy7n2s7k-guix-ce35dc8
>   –> /gnu/store/2h03nwj2r2jywjk5sk7sxn2hgm979v2m-profile
>
> This last item has two referrers:
>
>  1. /gnu/store/9gfmn1yra7rzavxb9wppqi4lpdvqid8c-inferior-script.scm
>  2. itself!

I have,

--8<---cut here---start->8---
$ guix gc --list-dead | grep 9gfmn1yra7rzavxb9wppqi4lpdvqid8c
finding garbage collector roots...
determining live/dead paths...
/gnu/store/9gfmn1yra7rzavxb9wppqi4lpdvqid8c-inferior-script.scm

$ guix gc --references 
/gnu/store/9gfmn1yra7rzavxb9wppqi4lpdvqid8c-inferior-script.scm
/gnu/store/2h03nwj2r2jywjk5sk7sxn2hgm979v2m-profile

$ guix gc --referrers /gnu/store/2h03nwj2r2jywjk5sk7sxn2hgm979v2m-profile
/gnu/store/2h03nwj2r2jywjk5sk7sxn2hgm979v2m-profile
/gnu/store/9gfmn1yra7rzavxb9wppqi4lpdvqid8c-inferior-script.scm

$ guix gc --list-dead | grep 2h03nwj2r2jywjk5sk7sxn2hgm979v2m
finding garbage collector roots...
determining live/dead paths...
/gnu/store/2h03nwj2r2jywjk5sk7sxn2hgm979v2m-profile

$ guix gc -D /gnu/store/9gfmn1yra7rzavxb9wppqi4lpdvqid8c-inferior-script.scm
finding garbage collector roots...
[0 MiB] deleting 
'/gnu/store/9gfmn1yra7rzavxb9wppqi4lpdvqid8c-inferior-script.scm'
deleting `/gnu/store/trash'
deleting unused links...
note: currently hard linking saves 27283.40 MiB

$ guix gc --list-dead | grep 9gfmn1yra7rzavxb9wppqi4lpdvqid8c
finding garbage collector roots...
determining live/dead paths...

$ guix gc --referrers /gnu/store/2h03nwj2r2jywjk5sk7sxn2hgm979v2m-profile
/gnu/store/2h03nwj2r2jywjk5sk7sxn2hgm979v2m-profile
--8<---cut here---end--->8---

Do you have special options for guix-daemon or the default ones?

Well, can you run,

guix gc -D /gnu/store/2h03nwj2r2jywjk5sk7sxn2hgm979v2m-profile

?

Cheers,
simon

Imagemagick with OpenEXR support

[Théo Maxime Tyburn]

Hi guixers,

I am trying to add OpenEXR to the current Imagemagick.

I tried this out
```
(package
  (inherit imagemagick)
  (inputs (append `(("openexr" ,openexr)) (package-inputs imagemagick
```

but in the configure phase:
```
checking for OpenEXR >= 1.0.6... no
[...]
Delegate library configuration:
OpenEXR   --with-openexr=yes  no
```

I'm not sure why OpenEXR is not visible at configure time. There doesn't
seem to be any manual addition of references to include or lib
directories from the store in the current imagemagick package
definition. So I assume it should just work fine.

Any idea?

Théo

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  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  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.012"
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.1002"
   Evaluated: "0.1" == "0.1002"
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.915"
   Evaluated: "-10.0" == "-9.915"
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.12"
   Evaluated: "0.1" == "0.12"
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.89942"
   Evaluated: "-10.0" == "-9.89942"
--8<---cut here---end--->8---

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


Cheers,
simon

i686 core-updates failure.

[Kaelyn]

Hi,

I've been working on getting wine to build on core-updates, with the most 
recent blocker being python-numpy failing two tests on i686 (one of which is 
apparently too big for 32-bit systems, based on the comment in the Gentoo 
ebuild of python-numpy where they skip the test). I just poked through the CI 
dashboard for the latest core-updates evaluation to see if it was hitting the 
same failure (it was), and discovered an odd chain of dependencies. Before 
going into the chain, I want to mention that wine has 6 failing 
dependencies[1], one of which is pulseaudio, two of which include pulseaudio as 
part of why they failed, and two include dependency failures that are on 
pulseaudio's dependency chain (the 6th failed dependency is due to qtbase which 
I didn't look into; none are direct failures).

On to the odd chain:
* The sole failed dependency of pulseaudio is bluez
* bluez's sole failed dependency is libical
* libical's sole failed dependency is gtk-doc (also a failed dependency of two 
other wine dependencies)
* gtk-doc's sole failed dependency is dblatex
* dblatex's sole failed dependency is inkscape(?!?!?)
* inkscape's sole failed dependency is python-numpy, which is failing two tests.

I call the dependency chain odd in that pulseaudio--which is near the heart of 
a lot of Linux software that supports audio--is failing because inkscape--a 
graphical vector editor--is a dependency of a tool designed to extract API 
documentation from source code.

For the dependency chain, I have no real thoughts, goals, or proposed changes 
other than surprise that pulseaudio fails to build because a GUI SVG editor 
failed to build.

For the actual failures in python-numpy[2]:
1. TestUfunc::test_identityless_reduction_huge_array in 
numpy/core/tests/test_ufunc.py: as I alluded to earlier, the Gentoo ebuild[3] 
disables this test with a comment that the test is "too large for 32-bit 
platforms".
2. TestKind::test_all in numpy/f2py/tests/test_kind.py: I'm not sure why this 
test is failing or what to do about it, since it seems to be seeing incorrect 
values for objects coming from Fortran code. Perhaps a type size mismatch for 
32-bit platforms, but hard for me to say since I don't know Fortran and I 
haven't had luck finding other reports of that test failing.

Cheers,
Kaelyn


[1] https://ci.guix.gnu.org/build/843194/details
[2] https://ci.guix.gnu.org/build/712672/log/raw
[3] 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/numpy/numpy-1.24.0.ebuild#n142

herd stop hangs

[Vladilen Kozin]

Hello.

I wrote a shepherd service that runs a java application in a semi standard
fashion

(start
  #~(make-forkexec-constructor ...
#:user ..
#:group ..
#:environment-variables ...
(stop
  #~(make-kill-destructor)

$ sudo herd start my-service
starts without a hitch, but

$ sudo stop my-service
simply hangs for the default 5sec until Shepherd SIGKILLs it (as per
/var/log/messages) and even after that console where I run the herd stop
command doesn't get released until I manually CTRL-C it.

Been driving me nuts, cause Java handles SIGTERM but just in case I even
added shutdownHook to my app that should explicitly execute on SIGTERM and
other such signals. Testing it on OSX e.g. works just fine. But stop
wouldn't work on guix. I then decided to try everything manually:

$ start my java app from the console

In another console
$ sudo pkill -TERM pid

and nada ... it's like signal isn't even delivered.
$ sudo pkill -KILL pid

Eh ... still nothing
$ sudo kill -s SIGTERM pid
gets delivered

Ha? kill vs pkill ... ha? Could this give a clue as to why sudo herd stop
won't work?
What is going on here? Any ideas? I'm completely lost at this point.
-- 
Best regards
Vlad Kozin

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

[Simon Tournier]

Hi,

On mer., 12 avril 2023 at 17:39, Simon Tournier  
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 .

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

Cheers,
simon

Status of Julia on core-updates (was Re: A Joyous Core-Updates Week-End 🎉)

[Simon Tournier]

Hi,

> 2) Hack on `core-updates`.

About x86_64, the build failure of Julia [1] seems coming 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.012"
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.1002"
   Evaluated: "0.1" == "0.1002"
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.915"
   Evaluated: "-10.0" == "-9.915"
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.12"
   Evaluated: "0.1" == "0.12"
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.89942"
   Evaluated: "-10.0" == "-9.89942"
--8<---cut here---end--->8---



About i686, Julia is broken since February on master, probably by [2],
therefore, this broken state for i686 is not blocking for the merge.

1: https://ci.guix.gnu.org/build/826760/log/raw
2: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1750d68309e26293c2da5aad953a061867f2cb14


Cheers,
simon on the behalf of the Julia team

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.1002"
>Evaluated: "0.1" == "0.1002"

This comes from the following code:
setprecision(21) do
@test string(parse(BigFloat, "0.1")) == "0.1002"
...
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.1002*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.002e-01. The julia function _prettify_bigfloat from
mpfr.jl probably transforms this into 0.1002.

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.002e-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 
Date:   Tue Jan 10 14:52:36 2023 -0800
update MPFR to 4.2.0 (#48165)
Co-authored-by: Mosè Giordano 

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  wrote:
>
> TLDR: Solution for julia in the last paragraph.

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


> commit 1e5fdb29f8858f3244f6aff116ee12e4c8247f3a
> Author: Simon Byrne 

[...]

> 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

Re: Status of Julia on core-updates (was Re: A Joyous Core-Updates Week-End 🎉)

[Simon Tournier]

Hi,

On Wed, 12 Apr 2023 at 19:32, Simon Tournier  wrote:

> About x86_64, the build failure of Julia [1] seems coming from the
> update of MPFR and I have no clue how to fix that.  Any idea?

In case people overlooked, Andreas provided the way to fix in
.

Cheers,
simon

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

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On mer., 12 avril 2023 at 17:39, Simon Tournier  
> 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 .
>
> 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: Imagemagick with OpenEXR support

[Csepp]

Théo Maxime Tyburn  writes:

> Hi guixers,
>
> I am trying to add OpenEXR to the current Imagemagick.
>
> I tried this out
>
> ```
> (package
>   (inherit imagemagick)
>   (inputs (append `(("openexr" ,openexr)) (package-inputs imagemagick
> ```
>
> but in the configure phase:
> ```
> checking for OpenEXR >= 1.0.6... no
> [...]
> Delegate library configuration:
> OpenEXR   --with-openexr=yes  no
> ```
>
> I'm not sure why OpenEXR is not visible at configure time. There doesn't
> seem to be any manual addition of references to include or lib
> directories from the store in the current imagemagick package
> definition. So I assume it should just work fine.
>
> Any idea?
>
> Théo

If we are going by semver, then 1.0.6 is incompatible with 3.x.  Maybe
it expects an older version?

rrdtool hash mismatch

[Aleksandr Vityazev]

Hi,

rrdtool package has not been updated for several years and according to
ci.guix.gnu.org builds normally, but if you run:

./pre-inst-env guix build --no-substitutes --check --no-grafts rrdtool

it outputs an error
sha256 hash mismatch for 
/gnu/store/icyq4d3fsbbf2yw3dmg7cxgb05qzfd3q-rrdtool-1.7.2.tar.gz:
expected hash: 1nsqra0g2nja19akmf9x5y9hhgc35ml3w9dcdz2ayz7zgvmzmm6d1
actual hash: 029r3h7l06m3sy9q0hr2krvinhzkqvyl14wj7qjck79bm7rdvp48

which looks strange to me. Maybe it's not, but I haven't figured out
why?

-- 
Best regards,
Aleksandr Vityazev

Re: herd stop hangs

[Attila Lendvai]

> What is going on here? Any ideas? I'm completely lost at this point.

a random stab: with custom service code, it's possible to put shepherd into a 
state where it doesn't respond to herd remote requests anymore (nor 
shutdown/reboot requests). try if your shepherd works fine otherwise, e.g. with 
other services. if not, then the issue might be in the code that starts your 
service.

unfortunately i can't remember anymore what caused this for me, and shepherd 
has also seen a few fixes since then.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The penalty for laughing in a courtroom is six months in jail; if it were not 
for this penalty, the jury would never hear the evidence.”
— H.L. Mencken (1880–1956)

Re: [core-updates] qtbase 6 ssl tests fail.

[Josselin Poiret]

Hi Ricardo,

I see you've fixed this by disabling the qssl tests, however I think
this is a shortcoming on our part.  Qt 6.4 has a fix for this, so I
wanted to upgrade our Qt to 6.5.0.  Upstream only supports the Ninja
CMake generator, so I also adapted the package definition to it.  One
issue is that one file takes 4G of RAM to build on my computer, and so
gets terminated on a parallel build.  What would be the usual policy
with such a problem?

Disabling parallel builds for Qt 6 would massively slow the whole build,
so I'm not sure this is a solution either.

Here's the patch I have for now.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

[PATCH] WIP upgrade qt 6 to 6.5.0

[Josselin Poiret]

---
 gnu/packages/qt.scm | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index acf2d70736..46fbdb2368 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -68,6 +68,7 @@ (define-module (gnu packages qt)
   #:use-module (gnu packages cmake)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages cpp)
+  #:use-module (gnu packages crypto)
   #:use-module (gnu packages cups)
   #:use-module (gnu packages curl)
   #:use-module (gnu packages databases)
@@ -593,29 +594,28 @@ (define-public qtbase-5
 (define-public qtbase
   (package/inherit qtbase-5
 (name "qtbase")
-(version "6.3.2")
+(version "6.5.0")
 (source (origin
   (inherit (package-source qtbase-5))
   (uri (qt-urls name version))
   (sha256
(base32
-"19m9r8sf9mvyrwipn44if3nhding4ljys2mwf04b7dkhz16vlabr"))
+"1vzmxak112llvnx9rdgss99i9bc88rzsaxn59wdyqr5y9xxsmqgx"))
   (modules '((guix build utils)))
   (snippet
;; corelib uses bundled harfbuzz, md4, md5, sha3
'(with-directory-excursion "src/3rdparty"
   (for-each delete-file-recursively
-;; The bundled pcre2 copy is kept, as its headers
-;; are required by some internal bootstrap target
-;; used for the tools.
-(list "double-conversion" "freetype" "harfbuzz-ng"
-  "libpng" "libjpeg" "sqlite" "xcb" 
"zlib"))
+(list "blake2" "double-conversion" "freetype"
+  "harfbuzz-ng" "libpng" "libjpeg" "pcre2"
+  "sqlite" "xcb" "zlib"))
 (build-system cmake-build-system)
 (arguments
  (substitute-keyword-arguments (package-arguments qtbase-5)
((#:configure-flags _ ''())
 `(let ((out (assoc-ref %outputs "out")))
-   (list "-DQT_BUILD_TESTS=ON"
+   (list "-GNinja"
+ "-DQT_BUILD_TESTS=ON"
  (string-append "-DINSTALL_ARCHDATADIR=" out "/lib/qt6")
  (string-append "-DINSTALL_DATADIR=" out "/share/qt6")
  (string-append "-DINSTALL_DOCDIR=" out "/share/doc/qt6")
@@ -759,9 +759,6 @@ (define-public qtbase
   ;; The 'tst_qfilesystemwatcher' installs a watcher on
   ;; '/home', which doesn't exist in the build container.
   "tst_qfilesystemwatcher"
-  ;; Not all of the tested formats are supported by our
-  ;; build of openssl; 871 passed, 122 failed.
-  "tst_qsslkey"
   ;; The 'mockplugins' test fail following error: "Unknown
   ;; platform linux-g++", and the other plugin tests
   ;; depend on it.
@@ -848,14 +845,21 @@ (define-public qtbase
'("device_config.prf" "moc.prf" 
"qt_build_config.prf"
  "qt_config.prf"))
 (("\\$\\$\\[QT_HOST_DATA/get\\]") archdata)
-(("\\$\\$\\[QT_HOST_DATA/src\\]") archdata)
+(("\\$\\$\\[QT_HOST_DATA/src\\]") archdata)
+(replace 'build
+  (lambda* _
+(invoke "cmake" "--build" ".")))
+(replace 'install
+  (lambda* _
+(invoke "cmake" "--install" ".")))
 (native-inputs
  (modify-inputs (package-native-inputs qtbase-5)
-   (prepend wayland-protocols
+   (prepend ninja
+wayland-protocols
 xvfb-run)))
 (inputs
  (modify-inputs (package-inputs qtbase-5)
-   (prepend bash-minimal coreutils-minimal libxcb md4c)
+   (prepend bash-minimal coreutils-minimal libb2 libxcb md4c)
(replace "postgresql" postgresql))) ;use latest postgresql
 (native-search-paths
  (list (search-path-specification

base-commit: ac8b2a0469a4884353ac5c0f0854012da0b04fda
-- 
2.39.2

staging merge into master

[Maxim Cournoyer]

Hello,

I'm planning to merge staging into master soon (tomorrow or friday),
unless someone has a problem with it.  It includes at least two CVE
fixes as well as a bunch of updates such as a newer gstreamer, ffmpeg,
qt 5, python-cryptography and a few others, and seems to be close to
master in terms of coverage (currently 68% for staging vs 73% for
master, according to https://ci.guix.gnu.org/).

I was able to reconfigure my system with it, and haven't seen issues so
far.  Testing welcome!

-- 
Thanks,
Maxim

Re: i686 core-updates failure.

[Josselin Poiret]

Hi Kaelyn,

Kaelyn  writes:

> I call the dependency chain odd in that pulseaudio--which is near the heart 
> of a lot of Linux software that supports audio--is failing because 
> inkscape--a graphical vector editor--is a dependency of a tool designed to 
> extract API documentation from source code.

I agree that this is quite a "heavy" dependency chain for pulseaudio,
but this is also the case for most programs which produce documentation.
In the end, they also don't retain references to inkscape, so once
they're built on CI, anyone using substitutes wouldn't need to download
all of that part of the dependency chain.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: rrdtool hash mismatch

[Josselin Poiret]

Hi,

Aleksandr Vityazev  writes:

> Hi,
>
> rrdtool package has not been updated for several years and according to
> ci.guix.gnu.org builds normally, but if you run:
>
> ./pre-inst-env guix build --no-substitutes --check --no-grafts rrdtool
>
> it outputs an error
> sha256 hash mismatch for 
> /gnu/store/icyq4d3fsbbf2yw3dmg7cxgb05qzfd3q-rrdtool-1.7.2.tar.gz:
> expected hash: 1nsqra0g2nja19akmf9x5y9hhgc35ml3w9dcdz2ayz7zgvmzmm6d1
> actual hash: 029r3h7l06m3sy9q0hr2krvinhzkqvyl14wj7qjck79bm7rdvp48
>
> which looks strange to me. Maybe it's not, but I haven't figured out
> why?

The upstream-provided tarball has probably been changed on the server
without a version bump.  The reason why you can still use it with
substitutes is that Guix just uses the version that's built with the old
tarball because we know its hash.  When you try to download it from
upstream, Guix rightfully complains that the hash has changed and
refuses to go forward!

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: staging merge into master

[Josselin Poiret]

Hi Maxim,

Maxim Cournoyer  writes:

> Hello,
>
> I'm planning to merge staging into master soon (tomorrow or friday),
> unless someone has a problem with it.  It includes at least two CVE
> fixes as well as a bunch of updates such as a newer gstreamer, ffmpeg,
> qt 5, python-cryptography and a few others, and seems to be close to
> master in terms of coverage (currently 68% for staging vs 73% for
> master, according to https://ci.guix.gnu.org/).
>
> I was able to reconfigure my system with it, and haven't seen issues so
> far.  Testing welcome!

I'm a bit conflicted on this one, as:
+ this could let us get rid of staging as well!
+ this might fix some build issues and package errors on core-updates
(as well as fix CVEs!)
- this might create some build issues and package errors on core-updates
- we might not have time for a full CI run on core-updates before this
week-end.

I don't have a particularly strong opinion either way, but if you do
merge it, could you make sure to also merge master into c-u and launch a
CI evaluation right afterwards?  Thanks for taking care of staging!

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: staging merge into master

[Andreas Enge]

Hello Maxim,

Am Wed, Apr 12, 2023 at 04:38:20PM -0400 schrieb Maxim Cournoyer:
> I'm planning to merge staging into master soon (tomorrow or friday),
> unless someone has a problem with it.  It includes at least two CVE
> fixes as well as a bunch of updates such as a newer gstreamer, ffmpeg,
> qt 5, python-cryptography and a few others, and seems to be close to
> master in terms of coverage (currently 68% for staging vs 73% for
> master, according to https://ci.guix.gnu.org/).

tomorrow would be great, as well as the merge of master to core-updates:
That would leave a bit of time for ci to pick up the new builds, and
we would have a better starting position for the core-updates sprint
beginning on Saturday.

Thanks a lot for getting this old branch in shape!

Andreas

Re: staging merge into master

[Andreas Enge]

Am Wed, Apr 12, 2023 at 11:18:26PM +0200 schrieb Josselin Poiret:
> I don't have a particularly strong opinion either way, but if you do
> merge it, could you make sure to also merge master into c-u and launch a
> CI evaluation right afterwards?

The second part is automatic right now, ci is configured to build all
of core-updates.

Andreas

Re: i686 core-updates failure.

[Andreas Enge]

Hello,

Am Wed, Apr 12, 2023 at 04:11:58PM + schrieb Kaelyn:
> For the actual failures in python-numpy[2]:

you could always try whether an update solves the test failures; the package
has 2892 dependents, but anyway, the only option is fixing it and rebuilding
all the 2892 dependents also on x86_64, or renouncing at the 2892 dependents
on i686. I think the former would be preferable (and maybe even required for
merging).

Andreas

Re: herd stop hangs

[Vlad Kozin]

Indeed reboot / shutdown no longer work … wat :) 

Don’t have any bright ideas about possible next steps tbh. 

Best,
Vlad

> On Apr 12, 2023, at 9:05 PM, Attila Lendvai  wrote:
> 
> 
>> 
>> What is going on here? Any ideas? I'm completely lost at this point.
> 
> a random stab: with custom service code, it's possible to put shepherd into a 
> state where it doesn't respond to herd remote requests anymore (nor 
> shutdown/reboot requests). try if your shepherd works fine otherwise, e.g. 
> with other services. if not, then the issue might be in the code that starts 
> your service.
> 
> unfortunately i can't remember anymore what caused this for me, and shepherd 
> has also seen a few fixes since then.
> 
> -- 
> • attila lendvai
> • PGP: 963F 5D5F 45C7 DFCD 0A39
> --
> “The penalty for laughing in a courtroom is six months in jail; if it were 
> not for this penalty, the jury would never hear the evidence.”
>— H.L. Mencken (1880–1956)
> 

Re: staging merge into master

[Maxim Cournoyer]

Hello,

Josselin Poiret  writes:

> Hi Maxim,
>
> Maxim Cournoyer  writes:
>
>> Hello,
>>
>> I'm planning to merge staging into master soon (tomorrow or friday),
>> unless someone has a problem with it.  It includes at least two CVE
>> fixes as well as a bunch of updates such as a newer gstreamer, ffmpeg,
>> qt 5, python-cryptography and a few others, and seems to be close to
>> master in terms of coverage (currently 68% for staging vs 73% for
>> master, according to https://ci.guix.gnu.org/).
>>
>> I was able to reconfigure my system with it, and haven't seen issues so
>> far.  Testing welcome!
>
> I'm a bit conflicted on this one, as:
> + this could let us get rid of staging as well!
> + this might fix some build issues and package errors on core-updates
> (as well as fix CVEs!)
> - this might create some build issues and package errors on core-updates
> - we might not have time for a full CI run on core-updates before this
> week-end.
>
> I don't have a particularly strong opinion either way, but if you do
> merge it, could you make sure to also merge master into c-u and launch a
> CI evaluation right afterwards?  Thanks for taking care of staging!

Sounds good.  If I feel confident tomorrow I'll merge it to master and
tackle the probably tricky merge to core-updates at the same time.

Thanks for tipping in along with Andreas!

-- 
Thanks,
Maxim

Re: staging merge into master

[Maxim Cournoyer]

Hi Andreas,

Andreas Enge  writes:

> Hello Maxim,
>
> Am Wed, Apr 12, 2023 at 04:38:20PM -0400 schrieb Maxim Cournoyer:
>> I'm planning to merge staging into master soon (tomorrow or friday),
>> unless someone has a problem with it.  It includes at least two CVE
>> fixes as well as a bunch of updates such as a newer gstreamer, ffmpeg,
>> qt 5, python-cryptography and a few others, and seems to be close to
>> master in terms of coverage (currently 68% for staging vs 73% for
>> master, according to https://ci.guix.gnu.org/).
>
> tomorrow would be great, as well as the merge of master to core-updates:
> That would leave a bit of time for ci to pick up the new builds, and
> we would have a better starting position for the core-updates sprint
> beginning on Saturday.

Sounds good!  I'll try to do it tomorrow most probably!

> Thanks a lot for getting this old branch in shape!

My pleasure!  Thanks to you for being at the front for the core-updates
merge.

-- 
Thanks,
Maxim

A new service for Cachefilesd

[Development of GNU Guix and the GNU System distribution.]

Hi everyone,

A little while ago, Bruno Victal and I wrote a service for Cachefilesd
together. [1] I have been using it in production for several months.
Someone told me the bug was too old to be eligible for automatic CI
builds that might have attracted a committer's attention. In lieu of
that automatic signal, I am therefore sending this friendly reminder.

Cachefilesd is a daemon that uses the "FS-Cache" feature in the Linux
kernel [2] to improve the user experience with remote file systems
like NFS.

Kind regards
Felix Lechner

[1] https://issues.guix.gnu.org/41180#7
[2] https://www.kernel.org/doc/html/latest/filesystems/caching/fscache.html

Re: Commits and bug closing

[Maxim Cournoyer]

Hi Simon,

Simon Tournier  writes:

[...]

> Somehow, the current informal “convention” is to add,
>
> Fixes .
>
> in the commit message that closes specific bug.  However, it is not
> fully uniform,
>
> gnu: openjdk10: Build from hg.
>
> * gnu/packages/java.scm (openjdk10)[source]: Use HG-DOWNLOAD.
>
> This fixes 
> for OpenJDK 10.
>
>
> or
>
> gnu: icecat: Fix Kerberos support.
>
> Fixes .

I'd say the more correct one is the later, assuming a GNU change log
followed, since the change log should appear after the descriptive
commit message, if any.

-- 
Thanks,
Maxim

Re: herd stop hangs

[Ivan Sokolov]

Vladilen Kozin  writes:

> Been driving me nuts, cause Java handles SIGTERM but just in case I even added
> shutdownHook to my app that should explicitly execute on SIGTERM and other 
> such signals.
> Testing it on OSX e.g. works just fine. But stop wouldn't work on guix. I 
> then decided to try
> everything manually:
>
> $ start my java app from the console
>
> In another console
> $ sudo pkill -TERM pid
>
> and nada ... it's like signal isn't even delivered.
> $ sudo pkill -KILL pid
>
> Eh ... still nothing
> $ sudo kill -s SIGTERM pid
> gets delivered
>
> Ha? kill vs pkill ... ha? Could this give a clue as to why sudo herd stop 
> won't work?
> What is going on here? Any ideas? I'm completely lost at this point. 

I don't know about Shepherd, but I've never seen pkill used with a pid,
and pkill(1) does not mention it either.

Re: i686 core-updates failure.

[Kaelyn]

Hi,

--- Original Message ---
On Wednesday, April 12th, 2023 at 9:31 PM, Andreas Enge  wrote:


> 
> 
> Hello,
> 
> Am Wed, Apr 12, 2023 at 04:11:58PM + schrieb Kaelyn:
> 
> > For the actual failures in python-numpy[2]:
> 
> 
> you could always try whether an update solves the test failures; the package
> has 2892 dependents, but anyway, the only option is fixing it and rebuilding
> all the 2892 dependents also on x86_64, or renouncing at the 2892 dependents
> on i686. I think the former would be preferable (and maybe even required for
> merging).

I forgot to mention that I had also tried updating to the latest numpy 
(2.24.2), with the same tests failing. I agree the test failures in numpy need 
to be resolved in some way for merging core-updates, since the failure affects 
such a large number of common (desktop) applications on i686. My inclination is 
to disable both failing tests (at least for now), and possibly updating to the 
latest numpy since changing the package would trigger a rebuild anyway. I only 
hesitate about disabling TestKind.test_all since I don't know what role the 
Fortran bridging code plays in numpy and if the failure is a sign of a 
legitimate problem instead of a platform limitation (as the large array test 
failure seems to be).

Cheers,
Kaelyn

> 
> Andreas