bug#71921: Bootstrapping path discovered for RISC-V 64bit

have reported it upstream. We should use Gash once the issue is fixed. Also, we only made the path until a modern GCC, not all the rest of it, that we should be able to reuse from the current `commencement.scm` module. This is the link to the repo: https://github.com/ekaitz-zarraga/commencemen

bug#69394: cross-gcc-toolchain for riscv64 doesn't search crt1.o properly

Hi, I made this package: ``` (define-module (cross) #:use-module (guix packages) #:use-module (guix gexp) #:use-module (gnu packages cross-base)) (define-public gcc-cross-riscv64-linux-gnu-toolchain (cross-gcc-toolchain "riscv64-linux-gnu")) ``` And used in in the session

bug#67796: Automake is not compatible with older Autoconfs we provide

Hi, On 2024-01-12 19:38, Giovanni Biscuolo wrote: It's not a big deal if we just remove the older versions. but if they are needed for bootstrapping they should be kept around, no? No, because they are not needed for the bootstrapping itself. We build stuff from scratch for it, I needed t

bug#67796: Automake is not compatible with older Autoconfs we provide

Hi, On 2024-01-11 10:42, Giovanni Biscuolo wrote: Hi Ekaitz Ekaitz Zarraga writes: Hi, We have automake packaged, but it's not compatible with older autoconf versions so autoconf is not very usable at this point. ``` Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv)$ guix

bug#67796: Automake is not compatible with older Autoconfs we provide

Maxim, > 'guix show automake' shows we also have automake 1.9.6 available. I suppose this still works with the older autoconf? I don't have that automake version and I can't find it Guix's codebase. Are you up to date with master? Best, Ekaitz

bug#67796: Automake is not compatible with older Autoconfs we provide

Hi, We have automake packaged, but it's not compatible with older autoconf versions so autoconf is not very usable at this point. ``` Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv)$ guix shell automake autoconf@2.64 Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv) [env]$ auto

bug#67622: libtorrent-rasterbar: Tests stuck forever

Hi, I think b1cca212640 introduced some error in the tests of libtorrent-rasterbar producing the package to hang forever. I tried this several times with same result. This is the output of my `guix build libtorrent-rasterbar` after 12 hours: ``` The following derivation will be built: /gnu/

bug#66699: zig: fail to link SDL2

Hi, I tracked this pretty far: This is a related issue that mentions the `mepo` package: https://github.com/ziglang/zig/issues/12170 And I realized the problem comes from `pkg-config`. It's telling zig to use the static library first. Removing `pkg-config` from the `native-inputs` in your propo

bug#66699: zig: fail to link SDL2

Hi, On Friday, November 10th, 2023 at 06:01, Nguyễn Gia Phong wrote: > On 2023-11-01 at 20:52+00:00, Ekaitz Zarraga wrote: > > > On Monday, October 23rd, 2023 at 09:34, Nguyễn Gia Phong wrote: > > > > > I am trying to package Mepo, an OpenStreetMap fronten

bug#66699: zig: fail to link SDL2

--- Original Message --- On Monday, October 23rd, 2023 at 09:34, Nguyễn Gia Phong wrote: > I am trying to package Mepo, an OpenStreetMap frontend written in Zig. > The currently packaged Zig fails to find transitive dependencies of SDL2: > https://paste.sr.ht/~cnx/db21e1ef9a6828f3ec898db

bug#63048: [Home] Shell alias values are not properly quoted

I made something like this instead of reusing the code you suggested, Ludo. But it doesn't work. I don't really know why: diff --git a/guix/scripts/home/import.scm b/guix/scripts/home/import.scm index fd263c0699..2d7a7abbf2 100644 --- a/guix/scripts/home/import.scm +++ b/guix/scripts/home/import

bug#63048: [Home] Shell alias values are not properly quoted

As an extra note: The problem I encountered was when the alias was defined using single quote marks: alias ls='ls blabla "problem"' this is parsed to: ("ls" . "blabla \"problem\"") Which is written as: alias ls="blabla "problem"" Which is wrong. So the problem relies on the fact that the q

bug#62226: bash-minimal fails to build on x86_64-w64-mingw32

Hi, Adding: ``` "ac_cv_header_sys_socket_h=no" ``` To configure flags in the case the target is mingw solves the first issue, but more issues appear. I have no enough knowledge about autotools to dig into this much further but it looks like we are finding wrong stuff in the configure step: `

