bug#69308: linux-libre-documentation fails to build
linux-libre-documentation fails to build (see https://ci.guix.gnu.org/build/3512631/details)
bug#63530: Issue was fixed
This issue seems to have been fixed by Tobias with commit 22642d460488896ec1ddb25d7eb262938db810eb using a patch to work around the issue. I created a patch that'd upgrade to the next version where igt-gpu-tools is actually fixed (so the patch is not needed anymore): https://issues.guix.gnu.org/67508
bug#65982: more info
commit b0d47d9e18e52ff7935aebe6ab37e702f58101be (Update u-boot to 2023.07.02) breaks creation of a bootable image. Building in a time-machine at commit d6a53849935f8584e1df57faa79c18c23fbb2aa1 works as expected.
bug#65982: Pinebook Pro image broken
Trying to set up my Pinebook Pro with my favorite distribution i found out that the usual way (invoking `guix system image gnu/system/images/pinebook-pro.scm` to build an image which is then dd'd to a micro SD card) does not yield a working result. Doing the same with guix time-machine on commit c9c195936d128465030bc05f8c319367602c93b5 generates a bootable image. Since building with a current checkout does not yield a bootable image (the pinebooks gracefully falls back to boot from the eMMC memory with its pre-installed Manjaro) I guess the bootloader broke.
bug#63530: Missing library in package procps
A little more hacking leads me to the conclusion that (probably with version 4 but it's not exactly clear from the changelog) procps has made some significant changes to it's API. So, unless igt-gpu-tools (and probably others) are fixed upstream they remain broken. Fixes through simple regex-magic in our build-phases might be possible, but I am not confident enough in the matter to guarantee that the package would not just build but be broken in a more specific manner. Is there an easy way to check which dependents of procps are actually broken currently? Or is it really just igt-gpu-tools? There's two ways to go (I'd be happy for some input and volunteer to do the actual leg-work): 1. Add an additional procps-3 package with the older API to fix the broken packages. 2. Leave it as-is and wait for an upstream change of the currently broken packages.
bug#63530: Missing library in package procps
Hi Trying to upgrade a somewhat outdated system (from March 23) I noticed igt-gpu-tools failed to build. Investigating a bit the build fails due to some "proc/readproc.h" include missing. I think i managed to fix the failure in procps's Makefile, but testing the patched build results in a rather huge rebuild. `guix refresh -l procps` results in 5328 packages. Are there any other approaches one could take to a) fix the broken package without b) triggering a world-rebuild? I'm not sure if this is an upstream bug and whether other packages are affected, neither do I know whether the other header files that aren't being copied to the install dir should be. Thanks for your input in advance! I'll update this issue with a patch as soon as I manage to verify that my attempt actually works. gabber
bug#59160: Acknowledgement (Fritzing parts are missing)
Resending this to debbugs since the mail previously was only sent to Tobias
Hi Tobias
Thanks for the review!
The line in question will make all functions return prematurely that are
intended to use libgit2 (that's why the git_libgit2_init is
patched). Fritzing still reports "Sorry, we have a problem with the
swapping mechanism.
Fritzing still works, but you won't be able to change parts
properties.Error 1", but seems to work fine apart from that.
Since the content of the returned String doesn't seem to matter (as long
as it's not an empty string) I've adjusted it to a less ugly "true".
I'm sorry i don't have the capacity to provide a more satisfying
solution ATM but at least Fritzing is back to a usable state.
Best wishes,
g
> From 242f0f785843560030a811635c0c4a72d81b Mon Sep 17 00:00:00 2001
From: Gabriel Wicki
Date: Tue, 22 Nov 2022 00:35:19 +0100
Subject: [PATCH] gnu: fritzing: Update to 0.9.6.
* gnu/packages/engineering.scm (fritzing): Update to 0.9.6.
[arguments]<#:phases>{'configure}: Modify to work with
new version.
---
gnu/packages/engineering.scm | 34 ++
1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/gnu/packages/engineering.scm b/gnu/packages/engineering.scm
index 43e23e30a8..edfef77a5c 100644
--- a/gnu/packages/engineering.scm
+++ b/gnu/packages/engineering.scm
@@ -669,7 +669,7 @@ (define-public fasthenry
(define-public fritzing
(package
(name "fritzing")
-(version "0.9.3b")
+(version "0.9.6")
(source (origin
(method git-fetch)
(uri (git-reference
@@ -678,7 +678,7 @@ (define-public fritzing
(file-name (git-file-name name version))
(sha256
(base32
-"0hpyc550xfhr6gmnc85nq60w00rm0ljm0y744dp0z88ikl04f4s3"
+"083nz7vj7a334575smjry6257535h68gglh8a381xxa36dw96aqs"
(build-system gnu-build-system)
(arguments
`(#:phases
@@ -687,24 +687,18 @@ (define-public fritzing
(lambda* (#:key inputs outputs #:allow-other-keys)
(copy-recursively (assoc-ref inputs "fritzing-parts-db")
"parts")
- ;; Make compatible with libgit2 > 0.24
- (substitute* "src/version/partschecker.cpp"
- (("error = git_remote_connect\\(remote, GIT_DIRECTION_FETCH,
\\)")
-"error = git_remote_connect(remote, GIT_DIRECTION_FETCH,
, NULL, NULL)"))
-
;; Use system libgit2 and boost.
(substitute* "phoenix.pro"
- (("^LIBGIT2INCLUDE =.*")
-(string-append "LIBGIT2INCLUDE="
- (assoc-ref inputs "libgit2") "/include\n"))
- (("^LIBGIT2LIB =.*")
-(string-append "LIBGIT2LIB="
- (assoc-ref inputs "libgit2") "/lib\n")))
- ;; This file checks for old versions of Boost, insisting on
- ;; having us download the boost sources and placing them in the
- ;; build directory.
- (substitute* "pri/utils.pri"
- (("error\\(") "message("))
+ (("^LIBGIT_STATIC.*")
+(string-append "LIBGIT2INCLUDE=" (assoc-ref inputs "libgit2")
"/include\n"
+ "LIBGIT2LIB=" (assoc-ref inputs "libgit2")
"/lib\n"
+ "INCLUDEPATH += $$LIBGIT2INCLUDE\n"
+ "LIBS += -L$$LIBGIT2LIB -lgit2\n"))
+ (("^.*pri/libgit2detect.pri.") ""))
+ ;; Trick the internal mechanism to load the parts
+ (substitute* "src/version/partschecker.cpp"
+ ((".*git_libgit2_init.*")
+"return \"true\";"))
(let ((out (assoc-ref outputs "out")))
(invoke "qmake"
@@ -723,11 +717,11 @@ (define-public fritzing
(method git-fetch)
(uri (git-reference
(url "https://github.com/fritzing/fritzing-parts;)
- (commit version)))
+ (commit (string-append "release_" version
(file-name (git-file-name "fritzing-parts" version))
(sha256
(base32
- "1d2v8k7p176j0lczx4vx9n9gbg3vw09n2c4b6w0wj5wqmifywhc1"))
+ "0wsvn57v6n0ygnhk2my94rrfzb962z1cj4d1xmp1farwck3811h6"))
(home-page "https://fritzing.org;)
(synopsis "Electronic circuit design")
(description
--
2.38.0
bug#59160: Acknowledgement (Fritzing parts are missing)
I've come up with the following patch. It is not optimal (there's still
some warnings and it makes use of an ugly hack to get rid of a certain
"Unable to find parts git repository" message) but with that patch
Fritzing is in a usable state.
>From e713d634d8358d1a24219634fa7e8ed3b5c5dff4 Mon Sep 17 00:00:00 2001
From: Gabriel Wicki
Date: Thu, 10 Nov 2022 01:53:41 +0100
Subject: [PATCH] * gnu/packages/engineering.scm (fritzing): Update to 0.9.6.
[source]: Update hash.
[arguments]: Update libgit2 hacks.
---
gnu/packages/engineering.scm | 34 ++
1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/gnu/packages/engineering.scm b/gnu/packages/engineering.scm
index b6a881d03b..dd12029b3f 100644
--- a/gnu/packages/engineering.scm
+++ b/gnu/packages/engineering.scm
@@ -669,7 +669,7 @@ (define-public fasthenry
(define-public fritzing
(package
(name "fritzing")
-(version "0.9.3b")
+(version "0.9.6")
(source (origin
(method git-fetch)
(uri (git-reference
@@ -678,7 +678,7 @@ (define-public fritzing
(file-name (git-file-name name version))
(sha256
(base32
-"0hpyc550xfhr6gmnc85nq60w00rm0ljm0y744dp0z88ikl04f4s3"
+"083nz7vj7a334575smjry6257535h68gglh8a381xxa36dw96aqs"
(build-system gnu-build-system)
(arguments
`(#:phases
@@ -687,24 +687,18 @@ (define-public fritzing
(lambda* (#:key inputs outputs #:allow-other-keys)
(copy-recursively (assoc-ref inputs "fritzing-parts-db")
"parts")
- ;; Make compatible with libgit2 > 0.24
- (substitute* "src/version/partschecker.cpp"
- (("error = git_remote_connect\\(remote, GIT_DIRECTION_FETCH,
\\)")
-"error = git_remote_connect(remote, GIT_DIRECTION_FETCH,
, NULL, NULL)"))
-
;; Use system libgit2 and boost.
(substitute* "phoenix.pro"
- (("^LIBGIT2INCLUDE =.*")
-(string-append "LIBGIT2INCLUDE="
- (assoc-ref inputs "libgit2") "/include\n"))
- (("^LIBGIT2LIB =.*")
-(string-append "LIBGIT2LIB="
- (assoc-ref inputs "libgit2") "/lib\n")))
- ;; This file checks for old versions of Boost, insisting on
- ;; having us download the boost sources and placing them in the
- ;; build directory.
- (substitute* "pri/utils.pri"
- (("error\\(") "message("))
+ (("^LIBGIT_STATIC.*")
+(string-append "LIBGIT2INCLUDE=" (assoc-ref inputs "libgit2")
"/include\n"
+ "LIBGIT2LIB=" (assoc-ref inputs "libgit2")
"/lib\n"
+ "INCLUDEPATH += $$LIBGIT2INCLUDE\n"
+ "LIBS += -L$$LIBGIT2LIB -lgit2\n"))
+ (("^.*pri/libgit2detect.pri.") ""))
+ ;; Trick the internal mechanism to load the parts
+ (substitute* "src/version/partschecker.cpp"
+ ((".*git_libgit2_init.*")
+"return
\"083nz7vj7a334575smjry6257535h68gglh8a381xxa36dw96aqs\";"))
(let ((out (assoc-ref outputs "out")))
(invoke "qmake"
@@ -723,11 +717,11 @@ (define-public fritzing
(method git-fetch)
(uri (git-reference
(url "https://github.com/fritzing/fritzing-parts;)
- (commit version)))
+ (commit (string-append "release_" version
(file-name (git-file-name "fritzing-parts" version))
(sha256
(base32
- "1d2v8k7p176j0lczx4vx9n9gbg3vw09n2c4b6w0wj5wqmifywhc1"))
+ "0wsvn57v6n0ygnhk2my94rrfzb962z1cj4d1xmp1farwck3811h6"))
(home-page "https://fritzing.org;)
(synopsis "Electronic circuit design")
(description
--
2.37.3
bug#59160: Fritzing parts are missing
I've come to notice that Fritzing currently does not work in Guix. The program starts but greets the user with a bunch of warnings/error pop-ups. One being about "142 parts" missing or not being found and indeed: the parts pane remains empty and Fritzing therefor unusable.
bug#56676: SuperCollider's Help Browser doesn't display text (possible QtWebEngine issue?)
Hi! I've noticed that when starting SuperCollider IDE (with the scide command) the Help Browser (which is the panel on top on the right side with vanilla/no configuration) doesn't show any text. IIRC SuperCollider's documentation is HTML documents (you can also browse it online [1]) displayed through some QtWeb-widget (I am no expert in Qt). My first question: is this reproducible? Or do others also see no text in the Help Browser? I have tried adding qtwebengine as an input and passing a configure flag, but this didn't change the issue: diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm index bab9d66a2d..975690b72f 100644 --- a/gnu/packages/audio.scm +++ b/gnu/packages/audio.scm @@ -3183,6 +3183,7 @@ (define-public supercollider "-DSC_QT=ON" "-DCMAKE_BUILD_TYPE=Release" "-DFORTIFY=ON" + "-DSC_USE_QTWEBENGINE:BOOL=ON" ;; "-DLIBSCSYNTH=ON" ; TODO: Re-enable? "-DSC_EL=OFF") ;scel is packaged individually as emacs-scel #:phases @@ -3234,6 +3235,7 @@ (define-public supercollider qtdeclarative qtsvg qtwebchannel + qtwebengine qtwebsockets)) (propagated-inputs ;to get native-search-path (list qtwebengine)) I'm more than happy to hunt that bug down but am grateful for any pointers to where the issue could possibly originate. gabriel [1] https://doc.sccode.org
bug#48595: `guix install mes` fails in 'check'-phase
(This is a reply to the original bug report [0]; cross-posting to bug-...@gnu.org for reasons described below. I hope this is ok) On Sun, Jun 13, 2021 at 02:52:41PM +0200, Ludovic Courtès wrote: > Hi, Hello! I guess i need to clarify: it's not mes building that fails; it's mescc-tools (version 0.7.0 on x86_64) (which mes depends upon). Sorry for the confusion. > Could this be non-deterministic? I have the same problem in guix on my Debian host and in my qemu Guix System. And since the error is the same as in the build on ci.guix.gnu.org [1] i'm under the impression that it might be (at least somewhat) deterministic ;) I should be able to test this in my (real) Guix System host tomorrow. > Thoughts? Digging through the CI logs a bit i found mescc-tools-0.7.0 failing to build for x86_64[2]. Also there is this build (mes-0.23 for x86_64) failing with the same errors [3], but during `check' phase for dependency nyacc-1.00.2 (this is not the current version; also: i'm not sure if this really is related, but the log outputs are strikingly similar). My debugging[5] didn't reveal anything further than what's already in the logs. So i'm CC-ing bug-mes mailing list, since that's probably the most adequate place to discuss this issue :) g [0] https://issues.guix.gnu.org/48595 [1] https://ci.guix.gnu.org/build/286577/details [2] https://ci.guix.gnu.org/build/82814/details [3] https://ci.guix.gnu.org/build/82812/details [4] mescc-tools/test/test1/hello.sh:26 [5] ./test/results/test1-binary --> segfault
bug#48595: `guix install mes` fails in 'check'-phase
i tried running `guix install mes` which fails on my x86_64 debian machine. CI fails as well (https://ci.guix.gnu.org/build/286577/details). log output shows a couple of segmentation faults and an undefined variable in phase 'check': test/test10/hello.sh + '[' amd64 = amd64 ']' + ./test/results/test1-binary + . ./sha256.sh ++ set -ex test/test1/hello.sh: line 37: 171 Segmentation fault ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1 + '[' amd64 = x86 ']' + exit 0 make: *** [makefile:104: test1-binary] Error 139 [...] test/test7/hello.sh: line 31: 175 Segmentation fault ./test/results/test7-binary test/test7/hex1.hex1 > test/test7/proof [...] test/test3/hello.sh: line 23: GET_MACHINE_FLAGS: unbound variable
