bug#60413: cutter is outdated and also segfaults on launch
Our package for the Cutter reverse engineering framework is very outdated and now the package does not even work, since the Cutter executable simply crashes on startup in ImportsModel::rowCount. I attempted packaging the new version that uses the new rizin fork of radare2 but didn't get far. I can't work on it right now, but if someone wants to pick up where I left off, I'll push my branch to https://git.sr.ht/~raingloom/guix-source/tree/raingloom/cutter It's not currently online and it's on a different machine than the one I'm writing from, but once pushed, it should be at that URL. I'm not sure how a package that doesn't even start passed its check phase. Tests don't seem to be disabled, so maybe it's Wayland related? But it was working fine a few months ago, so this is weird. Either way, the version is old, so unless the fix is trivial, time is better spent updating the package than fixing the current version.
bug#49115: Mumi inserts spurious underscore in bug title
Hi Ricardo, Thanks for the bug report! It's very strange, but I'm not able to reproduce this. I tried the following. bug_49114.mbox is downloaded from https://debbugs.gnu.org/cgi/bugreport.cgi?mbox=yes;bug=49114 --8<---cut here---start->8--- (use-modules (email email)) (pk (parse-email-headers "Subject: bug#49114: =?UTF-8?Q?=E2=80=98guix_?= =?UTF-8?Q?lint=E2=80=99?= should catch certificate validation exceptions ")) (for-each (lambda (bv) (pk (assoc-ref (email-headers (parse-email bv)) 'subject))) (call-with-input-file "bug_49114.mbox" mbox->emails)) --8<---cut here---end--->8--- Even at https://issues.guix.gnu.org/49114 , only the "bug title" has the spurious underscore. The subject of the first message does not. Is the bug title something stored in the xapian index? Could it be that this was an older bug that has corrupted the xapian index? If I understand correctly, mumi does not rebuild its xapian index. I think it should do so from time to time. It would help prevent old bugs from getting persisted in storage. Cheers, and wish you a Happy New Year! :-) Arun
bug#60205: Dino lacks some icons
On úterý 20. prosince 2022 14:56:55 CET you wrote: > Liliana Marie Prikler writes: > > Am Montag, dem 19.12.2022 um 16:14 + schrieb Tirifto: > >> ** (dino:17647): CRITICAL **: 17:06:11.642: file /tmp/guix-build- > >> dino-0.3.1.drv-0/dino-0.3.1/main/src/ui/main_window.vala: line 68: > >> uncaught > >> error: Unrecognized image file format (gdk-pixbuf-error-quark, 3) > >> > >> (dino:17647): Gtk-WARNING **: 17:06:11.676: Found an icon but could > >> not load > >> it. Most likely gdk-pixbuf does not provide SVG support. > >> > >> (dino:17647): Gtk-WARNING **: 17:06:11.680: Could not load a pixbuf > >> from > >> icon theme. > >> This may indicate that pixbuf loaders or the mime database could > >> not be found. > > > > These two lines appear to mark the most likely culprit. Now, normally > > our gdk-pixbuf packages do support svg, but there's some strings > > attached. Most of our GNOME related programs are tested in a GNOME > > environment rather than a pure one, which means that things that > > shouldn't work happen to do. Compare the output of > > > > guix shell --pure -E DISPLAY dino librsvg adwaita-icon-theme -- dino > > > > to > > > > guix shell --pure -E DISPLAY dino -- dino > > > > Note that librsvg is a regular input to dino and should thus be > > available as a pixbuf loader. I'm not sure what exactly is wrong here > > (perhaps dino should swap its librsvg input for gdk-pixbuf), but > > another caveat is that on non-x86_64 systems we are forced to use a > > pre-Rust version of librsvg, which barfs on some particular input > > files. > > Just quoting bug 48636: > > I have adwaita-icon-theme and hicolor-icon-theme in my system profile, > which I think makes some gtk stuff play nicer. I would suggest > installing them if you don't have them. I also have > gnome-themes-standard and gnome-themes-extra, so those may also be worth > installing if the other things don't do the trick. > > Perhaps the hicolor icons should be made a dependency so users don't > have to figure this out on their own. I recall another package getting > that treatment a while back. > > End quote > > Perhaps dino should have hicolor-icon-theme as a dependency. Thank you both for your help! I have done some experimenting with the provided information. When I run the following command: guix shell --pure -E DISPLAY dino librsvg adwaita-icon-theme -- dino Dino displays perfectly well, only with the Adwaita theme. I use KDE, so I thought installing a matching theme might allow it to match the host system. And indeed, after adding the packages ‘breeze’, ‘breeze-gtk’, and ‘breeze- icons’ into my profile, Dino runs with the correct theme and icons. I assume it’s always a good idea to install the theme you’re using in Guix also. The window control buttons still wouldn‘t show up until I installed ‘librsvg’ and incorporated it into my profile. As for ‘hicolor-icon-theme’, I don’t think it has had an effect on Dino; icons were still missing with only hicolor-icon-theme provided. > > Hope that helps. > > > > Cheers Thank you both for your help, my issue has now been solved; although perhaps this ticket should remain open until it’s solved in Guix by default? Best of wishes // Tirifto
bug#60404: Can not geiser-eval-last-sexp package define when use geiser-connect and guix repl --listen=tcp:37146
1. Run bash command: guix repl --listen=tcp:37146
2. Run geiser-connect to connect guix repl.
3. open emacs-xyz.scm
4. enable guix-devel-mode and run C-c . u
5. C-x C-e emacs-dired-sidebar define.
the error showed:
---
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Syntax error:
unknown file:#f:#f: encountered raw symbol in macro output in subform socket of
(current-location-vector)
[Debugging level: 2]
Expression evaluated was:
(define-public emacs-dired-sidebar
(package
(name "emacs-dired-sidebar")
(home-page "https://github.com/jojojames/dired-sidebar;)
(version "0.2.0")
(source
(origin
(method git-fetch)
(uri (git-reference
(url home-page)
(commit version)))
(file-name (git-file-name name version))
(sha256
(base32 "090dqaqyjmkzrz4szjpk1iip0bdvb0frp4l79393f8ki8w7c16c1"
(build-system emacs-build-system)
(propagated-inputs
(list emacs-dired-hacks))
(synopsis "Sidebar for Emacs using Dired")
(description
"This package provides a sidebar for Emacs similar to @code{NeoTree}
or @code{treemacs}, but leveraging @code{Dired} to do the job of display.")
(license license:gpl3+)))
--
bug#57867: Tealdeer build fails
Hi Corvo, Corvo Liu writes: > I don't get it. How can a package "used to work" and "fail" now? If that is > the case, how is guix "declarative"? Some dependencies might have been updated in the meantime resulting in build failures. If you use a Guix commit from back when that package was building fine, it will still build fine. Guix being reproducible doesn't mean that Guix doesn't update any of its packages. Best, -- Josselin Poiret
