bug#65456: [PATCH v3] self: Build guix/ and gnu/packages/ directories in 26 steps.

[Dr. Arne Babenhauserheide]

Janneke Nieuwenhuizen  writes:

> So, some good news at last; I can confirm that using v4 of this patch we
> now have "guix pull", pulling from a local git directory, now fully
> working on the Hurd!

That’s awesome! Thank you for your work!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

bug#65456: [PATCH v3] self: Build guix/ and gnu/packages/ directories in 26 steps.

[Janneke Nieuwenhuizen]

Janneke Nieuwenhuizen writes:

Hi!

> Ludovic Courtès writes:
>
> Hi!
>
>> Janneke Nieuwenhuizen  skribis:
>>
[..]
>> In fact, guix/*.go is entirely missing, it seems:
>
> Right...that makes sense now that I look at the code again.
>
> Wait...I probably even experienced this breakage after running `guix
> pull' on the Hurd but failed to notice its cause, the missing guix/*.go,
> and ascribed it to "something" being broken on Hurd.  So the good news
> is that we'll most probably have guix pull work on the Hurd after fixing
> this!

So, some good news at last; I can confirm that using v4 of this patch we
now have "guix pull", pulling from a local git directory, now fully
working on the Hurd!  (When pulling from a git url, I get "Illegal
instruction" while receiving objects.)

See log below.

Greetings,
Janneke

/ssh:childhurd1:/root/src/guix/wip-hurd/ #$ guix pull 
--url=https://gitlab.com/janneke/guix --branch=wip-hurd
Updating channel 'guix' from Git repository at 
'https://gitlab.com/janneke/guix'...
guix pull: error: Git error: the SSL certificate is invalid
/ssh:childhurd1:/root/src/guix/wip-hurd/ #$ guix pull 
--url=http://gitlab.com/janneke/guix --branch=wip-hurd
Updating channel 'guix' from Git repository at 
'http://gitlab.com/janneke/guix'...
guix pull: error: Git error: the SSL certificate is invalid
/ssh:childhurd1:/root/src/guix/wip-hurd/ #$ guix install nss-certs
guix install: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

The following package will be installed:
   nss-certs 3.88.1

substitute: updating substitutes from 'http://dezyne.org:8181'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivations will be built:
  /gnu/store/z1jyx8lyhgr1gykiky5wjh5mncwvp6ls-profile.drv
  /gnu/store/p3kkmm8ap3z68irnzl6dsq9clkzrg9cj-nss-certs-3.88.1.drv
  /gnu/store/cjkisarl0gcwrvgcc3hklz63x7dz6ji2-nss-3.88.1.tar.xz.drv
  /gnu/store/iwsyc1bvgn9x7qg0x3an5g2q23a6l2xk-certdata2pem-0.0.0.drv

71.6 MB will be downloaded
 certdata2pem.c  2KiB 23KiB/s 00:00 
[##] 100.0%
 nss-3.88.1.tar.gz  68.3MiB  2.1MiB/s 00:32 
[##] 100.0%
building /gnu/store/iwsyc1bvgn9x7qg0x3an5g2q23a6l2xk-certdata2pem-0.0.0.drv...
building /gnu/store/cjkisarl0gcwrvgcc3hklz63x7dz6ji2-nss-3.88.1.tar.xz.drv...
building /gnu/store/p3kkmm8ap3z68irnzl6dsq9clkzrg9cj-nss-certs-3.88.1.drv...
building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
building directory of Info manuals...
building profile with 1 package...
killing process 174: Invalid argument
killing process 175: Invalid argument
/ssh:childhurd1:/root/src/guix/wip-hurd/ #$ guix pull 
--url=https://gitlab.com/janneke/guix --branch=wip-hurd
Updating channel 'guix' from Git repository at 
'https://gitlab.com/janneke/guix'...
guix pull: error: Git error: the SSL certificate is invalid
/ssh:childhurd1:/root/src/guix/wip-hurd/ #$ bash -login
root@guixydevel ~/src/guix/wip-hurd# 
root@guixydevel ~/src/guix/wip-hurd# guix pull 
--url=https://gitlab.com/janneke/guix --branch=wip-hurd
Updating channel 'guix' from Git repository at 
'https://gitlab.com/janneke/guix'...
receiving objects  49% [##  
 ]Illegal instruction (core dumped)
root@guixydevel ~/src/guix/wip-hurd# guix pull --url=$PWD --branch=wip-hurd
Updating channel 'guix' from Git repository at '/root/src/guix/wip-hurd'...
guix pull: error: Git error: cannot locate remote-tracking branch 
'origin/keyring'
root@guixydevel ~/src/guix/wip-hurd# git branch keyring origin/keyring
branch 'keyring' set up to track 'origin/keyring'.
root@guixydevel ~/src/guix/wip-hurd# guix pull --url=$PWD --branch=wip-hurd
Updating channel 'guix' from Git repository at '/root/src/guix/wip-hurd'...
Authenticating channel 'guix', commits 9edb3f6 to beb2704 (26 new commits)...
guix pull: warning: pulled channel 'guix' from a mirror of 
https://git.savannah.gnu.org/git/guix.git, which might be stale
Building from this channel:
  guix  /root/src/guix/wip-hurd beb2704
substitute: updating substitutes from 'http://dezyne.org:8181'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'http://dezyne.org:8181'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'http://dezyne.org:8181'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
building /gnu/store/67p25fiinjvm1h0ga8ba

bug#65461: Cannot compile any Rust projects

[Hilton Chain via Bug reports for GNU Guix]

Hello Brian,

On Thu, 24 Aug 2023 02:22:07 +0800,
brian wrote:
>
> I'd like to propose that the ‘out’ output of gcc-toolchain include the
> stub rt, pthread, and dl stub static libraries. This problem comes up on
> a very regular basis, and I can think of no reason not to have the
> compatibility shims made available.
>
> They contain no code, as they only exist to satisfy linker command
> lines, so they're not relevant for grafting purposes. The workaround of
> including the static toolchain means that every static library, not just
> the empty stubs, is made availible for linking, which is, IMHO, strictly
> worse than putting empty .a files into the default output.
>
> WDYT?

Grepping "!" in gcc-toolchain:static gives me libanl.a, libdl.a,
libpthread.a, librt.a and libutil.a.  Currently only librt.a is not
present in gcc-toolchain:out, so the proposal is really reasonable for
me.

Cc-ing Josselin since they have sent a patch to #63258.

Hi Josselin, what's the current state of the patch?  Can you resend it
to guix-patches to trigger the build process?


Thanks

bug#64586: Emacs-Packages should contain native-compiled files

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 23.08.2023 um 17:37 +0200 schrieb Simon Tournier:
> Hi,
> 
> On Wed, 12 Jul 2023 at 21:36, Liliana Marie Prikler
>  wrote:
> 
> > You are correct, but unlike other language ecosystems (e.g. Python
> > or Common Lisp), we don't have a convenient "package-with-emacs" as
> > of yet.  This is basically step 3 of <
> > https://issues.guix.gnu.org/63984#0>
> > of which only step 1 has been concluded so far.  (In fact, I need
> > to merge 29.0.92 into emacs-team, but that shouldn't be as
> > difficult as the rest in there.)  If you want things to happen
> > faster, just tag your patches with emacs-team and we will review
> > them :)
> 
> Just to point that a kind of ’package-with-emacs’ had been discussed
> in #41732 [1] and my current understanding is that some corner cases
> are annoying.
The plan would have been to address those, but we were caught with our
panties down and are behind the latest Emacs release.  Oh well, guess
those nice things have to be delayed a little longer.

> Emacs packages use 3 variants for “compiling“: emacs-minimal, emacs-
> no-x and emacs; see #:emacs in arguments field.
> 
> (And I let aside emacs-no-x-toolkit. :-))
> 
> Therefore, it does not appear to me easy to have some generic
> package-with-emacs for rewriting the “compiler” of the Emacs
> packages.  Somehow, a profile containing Emacs packages has these
> packages not necessary built with the same Emacs build-system
> compiler but still work together; contrary to Python, Common Lisp,
> OCaml or others.
I don't think there'd be that many cases to consider.  You can either
adjust #:emacs (when using emacs-build-system) or you have it as
native-input (when using any other build system).  For both cases, you
can add some logic to make that emacs the one used as the argument to
the hypothetical package-with-emacs function.

> And I do not know what could be an handy way to declare Emacs package
> variants.  Any idea?
I'd have to investigate that myself.  My basic idea would have been to
copy what Common Lisp is doing and introduce consistent naming, i.e.
have emacs-minimal-org, emacs-no-x-toolkit-org, etc.  That being said,
I consider some variants to be more important than others, particularly
regular emacs-PACKAGE > emacs-any-other-variant-PACKAGE.  Which ones to
build on CI will imho be much rather a political discussion than a
technical one.

Cheers

bug#65461: Cannot compile any Rust projects

[brian via Bug reports for GNU Guix]

I'd like to propose that the ‘out’ output of gcc-toolchain include the
stub rt, pthread, and dl stub static libraries. This problem comes up on
a very regular basis, and I can think of no reason not to have the
compatibility shims made available.

They contain no code, as they only exist to satisfy linker command
lines, so they're not relevant for grafting purposes. The workaround of
including the static toolchain means that every static library, not just
the empty stubs, is made availible for linking, which is, IMHO, strictly
worse than putting empty .a files into the default output.

WDYT?

-bjc

bug#65219: OpenFOAM is not reproducible

[Simon Tournier]

Hi,

On Fri, 11 Aug 2023 at 09:41, Ludovic Courtès  wrote:

> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/applications/solvers/heatTransfer/chtMultiRegionFoam/chtMultiRegionTwoPhaseEulerFoam/chtMultiRegionTwoPhaseEulerFoam.C.dep
> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/applications/solvers/multiphase/reactingMultiphaseEulerFoam/reactingMultiphaseEulerFoam.C.dep
> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/applications/solvers/multiphase/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.C.dep
> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/src/functionObjects/phaseSystems/sizeDistribution/sizeDistribution.C.dep
> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseCompressibleTurbulenceModels/kineticTheoryModels/kineticTheoryModel/kineticTheoryModel.C.dep
> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseCompressibleTurbulenceModels/phasePressureModel/phasePressureModel.C.dep
> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseCompressibleTurbulenceModels/twoPhaseCompressibleTurbulenceModels.C.dep
> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseSystem/diameterModels/IATE/IATE.C.dep
> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseSystem/diameterModels/IATE/IATEsources/phaseChange/phaseChange.C.dep
> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseSystem/twoPhaseSystem.C.dep
> 
> /share/OpenFOAM/build/linux64GccDPInt32Opt/src/phaseSystemModels/reactingEuler/twoPhaseSystem/twoPhaseSystems.C.dep

Are these files required at run-time?  I mean, why are they retain?  And
I was guessing they should be removed, no?

> /share/OpenFOAM/test/IO/fileHandler/log.blockMesh
> /share/OpenFOAM/test/IO/fileHandler/log.decomposePar
> /share/OpenFOAM/test/IO/fileHandler/log.decomposePar.collated
> /share/OpenFOAM/test/IO/fileHandler/log.decomposePar.uncollated
> /share/OpenFOAM/test/IO/fileHandler/log.foamFormatConvert
> /share/OpenFOAM/test/IO/fileHandler/log.foamFormatConvert.uncollated
> /share/OpenFOAM/test/IO/fileHandler/log.particleFoam
> /share/OpenFOAM/test/IO/fileHandler/log.particleFoam.collated
> /share/OpenFOAM/test/IO/fileHandler/log.particleFoam.multiCollated
> /share/OpenFOAM/test/IO/fileHandler/log.particleFoam.uncollated
> 
> /share/OpenFOAM/test/IO/fileHandler/log.particleFoam.uncollated_from_multiCollated
> /share/OpenFOAM/test/IO/fileHandler/log.reconstructPar
> /share/OpenFOAM/test/IO/fileHandler/log.reconstructPar.collated
> /share/OpenFOAM/test/IO/fileHandler/log.reconstructPar.multiCollated
> 
> /share/OpenFOAM/test/IO/fileHandler/machineA/fileHandler/log.particleFoam.distributed_multiCollated
> /share/OpenFOAM/test/fvMeshTools/cavity/0.005/polyMesh/faces
> /share/OpenFOAM/test/fvMeshTools/cavity/0.005/polyMesh/neighbour
> /share/OpenFOAM/test/fvMeshTools/cavity/0.005/polyMesh/owner
> /share/OpenFOAM/test/fvMeshTools/cavity/0.005/polyMesh/points
> /share/OpenFOAM/test/fvMeshTools/cavity/0.01/polyMesh/faces
> /share/OpenFOAM/test/fvMeshTools/cavity/0.01/polyMesh/neighbour
> /share/OpenFOAM/test/fvMeshTools/cavity/0.01/polyMesh/owner
> /share/OpenFOAM/test/fvMeshTools/cavity/0.01/polyMesh/points
> /share/OpenFOAM/test/fvMeshTools/cavity/0.015/polyMesh/faces
> […]
> 
> /share/OpenFOAM/test/multiphase/multiphaseEulerFoam/thermal/waterEvaporation/log.multiphaseEulerFoam.e.steam_h.water
> 
> /share/OpenFOAM/test/multiphase/multiphaseEulerFoam/thermal/waterEvaporation/log.multiphaseEulerFoam.h.steam_e.water
> 
> /share/OpenFOAM/test/multiphase/multiphaseEulerFoam/thermal/waterEvaporation/log.multiphaseEulerFoam.h.steam_h.water
> 
> /share/OpenFOAM/test/multiphase/multiphaseEulerFoam/thermal/waterEvaporation/postProcessing.eps
> /share/OpenFOAM/test/postProcessing/channel/log.blockMesh
> /share/OpenFOAM/test/postProcessing/channel/log.topoSet
> /share/OpenFOAM/test/testLoopReport

Similar question, no?  Why log files and testing files are part of the
output?

Cheers,
simon

bug#64999: Acknowledgement (emacs-next: emacs-29.1 fails to native-compile libraries, giving a runtime error that ctri.o and other files can't be found)

[Simon Tournier]

Hi,

On Tue, 01 Aug 2023 at 17:37, Adam Porter  wrote:

> I don't know enough about Guix to understand why using "guix install" 
> with the package transformation option caused the runtime problem with 
> gcc, but everything does seem to work with the updated definition.

See Josselin’s explanations. :-)

> So I guess this report can be closed.

I am closing.  And you could also do it just by appending -done in the
bug email address; here 64999-d...@debbugs.gny.org.


Cheers,
simon

bug#56365: Emacs crash when built with Guix

[Simon Tournier]

Hi,

On Sun, 03 Jul 2022 at 01:01, Ryan Prior  wrote:

> I've been getting a persistent crash when I select text in Emacs this
> past couple days. I'll post the stacktrace below.

This bug seems related to #58606 [1], no?

And a similar bug is tracked upstream with [2].  Could you confirm it is
the same bug or if it is another one?

1: https://issues.guix.gnu.org/58606
2: https://issues.guix.gnu.org/62291

Cheers,
simon

bug#64586: Emacs-Packages should contain native-compiled files

[Simon Tournier]

Hi,

On Wed, 12 Jul 2023 at 21:36, Liliana Marie Prikler  
wrote:

> You are correct, but unlike other language ecosystems (e.g. Python or
> Common Lisp), we don't have a convenient "package-with-emacs" as of
> yet.  This is basically step 3 of 
> of which only step 1 has been concluded so far.  (In fact, I need to
> merge 29.0.92 into emacs-team, but that shouldn't be as difficult as
> the rest in there.)  If you want things to happen faster, just tag your
> patches with emacs-team and we will review them :)

Just to point that a kind of ’package-with-emacs’ had been discussed in
#41732 [1] and my current understanding is that some corner cases are
annoying.

Emacs packages use 3 variants for “compiling“: emacs-minimal, emacs-no-x
and emacs; see #:emacs in arguments field.

(And I let aside emacs-no-x-toolkit. :-))

Therefore, it does not appear to me easy to have some generic
package-with-emacs for rewriting the “compiler” of the Emacs packages.
Somehow, a profile containing Emacs packages has these packages not
necessary built with the same Emacs build-system compiler but still work
together; contrary to Python, Common Lisp, OCaml or others.

And I do not know what could be an handy way to declare Emacs package
variants.  Any idea?

1: https://issues.guix.gnu.org/issue/41732

Cheers,
simon

bug#65208: etc/teams.scm regexp

[Simon Tournier]

Hi,

On Thu, 10 Aug 2023 at 09:34, Greg Hogan  wrote:

> I am seeing unapplied "#" in some team scopes when running
>  `./etc/teams.scm list-teams`.

This is done by .

I do not know what it had never been merged.  Probably because the
revamp for a v3 was more work than I could put in.

Cheers,
simon

bug#64753: compute-guix-derivation

[Simon Tournier]

Hi,

On Thu, 20 Jul 2023 at 23:25, Ludovic Courtès  wrote:

> It seems that the gut of the problem is that ci.guix.gnu.org was either
> unreachable or very slow.

Well, #64659 [1] seems another similar bug report.  And I often hit
transient failures with substitutions.

How could we improve the situation?


1: https://issues.guix.gnu.org/issue/64659

Cheers,
simon

bug#65460: ghc/ghci are broken

[Saku Laesvuori via Bug reports for GNU Guix]

> > Thanks! Adding gcc-toolchain to the profile fixed it, but shouldn't this 
> > be automatically brought in by `guix install ghc`? This does still feels 
> > like a bug to me, shouldn't gcc-toolchain be a part of ghcs native-inputs?

native-inputs are for buildtime inputs and here ghc needs a c toolchain
at runtime to compile another haskell program so gcc-toolchain should be
in "normal" inputs.

> I assume GHC can work with other toolchains, like Clang, so it's better
> to be explicit about what you want to use.

I think it would still be good to have a c toolchain as an input. Guix
packages are, if I understand correctly, supposed to work without having
to explicitly install their dependencies. If someone wants to use a
different c toolchain than the default, they can use a package
transformation to change it.

Maybe we could even have the current ghc as a hidden package and have
the public package wrap the hidden ghc adding gcc-toolchain to it's
environment, so that changing the c toolchain wouldn't require
rebuilding ghc.


signature.asc
Description: PGP signature

bug#65460: ghc/ghci are broken

[Csepp]

Jonas via Bug reports for GNU Guix  writes:

> Thanks! Adding gcc-toolchain to the profile fixed it, but shouldn't this 
> be automatically brought in by `guix install ghc`? This does still feels 
> like a bug to me, shouldn't gcc-toolchain be a part of ghcs native-inputs?
>
> sanoj@deimos ~/builds/hs-hello$ guix shell --container ghc -- ghc hello.hs
> Linking hello ...
>
> : error:
>      Warning: Couldn't figure out C compiler information!
>   Make sure you're using GNU gcc, or clang
> ghc: could not execute: gcc
>
> Den 8/23/23 07:14, skrev (:
>> Jonas via Bug reports for GNU Guix  writes:
>>> And compiling a hello-world program with ghc gives me:
>>>
>>> [1 of 1] Compiling Main ( hello.hs, hello.o )
>>>
>>> : error:
>>>       Warning: Couldn't figure out C compiler information!
>>>    Make sure you're using GNU gcc, or clang
>> At the risk of stating an obvious thing that you've probably already
>> tried; is `gcc-toolchain` available in the environment?
>>
>> -- (

I assume GHC can work with other toolchains, like Clang, so it's better
to be explicit about what you want to use.

bug#65474: Reproducing a texlive bug

[Andreas Enge]

Hello,

I can confirm that the same problem presents itself on
  guix 9896b37
Repository-URL: https://git.savannah.gnu.org/git/guix.git
Branch: master
Commit: 9896b37ac53e9b0504de55dd5ba4bfa2c241a7ed
of August 17.

A likely culprit is
commit 3481a5cb37cacbb54f74a2b1fa52ffc5c972b09f
Author: Nicolas Goaziou 
Date:   Wed Aug 9 10:45:42 2023 +0200
guix: profiles: Do not raise error on incomplete TeX Live setups.
* guix/profiles.scm (texlive-font-maps): Check if TEXLIVE-SCRIPTS is present
in the manifest before trying to generate font maps.
which was the last time the profile hook for font generation has been
touched.

Andreas

bug#65127: Python-pytorch slow

[Cayetano Santos via Bug reports for GNU Guix]

>lun. 07 août 2023 at 16:50, Cayetano Santos  wrote:

> Hi guix,
>
>   I just noticed that the following line (latest guix, as for today)
>
>   guix shell -C --emulate-fhs --network python python-pytorch 
> python-torchvision -- python3 quickstart_tutorial.py
>
>   with
>
>   
> https://raw.githubusercontent.com/pytorch/tutorials/main/beginner_source/basics/quickstart_tutorial.py
>
>   is noticeably slower than the version of the torch suite provided by
>   conda, for example.

By this I meant when only using CPU, not GPU.

C.

bug#65474: Bug in python-notebook

[Cayetano Santos via Bug reports for GNU Guix]

Hi guix,

  I have just updated by local copy of guix with

guix pull

  At this point, a simple

guix pack python-notebook

  gives me an error message related to a failed compilation in

/gnu/store/8wf5h68zm5lf9n157qbwdfmqz8dfpczq-texlive-font-maps.drv

  The compilation journal gives the following

Backtrace:
   3 (primitive-load "/gnu/store/4msdwzccfp51zhmnkr61vvpdllz?")
In ice-9/eval.scm:
619:8  2 (_ #f)
In ice-9/boot-9.scm:
140:2  1 (dynamic-wind # ?)
In unknown file:
   0 (chdir "/tmp/texlive/share/texmf-dist")

ERROR: In procedure chdir:
In procedure chdir: No such file or directory

Thanks,

Cayetano Santos

bug#65472: texlive split packages are missing isodate.sty, wallpaper.sty, and dashrule.sty

[Dr. Arne Babenhauserheide]

Hi,


after switching to split texlive packages (via texlive-scheme-medium),
my documents fail to compile.

I cannot find split packages for isodate.sty, wallpaper.sty, and dashrule.sty


Minimal reproduction:

--- file: test.tex ---
\documentclass{memoir}
\usepackage[iso,german]{isodate}
\usepackage{wallpaper}
\usepackage{dashrule}
\usepackage{everypage}
\begin{document}
\end{document}


guix shell --pure texlive-scheme-medium test

! LaTeX Error: File `isodate.sty' not found.
! LaTeX Error: File `wallpaper.sty' not found.
! LaTeX Error: File `dashrule.sty' not found.


Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

bug#65390: bug#65395: [PATCH] gnu: naev: Fix build.

[宋文武 via Bug reports for GNU Guix]

iyzs...@envs.net writes:

> From: 宋文武 
>
> * gnu/packages/games.scm (naev)[inputs]: Don't use sdl-union.
> Remove sdl2-mixer.

Pushed now, closing.

bug#65460: ghc/ghci are broken

[Jonas via Bug reports for GNU Guix]

Thanks! Adding gcc-toolchain to the profile fixed it, but shouldn't this 
be automatically brought in by `guix install ghc`? This does still feels 
like a bug to me, shouldn't gcc-toolchain be a part of ghcs native-inputs?

sanoj@deimos ~/builds/hs-hello$ guix shell --container ghc -- ghc hello.hs
Linking hello ...

: error:
     Warning: Couldn't figure out C compiler information!
  Make sure you're using GNU gcc, or clang
ghc: could not execute: gcc

Den 8/23/23 07:14, skrev (:
> Jonas via Bug reports for GNU Guix  writes:
>> And compiling a hello-world program with ghc gives me:
>>
>> [1 of 1] Compiling Main ( hello.hs, hello.o )
>>
>> : error:
>>       Warning: Couldn't figure out C compiler information!
>>    Make sure you're using GNU gcc, or clang
> At the risk of stating an obvious thing that you've probably already
> tried; is `gcc-toolchain` available in the environment?
>
> -- (

bug#65456: [PATCH v4] self: Build directories in chunks of max 25 files at a time.

[Janneke Nieuwenhuizen]

Janneke Nieuwenhuizen writes:

Hi!

> Ludovic Courtès writes:
>> Janneke Nieuwenhuizen  skribis:
>>
[..]

> it still has the "gnu/packages" directory name hardcoded here.  (I even
> believe this was kind-of intentional, meaning not to split-up builds of
> other directories...).  The result is, of course, that partition always
> produces an empty result for any '("guix/foo.scm") files!
>
> It is fixed by doing
>
>  (cute string-append "^" directory "/" <>)

Well, almost...In my test script it worked, but directory is "." in the
actual self.scm.

So with v3 no .go files get built at all...and then a naive `guix build
hello' seems to work!; `guix shell' for example fails.  Comparing the
list of files from `find /gnu/store/...-guix-20230823.08 -follow' is
also helpful.

I realised that there's no need to use the name-based splitting hack
that Makefile.am uses and changed the creation of chunks to simply use a
maximum chunk length of 25 files.

New version attached.

Greetings,
Janneke

>From ad94f06620e53fcc1495a2e2479dfc627177047c Mon Sep 17 00:00:00 2001
Message-ID: 
From: Janneke Nieuwenhuizen 
Date: Thu, 22 Jun 2023 08:30:25 +0200
Subject: [PATCH v4] self: Build directories in chunks of max 25 files at a
 time.

Similar to split build of make-go in Makefile.am, this breaks-up building
directories into chunks of max 25 files.  Also force garbage collection.

* guix/self.scm (compiled-modules)[process-directory]: Split building of
directories into chunks of max 25 files.
---
 guix/self.scm | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/guix/self.scm b/guix/self.scm
index 81a36e007f..fc2dfd8131 100644
--- a/guix/self.scm
+++ b/guix/self.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2017-2023 Ludovic Courtès 
 ;;; Copyright © 2020 Martin Becze 
+;;; Copyright © 2023 Janneke Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1210,7 +1211,8 @@ (define* (compiled-modules name module-tree module-files
 '((guix build compile)
   (guix build utils)))
   #~(begin
-  (use-modules (srfi srfi-26)
+  (use-modules (srfi srfi-1)
+   (srfi srfi-26)
(ice-9 match)
(ice-9 format)
(ice-9 threads)
@@ -1244,12 +1246,23 @@ (define* (compiled-modules name module-tree module-files
 (force-output))
 
   (define (process-directory directory files output)
-;; Hide compilation warnings.
-(parameterize ((current-warning-port (%make-void-port "w")))
-  (compile-files directory #$output files
- #:workers (parallel-job-count)
- #:report-load report-load
- #:report-compilation report-compilation)))
+(let* ((size 25)  ;compile max 25 files a time
+   (chunks (unfold
+(lambda (seed) (< (length seed) size)) ;p
+(cute take <> size);f
+(cute drop <> size);g
+files  ;seed
+list)));tail
+  (for-each
+   (lambda (chunck)
+ ;; Hide compilation warnings.
+ (parameterize ((current-warning-port (%make-void-port "w")))
+   (compile-files directory output chunck
+  #:workers (parallel-job-count)
+  #:report-load report-load
+  #:report-compilation report-compilation))
+ (gc))
+   chunks)))
 
   (setvbuf (current-output-port) 'line)
   (setvbuf (current-error-port) 'line)

base-commit: f4d0d0bd5e7d0e67281d84d81068f7fd5eb480ea
-- 
2.41.0


-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

bug#65419: [Shepherd] Non-reponding service control fiber

[Giovanni Biscuolo]

Hello,

Ludovic Courtès  writes:

[...]

> The conclusion seems to be that the control fiber of the ‘root’ service
> is not responding: it is blocked on a get/put? did it exit?
>
> Unfortunately we don’t have data from the logs that would give clues as
> to what went wrong.

I've had a look at /var/log/messages but nothing seems wrong except
messages like this one:

--8<---cut here---start->8---

Aug 21 14:48:42 localhost shepherd[1]: 6 connections still in use after 
sshd-13752 termination. 
Aug 21 14:48:42 localhost shepherd[1]: Service sshd-13752 (PID 29977) exited 
with 255. 
Aug 21 14:48:42 localhost shepherd[1]: Service sshd-13752 has been disabled. 
Aug 21 14:48:42 localhost shepherd[1]: Transient service sshd-13752 terminated, 
now unregistered. 

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

Is it useful configuring the monitoring service [1] on milano-guix-1 to
have useful data in the logs in case we get a similar issue?

Thanks, Gio'


[1] 
https://www.gnu.org/software/shepherd/manual/shepherd.html#Monitoring-Service

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature