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

[pukkamustard]

Csepp  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  writes:

> Csepp  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 + 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: Time travel accident

[Konrad Hinsen]

Simon Tournier  writes:

> 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

For me it is (well, was, see below) under "–list-live". But it has no
referrers. And...

> $ guix gc -D /gnu/store/9gfmn1yra7rzavxb9wppqi4lpdvqid8c-inferior-script.scm

fails for me (as it should for a live item).

Yesterday, I did "rm -rf ~/.cache/guix/inferiors" followed by "guix gc".
Right now, after the above tests, I did another "guix gc". And now...
the two items we are testing here are "dead" and I could remove them.

So it seems that two garbage collections are better than one, even
though nothing much happened in between (just a few "guix shell"
executions that added a few items to the store).

Cheers,
  Konrad

Powerpc on core-updates

[Andreas Enge]

Hello,

recently I claimed that powerpc was repaired, but I must have made a mistake.
It is still completely broken:
   https://ci.guix.gnu.org/eval/391720/dashboard?system=powerpc64le-linux
due to this:
   https://issues.guix.gnu.org/61879
 
It does not look easy to fix, but might be *the* blocker for a core-updates
merge...

The error is this:
../../../libstdc++-v3/src/c++17/floating_from_chars.cc: In function 
'std::from_chars_result std::from_chars(const char*, const char*, __ieee128&, 
std::chars_format)':
../../../libstdc++-v3/src/c++17/floating_from_chars.cc:499:8: error: 'string' 
is not a member of 'std::pmr'; did you mean 'std::string'?
  499 |   pmr::string buf(&mr);
  |^~
In file included from 
/tmp/guix-build-libstdc++-11.3.0.drv-0/gcc-11.3.0/build/include/string:39,
 from ../../../libstdc++-v3/src/c++17/floating_from_chars.cc:34:
/tmp/guix-build-libstdc++-11.3.0.drv-0/gcc-11.3.0/build/include/bits/stringfwd.h:79:33:
 note: 'std::string' declared here
   79 |   typedef basic_stringstring;
  | ^~
../../../libstdc++-v3/src/c++17/floating_from_chars.cc:504:55: error: 'buf' was 
not declared in this scope
  504 |   if (const char* pat = pattern(first, last, fmt, buf)) [[likely]]

In the file
   libstdc++-v3/src/c++17/floating_from_chars.cc
previous functions have code like this:
#if _GLIBCXX_USE_CXX11_ABI
  buffer_resource mr;
  pmr::string buf(&mr);
#else
  string buf;
  if (!reserve_string(buf))
return make_result(first, 0, {}, ec);
#endif

while here we only have:
  buffer_resource mr;
  pmr::string buf(&mr);

So my guess would be that we should simply replace this snippet with the
one above.

Could someone with access to a powerpc machine try out this change?

Andreas

Re: A friendlier API for operating-system declarations

[Ludovic Courtès]

Hi Edouard,

Edouard Klein  skribis:

> For my clients and my own use, I use a layer on top of operating-system
> declarations in which I create functions that take an os as a first
> argument, and return an os.
>
> With the help of the handy -> macro, I can chain them, thus allowing an
> easy stacking of multiple "roles" or "functionalities" on the same
> machine, and an easy transfer of said functionality to another machine:
> just cut and paste one line from one declaration to the other.
>
> I have written a tutorial for my clients here:
>
> https://guix-hosting.com/docs/tuto/getting-started.html

Very nice!

> After a few months of experience, and positive feedback from my clients,
> my question to you guys is: would you be interested in mainlining this,
> or should I keep my development efforts separate in my channel ?

I think it’s worth considering, taking into account maintenance
considerations as Liliana wrote.

> I do think this API is easier than manipulating services, and although
> extendable services are awesome and a very nifty piece of engineering,
> they require quite a good knowledge of scheme and take a while to be
> used to, while this new API, while way less powerful, lowers the barrier
> to entry for newcomers.

Normally, adding a service amounts to adding a line in the ‘services’
field:

  (operating-system
;; …
(services (append (list (service nginx-service-type) …)
  %base-services)))

It is more verbose that what you have, but it’s still roughly one line
(or one entry) per service.

Another interesting bit in your channel are templates though: an OS
template for hosting at OVH, etc.  These are very valuable because they
take care of all the boilerplate.

Thanks for sharing!

Ludo’.

Re: Powerpc on core-updates

[Andreas Enge]

I may as well try to provide a patch. It is untested even on x86_64,
since it requires quite a few rebuilds. If it works on powerpc, it should
probably be made conditional on the architecture to avoid a world rebuild.
I do not know whether this is possible in the patches field in an origin.

Andreas

>From 5eb50bdc34759d4c917f2143e037fad62bc08ed7 Mon Sep 17 00:00:00 2001
From: Andreas Enge 
Date: Thu, 13 Apr 2023 11:46:47 +0200
Subject: [PATCH] gnu: gcc-11: Fix build on powerpc64le.