bug#62226: bash-minimal fails to build on x86_64-w64-mingw32

Any package that uses `bash-minimal` to build in mingw (all of them?) fails when trying to build `bash-minimal` with the following error: ``` phase `patch-generated-file-shebangs' succeeded after 0.0 seconds starting phase `build' rm -f mksyntax.exe gcc -DPROGRAM='"bash.exe"' -DCONF_HOSTTYPE='"x8

bug#57932: `environment_variables` in build containers are set wrong

Hi, I have a package that depends on `mes`. When I build it with `guix build $package -K` and I jump to the resulting build directory, the `environment_variables` file looks like this: ``` export LIBRARY_PATH="/gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0/lib:/gnu/store/22n2s0vfvqg9v

bug#55833: cross-base error: wrong type argument in position 1

Forget it, there was some code missing to match the platform correctly in my custom GCC. Added it and now it's working without the `unknown` part. Cheers

bug#55833: cross-base error: wrong type argument in position 1

Hi, > * use "riscv64-linux-gnu" instead of "riscv64-unknown-linux-gnu" > (as expected by (guix platforms riscv)). There's an slight problem with that. I tried to do it and I can't build my custom gcc without sending the full triplet (with -unknown) and if I make the other parts of the system, li

bug#55833: cross-base error: wrong type argument in position 1

In procedure raise-exception: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f ``` I think the error was introduced in the commit b55310603f0df7d5ae02d47cb8d4be58bf1d41ca but I can't really explain what's happening. You can replicate this usin

bug#54626: gcc-4.7 and gcc-4.8 compilation failure in x64

I've managed to compile gcc-4.7 using a really old commit (v0.16.0) with guix time-machine but nowadays is broken.

bug#54626: gcc-4.7 and gcc-4.8 compilation failure in x64

Hi, I'm digging on old compiler versions for bootstrapping purposes and I realized that gcc 4.7 and 4.8 packages don't compile on x64. We have been able to reproduce the failure of gcc 4.7 but we didn't test the 4.8 error that far. In gcc-4.7 the error is the following: ./md-unwind-support.h:

bug#53696: Integer overflow on Guix GC size calculation

> Ekaitz Zarraga eka...@elenq.tech skribis: > > > > Ekaitz, what guix-daemon version are you running? > > > > $ guix --version > > What about the daemon though? As in: > > sudo /proc/$(pidof guix-daemon |cut -f1 -d ' ')/exe --version > > Tha

bug#53696: Integer overflow on Guix GC size calculation

> Ekaitz, what guix-daemon version are you running? $ guix --version guix (GNU Guix) c5000dcc375229ff42727f090d4243107d3a04a6 Copyright (C) 2022 the Guix authors License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redist

bug#53696: Integer overflow on Guix GC size calculation

Hi, On Wednesday, February 2nd, 2022 at 8:45 PM, Liliana Marie Prikler wrote: > Hi, > > Am Dienstag, dem 01.02.2022 um 21:54 + schrieb Ekaitz Zarraga: > > > Hi, > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Tuesday, February 1s

bug#53696: Integer overflow on Guix GC size calculation

Hi, ‐‐‐ Original Message ‐‐‐ On Tuesday, February 1st, 2022 at 10:20 PM, Liliana Marie Prikler wrote: > > I find it somewhat concerning that you've accumulated more than 2^64 > bytes of garbage. I'm a dirty boy. > Are some items counted double here? The number started growing from

bug#53696: Integer overflow on Guix GC size calculation

Hi, I noticed there's some kind of a wierd integer overflow on the size calculation on `guix gc`: [17592186042896 MiB] deleting '/gnu/store/j2s6kva8l20m6rjj10bnknq99jc9rg6w-ghc-random-1.2.0-builder' [17592186042896 MiB] deleting '/gnu/store/8nx7zzj629qvv1533c48bl19wrkwcjh2-curl-7.79.1-doc' [17

bug#53694: Librecad fails to build

Hi, After a `guix pull` librecad fails to build. I attach the log. It looks related with `boost` but I have no time to research further right now. Best, Ekaitz q36q0k7jjsh9lpk3h1i651dilgrdrq-librecad-2.2.0-rc2.drv.bz2 Description: application/bzip

bug#51027: Icecat: gfx.webrender.all unset by default - gpu performance issues

Hi, I recently found my GPU struggling to render simple websites on icecat while ungoogled-chromium is able to do it correctly. The most recent one was element, Matrix's web client. I opened an issue there[^1] and they told me to set the `gfx.webrender.all` to `true`. I did it and everything wor

bug#48595: `guix install mes` fails in 'check'-phase

BTW, > #t) > - (propagated-inputs `(("which" ,which))) > It's wrong. It should be `inputs` but you get what I mean. :S

bug#48595: `guix install mes` fails in 'check'-phase

>From 828ba527e652de9166eddf24a9296b5aa2db3f79 Mon Sep 17 00:00:00 2001 From: Ekaitz Zarraga Date: Tue, 27 Jul 2021 10:00:30 +0200 Subject: [PATCH] Update guix helper files Bump mescc-tools to 1.1.0 --- guix/git/mes.scm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --gi

bug#47463: Fixed by 47467

Empty Message

bug#47463: Blender: Voxel remesher failed to create mesh

This issue can be closed since: 47467 is merged

bug#47463: Blender: Voxel remesher failed to create mesh

Hi, I found an issue with blender. Our packaged version it's not able to run the Voxel Remesher, I think because OpenVBD[^1] is not included in our package. Every time I use the Voxel Remesh tool it says: "Voxel remesher failed to create mesh" But the Quadriflow remesher works fine. I searche

bug#43448: [PATCH] gnu: freecad: Fix compilation flags

Hi everyone, I managed to solve the longstanding issue with freecad's compilation (#43448). I'll submit a new change with the package update to 0.18.5 next. Thanks >From d4d8a65679406b212c68d5198f239bdd71395541 Mon Sep 17 00:00:00 2001 From: Ekaitz Zarraga Date: Sun, 6 Dec

bug#43448: FreeCAD fails to compile

On Saturday, December 5, 2020 5:55 PM, John Soo wrote: > Nice work Ekaitz! > > I worked hard on freecad, it is quite a difficult program to package. That > was a weird issue that I asked about on the freecad forums. Perhaps it is > fixed upstream now, which would be excellent. Thanks for keepin

bug#43448: FreeCAD fails to compile

