Hi Christopher and Maxim,
Hi, I've been having difficulties since the the recent linphone
updates. I know some work has been done on the package in recent
commits, so just a few minutes ago I ran
guix time-machine -- environment --ad-hoc linphone-desktop
christopher@theoden ~ [env]$ guix
Upstream bug filed: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47940
Here's some output when I launch qutebrowser from a terminal. It seems
like it may be using ALSA instead of pulse for some reason.
```
ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave
[14812:14812:0421/184051.727290:ERROR:alsa_util.cc(204)] PcmOpen:
default,No such file or
Hello,
Kei Kebreau writes:
> I've pushed the patch as-is to master.
Thank you.
> I was If you are able to provide a method to replicate the issues you
> speak of here, please message me and we can open a bug report.
OK noted.
Regards,
--
Nicolas Goaziou
Control: tags 44675 +patch
On 2020-11-15, Vagrant Cascadian wrote:
> Please consider a guix lint description/synopsis check for basic
> spelling, typo and rudimentary grammar issues.
...
> Many of these are likely to be caught by most spell checking routines;
> I'm not sure if there is anything
Hi,
Jack Hill skribis:
> Using guix ae5128e21eb7afa66bd7cfd7fd1bc5764d00663e, the cve lint
> check fails when fetching the CVE database as follows:
>
> $ guix lint -c cve hello
> fetching CVE database for 2021...
> Backtrace:
> 15 (primitive-load
On 4/2/21 10:44 AM, Nicolas Goaziou wrote:
Hello,
Kei writes:
How are you able to tell (aside from looking at the command line arguments)?
I'm unable to distinguish the startup processes using Emacs on Debian and Guix
even if I install "etc/emacspeak.sh" as the startup script instead of
Hi Guix,
Using guix ae5128e21eb7afa66bd7cfd7fd1bc5764d00663e, the cve lint check
fails when fetching the CVE database as follows:
$ guix lint -c cve hello
fetching CVE database for 2021...
Backtrace:
15 (primitive-load "/home/jackhill/.config/guix/current/bi…")
In guix/ui.scm:
Sorry for the slow response.
On Wed, Apr 21, 2021 at 12:38:58AM +0200, Ludovic Courtès wrote:
> Hi Florian,
>
> "pelzflorian (Florian Pelz)" skribis:
> > On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
> >> > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd
> > It
Here’s the paste, for posterity:
--8<---cut here---start->8---
This script installs GNU Guix on your system
https://www.gnu.org/software/guix/
Press return to continue...
[1618245319.405]: Starting installation (Mon 12 Apr 2021 12:35:19 PM EDT)
Empty Message
On Wed, Apr 21, 2021 at 04:24:18PM +, Ekaitz Zarraga wrote:
> This issue can be closed since: 47467 is merged
Feel free to close it.
Bugs are closed by sending mail to
This issue can be closed since: 47467 is merged
On Fri, Apr 02, 2021 at 11:33:57AM +0200, Mathieu Othacehe wrote:
>
> > ). Please consider running po4a-updatepo to refresh it.
> > Your input po file ./guix-manual.de.po seems outdated (The amount of
> > entries differ between files: 10012 is not 325
> > ). Please consider running po4a-updatepo
I can't copy-paste easily to my email client right now, so here's a paste. I'll
send the content later.
https://paste.debian.net/1194563/
Le 21 avril 2021 08:45:01 GMT-04:00, "Ludovic Courtès" a écrit :
>Hi Julien,
>
>Julien Lepiller skribis:
>
>> When installing Guix on a new machine
I ran into the same issue and agree with your conclusion that we
may not need build-sandbox-paths.
Attached a patch that removes the `build-sandbox-paths` option.
This causes nix to use the default value which seems to work fine.
>From 886410216c7b1fb6572e7cfdd83dcbd6836e78e4 Mon Sep 17
Hi all,
I’m continuing my testing of the 1.3.0 branch, and I’ve found that coreutil's
tests/tail-2/inotify-dir-recreate.sh fails on filesystems where tail detects
that it cannot use inotify safely (probably arising out of this check:
Leo Famulari skribis:
> On Tue, Apr 13, 2021 at 10:12:13AM +0200, Ludovic Courtès wrote:
>> Could you type ‘bt’ (backtrace) at the GDB prompt?
>
> It goes like this:
>
> --
> Using host libthread_db library
> "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1".
>
Hi Julien,
Julien Lepiller skribis:
> When installing Guix on a new machine (foreign distro), substitute were not
> properly set up:
>
> …
> Permit downloading pre-built package binaries from the project's build farm?
> (yes/no) yes
> /home/roptat/guix-install.sh: line 445:
>
Hi,
Carlo Zancanaro skribis:
> On 21 April 2021 2:38:56 am AEST, "Ludovic Courtès" wrote:
>>Sounds good?
>
> Sounds good, except I don't have commit privileges. Can someone else push
> it for me?
Oops! I adjusted the patch so it would apply to ‘master’, and followed
up with two commits:
Hi,
Bone Baboon skribis:
> Thank you
> Now when I do a `guix pull --no-substitutes` guile-git build
Awesome, thanks for checking!
Ludo’.
Am Mittwoch, den 21.04.2021, 02:35 -0500 schrieb bdju:
> On Wed Apr 21, 2021 at 2:30 AM CDT, Leo Prikler wrote:
> > That's quite an interesting observation. Could you tell me what DM
> > (gdm, sddm, sway) you're using?
idiot thinking sway is a DM and not a WM.
> >
> > The gnome-keyring PAM
On Wed Apr 21, 2021 at 2:30 AM CDT, Leo Prikler wrote:
> That's quite an interesting observation. Could you tell me what DM
> (gdm, sddm, sway) you're using?
>
> The gnome-keyring PAM service works by adding an auto_start login
> entry, that refers to gnome-keyring's
>
Am Mittwoch, den 21.04.2021, 01:49 -0500 schrieb bdju:
> On Tue Apr 6, 2021 at 1:55 AM CDT, Leo Prikler wrote:
> > gnome-keyring-service is not a shepherd service. It is a pam
> > service,
> > that ensures your login keyring (if it exists) is unlocked when you
> > log
> > in. That's all it does.
>
On Tue Apr 6, 2021 at 1:55 AM CDT, Leo Prikler wrote:
> gnome-keyring-service is not a shepherd service. It is a pam service,
> that ensures your login keyring (if it exists) is unlocked when you log
> in. That's all it does.
>
> `ps x | grep gnome-keyring` should have a non-empty output. Mine
>
Problem is gone for me now. (78.6.0)
26 matches
Mail list logo