* gnu/packages/patches/gcc-11-libstdc++-powerpc.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patch.
* gnu/packages/gcc.scm (gcc-11)[origin]: Use patch.
---
 gnu/local.mk   |  1 +
 gnu/packages/gcc.scm   |  5 +++--
 .../patches/gcc-11-libstdc++-powerpc.patch | 18 ++
 3 files changed, 22 insertions(+), 2 deletions(-)
 create mode 100644 gnu/packages/patches/gcc-11-libstdc++-powerpc.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index b07811f1cb..1255846462 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1184,6 +1184,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/gcc-11-libstdc++-hurd-libpthread.patch   \
   %D%/packages/patches/gcc-12-cross-environment-variables.patch \
   %D%/packages/patches/gcc-10-tree-sra-union-handling.patch\
+  %D%/packages/patches/gcc-11-libstdc++-powerpc.patch   \
   %D%/packages/patches/gcolor3-update-libportal-usage.patch\
   %D%/packages/patches/gd-fix-tests-on-i686.patch  \
   %D%/packages/patches/gd-brect-bounds.patch   \
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index a511cdbc45..631e08db25 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -2,7 +2,7 @@
 ;;; Copyright © 2012-2023 Ludovic Courtès 
 ;;; Copyright © 2014, 2015, 2018 Mark H Weaver 
 ;;; Copyright © 2014, 2015, 2016, 2017, 2019, 2021 Ricardo Wurmus 

-;;; Copyright © 2015 Andreas Enge 
+;;; Copyright © 2015, 2023 Andreas Enge 
 ;;; Copyright © 2015-2018, 2020-2023 Efraim Flashner 
 ;;; Copyright © 2016 Carlos Sánchez de La Lama 
 ;;; Copyright © 2018 Tobias Geerinckx-Rice 
@@ -703,7 +703,8 @@ (define-public gcc-11
   "0fdclcwf728wbq52vphfcjywzhpsjp3kifzj3pib3xcihs0z4z5l"))
 (patches (search-patches "gcc-9-strmov-store-file-names.patch"
  "gcc-5.0-libvtv-runpath.patch"
- "gcc-10-tree-sra-union-handling.patch"))
+ "gcc-10-tree-sra-union-handling.patch"
+ "gcc-11-libstdc++-powerpc.patch"))
 (modules '((guix build utils)))
 (snippet gcc-canadian-cross-objdump-snippet)))
