bug#68960: [doc] No host resolution when "Chrooting into an existing system"
Following the instructions from the "Chrooting into an existing system" section of the manual, the resulting chroot fails to resolve hosts, e.g. --8<---cut here---start->8--- ping gnu.org --8<---cut here---end--->8--- fails but --8<---cut here---start->8--- ping 9.9.9.9 --8<---cut here---end--->8--- works. This means in particular that most guix commands fail within the chroot since Guix uses hostnames by default.
bug#68905: Boot fails when symlink exists
Today my Guix System crashed during the boot process for external reasons. Upon restart, booting a system would drop into the REPL right after the following line: --8<---cut here---start->8--- making '/var/...' the current system... --8<---cut here---end--->8--- complaining that the symlink already exists. I checked gnu/build/activation.scm (activate-current-system), and there is this: --8<---cut here---start->8--- ;; Atomically make SYSTEM current. (let ((new (string-append %current-system ".new"))) (symlink system new) (rename-file new %current-system))) --8<---cut here---end--->8--- And indeed, there was a dangling /run/current-system.new file on my disk. After removing it (from a live USB, didn't know how to do this from the Guile REPL), the system succeeded to boot. The fix should be easy: ensure that (symlink system new) overwrites any potentially existing file. Cheers! Pierre
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
Excellent, thanks a lot! :) signature.asc Description: PGP signature
bug#56437: Reduce closure size of gsettings-desktop-schemas
Sounds good! signature.asc Description: PGP signature
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
I've pushed the SBCL closure size reduction. I'll be the road for a while, unable to work on this patch, so if anyone wants to work on it and merge, please go ahead :) Left to do: - Suggestion: add a keyword to choose between asdf:compile-system and asdf:load-system (default should be asdf:load-system). - Make sure sbcl-stumpwm-kbd-layouts usees asdf:compile-system. - Rebuild the Lisp world to test. Cheers! Pierre signature.asc Description: PGP signature
bug#56437: Reduce closure size of gsettings-desktop-schemas
Hi, Gsettings-desktop-schemas is required by WebKitGTK to load HTTPS pages. But it also depends on gnome-backgrounds which weights some 40 MiB. For sure this does not help the closure size... I suggest we create a separate output, or maybe a gsettings-desktop-schemas-minimal which does not include the reference to the backgrounds. Thoughts? Pierre signature.asc Description: PGP signature
bug#56429: Reduce aspell closure size
Hi, Currently aspell depends on Perl only because of its aspell-import script. Could we move this script to a separate output (which name?) to halve the closure size? Cheers! signature.asc Description: PGP signature
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
While we are rebuilding the Lisp world, I suggest we remove Coreutils
from the SBCL closure since it's only needed on LispWorks and on
non-Linux:
--8<---cut here---start->8---
(add-after 'install 'remove-coreutils-references
;; They are only useful on non-Linux, non-SBCL.
(lambda* (#:key outputs #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
(share-dir (string-append out "/share/sbcl/")))
(substitute* (string-append share-dir
"src/code/run-program.lisp")
(("\\(run-program \".*uname\"")
"(run-program \"uname\""))
(substitute* (string-append share-dir "contrib/asdf/asdf.lisp")
(("\\(\".*/usr/bin/env\"")
"(\"/usr/bin/env\""))
(substitute* (string-append share-dir "contrib/asdf/uiop.lisp")
(("\\(\".*/usr/bin/env\"")
"(\"/usr/bin/env\""))
#t)))
--8<---cut here---end--->8---
signature.asc
Description: PGP signature
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
Find the first draft attached. Do not merge, we need to figure out what to do with sbcl-stumpwm-kbd-layouts. signature.asc Description: PGP signature This fixes 2 flaws in the asdf-build-system: 1. Use asdf:load-system instead of asdf:compile-system. The latter is not recommended by the manual and fails with at least 2 systems. 2. Add the build directory to the ASDF registry so that .asd files are automatically found. This has a double benefit: - It dramatically simplifies package definition writing. - It fixes a bug which used to cause the check phase to fail. All commits after the first two adapt the Common Lisp package definitions to the new build system and in particular fix many check phases. >From fd4eb6c4d5fce8d3c1ef205b541ddf76ed0c478a Mon Sep 17 00:00:00 2001 From: Pierre Neidhardt Date: Fri, 1 Jul 2022 16:37:44 +0200 Subject: [PATCH 01/18] guix: build: Switch from asdf:compile-system to asdf:load-system. * guix/build/lisp-utils.scm (compile-systems): Switch from asdf:compile-system to asdf:load-system. According to the ASDF manual: This will make sure all the files in the system are compiled, but not necessarily load any of them in the current image; on most systems, it will _not_ load all compiled files in the current image. This function exists for symmetry with 'load-system' but is not recommended unless you are writing build scripts and know what you're doing. --- guix/build/lisp-utils.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guix/build/lisp-utils.scm b/guix/build/lisp-utils.scm index 17d2637f87..bd6b21d5a6 100644 --- a/guix/build/lisp-utils.scm +++ b/guix/build/lisp-utils.scm @@ -116,7 +116,7 @@ (define (compile-systems systems asd-files) `(asdf:load-asd (truename ,asd-file))) asd-files) ,@(map (lambda (system) - `(asdf:compile-system ,system)) + `(asdf:load-system ,system)) systems (define (test-system system asd-files test-asd-file) -- 2.32.0 >From 2395f5bef855cb734d13745b9c90a3bbae550d56 Mon Sep 17 00:00:00 2001 From: Pierre Neidhardt Date: Fri, 1 Jul 2022 17:17:32 +0200 Subject: [PATCH 02/18] build-system: asdf: Let ASDF locate the .asd files. * guix/build-system/asdf.scm (package-with-build-system): Remove 'asd-files' and replace 'test-asd-file' by 'asd-test-systems'. (lower): Same. * guix/build/asdf-build-system.scm (source-asd-file): Remove since ASDF does it better than us. (find-asd-files): Same. (build): Remove unused asd-files argument. (check): Remove asd-files argument and replace asd-systems by asd-test-systems. * guix/build/lisp-utils.scm (compile-systems): Call to ASDF to find the systems. (test-system): Same. This approach has many benefits: - It's simplifies the build system. - The package definitions are easier to write. - It fixes a bug with systems that call asdf:clear-system which would cause the load to fail. See for instance test systems using Prove. --- guix/build-system/asdf.scm | 13 +++- guix/build/asdf-build-system.scm | 28 ++--- guix/build/lisp-utils.scm| 35 ++-- 3 files changed, 29 insertions(+), 47 deletions(-) diff --git a/guix/build-system/asdf.scm b/guix/build-system/asdf.scm index a0f4634db0..98231714d9 100644 --- a/guix/build-system/asdf.scm +++ b/guix/build-system/asdf.scm @@ -202,7 +202,7 @@ (define (new-inputs inputs-getter) (define base-arguments (if target-is-source? (strip-keyword-arguments - '(#:tests? #:asd-files #:lisp #:asd-systems #:test-asd-file) + '(#:tests? #:lisp #:asd-systems #:asd-test-systems) (package-arguments pkg)) (package-arguments pkg))) @@ -270,9 +270,8 @@ (define (asdf-build lisp-type) (lambda* (name inputs #:key source outputs (tests? #t) - (asd-files ''()) (asd-systems ''()) - (test-asd-file #f) + (asd-test-systems ''()) (phases '%standard-phases) (search-paths '()) (system (%current-system)) @@ -292,6 +291,11 @@ (define systems `(quote ,(list package-name))) asd-systems)) +(define test-systems + (if (null? (cadr asd-test-systems)) + systems + asd-test-systems)) + (define builder (with-imported-modules imported-modules #~(begin @@ -302,9 +306,8 @@ (define builder (%lisp-type #$lisp-type)) (asdf-build #:name #$name #:source #+source - #:asd-files #$asd-files #:asd-systems #$systems - #:test-asd-file #$test-asd-file + #:asd-test-systems #$test-systems #:system #$system #:tests? #
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
I found a blocker: Some StumpWM contribs like sbcl-stumpwm kbd-layout make calls at the top level which expect a running session of StumpWM, and thus asd:load-system will fail on them, while asdf:compile-system used to work. Suggestion: add an option to our build system to choose between asdf:load-system and asdf:compile-system. We default to asdf:load-system and use asdf:compile-system in stumpwm-contrib. Thoughts? signature.asc Description: PGP signature
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
Robert Goldman from ASDF found out why the "COMPONENT not found" issue happens: https://gitlab.common-lisp.net/asdf/asdf/-/issues/119#note_9808 So either we fix most of the Prove-depending libraries, or we just do what's expected from every one, that is, add the directory to the ASDF registries. The latter is much easier of course... signature.asc Description: PGP signature
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
Exactly, I already wrote the patch that did! :) Will send soon, need to do some more testing. signature.asc Description: PGP signature
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
Hi Guillaume, I gave it a go and your suggestion indeed cuts it for cleavir and cl-gamepad. It did not fix it for the tests though. I did some more testing, and this is what I found out on one of the failing systems (cl-reexport): from a --pure sbcl repl, if I load the .asd files manually then run test-system, I can reproduce the issue. However, if I run --8<---cut here---start->8--- (asdf:initialize-source-registry `(:source-registry (:tree ,(uiop:getcwd)) :inherit-configuration)) (asdf:test-system :cl-reexport) --8<---cut here---end--->8--- then it works! In other words, I believe that `asdf:load-asd' is yet another under-used ASDF function, and we should probably go with the officially recommended way, namely adding the source folder to the ASDF registry. Thoughts? I'll try it out then send a patch. Cheers! signature.asc Description: PGP signature
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
Hi Liliana, It's tempting to think that Guix packages are good candidates for "build scripts", but in the face of it, it may very well be that ASDF authors had something completely different in mind. In any case, asdf:compile-system seems to be underused to the point that barely anyone beside Guix packagers ever experience it. Cheers! signature.asc Description: PGP signature
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
Do you have time to try it out? signature.asc Description: PGP signature
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
While trying to package https://github.com/s-expressionists/Cleavir I hit a strange issue in which it would fail to compile, while calling `asdf:load-system' locally worked. Then I realized that our asdf-build-system/sbcl uses `asdf:compile-system' instead of `asdf:load-system'. From the ASDF doc: --8<---cut here---start->8--- This will make sure all the files in the system are compiled, but not necessarily load any of them in the current image; on most systems, it will _not_ load all compiled files in the current image. This function exists for symmetry with 'load-system' but is not recommended unless you are writing build scripts and know what you're doing. --8<---cut here---end--->8--- So should we really use it? By the way this _may_ be related to the issue we've got with loading the tests of some packages, like sbcl-jonathan: --8<---cut here---start->8--- ;; Tests fail with: Component JONATHAN-ASD::JONATHAN-TEST not found, ;; required by #. Why? --8<---cut here---end--->8--- Recipe to reproduce: - git clone https://github.com/s-expressionists/Cleavir - cd Cleavir - guix shell sbcl sbcl-acclimation sbcl-concrete-syntax-tree sbcl-closer-mop -- sbcl - (asdf:initialize-source-registry `(:source-registry (:tree ,(uiop:getcwd)) :inherit-configuration)) - (asdf:compile-system :cleavir-abstract-interpreter) --8<---cut here---start->8--- debugger invoked on a SB-PCL:CLASS-NOT-FOUND-ERROR in thread #: There is no class named CLEAVIR-ABSTRACT-INTERPRETER:STRATEGY. Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [TRY-RECOMPILING ] Recompile control and try loading it again 1: [RETRY] Retry loading FASL for #. 2: [ACCEPT ] Continue, treating loading FASL for # as having been successful. 3: Retry ASDF operation. 4: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 5: Retry ASDF operation. 6: Retry ASDF operation after resetting the configuration. 7: [ABORT] Exit debugger, returning to top level. --8<---cut here---end--->8--- And then - (asdf:load-system :cleavir-abstract-interpreter) works like a charm! Thoughts? Pierre signature.asc Description: PGP signature
bug#39101: asymptote build fails: Math formula deleted: Insufficient symbol fonts.
Thanks a lot! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#46424: Use load-systems or load-systems*
Interesting. This reminds me of a puzzling issue I recently had while working on the Nyxt .asd: - (asdf:load-asd "/path/to/nyxt.asd") - (asdf:make :nyxt/quicklisp) The nyxt/quicklisp system would call ql:update-dist and then would fail, saying it cannot find "nyxt/quicklisp" (which it is running!) because ql:update-dist would lead ASDF to somehow forget about the .asd. Adding (asdf:load-asd "/path/to/nyxt.asd") right after ql:update-dist fixes it. I've reworked the whole thing different on Nyxt's master branch, so this is no longer an issue. Maybe there is a hint lurking in there... -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#39101: asymptote build fails: Math formula deleted: Insufficient symbol fonts.
Hi Ricardo, Excellent investigation, and it turns out that it did the trick for Asymptote! Feel free to patch it. Thank you so much! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#33848: Store references in SBCL-compiled code are "invisible"
Hi Mark, thanks for the update and thanks for getting your hands dirty, this is a very valuable contribution to the core of Guix! Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#37955: warning: '.desktop' file refers to '', which cannot be found
Brendan Tildesley writes: > Do you mean delete the phase entirely or just from Racket? It's not always > the case that they are absolute paths. Racket probably just has some code to > generate them automatically. Good point! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#37955: warning: '.desktop' file refers to '', which cannot be found
So if the path is already an absolute store path, then I suppose that the whole phase is superfluous, isn't it? Couldn't we just delete it? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#37955: warning: '.desktop' file refers to '', which cannot be found
Thanks for the investigation. Would you like to send a patch? signature.asc Description: PGP signature
bug#33848: Store references in SBCL-compiled code are "invisible"
Hi Mark, hi Ludo,
> After applying the patch you sent, I confirm that Nyxt starts just fine
> when running:
>
> ./pre-inst-env guix environment --ad-hoc nyxt -CN -E ^DISPLAY
> --share=/tmp/.X11-unix -- nyxt
>
> … whereas on master it fails to start with:
>
> --8<---cut here---start->8---
> Unhandled SIMPLE-ERROR in thread # {10010D0103}>:
> Problem running initialization hook GLIB::RUN-INITIALIZERS:
> Unable to load any of the alternatives:
>
> ("/gnu/store/4vmhbc31cpbnlw3c96kcc094ihmaf7dv-glib-2.62.6/lib/libglib-2.0.so.0"
>
> "/gnu/store/4vmhbc31cpbnlw3c96kcc094ihmaf7dv-glib-2.62.6/lib/libglib-2.0.so")
> --8<---cut here---end--->8---
Fantastic, this looks like it's fixing this grafting issue indeed!
I also agree this looks like a net win even though the `guix gc` issue
is not fix.
The latter seems to be relatively easier to fix, doesn't it?
Cheers!
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#33848: Store references in SBCL-compiled code are "invisible"
Guillaume Le Vaillant writes: > Oh, you say this file would be created for every Lisp package. I thought > it would only be for the standalone binary case, because the "regular" > asdf-build-system/sbcl used for Lisp libraries ships the sources and its > make-asdf-configuration phase creates links to the required Lisp > dependencies in '/gnu/store/...', so there should not be missing > references. Right. The only case where there could be a missing reference is if the source code contains an FFI reference stored in non-ASCII / UTF-8. So we need to parse other encodings too as Mark suggested if I understand correctly. > I just wondered: does the grafting code take '.fasl' files into > consideration? > If yes, I guess a Lisp library could also end up in a strange > half-grafted state if the grafting code modifies ASCII references and > not UTF-32 ones... Absolutely, .fasls suffer from the same problem since they may encode strings as UTF-32. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#33848: Store references in SBCL-compiled code are "invisible"
I'm not familiar with the grafting code, so anyone who is (Mark? Ludo?) might be able to fix this much quicker than me! :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#33848: Store references in SBCL-compiled code are "invisible"
Hi Guillaume! > A store reference to a C library in a standalone Lisp binary can come > either from the current package or from some dependencies > (cl+ssl, cl-cffi-gtk, etc.). So we would need to scan the source > code of all the Lisp dependencies recursively to get the full list of > store refrences. I don't think there is need to scan recursively: if package A depends on B which depends on C, then A can lists the dependency on B in a file, and B can do the same for C. This way the relationship between A and C is properly stored. Am I missing something? > And as Mark wrote below, with the current grafting code, this list of > store references will not solve grafting for paths that are in UTF-32 or > both in ASCII and UTF-32 in the binary file. Indeed, and that's the core of the issue here I believe, since grafting is what breaks Nyxt in practice. Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#33848: Store references in SBCL-compiled code are "invisible"
Thank you for the reminder, Mark, I had forgotten about your suggestion. If we are going for a SBCL-specific solution, I believe that all references are stored in plain text files at some points (the .asd files and the .lisp files) which are often encoded in ASCII / UTF-8, so searching these files without having to deal with their encoding might be enough. But of course this is less general and more brittle. Mark, Guillaume, would you have time to give this a try? I'm a bit busy at the moment. Let me know if you can't work on it, I'll try to find time to work on a patch. Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#33848: Store references in SBCL-compiled code are "invisible"
Hi Ludo, > What could have been nice is if there’s a way to mark specific strings > as being ASCII, or if there’s a “byte vector” data type compatible with > strings, for instance. It does and it could work, but according to upstream it's just simpler to dump deps in a separate file. > 1. Some packages like ‘nyxt’ don’t use it, so we’d have to duplicate > the phase there. In the case of Nyxt, the reason it does not use it is because the asdf-build-system/sbcl binary production has some drawbacks. I could work on overhauling the build system to fix the uncanny behaviour, then Nyxt would use it. > 2. It may be coarse-grain compared to scanning binaries for references > (for example, we might retain references to build-only tools, such > as libraries used only for tests). The build system could easily leave out Lisp native-inputs, no? Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#47453: [Re] nyxt browser crashes when right click
Can you try installing it with `--no-grafts`? Can you report the shell output? Thanks! signature.asc Description: PGP signature
bug#47258: guix pull bug: the program '/gnu/store/...-compute-guix-derivation' failed to compute the derivation for Guix
Ludovic Courtès writes: > This is fixed in ef2b9322fae1d03bf639924d12214b0f58c11054 (it was > introduced hours before). Thanks! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#45302: Avahi substitute discovery keeps trying to ping unaccessible servers
Hi Mathieu, sorry, didn't have much time to play with Guix recently. All I can say is that I haven't experienced the issue lately. I'm on commit c03875b0361f114634caeb54935fe37a9b7b05af. I'll try the commands you suggested later. Thanks for your time! signature.asc Description: PGP signature
bug#45302: Avahi substitute discovery keeps trying to ping unaccessible servers
Hi Maxim! Thanks for the suggestion! I'm a bit ignorant here, but my guess is that yes, it would help! Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#45326: Include curl/wget (and git?) to the installation image
zimoun writes: > Does something as “guix git clone https://example.com --output=foo” make > sense? For me, yes! :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#45326: Include curl/wget (and git?) to the installation image
zimoun writes: > Somehow, it is already the case. :-) What do you need exactly? Because > this minimal thing could be exposed via “guix git ” via Guile-Git. > WDYT? `guix git' only has the `authenticate' action. Would be great if we could have `clone'! :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#45326: Include curl/wget (and git?) to the installation image
Apologies if this has been asked before, but would it be possible to include one of curl or wget in the installation image? It's particularly convenient to fetch authorization keys, channel specs and the like before installing a system. Additionally, including git (maybe git minimal?) would be great so synchronize Git repositories which may contain installation scripts, Guix configs and other dotfiles. Thoughts? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#45017: asdf-build-system packages have priority over user ones
Guillaume Le Vaillant writes: > SBCL and ECL are patched to use our cl-asdf because it is necessary to > build the sbcl-* and ecl-* packages. Also patching ABCL, CCL, and Clisp > sounds like a good idea. At least all the compilers would use the same > version of ASDF, and hopefully behave in the same way when looking for > configuration files. Yup, that'd be neat :) Related to this, I've noticed another issue with SBCL packages: when an SBCL package has a dependency that's updated in ~/common-lisp, (asdf:load-system ...) tries to recompile it in its folder, which fails since /gnu/store is read-only. Example: - Apply the above patch or edit ~/.config/common-lisp/source-registry.conf to make sure ~/common-lisp is loaded before system packages. - Install sbcl-cl-cookie. - Check out https://github.com/fukamachi/quri: git clone https://github.com/fukamachi/quri ~/common-lisp/quri - Now run --8<---cut here---start->8--- $ sbcl * (asdf:load-system :cl-cookie) WARNING: System definition file #P"/gnu/store/81cwmspx3366vdjs6v20rnd8a0xyr6in-sbcl-cl-fad-0.7.6/share/common-lisp/sbcl/cl-fad/cl-fad.asd" contains definition for system "cl-fad-test". Please only define "cl-fad" and secondary systems with a name starting with "cl-fad/" (e.g. "cl-fad/test") in that file. debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #: Error opening #P"/gnu/store/22q4ydm0pagi4irz0clssgkhkyh115j8-sbcl-cl-cookie-0.9.10-1.cea55ae/lib/common-lisp/sbcl/cl-cookie/src/cl-cookie-tmpGHU3ALSV.fasl": Read-only file system --8<---cut here---end--->8--- Not sure what to do about this. I'm guessing that Common Lisp development is not practical with Guix' SBCL packages and I should just stick to the CL packages. Thoughts? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
Hi Ludo! Ludovic Courtès writes: > As discussed earlier, I think you should use ‘-t machine’, which doesn’t > have the welcome message. ‘-t guile’ (the default) is meant for humans, > not for inter-process communication. Oh, for sure, I'm using `t machine` now. All I meant is that the aforementioned behaviour highlights a probable (harmless) bug, so if someone has got the time, they should look at what `guix repl` is doing with stdin, something is fishy. Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#45017: asdf-build-system packages have priority over user ones
Since staging was merged a few days ago, I've noticed an undesirable side-effect of our revamped asdf-build-system: the systems packages have priority over the user-local ones. Here is the default list of registries: --8<---cut here---start->8--- (defparameter* *default-source-registries* '(environment-source-registry user-source-registry user-source-registry-directory default-user-source-registry system-source-registry system-source-registry-directory default-system-source-registry) "List of default source registries" "3.1.0.102") --8<---cut here---end--->8--- `user-source-registry' points to what is read in ~/.config/common-lisp/source-registry.conf(.d/)?, so nothing by default. user-source-registry-directory reads what's in XDG_CONFIG_DIRS, and it finds the Guix packages there. The default-user-source-registry expands to --8<---cut here---start->8--- (:SOURCE-REGISTRY (:TREE (:HOME "common-lisp/")) (:DIRECTORY (:HOME ".sbcl/systems/")) (:DIRECTORY #P"/home/ambrevar/.local/share/common-lisp/systems/") (:TREE #P"/home/ambrevar/.local/share/common-lisp/source/") :INHERIT-CONFIGURATION) --8<---cut here---end--->8--- which is where I would drop my user-local packages. Finally, default-system-source-registry reads what's in XDG_DATA_DIRS, and it finds the packages there again, but it does not read the Guix-generated conf which collects the dependencies of each package. I believe the issue is that `user-source-registry-directory' should read from XDG_CONFIG_HOME, and not XDG_CONFIG_DIRS (which would make it redundant with `user-source-registry'). This would make it an upstream issue, but I wanted to double-check I properly understood the problem with the Guix community first. Guillaume, thoughts on this? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
Indeed, it works perfectly now, I've implemented your suggestions and Nyxt is now running a "guix repl server" to which it sends all the requests. It's awesome! :) The only issue remaining is the weird behaviour that one has to pass /dev/stdin to get rid of the welcome message: echo '(display "Hi.\n")' | guix repl /dev/stdin signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
Perfect, thanks for the feedback! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
If I understand correctly, "-t machine" is for when we want to retrieve the results of all top-level evaluations. If we only want specific results, then we are better off "passing" the desired value to the caller by dumping them to the standard output. For the latter, "-t machine" is not necessary I believe. Is this correct? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
Ludovic Courtès writes: > Hi, > > Bengt Richter skribis: > >> On +2020-11-13 10:41:38 +0100, Pierre Neidhardt wrote: >>> `guix repl` is a fantastic, hassle-free tool to bind Guix with >>> third-party languages. I've done it here: >>> >>> https://github.com/atlas-engineer/nyxt/blob/2-pre-release-4/libraries/ospama/ospama-guix.lisp > > I recommend using ‘guix repl -t machine’ Looks like `-t machine` has the same issue. This does what I want: --8<---cut here---start->8--- $ echo "(display \"Hi.\\n\")" | guix repl -t machine /dev/stdin Hi. --8<---cut here---end--->8--- This does not: --8<---cut here---start->8--- $ echo "(display \"Hi.\\n\")" | guix repl -t machine (repl-version 0 1 1) Hi. (values (non-self-quoting 2052 "#")) --8<---cut here---end--->8--- > and keeping the REPL process around instead of respawning it for every > expression. At first glance, we would want to do this indeed. But in the case of Nyxt, there would be no point when to terminate the process, so it would be around for the whole time Nyxt is running, which may not be desirable. Alternatively, I could simply keep it alive for a given duration (1 minute?) and automatically spawn it if the process is dead. Any recommendations? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
Tobias Geerinckx-Rice writes: > Here's that ungrafted derivation again: > > /gnu/store/2s6m5wkjksxi63wv1cz73x0kqj0az2l9-nyxt-2-pre-release-4.drv > > Can you confirm that we're building the same thing? We are not, it seems: --8<---cut here---start->8--- $ ./pre-inst-env guix build --no-grafts -d nyxt /gnu/store/bdi8dq8i3f59zxp7jrabas847dh80m7x-nyxt-2-pre-release-4.drv --8<---cut here---end--->8--- Commit 403ba4140f52b9ea9483e4c775f102bbb9753e51. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
Does building sbcl-dexador work for you? Maybe it's a parallel build issue. Can you reduce the number cores to 1 see if that helps? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
Tobias Geerinckx-Rice writes:
> Pierre,
>
> Pierre Neidhardt 写道：
>> and... it works! O.o
>
> Don't you hate it when that happens? Ban bug suicide.
>
> (Does that mean this one can be closed? Or retitled,
We can retitle it to remove the Guile banner indeed.
> if we want to debug Nyxt? :-)
Err... I'm confused, this is not about Nyxt :p
>> For future reference, it's also works in Common Lisp:
>>(uiop:run-program '("guix" "repl") :input s :output t
>>:error-output nil))
>
> Well, I stranded trying to import (or whatever the CL term is)
> UIOP itself, but my Common Lisp-fu is hella weak.
If you tried with SBCL, then you need to first require UIOP:
--8<---cut here---start->8---
(require :uiop)
(with-input-from-string (s "(display \"foo\\n\")")
(uiop:run-program '("guix" "repl") :input s :output :string :error-output
nil))
--8<---cut here---end--->8---
> This reminds me: do you want Nyxt to call ‘guix repl -q’ to skip
> loading ~/.guile to make your UI more predictable & debuggable?
> Or keep it as an escape hatch for cool hacks?
Oops, thanks for the reminder. Will do indeed, I don't think it's
needed in Nyxt. Or maybe make it optional. Well, if someone ever
complains about it...
Cheers!
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#44612: Read standard input in `guix repl'
Fantastic, this works! Thanks a lot, Guillaume! I'll update Nyxt then. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
Hi Chris! Christopher Baines writes: >> Any clue how to do that? > > I haven't been following along too closely, but I'm surprised guix repl > --type=machine hasn't been mentioned, is that relevant? Ha, didn't know about this one, I should have read the manual more closely! Sadly, it doesn't cut it: --8<---cut here---start->8--- > echo '(display "Hi.\n")' | guix repl -t machine 2>/dev/null (repl-version 0 1 1) Hi. (values (non-self-quoting 2052 "#")) --8<---cut here---end--->8--- -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
Tobias Geerinckx-Rice writes: > To ‘it does not work’ I can reply only that Nyxt doesn't build > [log attached] on current master Shoot! :p Which architecture? I builds for me on x86-64 at commit 403ba4140f52b9ea9483e4c775f102bbb9753e51. I've released Nyxt 2-pre-release-4 a few days ago and I've used it to build the Guix pack, so your feedback is surprising. Or is it a reproducibility issue? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44612: Read standard input in `guix repl'
Hey Tobias,
Always good to have someone actually test the stuff :)
Tobias Geerinckx-Rice writes:
> So far this looks like an (SB)CL(-specific) bug, right? Does it
> happen anywhere else? I tried Guile[0].
Maybe there was a misunderstanding, it's not about Common Lisp.
We can do easier than from Guile, i.e. from a shell:
--8<---cut here---start->8---
echo '(display "hello")' | guix repl
--8<---cut here---end--->8---
and... it works! O.o
OK, my bad then, I mistested somehow.
For future reference, it's also works in Common Lisp:
--8<---cut here---start->8---
> (with-input-from-string (s "(display \"foo\\n\")")
(uiop:run-program '("guix" "repl") :input s :output t :error-output
nil))
GNU Guile 3.0.4
Copyright (C) 1995-2020 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
foo
--8<---cut here---end--->8---
However this brings me to another issue: the program output is prefixed
with the REPL welcome message which is printed to stdout.
So ideally when we read from standard input we should not include the
welcome message.
Any clue how to do that?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#44612: Read standard input in `guix repl'
Tobias Geerinckx-Rice writes: > A magic ‘-’ alias is nice, providing ‘guix repl -- -’ still DTRT > (I know, who does that, but still). > > But why can't you just pipe your input into ‘guix repl’ now? It does not work now, I haven't looked at the details. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44552: Extra dynamic-space-size for asdf-build-system/sbcl?
OK, will do when I merge generic-cl! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44552: Extra dynamic-space-size for asdf-build-system/sbcl?
Guillaume Le Vaillant writes: > I guess we could increase the default max space size to 4 or 5 GB > without causing swapping issues on users' machines (at least on x86-64). > And users wanting a smaller one can use the "dynamic-space-size" option > at runtime. Fine with me, let's do it now on staging then? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44552: Extra dynamic-space-size for asdf-build-system/sbcl?
See https://github.com/alex-gutev/generic-cl/issues/6 The space size of our current SBCL package is 2Gb. Shall we increase it to 5Gb? What about adding an option to the build system to pass extra parameters to SBCL? Then we could pass "--dynamic-space-size=5000" just for generic-cl. Thoughts? Guillaume? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44548: Acknowledgement (SBCL build system fails to pacakge cl-environments, generic-cl.)
Good catch!
It also does the trick for generic-cl:
--8<---cut here---start->8---
(arguments
`(#:tests? #f
#:phases
(modify-phases %standard-phases
(add-after 'unpack 'fix-compile-order
(lambda _
(substitute* "generic-cl.asd"
((":module \"src\"") ":module \"src\" :serial t")))
---cut here---end--->8---
I don't understand why it works outside our build system.
It works when I run SBCL locally, so technically with the same ASDF.
I'll ask upstream, maybe they have a clue.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#44548: Acknowledgement (SBCL build system fails to pacakge cl-environments, generic-cl.)
Reported here: https://github.com/alex-gutev/generic-cl/issues/7 -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44548: Acknowledgement (SBCL build system fails to pacakge cl-environments, generic-cl.)
If I build manually it works:
--8<---cut here---start->8---
> sbcl --no-userinit
* (require :asdf)
("ASDF" "asdf" "UIOP" "uiop")
* (asdf:load-asd (truename
"/gnu/store/pr52bqxa2kf1n8jadhzw4rjsl3jjk6yl-sbcl-cl-environments-0.2.3-1.bbcd958/share/common-lisp/sbcl/cl-environments/cl-environments.asd"))
#
#
* (asdf:compile-system "cl-environments")
WARNING: System definition file
#P"/home/ambrevar/common-lisp/collectors/collectors.asd" contains definition
for system "collectors-test". Please only define "collectors" and secondary
systems with a name starting with "collectors/" (e.g. "collectors/test") in
that file.
WARNING: System definition file
#P"/gnu/store/n3sgz03ylnxprkbzj8f20zxvpldfxbcl-cl-symbol-munger-0.0.1-1.97598d4/share/common-lisp/source/cl-symbol-munger/symbol-munger.asd"
contains definition for system "symbol-munger-test". Please only define
"symbol-munger" and secondary systems with a name starting with
"symbol-munger/" (e.g. "symbol-munger/test") in that file.
T
--8<---cut here---end--->8---
The above builds against a local version of collectors, not sure that's
related though.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#44548: SBCL build system fails to pacakge cl-environments, generic-cl.
Hi!
I'm trying to package generic-cl on staging where the SBCL build system
has been revamped by Guillaume.
--8<---cut here---start->8---
(define-public sbcl-generic-cl
(package
(name "sbcl-generic-cl")
(version "0.7.1")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/alex-gutev/generic-cl;)
(commit (string-append "v" version
(file-name (git-file-name name version))
(sha256
(base32 "1jjg1d221a667wacbrh7abswrkzq6c9qwapdfh0frzl0la9xjz2f"
(build-system asdf-build-system/sbcl)
(inputs
`(("agutil" ,sbcl-agutil)
("alexandria" ,sbcl-alexandria)
("anaphora" ,sbcl-anaphora)
("arrows" ,sbcl-arrows)
("cl-custom-hash-table" ,sbcl-custom-hash-table)
("static-dispatch" ,sbcl-static-dispatch)
("trivia" ,sbcl-trivia)))
(native-inputs
`(("prove" ,sbcl-prove)))
(home-page "https://alex-gutev.github.io/generic-cl/;)
(synopsis "")
(description "")
(license license:expat)))
--8<---cut here---end--->8---
It fails with
--8<---cut here---start->8---
; wrote
/gnu/store/hkr132gc9ra2pnx16lbvl66pn86w11nx-sbcl-generic-cl-0.7.1/.cache/common-lisp/sbcl-2.0.10-linux-x64/gnu/store/d99q6jgx4xqw7fnk8vhb1xaqqc4h65fl-cl-environments-0.2.3-1.bbcd958/share/common-lisp/source/cl-environments/src/tools/types-tmp1CXFJSK9.fasl
; compilation finished in 0:00:00.012
Unhandled SB-INT:SIMPLE-FILE-ERROR in thread #:
Error opening
#P"/gnu/store/jzwgprixssmzm8yc76gh0ir1cw9myr4b-sbcl-static-dispatch-0.3-1.6243afc/lib/common-lisp/sbcl/static-dispatch/src/package-tmpX4BRKI0R.fasl":
Permission denied
--8<---cut here---end--->8---
My suspicion is that generic-cl depends on sbcl-static-dispatch, which
depends on cl-environments, which is a _source_ package and not an SBCL package.
Indeed, I fail to package sbcl-cl-environments:
--8<---cut here---start->8---
(define-public sbcl-cl-environments
(let ((commit "bbcd958a9ff23ce3e6ea5f8ee2edad9634819a3a")) ; No version in 2
years.
(package
(name "sbcl-cl-environments")
(version (git-version "0.2.3" "1" commit))
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/alex-gutev/cl-environments;)
(commit commit)))
(file-name (git-file-name name version))
(sha256
(base32
"1pfxl3vcdrb4mjy4q4c3c7q95kzv6rfjif3hzd5q91i9z621d64r"
(build-system asdf-build-system/sbcl)
(inputs
`(("alexandria" ,sbcl-alexandria)
("anaphora" ,sbcl-anaphora)
("collectors" ,sbcl-collectors)
("optima" ,sbcl-optima)))
(native-inputs
`(("prove" ,sbcl-prove)))
(home-page "https://github.com/alex-gutev/cl-environments;)
(synopsis "Implements the Common Lisp standard environment access API")
(description "This library provides a uniform API, as specified in Common
Lisp the Language 2, for accessing information about variable and function
bindings from implementation-defined lexical environment objects. All major
Common Lisp implementations are supported, even those which don't support the
CLTL2 environment access API.")
(license license:expat
--8<---cut here---end--->8---
It errors out with
--8<---cut here---start->8---
; file:
/gnu/store/xhgnh1yx8z999dx5qnxc0h3iwh1s836j-sbcl-cl-environments-0.2.3-1.bbcd958/share/common-lisp/sbcl/cl-environments/src/common/macro-util.lisp
; in: DEFMACRO! MATCH-STATE
; (CL-ENVIRONMENTS.UTIL:LET-IF ((CL-ENVIRONMENTS.UTIL::START
;(SECOND CL-ENVIRONMENTS.UTIL::STATES)
:START)
; (CL-ENVIRONMENTS.UTIL::BODY
;(CDDR CL-ENVIRONMENTS.UTIL::STATES)
;CL-ENVIRONMENTS.UTIL::STATES))
; (EQ (FIRST CL-ENVIRONMENTS.UTIL::STATES) :START)
; `(LABELS ((,CL-ENVIRONMENTS.UTIL::G!NEXT
; (,CL-ENVIRONMENTS.UTIL::FROM-STATE
; ,CL-ENVIRONMENTS.UTIL::G!FORCE
,CL-ENVIRONMENTS.UTIL::G!ARG)
; (OPTIMA:MULTIPLE-VALUE-MATCH #
; ,@#)))
; (,CL-ENVIRONMENTS.UTIL::G!NEXT ,CL-ENVIRONMENTS.UTIL::START NIL
; ,CL-ENVIRONMENTS.UTIL::ARG)))
;
; caught ERROR:
; during macroexpansion of
;
bug#44112: SBCL is not reproducible
zimoun writes: > In addition, GCC is also involved in the party. And I have also > replaced it by Clang with the same effect. Where? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#44112: SBCL is not reproducible
Guillaume Le Vaillant writes: > IIRC, SBCL itself is built in 2 stages. First its core is compiled > using another Common Lisp implementation (currently clisp in Guix), then > the complete SBCL is compiled using the core compiled in stage 1. Yes, this is correct. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#43815: emacs-pdf-tools often doesn't display text
zimoun writes: > How do you produce these private PDFs? I don't know, these are PDFs I receive over emails. I suspect they are generated by some *Office processor. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#43815: emacs-pdf-tools often doesn't display text
Hi! For a few weeks (since Emacs 27?) I've experienced an issue with emacs-pdf-tools: many PDFs don't display any text. If I convert the PDF to PDF with Ghostscript then it displays properly. For now I only have private PDFs to reproduce, I still need to found a public PDF. Has anyone else experienced this? Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#39562: python-keras build fails: test_selu: Not equal to tolerance rtol=1e-07, atol=0
Thanks! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#42773: sbcl-hu.dwim.common is missing a description
Oops! Thanks for letting me know, should be fixed with 9e7b2658d97493a5be01fb3d8c32762354c411dc. Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#42826: exception caught while executing 'start' on service 'file-system-/sys/kernel/debug'
On Guix commit 763b52dc54a5732d014ffaecba45125e9f38ed35
I get this error when reconfiguring my system:
--8<---cut here---start->8---
[...]
building
/gnu/store/wd1fj9n65xpdf22bzlswi6rk166miznh-install-bootloader.scm.drv...
guix system: bootloader successfully installed on '/dev/sdb'
The following derivation will be built:
/gnu/store/4b7pizn41jq8aayqban639c7xddby29w-upgrade-shepherd-services.scm.drv
building
/gnu/store/4b7pizn41jq8aayqban639c7xddby29w-upgrade-shepherd-services.scm.drv...
guix system: error: exception caught while executing 'start' on service
'file-system-/sys/kernel/debug':
Throw to key `match-error' with args `("match" "no matching pattern" ("none"
"/sys/kernel/debug" "debugfs" () #f #f #f))'.
--8<---cut here---end------->8---
The system reboots properly.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#42342: Wine64 segfaults (5.12/staging)
Now that wine stable is 5.12, I can't use start 32-bit applications
anymore. I tried from a clean wine prefix and I only get this error:
--8<---cut here---start->8---
Segmentation fault
--8<---cut here---end--->8---
Here is the end of the strace:
--8<---cut here---start->8---
openat(AT_FDCWD,
"/gnu/store/fhxjkwnv9w8a283f5qaiqq8hcmfmdap9-wine64-5.12/bin/../lib/wine32/wine/ntdll.dll.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/gnu/store/ajyl64ycr9vv51q2np68agwz2ad9lxqs-wine-5.12/lib/wine32/wine/ntdll.dll.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\360\302{4\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=941360, ...}) = 0
mmap2(0x7bc0, 864996, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7bc0
mmap2(0x7bc1e000, 487424, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e000) = 0x7bc1e000
mmap2(0x7bc95000, 200704, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x95000) = 0x7bc95000
mmap2(0x7bcc6000, 49152, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc5000) = 0x7bcc6000
mmap2(0x7bcd2000, 4836, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7bcd2000
close(3)= 0
openat(AT_FDCWD,
"/gnu/store/ajyl64ycr9vv51q2np68agwz2ad9lxqs-wine-5.12/lib/wine32/libm.so.6",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/gnu/store/z4li262il798hbl0l1h1k3a5g7r6bffa-glibc-2.31/lib/libm.so.6",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\241\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=1109456, ...}) = 0
mmap2(NULL, 1048680, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7eeff000
mmap2(0x7ef09000, 774144, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7ef09000
mmap2(0x7efc6000, 229376, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0xc7000) = 0x7efc6000
mmap2(0x7effe000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xfe000) = 0x7effe000
close(3)= 0
mprotect(0x7effe000, 4096, PROT_READ) = 0
mprotect(0x7bc0, 122880, PROT_READ|PROT_WRITE) = 0
mprotect(0x7bc1e000, 487424, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x7bc95000, 200704, PROT_READ|PROT_WRITE) = 0
mprotect(0x7bc95000, 200704, PROT_READ) = 0
mprotect(0x7bc1e000, 487424, PROT_READ|PROT_EXEC) = 0
mprotect(0x7bc0, 122880, PROT_READ) = 0
mprotect(0x7bcc6000, 4096, PROT_READ) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x30} ---
+++ killed by SIGSEGV +++
Segmentation fault
--8<---cut here---end------->8---
Are 32-bit applications really working for some of you?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#42730: Replace our lzlib bindings with guile-lzlib
Now that there is a guile-lzlib package, I suggest we replace (guix lzlib) with it. I haven't checked if it supersedes (guix lzlib). -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#42342: Wine64 segfaults (5.12/staging)
Cc-ing to Tobias and Jakub. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#42247: Channel news raise error on `guix pull`
I've added a news-file entry to my channel: --8<---cut here---start->8--- (channel (version 0) (news-file "news.scm")) --8<---cut here---end--->8--- which contains --8<---cut here---start->8--- (channel-news (version 0) (entry (commit "25387230a7f99c2b0886488ed061747c9e00434a") (title (en "Hello")) (body (en "World!" --8<---cut here---end--->8--- Reading the news file from the REPL works. --8<---cut here---start->8--- (with-input-from-file "/home/ambrevar/projects/foo/news.scm" (lambda () (read-channel-news (current-input-port --8<---cut here---end--->8--- However, guix pull chokes on it: --8<---cut here---start->8--- (repl-version 0 0) (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (channel-news)) (value #f)) --8<---cut here---end--->8--- I first encountered this issue in Feb 2020, but this issue might have been around since channel news were introduced. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#41651: nm-applet fails: Settings schema 'org.gnome.nm-applet' is not installed
It works indeed, thanks. We need to fix nm-applet. signature.asc Description: PGP signature
bug#41390: Hunspell packages don't work in Libreoffice
Installing hunspell-dict-fr has no effect on Libreoffice which does not offer spell checking beyond English. For now the only way to add extra dictionaries is to fetch them manually online. Besides, we miss many hunspell dictionaries. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#35728: Tor & IceCat's TorButton shows it's connected but doesn't route the traffic
I can confirm this issue and I've been experiencing it for almost a year. It used to work. This is very embarrassing since our IceCat is misleading the users that they are browsing anonymously while they are not. Mark, any idea about this? -- Pierre Neidhardt https://ambrevar.xyz/
bug#41282: doc: dot graphs display square glyphs instead of letters
The Guix manual from commit 7bba5425473b5d193946e537de77c631ae6c3667. I can reproduce the issue with --8<---cut here---start->8--- env INFOPATH=$HOME/.config/guix/current/share/info emacs --8<---cut here---end--->8--- The dot figures are generated during the Guix build I guess. Something odd is happening. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#41282: doc: dot graphs display square glyphs instead of letters
Recipe in Emacs: - C-h i - m Guix RET - i bootstrap RET - m Reduced Binary Seed Bootstrap > Do you have any fonts installed? I have font-dejavu, that's it. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#41282: doc: dot graphs display square glyphs instead of letters
See for instance "12.1 The Reduced Binary Seed Bootstrap". Commit 7bba5425473b5d193946e537de77c631ae6c3667. signature.asc Description: PGP signature
bug#41025: blueman does not start
I've pushed your latest patch here: c5a9b16dbdc8849560fb43095e090ba0952277b6. The only change I've done beside indentation is patching the scripts in libexec/. Thanks for your patience! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#41025: blueman does not start
Sorry to disappoint :p Sadly this patch does not work yet ;)
- You've hardcoded the python version (3.7) while you should get it
dynamically from the one you are using.
You can try using something like
--8<---cut here---start->8---
,(version-major+minor (package-version python))
--8<---cut here---end--->8---
- You've hardcoded paths to ~/.guix-profile which should be avoided
because profiles can be anywhere.
--8<---cut here---start->8---
+ (substitute*
+ '("apps/blueman-mechanism.in" "blueman/Functions.py")
+ (("/usr/bin:/bin:/usr/sbin:/sbin")
+(string-append
+ "~/.guix-profile/bin:"
+ "/run/current-system/profile/bin:"
+ "~/.guix-profile/sbin:"
+ "/run/current-system/profile/sbin"))
+ ((":/sbin:/usr/sbin")
+(string-append
+ ":/run/current-system/profile/sbin:"
+ "~/.guix-profile/sbin")))
--8<---cut here---end--->8---
I think this should be replace by the Python equivalent of `(getenv "PATH")`.
- In the following comment, the ';' should be a colon. "patching"
should probably be something like "we patch".
--8<---cut here---start->8---
+ ;; Python references are not being patched in patch-phase of build;
+ ;; despite using python-wrapper as input. So patching them manually.
--8<---cut here---end--->8---
Stay put, almost there! :)
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#41160: sbcl-cffi-libffi: Fails to build on ARM
Log attached. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature 0073bx3mc98019xd8q2yv2lpji460k-sbcl-cffi-libffi-0.21.0.drv.bz2 Description: Binary data
bug#39894: [Common Lisp] asdf-build-system/source should refer to dependencies in the store
I made a mistaken in the original post: the cl-* (source) packages do propagate their input. So source packages _do_ work as expected. What we'd like to do improve here is _not_ propagate the inputs and instead refer directly to them in the store. I tried generating and .asd which would do the following --8<---cut here---start->8--- (asdf:load-asd ORIGINAL-ASD) (push INPUT-PATH-TO-SOURCE asdf:*central-registry*) ; more push of all inputs here. --8<---cut here---end--->8--- The problem is that we can't name the .asd like the original or ASDF will complain about circular dependencies. The only way I can think about is to add the "push" lines to the original .asd itself (at the end should be fine). Not sure how I feel about modifying the original .asd, seems brittle. There may be a better way. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#41025: blueman does not start
t network-manager bindings for python are missing.
We may need to package this: https://github.com/seveas/python-networkmanager
Maybe I'm not starting it the right way.
Have you got blueman to work on your system? Are you using a foreign
distribution?
New package definition:
--8<---cut here---start->8---
(define-public blueman
(package
(name "blueman")
(version "2.1.2")
(source
(origin
(method url-fetch)
(uri
(string-append "https://github.com/blueman-project/blueman/releases/;
"download/2.1.2/blueman-2.1.2.tar.gz"))
(sha256
(base32 "0wamxdw36c8i3aqwmja5q70fajqwd7inpkvlpkldd54wdxbcd38d"
(build-system glib-or-gtk-build-system)
(arguments
`(#:configure-flags
(list
"--enable-polkit"
"--disable-appindicator" ; Deprecated
"--with-systemdsystemunitdir=no" ; Not required
"--with-systemduserunitdir=no") ; Not required
#:phases
(modify-phases %standard-phases
;; Python references are not being patched in patch-phase of build;
;; despite using python-wrapper as input. So patching them manually.
(add-after 'unpack 'patch-python-references
(lambda* (#:key inputs #:allow-other-keys)
(for-each
(lambda (name)
(substitute* (format #f "apps/blueman-~a.in" name)
(("@PYTHON@") (string-append (assoc-ref inputs "python")
"/bin/python3.7"
'("adapters" "applet" "assistant" "manager" "mechanism" "report"
"rfcomm-watcher" "sendto" "services" "tray"))
#t))
(add-after 'glib-or-gtk-wrap 'wrap-blueman
(lambda* (#:key outputs #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
(bin (string-append out "/bin/blueman-"))
(lib (string-append out "/lib/python3.7/site-packages/")))
(for-each
(lambda (program)
(pk program)
(pk (string-append bin program))
(wrap-program (string-append bin program)
`("PYTHONPATH" = (,(getenv "PYTHONPATH")
,lib))
`("GI_TYPELIB_PATH" = (,(getenv "GI_TYPELIB_PATH")
'("adapters" "applet" "assistant" "manager" "report"
"sendto" "services" "tray"))
#t))
(native-inputs
`(("cython" ,python-cython)
("glib:bin" ,glib "bin")
("gtk+:bin" ,gtk+ "bin")
("intltool" ,intltool)
("libtool" ,libtool)
("pkg-config" ,pkg-config)))
(inputs
`(("adwaita-icon-theme" ,adwaita-icon-theme)
("bluez" ,bluez)
("dbus" ,dbus)
("gdkpixbuf" ,gdk-pixbuf)
("glib" ,glib)
("gtk+" ,gtk+)
("iproute2" ,iproute)
("net-tools" ,net-tools)
("pango" ,pango)
("polkit" ,polkit)
("pulseaudio" ,pulseaudio)
("pycairo" ,python-pycairo)
("pygobject" ,python-pygobject)
("python" ,python-wrapper)
("libnm" ,libnma)))
(synopsis "GTK+ Bluetooth manager")
(description "Blueman is a Bluetooth management utility using the Bluez
D-Bus backend. It is designed to be easy to use for most common Bluetooth
tasks.")
(home-page "https://github.com/blueman-project/blueman;)
(license license:gpl3+)))
--8<---cut here---end--->8---
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#37831: GDM has a GNOME entry even when not installed
Thanks! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#32930: Broken ASDF tests?
Fixed in 92da05885c780fb92694f0d84ceda093b1b67db8. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#39324: GNOME Weather doesn't start
The error is --8<---cut here---start->8--- > gapplication launch org.gnome.Weather error sending Activate message to application: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Weather exited with status 1 --8<---cut here---end--->8--- strace attached. I've reported the issue upstream: https://gitlab.gnome.org/GNOME/gnome-weather/-/issues/97 I've pushed a workaround in ea529c75d1e527ab76bf865d765bb529fcc2bb7d. Also note that gnome-weather fails outside of GNOME (in my case with EXWM) with --8<---cut here---start->8--- > gnome-weather Unsatisfied dependency: GWeather --8<---cut here---end--->8--- -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature gnome-weather.strace Description: Binary data
bug#34275: clementine-1.3.1 fails test
For me on Guix ce226e9d8d52d2530f057f2000d36c0d55380ade it fails with --8<---cut here---start->8--- [ 97%] Linking CXX executable asxiniparser_test cd /tmp/guix-build-clementine-1.3.1-2.4619a4c.drv-0/build/tests && /gnu/store/iz9500ssxcqlyr74hg1jq10ycrh42yq1-cmake-minimal-3.15.1/bin/cmake -E cmake_link_script CMakeFiles/asxiniparser_test.dir/link.txt --verbose=1 /gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/bin/c++ -std=c++0x -fpermissive -Wno-c++11-narrowing -U__STRICT_ANSI__ -O2 -g -DNDEBUG -rdynamic CMakeFiles/asxiniparser_test.dir/asxiniparser_test.cpp.o -o asxiniparser_test libgmock.a libgtest.a ../src/libclementine_lib.a libtest_utils.a /gnu/store/n6ji2fxg1cn6abd2bn2jd14pglyblysr-qtbase-5.12.7/lib/libQt5Test.so.5.12.7 libtest_main.a libgmock.a libgtest.a ../src/libclementine_lib.a ../ext/libclementine-spotifyblob/libclementine-spotifyblob-messages.a ../ext/libclementine-tagreader/liblibclementine-tagreader.a ../ext/libclementine-remote/liblibclementine-remote.a ../ext/libclementine-common/liblibclementine-common.a -lprotobuf -lssl -lcrypto -ltag -lmygpo-qt5 -lQt5Network -lQt5Core -lchromaprint ../3rdparty/qtsingleapplication/libqtsingleapplication.a ../3rdparty/qtiocompressor/libqtiocompressor.a -lgio-2.0 -lgstapp-1.0 -lgsttag-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lz -lgio-2.0 -lgstapp-1.0 -lgsttag-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lz -lpthread ../3rdparty/qocoa/libQocoa.a /gnu/store/n6ji2fxg1cn6abd2bn2jd14pglyblysr-qtbase-5.12.7/lib/libQt5OpenGL.so.5.12.7 /gnu/store/n6ji2fxg1cn6abd2bn2jd14pglyblysr-qtbase-5.12.7/lib/libQt5Network.so.5.12.7 /gnu/store/n6ji2fxg1cn6abd2bn2jd14pglyblysr-qtbase-5.12.7/lib/libQt5Xml.so.5.12.7 /gnu/store/n6ji2fxg1cn6abd2bn2jd14pglyblysr-qtbase-5.12.7/lib/libQt5Concurrent.so.5.12.7 /gnu/store/n6ji2fxg1cn6abd2bn2jd14pglyblysr-qtbase-5.12.7/lib/libQt5DBus.so.5.12.7 -lcdio -lm ../gst/moodbar/libgstmoodbar.a -lgobject-2.0 -lglib-2.0 -lgstbase-1.0 -lgstreamer-1.0 -lgstaudio-1.0 -lgobject-2.0 -lglib-2.0 -lgstbase-1.0 -lgstreamer-1.0 -lgstaudio-1.0 -lfftw3 -lmtp -lpulse ../3rdparty/qxt/libqxt.a /gnu/store/n6ji2fxg1cn6abd2bn2jd14pglyblysr-qtbase-5.12.7/lib/libQt5Widgets.so.5.12.7 /gnu/store/h57fym6c3fpjlnvpb0gq444v00dins5v-qtx11extras-5.12.7/lib/libQt5X11Extras.so.5.12.7 /gnu/store/n6ji2fxg1cn6abd2bn2jd14pglyblysr-qtbase-5.12.7/lib/libQt5Gui.so.5.12.7 ../3rdparty/qsqlite/libqsqlite.a /gnu/store/n6ji2fxg1cn6abd2bn2jd14pglyblysr-qtbase-5.12.7/lib/libQt5Sql.so.5.12.7 /gnu/store/n6ji2fxg1cn6abd2bn2jd14pglyblysr-qtbase-5.12.7/lib/libQt5Core.so.5.12.7 -lsqlite3 -lX11 -ldl collect2: error: ld returned 1 exit status make[3]: *** [tests/CMakeFiles/asxiniparser_test.dir/build.make:120: tests/asxiniparser_test] Error 1 make[3]: Leaving directory '/tmp/guix-build-clementine-1.3.1-2.4619a4c.drv-0/build' make[2]: *** [CMakeFiles/Makefile2:1325: tests/CMakeFiles/asxiniparser_test.dir/all] Error 2 make[2]: Leaving directory '/tmp/guix-build-clementine-1.3.1-2.4619a4c.drv-0/build' make[1]: *** [CMakeFiles/Makefile2:846: tests/CMakeFiles/clementine_test.dir/rule] Error 2 make[1]: Leaving directory '/tmp/guix-build-clementine-1.3.1-2.4619a4c.drv-0/build' make: *** [Makefile:388: clementine_test] Error 2 Test suite failed, dumping logs. command "make" "clementine_test" failed with status 2 --8<---cut here-------end--->8--- -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#30435: libreoffice: Fonts don't show up after install
I can reproduce this on guix ce226e9d8d52d2530f057f2000d36c0d55380ade. But libreoffice is not the only victim: it seems that most applications fail to see the fonts installed in the user profile (on Guix System). Emacs is one example. Running --8<---cut here---start->8--- fc-cache -fv --8<---cut here---end--->8--- fixes the issue. Should we run this command in a profile hook? -- Pierre Neidhardt https://ambrevar.xyz/
bug#39117: GNOME Files: No file thumbnails
I can reproduce. Note that I've managed to get _some_ thumbnails when I first logged in. Now the thumbnail generation seems to be completely gone. Any clue what's happening, anyone? Has this ever worked before? -- Pierre Neidhardt https://ambrevar.xyz/
bug#39324: GNOME Weather doesn't start
I can reproduce. Note that from GNOME, running "gnome-weather" in a shell works. However the icon does not work either. I noticed that the desktop file executes --8<---cut here---start->8--- gapplication launch org.gnome.Weather --8<---cut here---end--->8--- Does any one know how this is supposed to work? If not, as a workaround I suggest we replace this line with "gnome-weather". -- Pierre Neidhardt https://ambrevar.xyz/
bug#40368: Docker server version is "dev" (should be a version number)
Hi, --8<---cut here---start->8--- > docker info Client: Debug Mode: false Server: Containers: 7 Running: 3 Paused: 0 Stopped: 4 Images: 5 Server Version: dev [...] --8<---cut here---end--->8--- See the last line. This triggers issues with programs that expect a version number here. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#40234: [java-iroha] Gradle fails with "Could not find tools.jar"
By the way, should JAVA_HOME be a native-search-path set by the JDKs? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#40234: [java-iroha] Gradle fails with "Could not find tools.jar"
Hi! I'm trying to build https://github.com/hyperledger/iroha-java manually with Gradle (tried with Guix but I'm stuck), and I get the following error: --8<---cut here---start->8--- Execution failed for task ':client:compileJava'. Could not find tools.jar. --8<---cut here---end--->8--- Then it suggests that the Java installation might be wrong. I tried with icedtea 3.7.0, openjdk 9 and openjdk 12, to no avail. Are our JDK packages wrong missing some jars? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#40062: nscd: Domain name resolution errors when travelling
When I move with my Guix laptop, I frequently get domain name resolution errors. To fix the issue, I need to run --8<---cut here---start->8--- # herd invalidate nscd hosts # herd restart nscd --8<---cut here---end--->8--- The issue is fixed as long as I don't move again. This is impractical and the solution is very much non-obvious :p -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#39894: [Common Lisp] asdf-build-system/source should refer to dependencies in the store
The sbcl build system generates a new .asd that refers to all the required input explicitly in the store. The asdf-build-system/source does not do that. Because of this, installing the source packages in a profile does not work as expected: loading the source in a Common Lisp REPL will fail, complaining about missing dependencies. I suggest we use an .asd generation similar to that of the SBCL build system. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#33844: Rename ghc-pandoc to pandoc
swedebu...@riseup.net writes: > Reason: it is used standalone to convert between formats. I agree. What do other people think? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#39318: [core-updates] 'make-desktop-entry-file' is not exported
My bad I guess :p Should I just export it? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#39079: SBCL CFFI from Guix unable to find dynamic libraries
Evan Straw writes: > This library depends on > the following other libraries, as reported by `ldd > /usr/lib/x86_64-linux-gnu/libcurl.so.4`: > > --8<---cut here---start->8--- > linux-vdso.so.1 (0x7ffd5f393000) > libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 > (0x7f941aae8000) > libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x7f941aac8000) ... > --8<---cut here---end--->8--- Which "ldd" did you use? Ubuntu's or Guix'? Where did you run it? My only guess is what Konrad said: the libcurl library references its dependencies with relative path (which ldd does _not_ display) and the Guix loaded knows nothing about /usr/lib/x86_64-linux-gnu. Try exporting LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu in the environment in which you run SBCL. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#38148: [PATCH 1/2] gnu: Add python-pyqtwebengine.
Mike Rosset writes:
>> Please apply the above pyqt change to a separate commit.
>
> I missed this comment with my new series. If this really needs to be
> done, I'll have to redo all of the commits and resend the series. Can
> this be avoided if possible?
Yes, this is really necessary, commits must be atomic or else the log
gets easily tangled.
This is not hard to do though:
- rebase-edit the offending commit ("r m" with magit), this will leave
git in a detached state.
- Soft-reset HEAD~.
- Commit the first changes to a new commit.
- Commit the rest.
Let me know if you need more help.
>> Use version-major+minor from (guix utils) instead?
>
>
> This is not an easy fix, I actually snarfed this from python-pyqt.
No problem, it's OK to leave it.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#39079: SBCL CFFI from Guix unable to find dynamic libraries
Konrad Hinsen writes: > Note that this is a feature, not a bug, so if that's the cause of the > problem, there is nothing to do about it. You'd have to compile sbcl > with the toolchain of the foreign distro. You don't have to use another SBCL. If you look at how we package cffi-based libraries (e.g. sbcl-cl-sqlite), you'll see that we set the path to the .so manually to the store location. This should not raise any issue. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#39079: SBCL CFFI from Guix unable to find dynamic libraries
Hi! Evan Straw writes: > However, the thing that still doesn't appear to be working right is loading > libraries from the foreign distro. I get the same behavior as before when > attempting to load a library under the foreign distro's library directory > (/usr/lib/x86_64-linux-gnu): It loads the library itself but fails upon trying > to load any dependencies, even if they are in the same directory. What are "dependencies" here? Can you provide a full recipe of what you are trying to do, including your .sbclrc and the Lisp code snippets you've run to test this? > Ideally, I would just install the libraries I need from Guix, but I > specifically want to interface with a library from the system, in this > case PulseAudio (I've just been using libcurl as a test to make sure > it works). Does it work for the libraries installed with Guix? > I did some investigation and tried both installing just CFFI from another > source, and then SBCL itself. Installing CFFI from Quicklisp but keeping SBCL > from Guix gave the same behavior and was unable to load dependencies of the > library. Installing SBCL from APT and CFFI from Quicklisp was able to load the > library and all dependencies with no issues. From this, I'm wondering if it's > a > problem with SBCL itself instead of CFFI? This seems to be a red herring, as Guix does not change how CFFI loads libraries. The only thing that changes is where the libraries are found with Guix packages. Let's see what we can reproduce with your examples! :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#38148: [PATCH 2/2] gnu: qutebrowser: Update to 1.9.0.
Mike Rosset writes:
> * gnu/packages/web-browsers.scm (qutebrowser): Update to 1.9.0.
>
> qutebrowser no longer uses qtwebkit by default. It now defaults to
> qtwebengine.
> ---
> gnu/packages/web-browsers.scm | 40 ---
> 1 file changed, 28 insertions(+), 12 deletions(-)
>
> diff --git a/gnu/packages/web-browsers.scm b/gnu/packages/web-browsers.scm
> index 137dccab81..035fdc1dd9 100644
> --- a/gnu/packages/web-browsers.scm
> +++ b/gnu/packages/web-browsers.scm
> @@ -276,7 +276,7 @@ access.")
> (define-public qutebrowser
>(package
> (name "qutebrowser")
> -(version "1.8.3")
> +(version "1.9.0")
> (source
> (origin
> (method url-fetch)
> @@ -285,11 +285,10 @@ access.")
> "qutebrowser-" version ".tar.gz"))
> (sha256
> (base32
> - "055zmzk3q0m3hx1742nfy2mdawfllrkvijnbzp1hiv01dj1bxaf8"
> + "1y0yq1qfr6g1s7kf3w2crd0b025dv2dfknhlz3v0001ns3rgwj17"
> (build-system python-build-system)
> (native-inputs
> - `(("asciidoc" ,asciidoc)
> - ("python-attrs" ,python-attrs))) ; for tests
> + `(("python-attrs" ,python-attrs))) ; for tests
> (inputs
> `(("python-colorama" ,python-colorama)
> ("python-cssutils" ,python-cssutils)
> @@ -298,23 +297,30 @@ access.")
> ("python-pygments" ,python-pygments)
> ("python-pypeg2" ,python-pypeg2)
> ("python-pyyaml" ,python-pyyaml)
> + ;; FIXME: python-pyqtwebengine needs to come before python-pyqt so
> + ;; that it's __init__.py is used first.
> + ("python-pyqtwebengine" ,python-pyqtwebengine)
> ("python-pyqt" ,python-pyqt)
> - ("qtwebkit" ,qtwebkit)))
> + ;; qtwebengine is not a direct input because it's already provided by
> + ;; python-pyqtwebengine. It's included so we can wrap
> + ;; QTWEBENGINEPROCESS_PATH
The phrasing is a bit confusing. I'd say
"While qtwebengine is already provided by python-pyqtwebengine, it's
included here so we can wrap QTWEBENGINEPROCESS_PATH."
> + ("qtwebengine" ,qtwebengine)))
> (arguments
> - `(;; FIXME: Tests have been added to Qutebrowser. But they currently
> fail on
> - ;; trying to locate QtWebEngine, and run it on a specific display.
> - ;; There does not seem to be a trivial way to suppress this test.
> - ;; Either fix this, or wait for a liberated QtWebEngine to make into
> GNU Guix.
> - ;; Change this according to <https://bugs.gnu.org/35866>.
> + `( ;; FIXME: With the existance of qtwebengine, tests can now run. But
> + ;; they are still disabled because test phase hangs. It's not readily
> + ;; apparent as to why
Missing period.
> #:tests? #f
> #:phases
> (modify-phases %standard-phases
> + (add-before 'check 'set-env-offscreen
> + (lambda _
> + (setenv "QT_QPA_PLATFORM" "offscreen")
> + #t))
> (add-after 'install 'install-more
> (lambda* (#:key outputs #:allow-other-keys)
> (let* ((out (assoc-ref outputs "out"))
> (app (string-append out "/share/applications"))
> (hicolor (string-append out "/share/icons/hicolor")))
> - (invoke "a2x" "-f" "manpage" "doc/qutebrowser.1.asciidoc")
Why are you removing this?
Other than those few nits, looks good to me!
Cheers!
--
Pierre Neidhardt
https://ambrevar.xyz/
bug#38148: [PATCH 1/2] gnu: Add python-pyqtwebengine.
Thanks for the patches, comments below:
Mike Rosset writes:
> * gnu/packages/qt.scm (python-pyqtwebengine): New variable.
> ---
> gnu/packages/qt.scm | 97 +
> 1 file changed, 97 insertions(+)
>
> diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
> index 514577678e..fcb297e99c 100644
> --- a/gnu/packages/qt.scm
> +++ b/gnu/packages/qt.scm
> @@ -38,6 +38,7 @@
>#:use-module (guix build-system cmake)
>#:use-module (guix build-system gnu)
>#:use-module (guix build-system trivial)
> + #:use-module (guix build-system python)
>#:use-module (guix packages)
>#:use-module (guix deprecation)
>#:use-module (guix utils)
> @@ -1947,6 +1948,17 @@ module provides support functions to the automatically
> generated code.")
>,@%gnu-build-system-modules)
> #:phases
> (modify-phases %standard-phases
> + ;; When building python-pyqtwebengine can not be
Comma after python-pyqtwebengine helps with readability.
> + ;; included. Here we substitute the full path to the header in the
Double-space after period.
> + ;; store.
> + (add-before 'configure 'substitute-source
> + (lambda* (#:key inputs #:allow-other-keys)
> + (let* ((qtbase (assoc-ref inputs "qtbase"))
> +(qtprinter.h (string-append "\"" qtbase
> "/include/qt5/QtPrintSupport/qprinter.h\"")))
> + (substitute* "sip/QtPrintSupport/qprinter.sip"
> + (("")
> + qtprinter.h))
> + #t)))
> (replace 'configure
> (lambda* (#:key inputs outputs #:allow-other-keys)
> (let* ((out (assoc-ref outputs "out"))
> @@ -1986,6 +1998,91 @@ framework. The bindings are implemented as a set of
> Python modules and
> contain over 620 classes.")
> (license license:gpl3)))
Please apply the above pyqt change to a separate commit.
> +(define-public python-pyqtwebengine
> + (package
> +(name "python-pyqtwebengine")
> +(version "5.12.1")
> +(source
> + (origin
> + (method url-fetch)
> + (uri (string-append
> +
> "https://www.riverbankcomputing.com/static/Downloads/PyQtWebEngine/;
> +version "/PyQtWebEngine_gpl-" version ".tar.gz"))
> + (sha256
> +(base32
> + "0wylkd7fh2g27y3710rpxmj9wx0wpi3z7qbv6khiddm15rkh81w6"
> +(build-system gnu-build-system)
> +(native-inputs
> + `(("python" ,python)
> + ("python-sip" ,python-sip)
> + ;; qtbase is required for qmake
> + ("qtbase" ,qtbase)))
> +(inputs
> + `(("python" ,python-wrapper)
> + ("python-sip" ,python-sip)
> + ("python-pyqt" ,python-pyqt)
> + ("qtbase" ,qtbase)
> + ("qtsvg" ,qtsvg)
> + ("qtdeclarative" ,qtdeclarative)
> + ("qtwebchannel" ,qtwebchannel)
> + ("qtwebengine" ,qtwebengine)
> + ("python-pyqt" ,python-pyqt)
> + ("qtwebengine" ,qtwebengine)))
qbwebengine duplicate.
> +(arguments
> + `(#:modules ((srfi srfi-1)
> + ,@%gnu-build-system-modules)
> + #:phases
> + (modify-phases %standard-phases
> + (replace 'configure
> + (lambda* (#:key inputs outputs #:allow-other-keys)
> + (let* ((out (assoc-ref outputs "out"))
> +(sipdir (string-append out "/share/sip"))
> +(pyqt-sipdir (string-append
> + (assoc-ref inputs "python-pyqt")
> "/share/sip"))
> +(python (assoc-ref inputs "python"))
> +(python-version
> + (last (string-split python #\-)))
> +(python-major+minor
> + (string-join
> + (take (string-split python-version #\.) 2)
> + "."))
Use version-major+minor from (guix utils) instead?
> +(lib (string-append out "/lib/python"
> +python-major+minor
> +"/site-packages/PyQt5"))
> +(stubs (string-append lib "/PyQt5")))
> +
> + (system* "mkdir" "-p" sipdir)
(mkdir-p sipdir)
> + (invoke "python" "configure.py"
> + "-w"
> + "--no-dist-info"
> + "--destdir" lib
> + "--no-qsci-api"
> + "--stubsdir" stubs
> + "--sipdir" sipdir
> + "--pyqt-sipdir" pyqt-sipdir
> + ;; Because this has a different prefix then python-pyqt then we need
"then python-pyqt" -> "than python-pyqt".
> + ;; to make this a namespace of it's own
Missing period.
--
Pierre Neidhardt
https://ambrevar.xyz/
