bug#65909: in Geiser

Hi, If I connect Geiser to a Guix REPL, like so: $ guix repl --listen=tcp:37146 & M-x geiser-connect RET RET and enter the following into it: ,use (guix packages) (package (name "test") (version "1.0.0") (source #f) (build-system #f) (home-page #f) (synopsis #f)

bug#65769: greetd-wlgreet-sway-session result is blinking cursor

chris writes: > I support any conclusion from Josselin and unmatched-paren and want to add > these observations, > * wlgreet *does require* the greeter lock file > * wlgreet *does not require* elogind/logind > * not-advanced users like me may want to use wlgreet without elogind I'm not

bug#65769: greetd-wlgreet-sway-session result is blinking cursor

chris writes: >> The greeter works after creating /run/user/986/wayland-1.lock and changing >> the >> owner of /run/user/986 and /run/user/986/wayland-1.lock to "greeter". wut. I don't remember ever having to do anything like that... > My system config is here > > >

bug#65769: greetd-wlgreet-sway-session result is blinking cursor

chris writes: > In irc, I messaged the user who created greetd-wlgreet-sway-session and it > seems > other users have encountered the blinking cursor and no one knows of a > solution. If possible, I would like help troubleshoot and resolve the issue. I believe that may have been moi :) This is

bug#65460: ghc/ghci are broken

Jonas writes: > Thanks! Adding gcc-toolchain to the profile fixed it, but shouldn't this > be automatically brought in by `guix install ghc`? This does still feels > like a bug to me, shouldn't gcc-toolchain be a part of ghcs native-inputs? If this is to happen, it should be a regular input,

bug#65460: ghc/ghci are broken

Jonas via Bug reports for GNU Guix writes: > And compiling a hello-world program with ghc gives me: > > [1 of 1] Compiling Main ( hello.hs, hello.o ) > > : error: >     Warning: Couldn't figure out C compiler information! > Make sure you're using GNU gcc, or clang At

bug#64981: GTK4 applications broken (missing libGLESv2)

Csepp writes: >> Am Dienstag, dem 01.08.2023 um 00:06 +0200 schrieb Csepp: >>> for example: >>> $ transmission-gtk >>> Couldn't open libGLESv2.so.2: libGLESv2.so.2 >>> >>> I get the same error with Tuba.  It likely affects other >>> applications. >> I assume you are not using the

bug#64090: Cannot compute a file with a G-exp

Robby Zambito writes: > Strangely with-extensions doesn't seem to be including the whole > dependency tree for me. Should it? No, I don't think it should. It *would* be possible to traverse the package inputs and add all the GUILE-BUILD-SYSTEM-using packages, but then you get the problem that

bug#64090: Cannot compute a file with a G-exp

Hi! Robby Zambito writes: > scheme@(guile-user)> (source-module-closure '((ice-9 popen) (ice-9 atomic) > (ini) (json))) > $8 = () SOURCE-MODULE-CLOSURE only works for modules provided by Guix or Guix channels ;) Modules included in Guile don't need it at all, and for modules provided by

bug#63115: match-record cryptic error message on unbound record type

Maxim Cournoyer writes: > When a record type is not in scope, the error message produced by the > match-record macro from (guix records) reads something like: > > --8<---cut here---start->8--- > guix/records.scm:598:32: map-fields: bad use of syntactic keyword

bug#62830: Bug report

qqq0ppp via Bug reports for GNU Guix writes: > Following the request to report a bug. > Here is the output of guix pull. guix.gnu.org was down at the time, it's a network error :)

bug#62830: Bug report

qqq0ppp via Bug reports for GNU Guix writes: > Following the request to report a bug. > Here is the output of guix pull. guix.gnu.org was down at the time, it's a network error :)

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

Hi, On Wed Mar 8, 2023 at 4:09 PM GMT, Jonas Møller via Bug reports for GNU Guix wrote: > And then proceeds to define-public rust as rust-1.60, and I was wondering if > there's any particular reason why a year-old version is used rather than the > 1.65 version. This seems like a mistake, given

bug#59508: mpv compiled without x11 support

On Tue Nov 22, 2022 at 8:33 PM GMT, Saku Laesvuori via Bug reports for GNU Guix wrote: > I'm not sure is that enough to make guix consider the package updated > (though I would assume so), so I didn't prepare a patch. Anyway the fix > is a trivial one line addition. It is. -- (

bug#59131:

Fixed independently of my patch by updating to that commit. -- (

bug#59131: gnu: emacs-magit: Tests fail.

Heya, On Wed Nov 9, 2022 at 4:04 AM GMT, Kyle Meyer wrote: > (In terms of fixing Guix's emacs-magit build, 36059e0b applies cleanly > to v3.3.0's tree.) Done: . -- (

bug#59131: gnu: emacs-magit: Tests fail.

Heya, On Wed Nov 9, 2022 at 4:04 AM GMT, Kyle Meyer wrote: > Thanks for posting this. This recently started failing on Magit's CI, > but nobody had looked into it too deeply yet. Your message suggested > that bisecting Git v2.38.0..v2.38.1 would be a good place to start. > > That pointed to

bug#59131: gnu: emacs-magit: Tests fail.

Heya Guix, $ guix describe Generation 240Nov 08 2022 18:38:30(current) guix c52cdd1 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: c52cdd18d6f869dfb1f8b5214a0db6ebb562 [...] EMACS-MAGIT fails to build on master, as two tests

bug#58046: Poedit fails to open PO files

On Sat Sep 24, 2022 at 8:02 PM BST, Luis Felipe via Bug reports for GNU Guix wrote: > WORKAROUND > > Start Poedit in a guix shell that adds gettext: > > guix shell poedit gettext > poedit > > Then, you can open the PO files normally. > > So it seems the package definition for Poedit is missing

bug#57306: guix pull to old commit fails due to unsupported manifest format

Oops, I didn't read the issue properly and assumed it was just a duplicate of the time-machine unsupported manifest format bug by someone who doesn't know about the workaround (there have been a few of those); sorry! -- (

bug#57306: guix pull to old commit fails due to unsupported manifest format

https://issues.guix.gnu.org/56545#1 > Commit 4ff12d1de7cd617b791996ee7ca1240660b4c20e introduced that bug, > which was fixed in c9fbd40785a99e13a59d8e530830ce85220a9871: > > https://issues.guix.gnu.org/56441 > > ‘guix describe’ should show that you’re using a commit in that range. > > The

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

Hello Maxim, On Wed Aug 17, 2022 at 2:16 PM BST, Maxim Cournoyer wrote: > So instead of 'unset-value?', I'd use 'value-unset?', but since in this > case we're dealing with a 'maybe' type defined with the 'define-maybe' > macro, I'd keep 'maybe-value-unset?'. How about `unset?` or `maybe-unset?`?

bug#57090: [BUG] Default Notation for chmod in guix style?

On Tue Aug 9, 2022 at 10:01 PM BST, Csepp wrote: > Seems to be a Scheme limitation: > > ``` > scheme@(guile-user)> '(#o10) > $1 = (8) > ``` `guix style` uses a completely seperate reader, defined in (guix read-print), so even though it's possible it has the same limitation, we could easily modify

bug#57090: [BUG] Default Notation for chmod in guix style?

On Tue Aug 9, 2022 at 9:59 PM BST, Maxime Devos wrote: > 'chmod' is not mentioned anywhere in (guix scripts style), so I'd think > it's just an oversight. The authority on the matter would be Ludovic > Courtès Is it possible that (guix read-print) stores octal numbers directly as Scheme

bug#57089: r-rmarkdown contains minified JavaScript

On Tue Aug 9, 2022 at 9:38 PM BST, Ricardo Wurmus wrote: > It is not immediately obvious, where the corresponding source code could be > found: They seem to come from various NPM packages; looks like these ones: * https://www.npmjs.com/package/bootstrap *

bug#47222:

We now have nettle 3.7.3, so this isn't an issue anymore. Closing. -- (

bug#57059: [BUG] pcc build failure

The build for the `pcc` compiler is broken on my machine (x86-64): ```log starting phase `set-SOURCE-DATE-EPOCH' phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds starting phase `set-paths' environment variable `PATH' set to

bug#52029: wterm fails to start on core-updates-frozen

On Sat Aug 6, 2022 at 2:38 AM BST, Tobias Geerinckx-Rice wrote: > Either of you feel like practicing a 'simple deprecation'? ;-) Done at #57014 :) -- (

bug#52029: wterm fails to start on core-updates-frozen

On Fri Aug 5, 2022 at 2:37 AM BST, Joshua Branson via Bug reports for GNU Guix wrote: > I vote that we remove wterm from guix. It is still unmaintained at the > github link below. And it doesn't ever run properly. Perhaps we could mark it as deprecated and point to Foot or WLTerm instead.

bug#56864: qutebrowser: wrap-qt-process-path phase wrong type to string-append

This issue affects the following packages as well as qute: twinkle, lyx, nheko, quaternion, kcrash, likely many KDE packages (possibly kdenlive, kdevelop, and others), kguiaddons, psi, sonnet. (Not a complete list, of course.) -- (

bug#56864: qutebrowser: wrap-qt-process-path phase wrong type to string-append

On Mon Aug 1, 2022 at 3:10 PM BST, Lars-Dominik Braun wrote: > Maybe a different incarnation of the same issue? The fix is on the package side, so other affected packages won't have been fixed by that commit. -- (

bug#56722: guix pull fails -- unbound variable in gnu/home/services/symlink-manager.scm

On Sun Jul 31, 2022 at 11:08 PM BST, Ludovic Courtès wrote: > Thanks for the heads-up. The offending commit is reinstated together > with a fix in 4de445f3dae5f5b42d59003cceddecfb296fb73b. Thanks, Ludo'! -- (

bug#56722: guix pull fails -- unbound variable in gnu/home/services/symlink-manager.scm

Tobias seems to have fixed this issue temporarily by reverting the Home GC commits. Should we close this, reopen that patch thread, and discuss the issues there? -- (

bug#54691: [PATCH v2 4/5] gnu: Remove rinutils.

On Sat Jul 23, 2022 at 4:16 PM BST, Liliana Marie Prikler wrote: > This package was introduced as native input to the now removed fortune-mod, > so let's remove it as well. This package seems potentially useful by itself; should we really be removing libraries just because they're leaves? --

bug#56722: guix pull fails -- unbound variable in gnu/home/services/symlink-manager.scm

vhallac has determined that commit ba22560627f848f40891a56355ff26b6de1380bc, which allowed `guix gc` to delete Home generations, caused this issue. Somehow. -- (

bug#56722: guix pull fails -- unbound variable in gnu/home/services/symlink-manager.scm

Log here: What's weird is that the culprit, gnu/home/services/symlink-manager.scm, *does* have access to `service-type`, because it imports (gnu home services), which re-exports it! My attempts to `git bisect` were

bug#56030: The guix pull profile is too big

> We could compile a '__guix_shell_path = "/..."' during the compilation > of the package (as a .o) and wrap gcc to insert it to the CLI arguments, > no linker scripts required. Alas, for some reason I couldn't find any documentation on how to define strings in a linker script. But never mind

bug#56030: The guix pull profile is too big

Okay, another (hopefully more coherent) proposal: Patch in a ``` extern char *__guix_shell_path; ``` And then, we use a linker script to provide the definition of __guix_shell_path at linking time. (Unfortunately there's no way to do this with a flag, afaik...) -- (

bug#56030: The guix pull profile is too big

Oh! I understand now! The __guix_bin_sh macro would actually be included in the expansion, not defined during the glibc build. Sorry (again) for the noise! -- (

bug#56030: The guix pull profile is too big

On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote: > Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But > it's not 'just use -DSHELL_PATH=', we still need to change 'system' > appropriately. Why would we need to change it? The glibc definition already uses that macro for

bug#56030: The guix pull profile is too big

On Thu Jul 21, 2022 at 4:42 PM BST, Julien Lepiller wrote: > We're trying to avoid hard-coding bash-static in glibc, instead letting the > build-system fill the value in dependents. So that can't be it, right? How would it be any different from -D__guix_bin_sh=...? That argument would simply be

bug#56030: The guix pull profile is too big

On Thu Jul 21, 2022 at 4:03 PM BST, paren--- via Bug reports for GNU Guix wrote: > Would this not violate POSIX? Correction: system(3) is ISO C, not POSIX. But: @ C11 7.1.4p1 ``` ... it is permitted to take the address of a library function even if it is also defined as a macro ^185 ...

bug#56030: The guix pull profile is too big

And considering the definition of system(3) in glibc: @ sysdeps/posix/system.c (took me way too long to find this; glibc's source code is a maze ;)) ``` #define SHELL_PATH "/bin/sh" /* Path of the shell. */ #define SHELL_NAME "sh"/* Name to give it. */ ```

bug#56030: The guix pull profile is too big

On Thu Jul 21, 2022 at 3:52 PM BST, Maxime Devos wrote: > * Add a macro '#define system ...' that calls this variant and inserts > __guix_bin_sh as the shell executable Would this not violate POSIX? Since, as far as I can see,

bug#56371: Can't remove a package present in profil

> Control: close #56371 To run a control command, send it to cont...@debbugs.gnu.org :) -- (

bug#53355: bug#51466: bug#53355: guix shell --check: confusing error message

On Tue Jun 28, 2022 at 11:38 AM BST, Maxime Devos wrote: > Then it could be fixed in that distro? And if the distro intentionally > keeps it broken for years, then that seems more a problem in the distro > than Guix to me. I believe Ludo' is referring to LTS distros and other situations where

bug#56016: [BUG] Various confusing error messages.

On Thu Jun 16, 2022 at 11:33 AM BST, Josselin Poiret wrote: > For now, [1] should add more context to this error message by printing > the whole backtrace. Nice!

bug#56012: guix pull fails. cannot build guix-package-cache.drv.

Hi vidak, On 16 June 2022 06:28:45 BST, vi...@riseup.net wrote: >hey all. > >vidak here. > >i cannot get `guix pull` to work for me. > >i am having issues getting the package-cache.drv to build. > >i was homeless, and unable to update my workstation for about... a >month? Oh no, I hope you're

bug#56016: [BUG] Various confusing error messages.

This issue aims to document error messages in Guix that need to be improved. If you get an error message and you have no idea what it's trying to tell you, please send it here! ~ Unbound variable while building package cache This might be a Guile or Guix thing, not sure which. Using the recent

bug#55953: `guix install dub` fails

This probably went unnoticed because we don't actually _have_ any Dub-based packages. Anyway, from that log: > source/dub/internal/vibecompat/data/json.d(2111): Error: template > instance `enforceEx!JSONException` template `enforceEx` is not > defined, did you mean enforce(E : Throwable =