The documentation for transmission-daemon-service-type makes it sound like the
web interface should be up and running:
Once the service is started, users can interact with the daemon
through its Web interface (at ‘http://localhost:9091/’) ...
However, the daemon throws 404 when
The new pretty progress bars are quite nice. One issue I am ecountering,
however, is demonstrated in the snippet below:
オブジェクトにインデックスを付けています 71%
▕▉
オブジェクトにインデックスを付けています 74%
Some headway: It looks like anthyprefs sits under a different directory than
the engine script:
$ guix shell --pure ibus ibus-anthy
$ ls $GUIX_ENVIRONMENT/share/ibus-anthy/setup/
__pycache__/ _config.py anthyprefs.py main.py prefs.py setup.ui
$ ls
Hey guix,
Anthy has been giving me grief lately. It's not showing up in ibus-setup's list
of input methods.
After futzing around with ibus and gsettings for a while, I noticed this:
$ guix shell --pure ibus ibus-anthy
$ ibus read-cache | xml sel -t -c
Nothing like ACKing a year later!
This was almost certainly a local hardware issue. The machine this happened on
ended up showing progressively more mysterious behaviour that could not be
reproduced on other machines.
Feel free to close!
Ludovic Courtès wrote:
> Hi,
>
> Any update on this
Apparently, our curl is compiled without libssl2 support enabled,
$ curl scp://...
curl: (1) Protocol "scp" not supported or disabled in libcurl
This patch fixes that.
From 7d90bdbd6377ca29387d0482eefc5f051ff524ed Mon Sep 17 00:00:00 2001
From: "B. Wilson"
Date: Sat, 1 Oct 2022
Maxim Cournoyer wrote:
> I'll see if these Bashisms can be easily switched to POSIX variants,
> else I'll experiment with setting the shebang of the test scripts to
> bash.
Is there any particular reason to go this route?
Writing portable scripts is full of all sorts of pitfalls and ill-meaning
CONFIG_SHELL simply acts as a user override; it's not part of autoconf's core
logic. That role belongs to the SHELL macro, who's picks the first available of
the following:
- CONFIG_SHELL environment variable,
- SHELL environment variable, or
- /bin/sh
See autoconf's m4sugar/m4sh.m4 for the gory
> I think we’re not on the same page. Is AM_SUBST_NOTMAKE([SHELL]) really
> problematic? Is seems like there is a legitimate use-case that foreign
> distro users with /bin/sh = dash would want “guix shell -D guix -- make”
> to just work without workaround? We could use elaexuotee’s
>
"pelzflorian (Florian Pelz)" wrote:
> Thank you for getting back to the bug. I am in the same situation in
> that I use Guix System now. :D
>
> On Tue, Jun 21, 2022 at 09:20:28AM +0900, elaexuo...@wilsonb.com wrote:
> > so you could be able to sanity
> > check with something like
> >
> > $
> Wilson, could you confirm whether there's still something to fix here?
> Else, let's close this ticket and move on.
The original issue arose on a Void Linux foreign distro installation. I have
long since converted to Guix System, so cannot easily test the original
environment.
However, Void
> At least the question “is texlive-amsfonts broken” is definitively
> answered. This was what this issue was about, no? I’d rather keep the
> other issue separate.
Well, it's still broken in the sense that we're not able to typeset with
eufm10, no? That said, I guess it could make sense to
Ricardo Wurmus wrote:
>
> elaexuo...@wilsonb.com writes:
>
> > Ricardo Wurmus wrote:
> >> This is a problem with the modular TeX Live packages. The pk files are
> >> bitmap fonts. I found that adding texlive-cm-super to the union helps
> >> in that the bitmap variants of the CM fonts will
Hello Guix,
Installing nvme-cli into my user profile causes the following error to show at
bash login:
bash: 'intel': syntax error: operand expected (error token is "'intel'")
Starting bash with xtrace enabled places the error at
share/bash-completion/completions/nvme:11:
readonly
Ricardo Wurmus wrote:
>
> Ricardo Wurmus writes:
>
> > elaexuo...@wilsonb.com writes:
> >
> >> Attached patch on top of version-1.4.0 attempts to typset PDF docs for the
> >> metamath package. However, the below error results, which seems to indicate
> >> that the Euler fonts are not found,
Hello Guix,
Attached patch on top of version-1.4.0 attempts to typset PDF docs for the
metamath package. However, the below error results, which seems to indicate
that the Euler fonts are not found, despite texlive-amsfonts existing in the
texlive-updmap.cfg input.
Good day. Thanks for looking into this.
Ludovic Courtès wrote:
> Here’s how I tried (and failed) to reproduce the segfault:
>
> --8<---cut here---start->8---
> $ find /tmp/test
> /tmp/test
> /tmp/test/gnu
> /tmp/test/gnu/packages
>
Hey Guix,
Recently working on a package, I have been encounting intermittent segfault
during a build.
The segfault seems to only occur when I have some error in my code that causes
a crash, and the segfaults tend to cluster, appearing unexpectedly for a few
build attempts, and then disappearing
Hey Guix,
Recently, during in the middle of a `guix package -m .guix/manifest.scm`, my
machine had power failure. After rebotting, I simply reran the above and
it completed without error.
However, it appears that some of files in the store items are corrupt:
$ vim
vim: error while
Ricardo Wurmus wrote:
> This is a problem with the modular TeX Live packages. The pk files are
> bitmap fonts. I found that adding texlive-cm-super to the union helps
> in that the bitmap variants of the CM fonts will not be generated any
> more. More font packages may be needed in the union
Um. Apparently, I was the one failing. I just tried connecting again, and as
long as smbd has setuid, the qemu SMB share works as advertised.
Sorry for the false alarm.
Hey Guix,
Having trouble getting the Samba directory share in qemu to work as advertised:
$ qemu-system-x86_64 -netdev user,id=net0,smb=/share ...
Running something like the above with samba installed should spin up `smbd`;
however, this doesn't happen. I see no smbd processes started. Qemu
> I believe this comes from the “cache=loose” 9p mount option added in
> commit e0d96774dd48c29ccc4c90fea1f8f71850ab0879.
>
> Does the patch below help?
Yes, when no caching behaviour is specified in the guest, the problem
disappears. I also tried cache=fscache and see the exact same problem as
## Overview
When using --expose to mirror a path between host and guest, the guest mirror
fails to reflect file modifications from the host. However, file creation and
deletion are correctly propogated.
To pick up file modifications in the guest, it is sufficient to remount
mirroring 9p
Thank you, Ludo.
I am having trouble reproducing the error for some reason now. For a few days
guix pull invariable died in this way, but now it's getting past that point and
failing in a completely new way on SIGPIPE.
I will try to come back with something more useful.
Ludovic Courtès wrote:
Not exactly sure what to report, but:
$ guix pull
Building from this channel:
guix https://git.savannah.gnu.org/git/guix.git 9c6ea3c
Computing Guix derivation for 'x86_64-linux'... \guix pull: error: You
found a bug: the program
Resurrecting this, since it cause me significant grief, and is a simple
workaround which I believe is worth putting in the documentation. First, here
is a short summary of the problem:
Currently, some of our make rules contain bashisms. As of commit 408ae72c, this
ends up generating broken
"pelzflorian (Florian Pelz)" wrote:
> On Wed, Apr 15, 2020 at 06:06:25PM +0900, elaexuotee--- via Bug reports for
> GNU Guix wrote:
> > When building from git, ./bootstrap ends up generating (via automake)
> > several
> > Makefiles that set SHELL = /bin/sh. H
When building from git, ./bootstrap ends up generating (via automake) several
Makefiles that set SHELL = /bin/sh. However, some targets contain rules that
make use of bashisms. This leads to breakage when /bin/sh is something other
than bash.
In particular, I am building from a foreign distro
Playing around with the git repo and following along with:
https://guix.gnu.org/manual/en/html_node/Building-from-Git.html#Building-from-Git
make authenticate is erroring out for me:
$ make authenticate
...
Throw to `srfi-34' with args `(#)'.
It looks like the referenced key
Thank you for hand holding me through this, and thank you for all the
amazing dev work.
Cheers.
signature.asc
Description: PGP signature
> It could be an out-of-memory (OOM) condition: this build phase is
> unfortunately very demanding currently (at least 2 GiB or RAM I think).
> How much RAM do you have?
I think we have a winner. This is running on a VM and I just realized it
it only runs with 500MB of ram.
So, if I am
From a relatively fresh system install, guix pull fails with the following
error:
| @ build-started
/gnu/store/waisnnl9nbmlbpfwbn50pif79fsdknf9-guix-packages-base.drv -
x86_64-linux
/var/log/guix/drvs/wa//isnnl9nbmlbpfwbn50pif79fsdknf9-guix-packages-base.drv.bz2
2701
Backtrace:
33 matches
Mail list logo