(arguments
diff --git a/gnu/packages/patches/gcc-11-libstdc++-powerpc.patch 
b/gnu/packages/patches/gcc-11-libstdc++-powerpc.patch
new file mode 100644
index 00..aff2ef16f1
--- /dev/null
+++ b/gnu/packages/patches/gcc-11-libstdc++-powerpc.patch
@@ -0,0 +1,18 @@
+diff -u -r gcc-11.3.0.alt/libstdc++-v3/src/c++17/floating_from_chars.cc 
gcc-11.3.0/libstdc++-v3/src/c++17/floating_from_chars.cc
+--- gcc-11.3.0.alt/libstdc++-v3/src/c++17/floating_from_chars.cc   
2023-04-13 11:36:08.169841428 +0200
 gcc-11.3.0/libstdc++-v3/src/c++17/floating_from_chars.cc   2023-04-13 
11:36:54.825827304 +0200
+@@ -495,8 +495,14 @@
+ from_chars(const char* first, const char* last, __ieee128& value,
+  chars_format fmt) noexcept
+ {
++#if _GLIBCXX_USE_CXX11_ABI
+   buffer_resource mr;
+   pmr::string buf(&mr);
++#else
++  string buf;
++  if (!reserve_string(buf))
++return make_result(first, 0, {}, ec);
++#endif
+   size_t len = 0;
+   errc ec = errc::invalid_argument;
+   __try
-- 
2.39.2

Re: i686 core-updates failure.

[Simon Tournier]

Hi,

CC: teams for each ecosystem.


About i686 core-updates failures, well I do not know where to start :-)
when giving a look at:

https://ci.guix.gnu.org/eval/391720/dashboard?system=i686-linux


1. Java

Well, it seems broken because wget-1.21.3
.

Any taker?


2. Python

Well, python-numpy-1.23.2 seems the first to tackle for improving the
situation. 

Any taker?



3. Haskell:

Well, Haskell is broken because ghc-8.10.7 is broken with:

--8<---cut here---start->8---
building of `/gnu/store/fk4nlvkdl0qgafybd8kbg2c9a4vq5fz4-ghc-8.10.7.drv' timed 
out after 3600 seconds of silence
@ build-failed /gnu/store/fk4nlvkdl0qgafybd8kbg2c9a4vq5fz4-ghc-8.10.7.drv - 
timeout
--8<---cut here---end--->8---

Note that Haskell is also broken on master for a similar error with
ghc-9.2.5 .

Therefore, the question is: do we drop Haskell for i686?


4. R

Corollary of #3, pandoc is broken and so many R packages too.

Well, the situation seems similar with master for Haskell and R
packages.


Cheers,
simon

Re: rrdtool hash mismatch

[Simon Tournier]

On Thu, 13 Apr 2023 at 11:52, Simon Tournier  wrote:

> Well, Aleksandr, would you like to give a try for updating this change
> in the Guix recipe?

Ah, already done with . :-)

Thanks!

Cheers,
simon

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

[Simon Tournier]

Hi,

On Thu, 13 Apr 2023 at 08:05, pukkamustard  wrote:

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

On Thu, 13 Apr 2023 at 10:09, Andreas Enge  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

Re: staging merge into master

[Simon Tournier]

Hi Maxim,

On Wed, 12 Apr 2023 at 23:27, Andreas Enge  wrote:
> 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.

I concur with Josselin, could you make sure to also merge master into
core-updates?

And could let the CI ends with the last evaluation of staging?  I mean
wait until the completion of 
triggered by commit 0fe2c78cac19acfb46c3bc365075293e51e0e5aa.  I would
avoid some “out of stock” of substitutes for end-user running.


Thanks for taking care of this!

Cheers,
simon

Re: rrdtool hash mismatch

[Simon Tournier]

Hi,

Details about Josselin’s message. :-)

On Wed, 12 Apr 2023 at 18:47, Aleksandr Vityazev  wrote:

> 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?

--8<---cut here---start->8---
$ guix hash $(guix build rrdtool -S)
1nsqra0g2nja19akmf9x5y9hhgc35ml3w9dcdz2ayz7zgvmzm6d1

$ guix download http://oss.oetiker.ch/rrdtool/pub/rrdtool-1.7.2.tar.gz
Starting download of /tmp/guix-file.fZIYKs
>From http://oss.oetiker.ch/rrdtool/pub/rrdtool-1.7.2.tar.gz...
following redirection to 
`https://oss.oetiker.ch/rrdtool/pub/rrdtool-1.7.2.tar.gz'...
following redirection to `http://oss.oetiker.ch/rrdtool/404.var'...
following redirection to `https://oss.oetiker.ch/rrdtool/404.var'...
 …7.2.tar.gz  5KiB  

   1.4MiB/s 00:00 [##] 100.0%
/gnu/store/7jb5yxwg531d0xkwgv23wpf3w9fkb4x3-rrdtool-1.7.2.tar.gz
029r3h7l06m3sy9q0hr2krvinhzkqvyl14wj7qjck79bm7rdvp48
--8<---cut here---end--->8---

Ok, what’s the difference between the two:

--8<---cut here---start->8---
$ tar xvf /gnu/store/7jb5yxwg531d0xkwgv23wpf3w9fkb4x3-rrdtool-1.7.2.tar.gz
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

$ file /gnu/store/7jb5yxwg531d0xkwgv23wpf3w9fkb4x3-rrdtool-1.7.2.tar.gz
/gnu/store/7jb5yxwg531d0xkwgv23wpf3w9fkb4x3-rrdtool-1.7.2.tar.gz: HTML 
document, ASCII text
--8<---cut here---end--->8---

Ah, the new is not a tarball.  Upstream changed their URL.

--8<---cut here---start->8---
$ cat /gnu/store/7jb5yxwg531d0xkwgv23wpf3w9fkb4x3-rrdtool-1.7.2.tar.gz
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

http://www.w3.org/1999/xhtml";>



RRDtool - Sorry this page does not exist


[...]



--8<---cut here---end--->8---

And as upstream is explaining on their website, the content of releases
is now hosted in GitHub.

https://oss.oetiker.ch/rrdtool/download.en.html

Well, Aleksandr, would you like to give a try for updating this change
in the Guix recipe?


Cheers,
simon

Examples of transient shepherd services?

[Bruno Victal]

Hi,

Are there any examples that demonstrate how a custom non make-inetd-constructor
transient shepherd service can be made and destroyed?


Regards,
Bruno

Re: i686 core-updates failure.

[jgart]

My thoughts on this are that unless someone has the time to maintain those 
broken packages we should just remove them and clean up shop a bit.

Is there a reason to keep around the broken packages?

A news entry about the removals would also be helpful if we decide to remove 
them in order for people to know and so future contributors can pick up the 
work if they are interested in maintaining them at a later date.

Anyways, one idea for what to do, WDYT

Re: i686 core-updates failure.

[Andreas Enge]

Am Thu, Apr 13, 2023 at 01:23:15PM + schrieb jgart:
> My thoughts on this are that unless someone has the time to maintain those 
> broken packages we should just remove them and clean up shop a bit.
> Is there a reason to keep around the broken packages?

Well, we can certainly remove a few hopeless, outdated, non-maintained
broken packages. But if we start to remove packages such as wget, and
Java, and Haskell, and much of R, and big chunks of Python, for i686,
this amounts to removing the architecture altogether. It is a decision
we may want to take at some point in time, but we should not do so casually.
And definitely not in this core-updates merge.

One argument for keeping i686 was that problems there were often indicative
of problems in "more exotic" architectures, whereas i686 is relatively easy
to build on x86_64 without specific (often slow) hardware. I am not sure
if this still holds for the 32 bit problems we have seen recently; so there
is a certain argument to make for removing the 32 bit architectures i686
and armhf (x86_64 will soon celebrate its 25th birthday, aarch64 is half
as old; I do not expect much hardware for the corresponding 32 bit
architectures to be around any more).

Andreas

Re: bug#61879: Powerpc on core-updates

[Christopher Baines]

Andreas Enge  writes:

> In the file
>libstdc++-v3/src/c++17/floating_from_chars.cc
> previous functions have code like this:
> #if _GLIBCXX_USE_CXX11_ABI
>   buffer_resource mr;
>   pmr::string buf(&mr);
> #else
>   string buf;
>   if (!reserve_string(buf))
> return make_result(first, 0, {}, ec);
> #endif
>
> while here we only have:
>   buffer_resource mr;
>   pmr::string buf(&mr);
>
> So my guess would be that we should simply replace this snippet with the
> one above.
>
> Could someone with access to a powerpc machine try out this change?

Thanks for figuring this out Andreas! I've managed to apply this change
in the relevant place, and it appears to work.

I tried to apply it in a way that only affected powerpc64le-linux, but
I'm not sure I was successful. I've got no idea where it's best to apply
this patch, or how describe it, but at least this is a step forward.

From 382862fc06085ba80380977caf2a1f9c3203a12d Mon Sep 17 00:00:00 2001
From: Christopher Baines 
Date: Thu, 13 Apr 2023 14:45:14 +0100
Subject: [PATCH] WIP

---
 gnu/packages/gcc.scm   | 108 ++---
 gnu/packages/patches/foo.patch |  20 ++
 2 files changed, 80 insertions(+), 48 deletions(-)
 create mode 100644 gnu/packages/patches/foo.patch

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index a511cdbc45..6f6f2caa5e 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -853,56 +853,68 @@ (define-public (make-libstdc++ gcc)
 (inherit gcc)
 (name "libstdc++")
 (arguments
- `(#:out-of-source? #t
-   #:modules ((srfi srfi-1)
+ (list
+  #:out-of-source? #t
+  #:modules `((srfi srfi-1)
   (srfi srfi-26)
   ,@%gnu-build-system-modules)
-   #:phases
-   (modify-phases %standard-phases
- ,@(if (version>=? (package-version gcc) "11")
-   `((add-after 'unpack 'hide-gcc-headers
-   (lambda* (#:key native-inputs inputs #:allow-other-keys)
- (let ((gcc (assoc-ref (or native-inputs inputs)
-   ,(if (%current-target-system)
-"cross-gcc"
-"gcc"
-   ;; Fix a regression in GCC 11 where the GCC headers
-   ;; shadows glibc headers when building libstdc++.  An
-   ;; upstream fix was added in GCC 11.3.0, but it only
-   ;; hides system include directories, not those on
-   ;; CPLUS_INCLUDE_PATH.  See discussion at
-   ;; 
-   ;; and the similar adjustment in GCC-FINAL.
-   (substitute* "libstdc++-v3/src/c++17/Makefile.in"
- (("AM_CXXFLAGS = ")
-  (string-append ,(if (%current-target-system)
-  "CROSS_CPLUS_INCLUDE_PATH = "
-  "CPLUS_INCLUDE_PATH = ")
- (string-join
-  (remove (cut string-prefix? gcc <>)
-  (string-split
-   (getenv
-,(if (%current-target-system)
- "CROSS_CPLUS_INCLUDE_PATH"
- "CPLUS_INCLUDE_PATH"))
-   #\:))
-  ":")
- "\nAM_CXXFLAGS = ")))
-   '())
- ;; Force rs6000 (i.e., powerpc) libdir to be /lib and not /lib64.
- (add-before 'chdir 'fix-rs6000-libdir
-   (lambda _
- (when (file-exists? "gcc/config/rs6000")
-   (substitute* (find-files "gcc/config/rs6000")
- (("/lib64") "/lib")
- (add-before 'configure 'chdir
-   (lambda _
- (chdir "libstdc++-v3"
-
-   #:configure-flags `("--disable-libstdcxx-pch"
-   ,(string-append "--with-gxx-include-dir="
-   (assoc-ref %outputs "out")
-   "/include"
+  #:phases
+  #~(modify-phases %standard-phases
+  #$@(if (and (target-ppc64le?)
+  (version>=? (package-version gcc) "11"))
+ #~((add-after 'unpack 'patch-foo
+  (lambda _
+(define patch
+  #$(local-file
+ (search-patch "foo.patch")))
+(peek "CWD" (getcwd))
+(invoke "patch" "--force" "-p1" "-i" patch
+

Re: bug#61879: Powerpc on core-updates

[Andreas Enge]

Am Thu, Apr 13, 2023 at 02:46:00PM +0100 schrieb Christopher Baines:
> Thanks for figuring this out Andreas! I've managed to apply this change
> in the relevant place, and it appears to work.

Good news, thanks!

> +  #$@(if (and (target-ppc64le?)
> +  (version>=? (package-version gcc) "11"))

The file changed a lot on master, and the patch will not apply and
should not be needed there. I did not check, but I think it is already
not needed for gcc@12 any more. So we should probably check for the
major version being equal to 11.

It should be easy to check that it does not cause any rebuilds on the
other architectures, and we cannot break powerpc more than it already
is, so feel free to push something along these lines to core-updates.

Andreas

Re: i686 core-updates failure.

[Simon Tournier]

Hi jgart,

On Thu, 13 Apr 2023 at 13:23, "jgart"  wrote:

> Is there a reason to keep around the broken packages?

Euh, maybe you have missed what the branch core-updates is. :-)

For packages with many dependents, it is not possible to update them
directly in master, because of two main reasons: 1) the build farm would
not be able to build in timely manner so many substitutes would be
lacking after each push and 2) it would be hard if not impossible to
know before the push the impact of one change over the complete list of
dependents.

Instead, we push these changes concerning some packages with many
dependents – considered as the “core” of Guix – to the branch
core-updates.  But because each change impacts large and intensive
rebuilds, this branch is not continuously built.

Therefore, the state of this branch core-updates is often poor; meaning
that many packages are potentially broken.

At some point, when enough changes are pushed into this core-updates
branch – well, it’s more when someone takes the lead for this branch –
we set the CI to re-build all the packages of the core-updates branch.

Then, we detect broken packages, often impacted by unrelated changes as
ungrafts and co., and we try to fix them all before merging this
core-updates branch into the master branch.

Thanks to the tireless Andreas’s lead over the past months, we are at
the point where the core-updates will be merged soon to master.

Considering the architecture x86_64, the state is almost good!
Yeah! \o/  Please give a look at « A Joyous Core-Updates Week-End 🎉 »
email which provides details about how to help and test.



Considering other architectures as i686, that’s not the case.  See [1].
The state of non-x86_64 architectures is weak compared to the usual
standards for merging.

All in all, no, it is possible to drop python-numpy for example [2]. :-)

Hope that makes sense.

1: https://ci.guix.gnu.org/eval/391720/dashboard?system=i686-linux
2: https://ci.guix.gnu.org/build/712672/details

Cheers,
simon

Re: i686 core-updates failure.

[Ricardo Wurmus]

"jgart"  writes:

> My thoughts on this are that unless someone has the time to maintain those 
> broken packages we should just remove them and clean up shop a bit.
>
> Is there a reason to keep around the broken packages?

Definitely not!

It’s been difficult enough to get them added in the first place.  Rather
than undoing years of past work just because it’s inconvenient to do
maintenance we should increase the number of people who feel responsible
to help with maintenance.

I know that I won’t continue contributing to Guix if packages are
removed with nonchalance.  We speak of removing Pandoc, Haskell, and
most of R.  That would be nothing short of reckless.

Yes, this is only i686 and it’s worth thinking about whether to continue
supporting this architecture when developers seemingly don’t care about
it any more.  But just removing foundational packages is akin to just
giving up.

-- 
Ricardo

Re: i686 core-updates failure.

[Greg Hogan]

On Thu, Apr 13, 2023 at 11:53 AM Ricardo Wurmus  wrote:
>
> Yes, this is only i686 and it’s worth thinking about whether to continue
> supporting this architecture when developers seemingly don’t care about
> it any more.  But just removing foundational packages is akin to just
> giving up.

We have package->supported-systems, although the package reference
does not define "supported system".

For test failures could we not disable tests conditional on the
architecture? Tests enabled/disabled could be presented to the user in
guix search/show.

Greg

Re: i686 core-updates failure.

[Andreas Enge]

Hello,

Am Thu, Apr 13, 2023 at 04:37:55AM + schrieb Kaelyn:
> 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).

I agree with your analysis: I am not overly shocked that on a 32 bit
architecture creating an array of 2^31 elements fails, while on a
64 bit architecture the same test passes. Still, how about sending
a bug report? Can anything be seen from the Debian package? If it is
a consistent 32 bit failure, it had better be repaired upstream.

For the Fortran bindings, I am hesitant as well. I think it is bad style
to disable a test just because it fails ;-)  Maybe someone with experience
in numpy can speak up.

Andreas

Re: i686 core-updates failure.

[Simon Tournier]

On Thu, 13 Apr 2023 at 17:31, Simon Tournier  wrote:

> All in all, no, it is possible to drop python-numpy for example [2]. :-)

No, it is *not* possible!  (My fingers had not been enough fast. ;-))

Re: i686 core-updates failure.

[Simon Tournier]

Hi Ricardo, all,

I totally agree with your words.  A minor comment about the merge of
core-updates…

On Thu, 13 Apr 2023 at 17:47, Ricardo Wurmus  wrote:

> I know that I won’t continue contributing to Guix if packages are
> removed with nonchalance.  We speak of removing Pandoc, Haskell, and
> most of R.  That would be nothing short of reckless.

…well, the current bad shape of master for non-x86_64 should not be
blocking for the core-updates merge, IMHO.

For instance, Pandoc is already broken for i686 on master.  Julia too!

Aside, I agree the situation must be improved.  Therefore…


…Concerning Julia, it seems about the configuration of the build farm,

--8<---cut here---start->8---
Error During Test at 
/tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/test/testdefs.jl:21
  Got exception outside of a @test
  LoadError: OutOfMemoryError()
--8<---cut here---end--->8---

Is it possible that Berlin is missing memory?


…Concerning GHC@9.2, it is also about the build farm,

--8<---cut here---start->8---
building of `/gnu/store/in0gfsahn1z6ym232wg3cayzim51zng8-ghc-9.2.5.drv' timed 
out after 3600 seconds of silence
@ build-failed /gnu/store/in0gfsahn1z6ym232wg3cayzim51zng8-ghc-9.2.5.drv - 
timeout
--8<---cut here---end--->8---

Well, so maybe it is fixable by extending the timeout.


Once Julia fixed on core-updates for x86_64 (the patch is almost ready,
I am currently checking it will have the expected effect ;-)), then I
will give a look for Julia on i686; probably tomorrow.


About GHC, I am trying to build ghc-8.10.7 on core-updates for i686.  It
could be nice to fix it.  Well, I will be happy if someone™ beats me. ;-)


1: https://ci.guix.gnu.org/eval/394617/dashboard?system=i686-linux


Cheers,
simon

Re: i686 core-updates failure.

[Ricardo Wurmus]

Simon Tournier  writes:

> On Thu, 13 Apr 2023 at 17:47, Ricardo Wurmus  wrote:
>
>> I know that I won’t continue contributing to Guix if packages are
>> removed with nonchalance.  We speak of removing Pandoc, Haskell, and
>> most of R.  That would be nothing short of reckless.
>
> …well, the current bad shape of master for non-x86_64 should not be
> blocking for the core-updates merge, IMHO.

Agreed.

> Aside, I agree the situation must be improved.  Therefore…

FWIW I’m all tied up trying to fix packages on core-updates, rust on
aarch64, and repairing aarch64 build nodes in the data center, so I
won’t be able to commit any time to work on i686 at this point.

-- 
Ricardo

Re: i686 core-updates failure.

[Lars-Dominik Braun]

Hi Simon,

> About GHC, I am trying to build ghc-8.10.7 on core-updates for i686.  It
> could be nice to fix it.  Well, I will be happy if someone™ beats me. ;-)

GHC 8.10.7 on i686 built fine for me locally with all timeouts
disabled. 9.2.5 is not done yet, but is slowly processing through the test
suite as well for me. Can someone build both manually on the CI servers
maybe?

Lars

Re: herd stop hangs

[Ludovic Courtès]

Hi,

Vladilen Kozin  skribis:

> $ 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.

(I guess the second command is ‘sudo herd stop my-service’.)  If you
interrupt the ‘herd’ command, does ‘sudo herd status’ and similar
commands still respond?

If not, could you share the relevant /var/log/messages excerpt?

Thanks for reporting the issue,
Ludo’.

Re: Examples of transient shepherd services?

[Ludovic Courtès]

Hi Bruno,

Bruno Victal  skribis:

> Are there any examples that demonstrate how a custom non 
> make-inetd-constructor
> transient shepherd service can be made and destroyed?

There’s a toy example in ‘tests/transient.sh’, but that’s all.  Inetd is
the only real use case so far.

Ludo’.

Re: i686 core-updates failure.

[Simon Tournier]

Hi Lars,

On Thu, 13 Apr 2023 at 22:02, Lars-Dominik Braun  wrote:

> > About GHC, I am trying to build ghc-8.10.7 on core-updates for i686.  It
> > could be nice to fix it.  Well, I will be happy if someone™ beats me. ;-)
>
> GHC 8.10.7 on i686 built fine for me locally with all timeouts
> disabled. 9.2.5 is not done yet, but is slowly processing through the test
> suite as well for me. Can someone build both manually on the CI servers
> maybe?

Thanks for checking.  It also builds for me locally.  So I guess,

+(properties
+ ;; 3 hours to avoid time-out in the check phase.
+ `((max-silent-time . 10800)))

would be helpful.  And it should be inherited by 9.2.5 so it should
also build on CI.  WDYT?


Cheers,
simon

Re: GOOPS-less Shepherd

[Ludovic Courtès]

Hi,

Bodertz  skribis:

> I don't have strong feelings either way, and the change won't really
> affect me too much, but what benefit is there in breaking things?  From
> what I understand from your message, users' configs will stop working in
> a few months when 1.0.x releases (or with the macro would "kinda work"),
> which is at least a short-term con, so what's the long-term benefit of
> this change?  Is GOOPS so bad a thing to require?

It’s not that GOOPS is “bad”.  There are two things: some overhead (not
too bad, but still a bit), and a number of more or less subjective issues.

The programming style GOOPS encourages is not something I enjoy; I think
it makes it harder to reason about the code (you have to think about
applicable methods, new methods can be added at run time, etc.)

Another argument is consistency with Guix, and consistency within the
Shepherd (right now the GOOPS bits feel out of place).

Overall, I think we’d rather “clean things up” before 1.0 so we don’t
have to introduce breakage later.

I hope this clarifies the situation!

Ludo’.

wget (was Re: i686 core-updates failure.)

[Simon Tournier]

Hi,

Fixing ’wget’ for i686 would help for Java and Julia.  Well, currently
’wget’ is broken on core-updates for i686,

