bug#61195: termite failed to build, need switch to a maintained fork
New fork: https://github.com/aperezdc/termite Maybe also remove vte-ng.
bug#59579: installing zbar prevents gdm to start on Ubuntu 22.04 foreign distro
Simon Tournier writes: > Hi, > > On Fri, 25 Nov 2022 at 18:45, Clément Lassieur wrote: > >> It's very difficult to pin the issue down to a guix package being >> installed. >> >> I imagine the bug would not happen if ~/.guix-profile/share was not in >> XDG_DATA_DIRS. > > Yes, it is related to XDG_DATA_DIRS and it can be tedious to find which > package brings the issue. > > I had a similar issue with the package ’python-ipython’ and recently > with ’fontconfig’ – both cases running on the top of Debian. > > The issue can happen whatever the profile; it just depends which ones > are sourced by your login shell. > Hello, I don't think XDG_DATA_DIRS should be the problems, but other environment variables with "lib", since the xdg data should be portable... So: --8<---cut here---start->8--- $ guix shell -C coreutils zbar --no-grafts -- env PS1=\u@\h \w [env]\$ TMPDIR=/tmp TEMPDIR=/tmp TMP=/tmp TEMP=/tmp LOGNAME=iyzsong USER=iyzsong HOME=/home/iyzsong PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/bin:/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/sbin XDG_DATA_DIRS=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/share GUIX_GTK3_PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/gtk-3.0 QMAKEPATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/qt5 QT_PLUGIN_PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/qt5/plugins XDG_CONFIG_DIRS=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/etc/xdg XCURSOR_PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/share/icons GDK_PIXBUF_MODULE_FILE=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache GUIX_ENVIRONMENT=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile --8<---cut here---end--->8--- I think GUIX_GTK3_PATH, QT_PLUGIN_PATH, GDK_PIXBUF_MODULE_FILE should be the problems.
bug#58290: guile ssh error on guix deploy
Hi, The bug should be fixed with the upgrade to Guile-SSH 0.16.3 in commit e6f557dd23fbb298afa92dba3133ed985e560699. Thanks Artyom for the prompt fix & release! Ludo’.
bug#61156: ‘guix container exec’ does not actually change PID namespaces
Ludovic Courtès skribis: > The reason is that calling setns(2) on a PID namespace “changes only the > PID namespace that subsequently created child processes of the caller > will be placed in; it does not change the PID namespace of the caller > itself.” Fixed in 0ef8fe22ed8985c9656835fc25ab3463d55b6669. Ludo’.
bug#61121: Cannot import IJulia in Julia
Hi, Thanks for getting back with me. Gentoo appears to have fixed this bug by linking julia/cert.pem to the system's ca-certificates.crt. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=26b59330b5222996defa4536237e62404bf21168 Is there a way I could rebuild my own slightly modified Julia with a link like that? I understand that there's probably a good reason that Guix's Julia doesn't by default have cert.pem, but I would be pleased with a hacky custom solution if it made Jupyter notebooks work. Thanks, Theodore Den mån 30 jan. 2023 kl 12:47 skrev Simon Tournier : > Hi, > > I confirm this bug. > > On sam., 28 janv. 2023 at 13:45, Theodore Ehrenborg < > theodore.ehrenb...@gmail.com> wrote: > > > [ 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 > > [...] > > > I saw a very similar bug on Gentoo: > > [...] > > > (https://bugs.gentoo.org/888978) > > Well, that’s because Julia upstream does not take care about packagers; > as explicitly mentioned in this comment: > > > https://github.com/JuliaLang/MbedTLS.jl/pull/261#issuecomment-1346886879 > > The Guixer Cayetano Santos fixed upstream the issue for one package. > But as you are noticing it is not done for all. > > I do not know what is the best solution because the issue is coming from > Julia itself. > > Efraim, any suggestion? > > Cheers, > simon >
bug#61055: file-needed/recurive does not canonicalize paths
Hi Lars, Lars-Dominik Braun skribis: > during testing of wip-haskell I observed the make-dynamic-linker-cache > phase is taking alot of time (up to two minutes on a fast machine with > SSD). Looking at ghc-hindent for example [1]: > > starting phase `make-dynamic-linker-cache' > created > '/gnu/store/2nrzbaxmqs2rq9yv52bpyn2azb3qj6h1-ghc-hindent-5.3.4/etc/ld.so.cache' > from 10085 library search path entries > phase `make-dynamic-linker-cache' succeeded after 119.5 seconds > > And while Haskell packages link to a pretty large number of dynamic > libraries (116 in this case), 1 search path entries seems wrong. Running > just > > (file-needed/recursive > "/gnu/store/2nrzbaxmqs2rq9yv52bpyn2azb3qj6h1-ghc-hindent-5.3.4/bin/hindent") > > takes a long time and reveals entries like > /gnu/store/1cyk8j2nd6r0cvm6kx1408kd763yf8h5-ghc-9.2.5/lib/ghc-9.2.5/Cabal-3.6.3.0/../directory-1.3.6.2/../unix-2.7.2.2/../bytestring-0.11.3.1/../template-haskell-2.18.0.0/../pretty-1.1.3.6/../array-0.5.4.0/../base-4.16.4.0/../ghc-bignum-1.2/../ghc-prim-0.8.0/libHSghc-prim-0.8.0-ghc9.2.5.so > so it looks like it deduplicates values, but does not canonicalize > paths. A relatively straight-forward fix could be the following change, > but I don’t know if that would cause any issues, since canonicalize-path > throws an exception if the resulting path does not exist. It’s also > a world rebuild since pretty much any package uses this phase (and the > reason and I cannot test it on a larger scale). Right. Other arguments against systematic canonicalization: (1) ‘canonicalize-path’ is costly, (2) developers and tools might choose to write ‘x/y/../z’ for a good reason and changing that could break their expectations. Can you see how we end up with those entries? These at DT_NEEDED entries, not DT_RUNPATH, right? If so, that probably means that ghc at some points invokes the linker along the lines of: ld -o hindent ../foo/../bar/../baz/libbaz.so Could you check in build logs exactly how that executable gets linked? Is there a way we could canonicalize there, or, better, get the build system to do something like: ld -o hindent -L ../foo/../bar/../baz -lbaz ? That way DT_NEEDED would be just “libbaz.so” instead of the complete file name. DT_RUNPATH would contain the weird file name, but that’s probably okay. HTH, Ludo’.
bug#60927: gPodder database version field different when built using --with-latest
Hi, Csepp skribis: > So it looks like the hashes are the same and the difference is instead > in how it's run. > Usually I run it with i3's XDG desktop file based launcher, but when I > used the --with-latest transformation I was running it from a guix > shell. > Maybe it's using the non-canonicalized path to itself as part of the > version string. Note that right now ‘--with-latest’ has no effect because it’s already the latest version that’s packaged: --8<---cut here---start->8--- $ guix build gpodder -n 4.2 MB would be downloaded: /gnu/store/7jhmy0j4z50vb7051ckl0fkwv60y9aq8-python-pytest-httpserver-1.0.0 /gnu/store/rmkakj3hbijzcn8jdicyhh4fcwgw4kjk-xset-1.2.4 /gnu/store/almvw06pqf7gj09zkzi37iyzxph7abb2-xdg-utils-1.1.3 /gnu/store/zbsg01v7jzryx2ccgaxnm0qzi8b9022h-youtube-dl-2021.12.17 /gnu/store/cl22f0z9xggjspqsplf91bkqm35ad6fw-python-flake8-4.0.1 /gnu/store/spwqzk6l1r8wx34wlfnw487rc86skzgv-python-pycodestyle-2.8.0 /gnu/store/gaqm1cgvbam1jr2x7r6jw5gdrm9hv997-python-mutagen-1.45.1 /gnu/store/75h3kapgwpgh6q2dxddgrzbxwb22z9k7-python-xmlschema-1.2.5 /gnu/store/ixp9xd4cbs774yh5qkvywmjk1606s8i8-python-pytest-bootstrap-6.2.5 /gnu/store/7frqm5ijy66f81hr8i1j6791k84lds9w-python-pytest-6.2.5 /gnu/store/rfgdckaa197c4wkzixqqi3lmd6cvv414-python-requests-2.28.1 /gnu/store/hz1fv46474jm8d0lbirglx3cvmy8npkl-gpodder-3.11.0 $ guix build gpodder -n --with-latest=gpodder guix build: 3.11.0 is already the latest version of 'gpodder' 4.2 MB would be downloaded: /gnu/store/7jhmy0j4z50vb7051ckl0fkwv60y9aq8-python-pytest-httpserver-1.0.0 /gnu/store/rmkakj3hbijzcn8jdicyhh4fcwgw4kjk-xset-1.2.4 /gnu/store/almvw06pqf7gj09zkzi37iyzxph7abb2-xdg-utils-1.1.3 /gnu/store/zbsg01v7jzryx2ccgaxnm0qzi8b9022h-youtube-dl-2021.12.17 /gnu/store/cl22f0z9xggjspqsplf91bkqm35ad6fw-python-flake8-4.0.1 /gnu/store/spwqzk6l1r8wx34wlfnw487rc86skzgv-python-pycodestyle-2.8.0 /gnu/store/gaqm1cgvbam1jr2x7r6jw5gdrm9hv997-python-mutagen-1.45.1 /gnu/store/75h3kapgwpgh6q2dxddgrzbxwb22z9k7-python-xmlschema-1.2.5 /gnu/store/ixp9xd4cbs774yh5qkvywmjk1606s8i8-python-pytest-bootstrap-6.2.5 /gnu/store/7frqm5ijy66f81hr8i1j6791k84lds9w-python-pytest-6.2.5 /gnu/store/rfgdckaa197c4wkzixqqi3lmd6cvv414-python-requests-2.28.1 /gnu/store/hz1fv46474jm8d0lbirglx3cvmy8npkl-gpodder-3.11.0 $ guix describe Generation 244 Jan 29 2023 23:24:35(current) guix 4eccb27 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 4eccb27b4c74a9112cbbad722d85558e9565f20b --8<---cut here---end--->8--- So as you wrote, the issue you’re seeing probably has nothing to do with ‘--with-latest’. Could you show exactly what command you’re running, what output you’re seeing, and what you were expecting? TIA, Ludo’.
bug#60947: Two different derivations for ‘guix’ depending on whether grafts are enabled
Ludovic Courtès skribis: > --- # > +++ # > @@ -45,7 +45,7 @@ >(assoc-ref %outputs "out")) > (ruby-build #:name "ruby-nokogiri-1.13.10" #:source > "/gnu/store/82giwp6r123kky2fg6a0bkx7dyh0vp2h-nokogiri-1.13.10.gem" #:system > "x86_64-linux" #:gem-flags > (list "--" "--use-system-libraries" > - (string-append "--with-xml2-include=" > "/gnu/store/g3y6ifhm0751vgsxv90yipfw6mk189kj-libxml2-2.9.12" > "/include/libxml2")) > + (string-append "--with-xml2-include=" > "/gnu/store/7h3rl7awha559jj0r7ba66njh27sb8pq-libxml2-2.9.12" > "/include/libxml2")) > #:test-target "test" #:tests? #f #:phases > (modify-phases %standard-phases > (add-after To be clear, what we have in source here is: --8<---cut here---start->8--- (define-public ruby-nokogiri (package ;; … (arguments (list #:tests? #f #:gem-flags #~(list "--" "--use-system-libraries" (string-append "--with-xml2-include=" #$(this-package-input "libxml2") "/include/libxml2" ;; … (license license:expat))) --8<---cut here---end--->8--- … and it’s the #$(this-package-input "libxml2") bit that causes that discrepancy. Ludo’.
bug#60947: Two different derivations for ‘guix’ depending on whether grafts are enabled
Ludovic Courtès skribis: > We have a problem! Depending on whether grafts are enabled, we end up > building one of two different derivations for ‘guix’ (“real” > derivations; none of them is a mere grafting derivation): A similar situation: --8<---cut here---start->8--- $ guix describe Generation 244 Jan 29 2023 23:24:35(current) guix 4eccb27 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 4eccb27b4c74a9112cbbad722d85558e9565f20b $ guix build ruby-nokogiri -d /gnu/store/gfry2algsp4rw8mp9d75qlrns1radjar-ruby-nokogiri-1.13.10.drv $ guix build ruby-nokogiri -d --no-grafts /gnu/store/vdnp9ila1946dakcrs55x3iwjc781pbi-ruby-nokogiri-1.13.10.drv --8<---cut here---end--->8--- This is causing a dozen of ‘ruby-’ package that ‘gnome-shell’ depends on to be rebuilt locally, even though ‘guix weather gnome-shell’ says it’s available. Annoying! Patch coming. Ludo’. --- # +++ # @@ -45,7 +45,7 @@ (assoc-ref %outputs "out")) (ruby-build #:name "ruby-nokogiri-1.13.10" #:source "/gnu/store/82giwp6r123kky2fg6a0bkx7dyh0vp2h-nokogiri-1.13.10.gem" #:system "x86_64-linux" #:gem-flags (list "--" "--use-system-libraries" - (string-append "--with-xml2-include=" "/gnu/store/g3y6ifhm0751vgsxv90yipfw6mk189kj-libxml2-2.9.12" "/include/libxml2")) + (string-append "--with-xml2-include=" "/gnu/store/7h3rl7awha559jj0r7ba66njh27sb8pq-libxml2-2.9.12" "/include/libxml2")) #:test-target "test" #:tests? #f #:phases (modify-phases %standard-phases (add-after
bug#61132: xfce 4.18 issues: gsettings, icons missing, and logout need long time
宋文武 writes: >> [...] >> >> 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. > 5. Thunar start slowly When I update to xfce 4.18, thunar start need 5 second, when I 1. backup my xfce4 config. 2. rm my old xfce4 config. 3. run xfce4 and quit. 4. restore old xfce4 config. 5. run xfce4 again. The problem dispear, I do not know why. --
bug#61121: Cannot import IJulia in Julia
Hi, I confirm this bug. On sam., 28 janv. 2023 at 13:45, Theodore Ehrenborg wrote: > [ 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 [...] > I saw a very similar bug on Gentoo: [...] > (https://bugs.gentoo.org/888978) Well, that’s because Julia upstream does not take care about packagers; as explicitly mentioned in this comment: https://github.com/JuliaLang/MbedTLS.jl/pull/261#issuecomment-1346886879 The Guixer Cayetano Santos fixed upstream the issue for one package. But as you are noticing it is not done for all. I do not know what is the best solution because the issue is coming from Julia itself. Efraim, any suggestion? Cheers, simon