Looks like this line, inherited from the previous definition, was giving some trouble: > (string-append "-DCMAKE_INSTALL_LIBDIR=\\"" (assoc-ref %outputs > "out") "/lib\\"") It was creating wrong variables (and wrong syntax too!): if(EXISTS "$ENV{DESTDIR}/tmp/guix-build-freeca

bug#43448: FreeCAD fails to compile

Hi, I solved most of the compilation issue with freecad. Now my package version compiles but install phase fails with this error: ```

bug#44381: Bombadillo: failed to build

Hi, Yeah, problem solved I'm sorry I thought I pulled before trying it... Thanks

bug#44381: Bombadillo: failed to build

Hi, Bombadillo package fails to build. This is the error I get, which like proposed in [1] doesn't show meaningful information. ``` starting phase `install-license-files' installing 1 license files from '.' Backtrace: 11 (primitive-load "/gnu/store/mrrxfmi21va142li2jwh7w3cksv…") In i

bug#44098: [freecad-0.18.4] Compilation failed

Hi, I had errors compiling freecad. I'm in this commit of guix: 6ea61b4818b355cab66e4f0931ce0314368e4abb Errors are not clear in the build output. I've found error messages around the following issues: - In configure step: mpi.h, shiboken2, pyside2 and pysidetools2 are not found - The pyside re

bug#41512: SERVICES: Documentation pictures broken

Hi, I just found the picture that describes service composition is broken: https://guix.gnu.org/manual/en/html_node/Service-Composition.html Regards, Ekaitz

bug#40170: Audio-Output of some IceCat videos far too low pitch

‐‐‐ Original Message ‐‐‐ On Saturday, March 21, 2020 6:59 PM, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote: > Merged with #37244, #38047. > > Arne Babenhauserheide 写道： > > > I don’t know why. > > I don't think anybody does for sure :-( > > Try the work-arounds in https://de

bug#40031: OpenScad Test errors

‐‐‐ Original Message ‐‐‐ On Wednesday, March 11, 2020 10:51 PM, Leo Famulari wrote: > On Wed, Mar 11, 2020 at 08:48:43PM +0000, Ekaitz Zarraga wrote: > > > Hi, > > My installation of GuixSD fails to install OpenSCAD. > > Running `guix environment --pure --ad-hoc

bug#40031: OpenScad Test errors

Hi, My installation of GuixSD fails to install OpenSCAD. Running `guix environment --pure --ad-hoc openscad` fails with the errors I attach. Can you reproduce or is it just a problem with my installation? Ideas about how can I correct this? Regards, Ekaitz ElenQ Technology Ethical Innovation

bug#39794: AVR-Toolchain-5 avr/io not found

> > I can replicate what you did and it works. > > Nice! :-) > > > May it be conflicting with other packages? > > arm-none-eabi-toolchain is conflicting with avr-toolchain since both are > setting the CROSS_* environment variables. See the output of `avr-gcc -E -v > -` below. > > This should pro

bug#39794: AVR-Toolchain-5 avr/io not found

> I'm not able to reproduce this error. Could you provide the exact steps > you did? Here's what I did. Oh... I saw what's happening... I was using `guix environment --manifest=manifest.scm` Being manifest: (specifications->manifest '("unzip" "zip" "git" "wget" "dfu-programm

bug#39794: AVR-Toolchain-5 avr/io not found

But looks like some part of the code is not including the /avr/include/inttypes.h file because it's declared on it. Ideas on this?

bug#39794: AVR-Toolchain-5 avr/io not found

Not working for me: ``` QMK Firmware 0.7.163 Making helix/rev2 with keymap default [ERRORS] In file included from drivers/avr/pro_micro.h:28:0, from keyboards/helix/rev2/matrix.c:33: /gnu/store/gq69j5j0458dcc4jp5ymq

bug#39794: AVR-Toolchain-5 avr/io not found

I'm checking the output by avr-gcc-4.9 in order to compare, and it doesn't have the stubs-32.h file neither but the compilation with avr-gcc-4.9 doesn't ask for it so it doesn't break. Instead, if I use avr-gcc-5 it asks for the stubs-32.h file and it fails because it's not installed. Both of

bug#39794: AVR-Toolchain-5 avr/io not found

Follow up of the problem: Looks like what it's missing is `multilib`, avr-gcc-4.9 package description clearly activates multilib and states that in a comment: (define-public avr-gcc-4.9 (let ((xgcc (cross-gcc "avr" #:xgcc gcc-4.9 #:xbinutils avr-binutils))) (package (inherit xgcc)

bug#39794: AVR-Toolchain-5 avr/io not found

Hi, I've been trying to debug AVR toolchain errors found in here: https://lists.gnu.org/archive/html/help-guix/2020-02/msg00204.html I'm not experienced enough to know all that's going on here and I need some assistance to make everything work. I'm working on QMK-Firmware (helix keyboard spec