https://ci.guix.gnu.org/build/709528/details

And the 5 error seem similar (missing file?), i.e., read,

--8<---cut here---start->8---
FAIL: Test-hsts
===

Setting --no-config (noconfig) to 1
Setting --hsts-file (hstsfile) to 
/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv
Setting --ca-certificate (cacertificate) to 
/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem
DEBUG output created by Wget 1.21.3 on linux-gnu.

Reading HSTS entries from 
/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv
URI encoding = 'ANSI_X3.4-1968'
converted 'http://localhost:41133/hw' (ANSI_X3.4-1968) -> 
'http://localhost:41133/hw' (UTF-8)
URL transformed to HTTPS due to an HSTS policy
Converted file name 'hw' (UTF-8) -> 'hw' (ANSI_X3.4-1968)
--2023-04-06 18:17:39--  https://localhost:41133/hw
Loaded CA certificate 
'/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem'
Certificates loaded: 1
Resolving localhost (localhost)... 127.0.0.1
Caching localhost => 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:41133... connected.
Created socket 3.
Releasing 0x080e1190 (new refcount 1).
The certificate has not yet been activated
Saving HSTS entries to 
/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv
1
Running Test Test-hsts.py
/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/src/wget --debug --no-config 
--hsts-file=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv
 
--ca-certificate=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem
 http://localhost:41133/hw 
