bug#61132: xfce 4.18 issues: gsettings, icons missing, and logout need long time
> [...] > > Hello Feng Shu and Michael Rohleder, I have create a wip-xfce branch and > applied all patches: They're all LGTM, and I will merge it after some > tests later. Thank you! > Pushed! During my tests, I find some issues though: 1. in xfce4-appearance-settings, switch the theme to greybird-dark will kill it, with output: ``` (xfce4-appearance-settings:13788): Gtk-WARNING **: 10:53:21.078: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg. This may indicate that pixbuf loaders or the mime database could not be found. (xfce4-appearance-settings:13788): GLib-GIO-ERROR **: 10:53:23.264: Settings schema 'org.gnome.desktop.interface' does not contain a key named 'color-scheme' ``` I think this is due to our gsettings-desktop-schemas is old. 2. some icons are missing, and by default there is no pixbuf loader for svg. With a manually set GDK_PIXBUF_MODULE_FILE, I get better result with elementary-xfce-icon-theme (the adwaita icon themes still missing some icons). 3. logout via xfce4-session-logout will wait more about 30s for me, sometimes it does logout immediately, no idea... 4. mousepad output: Mousepad-Message: 11:00:34.614: Plugin directory '/gnu/store/0m4rqqn3gxwg6mafhccqjwwvqdz1a5sr-mousepad-0.5.10/lib/mousepad/plugins' not found GLib-GIO-Message: 11:00:34.614: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. The default gsettings backend is dconf, I guess some applications like mousepad need fix to enable dconf or use the keyfile backend for gsettings... I now open a bug for thoes issues.
bug#61126: [patch] fix: tcsh fails to build if guix builders have niceness 5 or more
Hi, guix build tcsh failed in my guix build when running guix build --check tcsh The attached patch disables the test that fails when the niceness of guix builders is 5 or more. From 193dca1b55b68aa883c3ed8b28bf19e9527fa065 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Sat, 28 Jan 2023 22:29:39 +0100 Subject: [PATCH] gnu: tcsh: comment out test of nice with nice guix builder * gnu/packages/patches/tcsh-fix-autotest.patch: comment out test of nice. To reproduce: guix shell tcsh -- nice -n 4 tcsh -c "nice echo 1" # works guix shell tcsh -- nice -n 5 tcsh -c "nice echo 1" # breaks --- gnu/packages/patches/tcsh-fix-autotest.patch | 29 1 file changed, 29 insertions(+) diff --git a/gnu/packages/patches/tcsh-fix-autotest.patch b/gnu/packages/patches/tcsh-fix-autotest.patch index 9f5790641b..252560dbb2 100644 --- a/gnu/packages/patches/tcsh-fix-autotest.patch +++ b/gnu/packages/patches/tcsh-fix-autotest.patch @@ -1,3 +1,32 @@ +--- tests/commands.at tests/commands.at +@@ -890,15 +890,16 @@ + TCSH_UNTESTED([newgrp]) + + +-AT_SETUP([nice]) +- +-# Nothing really tested +-AT_CHECK([tcsh -f -c 'nice set var=1; echo $?var'], , +-[0 +-]) +- +- +-AT_CLEANUP ++# XXX This test fails if the Guix worker has a nice value >= 5 ++# AT_SETUP([nice]) ++# ++# # Nothing really tested ++# AT_CHECK([tcsh -f -c 'nice -n +1 set var=1; echo $?var'], , ++# [0 ++# ]) ++# ++# ++# AT_CLEANUP + + + AT_SETUP([nohup]) + --- tests/commands.at +++ tests/commands.at @@ -921,26 +921,27 @@ AT_CLEANUP -- 2.39.1 Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
bug#58495: opam import generates wrong check phase
Le Sat, 28 Jan 2023 20:28:59 +0100, Csepp a écrit : > Julien Lepiller writes: > > > Le Thu, 13 Oct 2022 18:16:18 +0200, > > Csepp a écrit : > > > >> Julien Lepiller writes: > >> > >> > Maybe this could be fixed in the dune-build-system? > >> > > >> Actually, good call. I'll look into it, unless you want to take a > >> stab at it. > > > > With the test-target argument removed, do you consider this fixed? > > Yup, it's fixed now, thanks for closing these. Closing, thanks
bug#61033: opam importer can't handle list field
Julien Lepiller writes:
> Le Tue, 24 Jan 2023 03:23:44 +0100,
> Csepp a écrit :
>
>> Truncated stack trace:
>>
>> ```
>> ...
>> In guix/import/opam.scm:
>> 287:2 3 (opam->guix-package "mirage-crypto-pk" #:repo _ # _)
>> In unknown file:
>>2 (filter #
>> …) In guix/import/opam.scm:
>>290:13 1 (_ ("mirage-no-solo5" "mirage-no-xen"))
>> In unknown file:
>>0 (string-prefix? "conf-" ("mirage-no-solo5" "mirage-n…")
>> …)
>>
>> ERROR: In procedure string-prefix?:
>> In procedure string-prefix?: Wrong type argument in position 2
>> (expecting string): ("mirage-no-solo5" "mirage-no-xen") ```
>>
>>
>>
>
> The issue is related to lines like this in the list of dependencies:
>
> (("mirage-no-solo5" & "mirage-no-xen") | "zarith-freestanding" |
> "mirage-runtime" {>= "4.0"})
>
> This reads as a choice between three dependencies:
> - mirage-no-solo5 with mirage-no-xen
> - zarith-freestanding
> - mirage-runtime
>
> The importer infrastructure is not intelligent enough to really be able
> to solve constraints in imported packages, so I don't see an easy
> solution. It could silently use the first option, or put a comment
> instead.
>
> Ideas?
I think in unhandled cases it should emit something usable instead of
erroring, like how it can already emit missing-source or whatever symbol
it uses.
If Guile had good error types like, like Result in OCaml or Rust, it
could signal this with the Error variant and then the sexp it failed on
as a parameter.
Alternatively we could do what Nix does and have importers implemented
externally, so we could just hook into OPAM and let it run its solver
and then emit Guix package definitions. It already has a distro
integration system anyways.
So far these errors have been rare enough that handling them on a case
by case basis is acceptable, however I also ran into issues where the
wrong version of a package was imported and I spent hours trying to
debug the build until I realized I imported a version that's too new.
Having an opam2guix tool would solve that.
bug#58495: opam import generates wrong check phase
Julien Lepiller writes: > Le Thu, 13 Oct 2022 18:16:18 +0200, > Csepp a écrit : > >> Julien Lepiller writes: >> >> > Maybe this could be fixed in the dune-build-system? >> > >> Actually, good call. I'll look into it, unless you want to take a >> stab at it. > > With the test-target argument removed, do you consider this fixed? Yup, it's fixed now, thanks for closing these.
bug#61121: Cannot import IJulia in Julia
Hi Guix, I would like to run a Jupyter notebook using Julia, so I need to install the IJulia backend: guix install julia julia # Enter julia REPL ] # To go into the julia pkg REPL add IJulia # Now type backspace to go to julia REPL using IJulia This produces the error: [ Info: Precompiling IJulia [7073ff75-c697-5162-941a-fcdaad2a7d2a] ERROR: LoadError: InitError: SystemError: opening file "/gnu/store/npj8z0g9nx14wl22yphqfs2c5w4qk5jk-julia-1.8.3/share/julia/cert.pem": No such file or directory The full error message is here: https://pastebin.com/qC8yyHXT I saw a very similar bug on Gentoo: Without this file (which can be a symbolic link to `/etc/ssl/certs/ca-certificates.crt`) many Julia 1.8.3 packages, e.g. `HTTP`, do not work. This is what happens: julia> import HTTP [ Info: Precompiling HTTP [cd3eb016-35fb-5094-929b-558a96fad6f3] ERROR: LoadError: InitError: SystemError: opening file "/usr/share/julia/cert.pem": (https://bugs.gentoo.org/888978) Any help would be greatly appreciated. Best regards, Theodore Ehrenborg
bug#58495: opam import generates wrong check phase
Le Thu, 13 Oct 2022 18:16:18 +0200, Csepp a écrit : > Julien Lepiller writes: > > > Maybe this could be fixed in the dune-build-system? > > > Actually, good call. I'll look into it, unless you want to take a > stab at it. With the test-target argument removed, do you consider this fixed?
bug#61033: opam importer can't handle list field
Le Tue, 24 Jan 2023 03:23:44 +0100,
Csepp a écrit :
> Truncated stack trace:
>
> ```
> ...
> In guix/import/opam.scm:
> 287:2 3 (opam->guix-package "mirage-crypto-pk" #:repo _ # _)
> In unknown file:
>2 (filter #
> …) In guix/import/opam.scm:
>290:13 1 (_ ("mirage-no-solo5" "mirage-no-xen"))
> In unknown file:
>0 (string-prefix? "conf-" ("mirage-no-solo5" "mirage-n…")
> …)
>
> ERROR: In procedure string-prefix?:
> In procedure string-prefix?: Wrong type argument in position 2
> (expecting string): ("mirage-no-solo5" "mirage-no-xen") ```
>
>
>
The issue is related to lines like this in the list of dependencies:
(("mirage-no-solo5" & "mirage-no-xen") | "zarith-freestanding" |
"mirage-runtime" {>= "4.0"})
This reads as a choice between three dependencies:
- mirage-no-solo5 with mirage-no-xen
- zarith-freestanding
- mirage-runtime
The importer infrastructure is not intelligent enough to really be able
to solve constraints in imported packages, so I don't see an easy
solution. It could silently use the first option, or put a comment
instead.
Ideas?
bug#61116: [bayfront] logs.guix FTS database is stale
Hi all, The search box on logs.guix.gnu.org works fine but is forever stuck in 2021. I realised that I've never properly reported this. Sorry. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
bug#61114: Improvement: Make guix import crate easier to use
I very happily discovered guix import after trying to write a package def for a rust crate, but ran into this: ;;; Failed to autoload string->semver-range in (semver ranges): ;;; no code for module (semver ranges) <> guix/import/crate.scm:260:26: In procedure find-crate-version:error: string->semver-range: unbound variable Turns out it's because guix import has a soft dep on guile-semver, but intentionally leaves it out since most users won't need it. (See: http://logs.guix.gnu.org/guix/2023-01-28.log#005327) The dependency is small: 0.4MB. Could we either add it as a hard dep, or at least document at https://guix.gnu.org/manual/en/html_node/Invoking-guix-import.html so it is easier to discover how to use guix import crate? Probably same sort of thing for Guile-Lib for the go importer. Thanks! Best Regards, Benjamin Cherry -- devcarbon - LLC, Owner [devcarbon.com](https://devcarbon.com/) [image]
