bug#54945: installer should have a no-graphics boot option

Disclaimer: the last time I used an ISO for installing Guix was before there was a graphical installer, so I'm not sure what it's expected to look like now. Anyways, I tried booting the latest release on a netbook, it failed around/after KMS. Kernel seemed to lock up. No panic, no usable visible

bug#54944: guix pull hangs on 32 bit

It's been at 67% on guix-packages-base for at least an hour now. The system itself is responsive and with the swap I gave it, it has more than enough memory. Htop shows three guile processes at the top of the list when sorted by CPU%, their states are S, D, D. Both CPUs are practically idling.

bug#54728: [PATCH 2/2] gnu: valgrind: fix ld.so symbols not found

* gnu/packages/valgrind.scm (valgrind/interactive)[native-inputs]: Add libc:debug [arguments]: Add patch-default-debuginfo-path phase * gnu/packages/commencement.scm (glibc-final): Export variable. Signed-off-by: Denis 'GNUtoo' Carikli --- gnu/packages/commencement.scm | 2 +-

bug#54728: [PATCH 1/2] gnu: valgrind: impots: sort imports alphabetically

* gnu/packages/valgrind.scm: sort imports alphabetically Signed-off-by: Denis 'GNUtoo' Carikli --- gnu/packages/valgrind.scm | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/gnu/packages/valgrind.scm b/gnu/packages/valgrind.scm index 1cdc0f3b71..6648f17dfa 100644 ---

bug#54728: Valgrind not working out of the box due to stripped ld.so

On Thu, 07 Apr 2022 18:40:08 +0200 Ludovic Courtès wrote: > Hi, Hi, > Unfortunately, until that branch is merge (most likely a few months > from now), we’ll have to use the workaround you mentioned. > > Alternatively, maybe we could temporarily patch the ‘valgrind’ package > such that it has

bug#54787: importer Bioconductor: no tarball, only Git

On Thu, 14 Apr 2022 at 15:57, Ricardo Wurmus wrote: > zimoun writes: > >> On Thu, 14 Apr 2022 at 13:43, Ricardo Wurmus wrote: >> >>> We probably should *not* use RELEASE_3_14 (or whatever) as the commit, >>> though, because that is a moving target. We need to resolve to the >>> actual commit

bug#54787: importer Bioconductor: no tarball, only Git

Ricardo Wurmus schreef op do 14-04-2022 om 13:43 [+0200]: > I wonder how the updater would need to be changed.  It would need to > know about the release branch and look for new commits in that branch > only. Perhaps would be useful? It adds a

bug#54787: importer Bioconductor: no tarball, only Git

zimoun writes: > On Thu, 14 Apr 2022 at 13:43, Ricardo Wurmus wrote: > >> We probably should *not* use RELEASE_3_14 (or whatever) as the commit, >> though, because that is a moving target. We need to resolve to the >> actual commit and use its hash. >> >> I wonder how the updater would need

bug#54787: importer Bioconductor: no tarball, only Git

Hi Ricardo, On Thu, 14 Apr 2022 at 13:43, Ricardo Wurmus wrote: > We probably should *not* use RELEASE_3_14 (or whatever) as the commit, > though, because that is a moving target. We need to resolve to the > actual commit and use its hash. > > I wonder how the updater would need to be changed.

bug#54793: guile-fibers does not cross-compile

Hi! Mathieu Othacehe skribis: > guile-fibers does not cross-compile, the error is the following: > > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > In procedure dlopen: file > "/tmp/guix-build-guile-fibers-1.1.0.drv-0/fibers-1.1.0/.libs/epoll.so", > message >

bug#54928: Libtool 2.4.6 vs. 2.4.7

Am Donnerstag, dem 14.04.2022 um 14:07 +0200 schrieb Andreas Enge: > > > I have installed libtool@2.4.7 into my profile > > That is a mistake. > > > > > as well as a number of other development tools > > Probably also a mistake. > > Could you elaborate why? If you work on a project, it seems

bug#54928: Libtool 2.4.6 vs. 2.4.7

Am Thu, Apr 14, 2022 at 02:07:02PM +0200 schrieb Andreas Enge: > I had already removed it, and the problem persisted. I suppose that > autoreconf or configure created it again in version 2.4.6, and during > make my version 2.4.7 was used instead. Actually it is "configure", in my case by calling

bug#54928: Libtool 2.4.6 vs. 2.4.7

Am Thu, Apr 14, 2022 at 01:29:46PM +0200 schrieb Liliana Marie Prikler: > libtool causes at least 13802 (mere two thirds of all our packages), so > one might want to ensure that there are no gratuitous bumps when making > new versions of it available :) Quite understandable, but if then the new

bug#54787: importer Bioconductor: no tarball, only Git

zimoun writes: > First, note that annotations do not have Git repo; at least not always, > e.g., > > That’s fine. We just ignore annotation and experiment packages, and use git only for regular packages.

bug#54928: Libtool 2.4.6 vs. 2.4.7

Am Donnerstag, dem 14.04.2022 um 11:53 +0200 schrieb Andreas Enge: > Hello, > > is there a good reason to have added libtool-2.4.7 without it > replacing the libtool variable (at version 2.4.6)?  libtool causes at least 13802 (mere two thirds of all our packages), so one might want to ensure that

bug#54929: ./pre-inst-env recompiling files

Recently even after a ./bootstrap ./configure --localstatedir=/var --prefix=/usr/local/guix make any command prefixed by ./pre-inst-env starts by recompiling a bunch of scheme files with the following messages: ;;; WARNING: loading compiled file

bug#54928: Libtool 2.4.6 vs. 2.4.7

Hello, is there a good reason to have added libtool-2.4.7 without it replacing the libtool variable (at version 2.4.6)? I have installed libtool@2.4.7 into my profile, as well as a number of other development tools, and apparently both libtool versions are now used and are colliding when doing

bug#54779: same problem here

Hi ! I do have the same problem here, and have found a temporary fix to allow finishing the reconfiguration. If you `herd stop root` before reconfiguring home, the `guix home reconfigure` should finish, with an error, but allowing the reconfiguration. Just in case it might be helpful for