Re: 02/03: gnu: openblas: Update architectures we provide substitutes for.

2023-06-02 Thread Christopher Baines

guix-comm...@gnu.org writes:

> efraim pushed a commit to branch master
> in repository guix.
>
> commit 076688fa1e41a09f034a80e1a593bac43f1f1482
> Author: Efraim Flashner 
> AuthorDate: Thu Jun 1 11:06:00 2023 +0300
>
> gnu: openblas: Update architectures we provide substitutes for.
>
> * gnu/packages/maths.scm (openblas)[arguments]: Adjust the substitutable?
> flag to only not provide substitutes when building for powerpc-linux.
> Adjust the comment accordingly.
> ---
>  gnu/packages/maths.scm | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)

I've been looking at why armhf-linux substitute availability has been
dropping recently, and I think this change triggered a lot of
rebuilds. Could this have gone to core-updates?

→ guix refresh -l openblas
Building the following 2282 packages would ensure 5596 dependent packages are 
rebuilt: ...


signature.asc
Description: PGP signature


rust-build-system from antioxidant

2023-06-02 Thread Development of GNU Guix and the GNU System distribution.


A few months ago, Maxime Devos worked on a new rust-build-system to
handle a few issues we were experiencing with cargo (see discussions on
antioxidant in guix-devel).

A month ago, we discussed about the possibility of the integration in
core guix, and the required steps. Maxime and I had a different
approach. Maxime highlighted the possibility to make a smooth transition
but once that would require many gradual changes and deprecation. My
approach was that since we'll have to eventually migrate all packages to
rust-build-system, and since we can freeze all former rust packages in
an archive channel, I would be clearer to make the transition at once.

Took me quite some time from there, but thanks to the huge work of
Maxime and a few rust patches, I've managed to compile ripgrep properly,
along with more than 350 packages which represent all transitive inputs
and native-inputs. It's basically a package-level copy of Maxime's work
on antioxidant, with more focus on "bootstrapping" properly (very few
packages are missing a test phase), and some work to cut down the number
of dependencies.

It's only a step, but a good one to continue the discussion about the
integration of this build-system (and the way it should be integrated).

You can find it in an archive right here for a 5 days (I would rather
not create a new 8 Gb repo online for 100 kb transferred, sorry). 

https://drop.chapril.org/download/696f37be60f243fd/#-j9Nt_xiN9eUBCsHfMDHig

If we manage to continue this to reach 100% builds like the antioxidant
channel, we could indeed switch in one big commit. The workspace
build-system is not included yet.

-- 
Best regards,
Nicolas Graves



Re: bug#61894: [PATCH RFC] Team approval for patches

2023-06-02 Thread Ludovic Courtès
Hello,

Ludovic Courtès  skribis:

> With the proposed policy, members of a team would also have to review
> and approve each other’s work.  Formal approval means getting an
> explicit “LGTM” (or similar) from at least one other team member.

I think it’s fair to say that there was no consensus on this proposal,
so I’m withdrawing it and closing this issue.

Thanks to everyone who contributed to the discussion!

Ludo’.