Our xcalc package launches something that I can't figure out how to use.
This is with Guix on Debian.
Can anyone reproduce it?
Debian's xcalc looks like I'd expect.
I've attached screenshots.
Does anyone have any ideas about what's wrong?
Pushed as 13f769c165c06b97472f61902d491c8910e86f8b.
Kind regards,
T G-R
signature.asc
Description: PGP signature
Alright, it's time to land these patches. I tested with a handful of
packages on x86_64 and it seems fine. I can test every package before
pushing.
However, Go 1.17.4 doesn't build for us on aarch64. I tried building the
derivation for this scheduled CI job:
https://ci.guix.gnu.org/build/1952348/
On Fri, Aug 06, 2021 at 10:04:19PM -0700, Sarah Morgensen wrote:
> I just noticed go-1.16 is failing on aarch64 [0]. I am not having any
> success tracking down the cause. It looks like the error is the same as
> was happening for go-1.14 circa 11 Mar [1], which was fixed by 9 Apr
> [2], but I cann
Hi,
Amar Singh writes:
> When Guix includes some Yasnippet snippets for Emacs in its source, why
> aren't these
> installed with package Guix?
These are meant for hacking on Guix itself, meaning having a git
checkout of the source readily available. They aren't typically useful
in the context
Hello,
Ludovic Courtès writes:
> Hi!
>
> Ludovic Courtès skribis:
>
>> Ludovic Courtès skribis:
>>
>>> I noticed that on Debian 9, ‘guix-daemon.service’ (systemd) runs under
>>> the C.UTF-8 locale by default, even if the machine is otherwise
>>> configured with another locale. Consequently, ‘
Hi,
Ludovic Courtès writes:
> Hello Danny,
>
> Danny Milosavljevic skribis:
>
>> /gnu/store/3c4y81fr7r6lk5d4fpx1cyqkl4x64kz5-iso-image-installer-builder:1:
>> FAIL shell and user commands
>>
>> ;;; (services (udev term-tty1 console-font-tty1 term-tty2 term-tty6
>> console-font-tty6 console-fon
* gnu/packages/gnupg.scm (gnupg-2.2.32): Replace with ...
(gnupg-next): ... new variable.
(qgpgme)[native-inputs]: Replace gnupg-2.2.32 with gnupg-next.
* gnu/packages/emacs-xyz.scm (emacs-pinentry)[propagated-inputs]: Use
gnupg-next.
---
gnu/packages/emacs-xyz.scm | 2 +-
gnu/packages/gnupg.scm
Looking at a page like this, we only have timestamps for "completed
builds", but not for failures:
https://ci.guix.gnu.org/search?query=gnome-41
On Tue, Dec 14, 2021 at 11:46:12AM -0500, Leo Famulari wrote:
> Here is a patch that unhides gnupg-2.2.32, updates it to 2.2.33, and
> makes emacs-pinentry use that package variant.
After sending this patch, I noticed that gnupg-2.2.32 is also used by
qgpgme. This bug was noticed earlier, but misi
Hello,
Ludovic Courtès writes:
> Hello,
>
> zna...@disroot.org skribis:
>
>> So, there I reconnect to Internet and restart guix-daemon with `# herd
>> restart guix-daemon`, and everything goes fine.
>
> Is this reproducible, or is the problem gone now?
>
> It may have been a transient networkin
Hello,
Ricardo Wurmus writes:
> Mark H Weaver writes:
>
>> Earlier, I wrote:
>>
>>> FWIW, I've found GNOME Shell to be quite solid on my X200, including
>>> since the 3.28 upgrade. However, I run it under Wayland, by running
>>> "XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session" fr
Hello!
Ludovic Courtès skribis:
> GNOME Shell is crashy since the 3.28 upgrade (it’s an install that was
> made before the 3.28 upgrade; I wonder whether the same happens on a
> fresh install.)
>
> It occasionally crashes (SIGSEGV) and is automatically respawned, which
> is kinda okay: as a user
Hi Danny,
Danny Milosavljevic writes:
> http://berlin.guixsd.org/log/64f1pzamnmb0x2bi8krp78nnbywpkqh1-disk-image
>
> ERROR: In procedure copy-file:
> In procedure copy-file: No space left on device
>
> copying 410 store items [
> ]Backtrace:
>
Our GnuPG package is version 2.2.30, which includes this bug:
https://dev.gnupg.org/T5577
The effect of this bug is that symmetric encryption / decryption does
not work. The bug was fixed in 2.2.31 and 2.3.3.
Changing GnuPG will cause 2406 rebuilds. I think that's suboptimal but
it's the situati
Hi Lars,
Lars-Dominik Braun skribis:
>> But precisely: as Alexander wrote, when JUPYTER_CONFIG_DIR points to the
>> store, jupyterlab cannot drop a config file there. Or am I missing
>> something?
> sorry, my message was unclear here. The config file is written at
> build time.
Oh I see.
>> B
Hi,
Christopher Baines skribis:
> Ludovic Courtès writes:
[...]
>> Ah yes, that looks like a problem: “doc”, which is taken straight from
>> the checkout, normally does not contain *.LANG.texi; those files are not
>> checked in.
>>
>> Could it be that ~/.cache/guix/checkouts contains a non-pr
17 matches
Mail list logo
