bug#47628: webkitgtk-2.32.0 is broken on my system

On Wed, Apr 07, 2021 at 09:35:48AM +0200, Guillaume Le Vaillant wrote: > Mark H Weaver skribis: > > > retitle 47628 webkitgtk-2.32.0 is broken on my system > > thanks > > > > Mark H Weaver writes: > > > >> FYI, since updating to webkitgtk-2.32.0 (commit > >> 3c5e1412e3ef769df8e4826d0aedabaa3aa0d

bug#33848: Store references in SBCL-compiled code are "invisible"

Hi Mark, Mark H Weaver skribis: > From 6eec36e66d20d82fe02c6de793422875477b90d8 Mon Sep 17 00:00:00 2001 > From: Mark H Weaver > Date: Fri, 2 Apr 2021 18:36:23 -0400 > Subject: [PATCH] DRAFT: grafts: Support rewriting UTF-16 and UTF-32 store > references. > > * guix/build/graft.scm (replace-st

bug#47325: [PATCH] gnu: newlib-nano: Fix nano lib and header paths

From: Morgan Smith * gnu/packages/embedded.scm (newlib-nano-arm-none-eabi)[arguments]: Hard link library files from *.a to *_nano.a. Hard link newlib.h to a common location. --- I CC'd Efraim because they commited my last gcc-arm-none-eabi patch. I hope that's ok. I'm not really sure who is resp

bug#47654: electron-cash fails to start

The electron-cash program fails to start and prints the following error: --8<---cut here---start->8--- Traceback (most recent call last): File "/gnu/store/34h2k23x2yzm8gycbxkjmq7aqnlzmi7x-electron-cash-4.2.4/bin/.electron-cash-real", line 96, in from el

bug#47655: QML2_IMPORT_PATH does not work in a profile

Hello Guix, When setting up a profile (via 'guix environment', for example) to develop a Qt application, the search paths set by qtbase point to the environment profile, which is a forest of symbolic links. Apparently this doesn't play well with at least QML2_IMPORT_PATH: the Qt application built

bug#47628: webkitgtk-2.32.0 fails to launch without /usr/bin/env

retitle 47628 webkitgtk-2.32.0 fails to launch without /usr/bin/env thanks Hi Efraim, Efraim Flashner writes: > It "works" for me on bb4f47a7f614eea78a8c8a0d3e5fc55bf4e52646, using Guix > System with Enlightenment. I get errors about not committing changes to > dconf and I'm unable to change set

bug#47628: webkitgtk-2.32.0 fails to launch without /usr/bin

retitle 47628 webkitgtk-2.32.0 fails to launch without /usr/bin thanks Earlier, I wrote: > That's it! I have /bin/sh but not /usr/bin/env. Adding /usr/bin/env > fixes the problem for me. Actually, it suffices for /usr/bin to exist as an empty directory. /usr/bin/env is never actually used.

bug#47628: webkitgtk-2.32.0 fails to launch without /usr/bin

I suspect that the relevant bit that needs to be changed is line 779 of the following file in the webkitgtk-2.32.0 source code: Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp Most likely, that line can simply be deleted. Here's the relevant excerpt, with line 779 marked by "==>":

bug#47655: QML2_IMPORT_PATH does not work in a profile

Here's a backtrace which shows where the problem occurs exactly: --8<---cut here---start->8--- $ gdb --args install/client-qt/bin/jami-qt --debug GNU gdb (GDB) 10.1 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

bug#47647: Feature request: Make guix communicate over Hidden Services

Hi There, I hope to see guix has the ability to communicate over Tor (not TLS over Tor, but Tor-Tor (client-server), Something similar to how apt doing with apt-transport-tor https://packages.debian.org/buster/apt-transport-tor This is mitigate the security problems of clearnet DNS,TLS and so

bug#42292: committer.scm: Add support for new package definitions

This is implemented in commit c8c3afe8485bd614692f13e1e8a4200136da1302 and the changes that follow it. -- Ricardo

bug#45187: git download defaults to origin/master

Hi, I’d just like to say that I successfully used Kyle’s first patch to get past the problem. Thank you! I’m a bit lost: is there something we need to decide on to move this forward? (The issue has become a bit more pressing as origin/main is the new default on Github since a while.) -- Ricar

bug#47634: Accompany .asc and .DIGESTS keys for the ISO

On Wed, Apr 07, 2021 at 05:42:40AM +, bo0od wrote: > Hi There, > > I see there is only .sig provided: > > https://guix.gnu.org/en/download/ > > Its better to provide more than one way of verification e.g: Why?

bug#47660: Add link to the ticket when someone reply

Hi There, When someone reply to my ticket and receive the message through email there is no URL included to the ticket, Which mean if i forgot what i have wrote before then i need to go and see what was the conversation by using ticket title in gnu bug which not nice. Please add URL of the t

bug#47634: Accompany .asc and .DIGESTS keys for the ISO

This is nicely written by Qubes documentation: https://www.qubes-os.org/security/verifying-signatures/ Leo Famulari: On Wed, Apr 07, 2021 at 05:42:40AM +, bo0od wrote: Hi There, I see there is only .sig provided: https://guix.gnu.org/en/download/ Its better to provide more than one way

bug#47662: Replace/Remove UUID request in config.scm

Hi There, When someone taking the manual-cli installation of GuixOS, And reaching where he will fill the config.scm, Parts of it really annoying to fill like UUID. If possible change it to the partition name only like sda1,xvda1..etc and let guix take the needed uuid from there (or any other

bug#47660: Add link to the ticket when someone reply

On Thu, Apr 08, 2021 at 05:38:59PM +, bo0od wrote: > Hi There, > > When someone reply to my ticket and receive the message through email there > is no URL included to the ticket, Which mean if i forgot what i have wrote > before then i need to go and see what was the conversation by using tick

bug#47633: Provide direct download to .iso

On Wed, Apr 07, 2021 at 05:31:57AM +, bo0od wrote: > I see that guix compress its image here: > > https://guix.gnu.org/en/download/ > > Which im not sure why (I dont see any known project doing that), The reason is to save bandwidth. > But regardless to the reason behind it this is actually

bug#47632: Extracting guix.iso.xz with Xarchiver will give damaged .iso

On Wed, Apr 07, 2021 at 05:27:49AM +, bo0od wrote: > I have just tested to extract guix.iso.xz using Xarchiver and tried to > install guix.iso on a vbox, The image wont be readable/identified for > installation. Thanks for the report. I installed Xarchiver and used it to extract the iso.xz to

bug#47225: QEMU warning about performance

On Tue, Apr 06, 2021 at 08:42:38PM -0400, Maxim Cournoyer wrote: > I hope I'm timely; I've made a revised version of the patch, that should > cover more cases (and actually uses 100 MiB rather than 1 MiB :-)). > > Thank you, > > From eb600c4ffbc8016709db9471f9dc0be1d60167a7 Mon Sep 17 00:00:00 2

bug#47664: CRAN importer does not parse “Remotes” field.

The CRAN importer can be used to import packages from CRAN and Bioconductor, but also from arbitrary git and hg repositories. Especially for code published as a git/hg repository the “Remotes” field of the DESCRIPTION file can be important. The bedtorch[1] package, for example, has a DESCRIPTION f

bug#47633: Provide direct download to .iso

Well, providing a .iso with compression would hopefully be similar to .iso.xz, and it would allow us to provision guix directly in gnome-boxes etc, that rely on osinfo-db (we have guix there, but no URL because of the extension). Le 8 avril 2021 14:50:58 GMT-04:00, Leo Famulari a écrit : >On We

bug#47569: ‘qt-build-system’ retains too many references via wrappers

Hi! Pushed fix as c5fd1b0bd362f8b8578a76a26a65ba5d00d48992. Maxim Cournoyer skribis: >> Seeing a growing number of packages require a custom wrap phase for >> qtwebengine, I think the following additions could make sense to be >> incorporated as part as this Qt-world rebuild: [...] >> modifie

bug#47569: ‘qt-build-system’ retains too many references via wrappers

Maxim Cournoyer skribis: > Thanks for the patch! I built jami-qt with it; the closure size was > reduced from 2.7 GiB to 2.2 GiB (there's probably more to do, but it's a > good start!). It seems to work just as well as before the change, from > a cursory look. Regarding the closure size, the t

bug#42129: guix-install.sh does not add build users to kvm group

On Mon, Jun 29, 2020 at 10:01:54PM +0200, Marius Bakke wrote: > guix-install.sh should add the build users to the 'kvm' group if present > so that commands that require use of KVM can succeed. Here is a patch (untested) that makes sure a 'kvm' group exists and adds it to the guixbuilders' groups.

bug#47634: Accompany .asc and .DIGESTS keys for the ISO

On 9 April 2021 3:34:20 am AEST, bo0od wrote: >This is nicely written by Qubes documentation: > >https://www.qubes-os.org/security/verifying-signatures/ From that page: > If you’ve already verified the signatures on the ISO directly, then verifying > digests is not necessary. Which implies

bug#42129: guix-install.sh does not add build users to kvm group

On Thu, Apr 08, 2021 at 06:38:59PM -0400, Leo Famulari wrote: > On Mon, Jun 29, 2020 at 10:01:54PM +0200, Marius Bakke wrote: > > guix-install.sh should add the build users to the 'kvm' group if present > > so that commands that require use of KVM can succeed. > > Here is a patch (untested) that m

bug#47627: syncthing package is vulnerable to CVE-2021-21404

On Tue, Apr 06, 2021 at 06:51:47PM -0400, Leo Famulari wrote: > Yeah. Given this report, we could also just build Syncthing with the > bundled source code, which is freely licensed. I've attached the patch. From 86a8d8d9f628ba8dde5d5e3382e56bf83dd4fb1b Mon Sep 17 00:00:00 2001 From: Leo Famulari

bug#47140: libupnp package vulnerable to CVE-2021-28302

Fixed by 2b605ef3b145ec136530f08ee7aa27382aa64b46 signature.asc Description: This is a digitally signed message part

bug#47644: Acknowledgement (guix on foreign distro won't upgrade, stuck on old commits)

Well, I figured out my issue. I had created backup files manifest.scm and channels.scm and put them in the ~/.config/guix directory for storage. Turns out that these files, or at least the channels one, get read and used automatically by `guix pull`. I have moved those files to a different dir

bug#45187: [PATCH] git: Update cached checkout to the remote HEAD by default.

Ricardo Wurmus writes: > I’m a bit lost: is there something we need to decide on to move this > forward? I guess the main open question is whether to rework things to use revparse-single as Marius suggested. And if we don't, another question (raised by me) is whether there's a better approach th

bug#47667: rust-rav1e-0.4 fails to build

While looking into upgrading the rav1e package, I noticed a new rust-rav1e-0.4.0 package. However, it fails to build, like this: -- starting phase `package' Packaging rav1e v0.4.0 (/tmp/guix-build-rust-rav1e-0.4.0.drv-0/rav1e-0.4.0) error: failed to prepare local package for uploading Caus

bug#47667: rust-rav1e-0.4 fails to build

I got it building with 29a6c361492b18bcb0f6d2517d010a1b48441521, adding some inputs that the rav1e package also has. Maybe we should merge these packages?