It seems to be working for me now.
Hi guix! Cannot build python-jupyter-client package without a
substitute. I will try to resolve this issue on my own. But I think
it's right to let you know that building the package fails on the
check phase with many errors like this:
For more information see
https://pluggy.readthedocs.io/en/stab
I came across two bugs in gnu/services/pm.scm in tlp-configuration.
1. disks-devices should be disk-devices, because the name after
serialization, DISKS_DEVICES, is not recognized.
https://linrunner.de/tlp/settings/disks.html#disk-devices
2. ahci-runtime-pm-on-ac? and ahci-runtime-pm-on-bat? shou
deletions(-)
Thanks, I think that is a great addition to the manual.
--Adam
Hi Liliana,
On 6/23/24 03:39, Liliana Marie Prikler wrote:
Am Samstag, dem 22.06.2024 um 19:52 -0500 schrieb Adam Porter:
Hello,
Today an emergency bugfix release was made of Emacs v29.4. It fixes
an important security vulnerability.
Note: Security bugs should go to guix-security instead
would
be restored for packages installed outside of Guix, but that's what
bug#71725 is about.)
Thanks,
Adam
e to get native-compilation support,
keeping it updated with Emacs's master branch at the time. It would be
helpful if that could still be used by users rather than having to wait
for an update to the package definition, especially in a case like this.)
Thanks for your work on Emacs in Guix.
--Adam
ated Guix users, it seems to have regressed for those of
us who are less "pure" Guix users, who need more flexibility, and who
have enjoyed such in the past.
Thanks,
Adam Porter
Hi,
FYI, I just filed bug#70153, which is related, about the "guix show" /
"guix package --show" command.
https://issues.guix.gnu.org/70153
--Adam
can run "apt-cache policy PACKAGE" to
see output like:
PACKAGE:
Installed: X.Y-1~deb11u1
Candidate: X.Y-1~deb11u1
Which makes it easy to compare them.
Thanks for your work on Guix.
--Adam
Hi,
Since Emacs 29.1 was just released, I tried to install it with:
guix install emacs-next --with-commit=emacs-next=emacs-29.1
This builds and installs without error, and it runs, but when Emacs
tries to native-compile Elisp libraries at startup, I get these errors
in the "*Warnings*" buff
FYI, I hacked together a new package definition, updating the emacs-next
one to build 29.1 from the release tarball, and after installing it,
everything seems to work, including native compilation.
I don't know enough about Guix to understand why using "guix install"
with the package transform
I see why no is add for default the distrobox repositorie but i would
like add debian main in distrobox, but i not see how why in others
distros not is necessary add repositories in distrobox
It's because podman doesn't have the configuration files it needs.
Distrobox doesn't provide a container
Hello bdju,
The build failure you reported is fixed in this patch, but it hasn't been
merged yet into guix:
https://issues.guix.gnu.org/62897
Looking at the vala source code, we can bootstrap the current version
from 0.39.5.8, which appears to be between release cycles – 0.39.6
already requires it, whereas 0.39.5 bootstraps from 0.25.1. I'm not
sure how to get 0.25.1 to build from source, though. The code in vala-
bootstrap does not a
I think we’ll have to add a parameter to ‘spawn-command’ to specify
environment variables.
Ludo’.
If you do this, can you add an #:append? flag which adds environment
variables to the inherited environment instead of specifying the
variables declaratively? It can be #f by default.
It would be
Referenced commit is only 6 commits behind, and there aren't any
breaking changes. Therefore, for testing purposes, I wrote a custom
bitlbee-discord package definition to publish on my channel after
reporting this bug. Since then, I have been chatting with my colleagues
all the time. In other words
I'm trying to configure bitlbee-discord in order to write on Discord
using ERC in Emacs. Unfortunately, every time I open connection to
Discord, this error is thrown:
discord - Login error: Failed to switch to websocket mode
Actually, it is a well-known issue caused by breaking changes in the new
I have just found a workaround. Simply add --without-tests=cpplint to
you command, for example:
guix package -i emacs-flycheck-cpplint --without-tests=cpplint
However, it is not a solution at all, it is still a workaround.
signature.asc
Description: PGP signature
Since I moved to Guix distribution on the 1st of January (btw, good
move), compiling cpplint@1.4.5 has always failed. More specifically,
errors are triggered by pytest during the check phase.
Some of relevant lines extracted from the log:
E AssertionError: ('Lists differ:
[\'src/chrome_content
Last night I installed the GNU Guix distribution to my dual-core
laptop. I prepared myself for two days of building qtwebengine, but
actually the substitution worked!
I haven't tested how the substitution wil behave on upgrade, but I don't
see why it wouldn't work. Therefore, it appears the issue
On Th, Oct 21, 2021 at 22:00, Leo Famulari wrote:
> I think that should be enough, even for qtwebengine / Chromium!
Actually, I have been building qtwebengine@5.15.2 recently, and the
building process definitely took more RAM space then. The largest
increase in memory demand occurred at 73% ---
hi everyone! i cannot type cyrillic chars in games (for example in xonotic). it
refuses to print out any chars after i change layout
log attached
nam4c9d1faq8rqm7syaqn470nbmzq9-wesnoth-1.14.14.drv.bz2
Description: application/bzip
hi everyone! tried to use obs in guix system. it has (as i think) a problem.
when i install obs in my user profile and run it - it runs but without any
icons. but if i run it from obs env - it works with all fancy icons.
Great!
Thanks for looking into it.
On Wed, Sep 2, 2020 at 3:22 pm, GNU bug Tracking System
wrote:
Your bug report
#43039: Vanilla GUIX 1.1.0 reconfigure fails on nss-certs
which was filed against the guix package, has been closed.
The explanation is attached below, along with your original
Computing Guix derivation for 'x86_64-linux'... /Backtrace:
In ./guix/store.scm:
2026:24 19 (run-with-store # _
#:guile-for-build _ #:system _ #:target _)
1860:8 18 (_ _)
In ./guix/gexp.scm:
243:18 17 (_ _)
1061:2 16 (_ _)
921:2 15 (_ _)
782:4 14 (_ _)
In ./guix/store.scm:
1
ption presented itself.
The only other change was enabling sshd, but regardless the issue
presents itself.
That should be enough to replicate, otherwise I'll be able to assist
further when I have my system back up.
Cheers,
Adam
> > $ sudo guix system reconfigure /etc/config.scm
> &g
tps://issues.guix.gnu.org/37662>
Error:
$ guix pull
Migrating profile generations to '/var/guix/profiles/per-user/adam'...
Updating channel 'guix' from Git repository at '
https://git.savannah.gnu.org/git/guix.git'...
$ sudo guix system reconfigure /etc/config.scm
guil
Hi everyone,
https://ci.guix.gnu.org/search/latest/image?query=spec:guix-master+status:success+system:x86_64-linux+hurd-barebones-disk-image
returns 504
I installed Guix into my system, and I've been enjoying using it.
However, I found that, after installing it, when I logged out and back
in, and then started Emacs, Emacs could no longer see my system's info
pages (including Emacs's own info pages). I found that the Emacs
variable Info-directory-l
Okay, here's what happened:
1. I found a bug in Guix that I wanted to report.
2. I checked the manual, which directed me to https://issues.guix.gnu.org/.
3. That page directed me to "submit your patches or email
bug-guix@gnu.org to open a new issue." There were no further
instructions, so I gu
My root device is on NVMe.
In my current kernel config CONFIG_NVME_CORE is set to a module, which is
included in my initrd.
However upstream defconfig has been changed to CONFIG_NVME_CORE=y
When trying to guix reconfigure my system, building the operating system
fails in check-device-initrd-modu
l...@gnu.org (Ludovic Courtès) writes:
> Adam Van Ymeren skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Hi,
>>>
>>> Jelle Licht skribis:
>
> [...]
>
>>>> It seems that the bundled copy of jemalloc in the rustc rep
l...@gnu.org (Ludovic Courtès) writes:
> Hi,
>
> Jelle Licht skribis:
>
>> 2017-11-30 23:41 GMT+01:00 Adam Van Ymeren :
>>
>>> I haven't had time to dig in to this further, but in case anyone wants
>>> to fix rustc-1.16.0, it's broken after
I haven't had time to dig in to this further, but in case anyone wants
to fix rustc-1.16.0, it's broken after the upgrade of jemalloc to 5.0.1.
Reverting commit 475b99fa5cf402430aa93a40e406e854ad2ff6e4 which reverts
jemalloc back to 4.5.0 causes rustc to build successfully again. It has
been brok
Adding more information for future readers.
Turns out this is an upstream problem with the meson build system.
https://github.com/mesonbuild/meson/issues/1923
It was reported upstream but closed here:
https://bugzilla.gnome.org/show_bug.cgi?id=786248
l...@gnu.org (Ludovic Courtès) writes:
> If you haven’t already, could you report it upstream?
Will do. Thanks!
---
gnu/packages/gnome.scm | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 1ceba162b..031b30426 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -3641,6 +3641,12 @@ for application developers.")
(arguments
x27;t know enough about meson and ninja to figure out how
to fix this.
It also builds successfully if you force ninja to only use one thread.
This should probably be reported upstream. Other distros may not notice
this if valac picks up the system Totem-1.0.gir if Totem is already
installed.
-Adam
Hi there,
I'm running Guix 0.10.0 on a Debian stretch box, and I'd like to
upgrade. The box had not been booted for quite some time, hence the
version is somewhat old.
Running `guix pull`, I get the following:
Starting download of /tmp/guix-file.k6X14m
From http://git.savannah.gnu.org/cgit/guix
from
/gnu/store/9x9229j1sramg64qppmn87m2vy2jq4im-glib-2.52.2/lib/libgobject-2.0.so.0
#7 0x7f7189df7536 in g_proxy_resolver_gnome_init ()
from /home/adam/.guix-profile/lib/gio/modules/libgiognomeproxy.so
#8 0x7f71fb9432a9 in g_type_create_instance ()
from
/gnu/store/9x9229j1sramg64qppmn87m2vy2j
Mark H Weaver writes:
>
> I ran into the same problem at one point, and have applied the following
> patch to my private branch of Guix. Perhaps it should be applied to
> master.
Thanks, this patch works for me. Something like this upstream would be
nice :)
This can probably be unified with th
become ready, or
poll/sleep a few times if we fail to locate the device.
Thanks!
-Adam
45 matches
Mail list logo