['/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/src/wget', '--debug', 
'--no-config', 
'--hsts-file=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv',
 
'--ca-certificate=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem',
 'http://localhost:41133/hw']
{'HOME': 
'/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/Test-hsts.py-test'}
Error: Expected file hw not found..
Traceback (most recent call last):
  File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/./Test-hsts.py", 
line 76, in 
err = test.begin()
  File 
"/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/http_test.py", line 
41, in begin
self.do_test()
  File 
"/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/base_test.py", line 
198, in do_test
self.post_hook_call()
  File 
"/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/base_test.py", line 
217, in post_hook_call
self.hook_call(self.post_configs, 'Post Test Function')
  File 
"/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/base_test.py", line 
207, in hook_call
conf.find_conf(conf_name)(conf_arg)(self)
  File 
"/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/conf/expected_files.py", 
line 55, in __call__
raise TestFailed('Expected file %s not found.' % file.name)
exc.test_failed.TestFailed: Expected file hw not found.
FAIL Test-hsts.py (exit status: 1)
--8<---cut here---end--->8---


Any idea?


Cheers,
simon

Re: GOOPS-less Shepherd

[Ludovic Courtès]

Hi,

Liliana Marie Prikler  skribis:

> Am Donnerstag, dem 06.04.2023 um 22:16 +0200 schrieb Ludovic Courtès:
>> What’s at stake, mostly, is the ability to reconfigure a long-running
>> shepherd instance.  Once 1.0.x is in Guix, ‘guix system reconfigure’
>> will most likely fail to upgrade services on a pre-0.10.x shepherd:
>> users will have to reboot.
> This caveat however, will only be a one-time thing, right?  That is,
> once running Shepherd 0.10.x or 1.0.x, you can reconfigure without
> needing to reboot supposedly until the next API break happening at
> 1.90.x or 2.0?

Yes, exactly.

Ludo’.

Re: wget (was Re: i686 core-updates failure.)

[Andreas Enge]

Am Thu, Apr 13, 2023 at 10:33:28PM +0200 schrieb Simon Tournier:
> Fixing ’wget’ for i686 would help for Java and Julia.  Well, currently
> ’wget’ is broken on core-updates for i686,
> And the 5 error seem similar (missing file?), i.e., read,
> Any idea?

I had a look, but no idea :(

Except for one: Would it make sense to try to depend on wget2 instead?

Andreas

Re: i686 core-updates failure.

[Simon Tournier]

On Thu, 13 Apr 2023 at 22:45, Andreas Enge  wrote:
> Am Thu, Apr 13, 2023 at 10:15:14PM +0200 schrieb Simon Tournier:
> > Thanks for checking.  It also builds for me locally.  So I guess,
> > +(properties
> > + ;; 3 hours to avoid time-out in the check phase.
> > + `((max-silent-time . 10800)))
> > would be helpful.
>
> I may misunderstand something, but while ghc takes a long time for its
> tests, it is not silent - it regularly outputs test results. I do not
> think it really is silent for one hour. So I am not sure this would help.
> Maybe some transient build failure?

Well, maybe it is transient because an issue with Berlin but the
failure [1] is because it was silent for one hour:

--8<---cut here---start->8---
building of `/gnu/store/i6h8q8jgqxli3mkfyw7lpwzf7gq6mrxk-ghc-8.10.7.drv'
timed out after 3600 seconds of silence
@ build-failed /gnu/store/i6h8q8jgqxli3mkfyw7lpwzf7gq6mrxk-ghc-8.10.7.drv
- timeout
--8<---cut here---end--->8---


And I think the patch would avoid such transient error.  Note it
similar for ghc-9 for i686 on master [2]; it is maybe not as transient
as it seems. ;-)

1: https://ci.guix.gnu.org/build/718809/log/raw
2: https://ci.guix.gnu.org/build/478772/log/raw

> I have just restarted the builds in cuirass.

Good, let see. :-)

Cheers,
simon

Re: herd stop hangs

[Vlad Kozin]

> (I guess the second command is ‘sudo herd stop my-service’.)  If you
> interrupt the ‘herd’ command, does ‘sudo herd status’ and similar
> commands still respond?

‘sudo herd stop myservice’ exactly. Sorry about that.
Herd continues to function. Appears that somehow SIGTERM has no effect or it 
never gets sent or it is in fact delivered and acted upon but shepherd fails to 
notice, so /var/log/messages shows subsequent SIGKILL. Whichever it is, herd 
status will show the service has been stopped. That’s one issue. Another is 
that the console where ‘sudo herd stop’ was typed required a CTRL C to get the 
prompt.

Could it be some weird sequence of what appears in the :running slot or smth? 
I’m using standard process constructors destructors mimicking other services

Re: i686 core-updates failure.

[Andreas Enge]

Am Thu, Apr 13, 2023 at 10:15:14PM +0200 schrieb Simon Tournier:
> Thanks for checking.  It also builds for me locally.  So I guess,
> +(properties
> + ;; 3 hours to avoid time-out in the check phase.
> + `((max-silent-time . 10800)))
> would be helpful.

I may misunderstand something, but while ghc takes a long time for its
tests, it is not silent - it regularly outputs test results. I do not
think it really is silent for one hour. So I am not sure this would help.
Maybe some transient build failure?

I have just restarted the builds in cuirass.

Andreas

Re: wget

[Andreas Enge]

Am Thu, Apr 13, 2023 at 10:43:31PM +0200 schrieb Simon Tournier:
> Do you mean replace all the occurrences of 'wget' by 'wget2'?  Maybe
> only the occurrences of 'wget' by 'wget2' for the current broken
> packages on i686?

Yes, assuming that wget2 is the future and wget a thing of the past.
But it is not very likely to work; the binary is also called "wget2",
so it is really a different project, and can only work if it is checked
for by the package to be built.

Andreas

Re: wget (was Re: i686 core-updates failure.)

[Simon Tournier]

On Thu, 13 Apr 2023 at 22:37, Andreas Enge  wrote:

> Except for one: Would it make sense to try to depend on wget2 instead?

I have no idea. )-:

Do you mean replace all the occurrences of 'wget' by 'wget2'?  Maybe
only the occurrences of 'wget' by 'wget2' for the current broken
packages on i686?

Well, it would be better to fix 'wget'. (-:

Cheers,
simon

Re: Contributing Guix Home services

[Ludovic Courtès]

Hi Tanguy!

Tanguy LE CARROUR  skribis:

> This doesn't answer the question "how complete need a service be to make
> it to master?", though. But I've a lot of re-write to do before submitting 
> patches
> anyway!

Sorry for not noticing earlier!  There’s no formal rule, but I think
that what we’ve been doing so far is to ensure basic functionality of
the service is covered, and to provide an “escape hatch” for bits of the
configuration that are not covered.

Contributions in this area are most welcome!

Thanks,
Ludo’.