bug#43420: icecat causes pulseaudio to crash

Hi Nathan, Nathan Dehnel writes: > Removing ~/.config/pulse fixed it, That's good! > I think because it removed a config file that was loading a couple of > modules. Can you verify that hypothesis by adding back the config file(s), without any database files, restarting pulseaudio and trying a

bug#43501: gst-plugins-bad cannot be built on linux-armhf, breaking qemu

Maxim Cournoyer writes: > This occurs on master (commit 679d5e6b3dcac4ee1f419c04b3719fead0bd9ee5). > > qemu-minimal is not impacted, but the fully-fledged qemu package > cannot be built, due to a dependency on gst-plugins-bad, which fails to > build like: It would be good to eliminate that depen

bug#43501: gst-plugins-bad cannot be built on linux-armhf, breaking qemu

Earlier, I wrote: > Ever since 'spice-gtk' was added, it has included *every* gstreamer > plugin package in its 'propagated-inputs'. On my private branch, I removed 'gst-libav', 'gst-plugins-bad' and 'gst-plugins-ugly' from the propagated-inputs of 'spice-gtk'. --8<---cut here

bug#43487: icecat store names in user profiles break bundled addons

Hi Andreas, Andreas Enge writes: > On Fri, Sep 18, 2020 at 02:48:34AM -0400, Mark H Weaver wrote: >> To temporarily fix these problems while retaining most of your user >> data, one option is to press the "Refresh IceCat…" button in >> . Choosing this option

bug#43610: IceCat segfault

m 68.12.0 to 78.3.0: commit c7011ff850420fdbe1319b3d218bd362f2f9d618 Author: Mark H Weaver Date: Sun Sep 6 21:47:33 2020 -0400 gnu: icecat: Update to 78.3.0-guix0-preview1 [security-fixes]. Includes fixes for CVE-2020-15673, CVE-2020-15676, CVE-2020-15677, and CVE-2020-15678. [...] Mo

bug#43610: IceCat segfault

Hi, raingloom writes: > It crashed immediately without any visible activity. Okay. > It does start up properly with a fresh profile. I'll try to bisect the > addons list later. In the meantime, to start IceCat 78 with your existing profile but with addons temporarily disabled, try running:

bug#43501: gst-plugins-bad cannot be built on linux-armhf

Hi Maxim, Apologies for the delayed response. Maxim Cournoyer writes: > Maxim Cournoyer writes: > >> Mark H Weaver writes: >> >>> --- a/gnu/packages/spice.scm >>> +++ b/gnu/packages/spice.scm >>> @@ -144,11 +144,8 @@ which allows users

bug#43610: IceCat segfault

Hi, raingloom writes: > On Sat, 26 Sep 2020 14:05:53 -0400 > Mark H Weaver wrote: > >> In the meantime, to start IceCat 78 with your existing profile but >> with addons temporarily disabled, try running: >> >> icecat -safe-mode >> >> That should

bug#43660: icedove: "guix build --source" should produce IceDove source

At present, "guix build --source icedove" simply returns the corresponding IceCat tarball. The addition of code from upstream Thunderbird, as well as the rebranding to "IceDove", is currently done within phases. It would be good to arrange for "guix build --source icedove" to return something mor

bug#43984: `--with-graft=...` doesn't work with packages of different length name/version

Hi Ludovic, Ludovic Courtès writes: > pkill9 skribis: > >>> All I’m saying is that nothing can be done when the new name is longer >>> than the old one: we just cannot graft. >> >> If a symlink is used though, it wouldn't matter if the new name is >> longer, the symlink would point to the new p

bug#44347: mingetty --no-clear is hard-coded

is the upstream default? Regards, Mark >From 61d0055493c46cdee178d0ffbbf15742de930028 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Sun, 1 Nov 2020 11:16:08 -0500 Subject: [PATCH] UNTESTED: gnu: mingetty-shepherd-service: Make 'clear-on-logout' configurable. Also ch

bug#44347: mingetty --no-clear is hard-coded

Here's a revised patch, still untested, that also updates the documentation. Mark >From 9229d0493cdbb521a2f7a821d47d60d2392b8447 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Sun, 1 Nov 2020 11:16:08 -0500 Subject: [PATCH] UNTESTED: gnu: mingetty-shepherd-service: Make &

bug#44453: MPEG-4 AAC decoder plugin is not installed

Leo Famulari writes: > On Wed, Nov 04, 2020 at 10:27:33PM +0100, musics--- via Bug reports for GNU > Guix wrote: >> To play a video with totem, I have this problem: >> >> An error occurred >> The playback of this movie requires a MPEG-4 AAC decoder plugin which is not >> installed. >> >> Wha

bug#44756: racket-7.9-src.tgz hash mismatch

Racket fails to build, due to a hash mismatch on the source tarball. Mark sha256 hash mismatch for /gnu/store/mnjlngcwv4lffn9xjf82m60dwcfmz2vd-racket-7.9-src.tgz: expected hash: 18pz6gjzqy6a62xkcmjanhr7kgxpvpmc0blrk4igz8ldcybz44if actual hash: 0gmp2ahmfd97nn9bwpfx9lznjmjkd042slnrrbd

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

In the 'lsof' test suite, the 'LTlock' test consistently fails on my system, possibly related to the fact that I use 'btrfs' for my local filesystems. Here's the relevant build log excerpt: --8<---cut here---start->8--- Optional tests: LTbigf ... OK LTdnlc ...

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

I should mention that 'gnome' depends on 'lsof' via the following dependency path (among others): gnome -> gnome-shell -> ruby-sass -> ruby-sass-spec -> ruby-terminfo -> ruby-rdoc -> ruby-rubocop -> ruby-parallel -> lsof Mark

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

Hi Tobias, Thanks for the super quick response and for reproducing the bug. > This looks like an upstream bug to me. Agreed. > Do you have time to file > one? We're using the upstream > since Victor Abell retired. I have time, but there's another problem:

bug#25504: icecat language packs

Hi, zimoun writes: > On Sat, 21 Jan 2017 at 16:12, ng0 wrote: >> We should include the language packages icecat provides. >> >> I haven't looked into this too much, and I'm not familar with >> application localization in Guix, if there are any mechanisms in >> place for this already. > > This o

bug#23874: [PATCH 1/2] profiles: Remove duplicates in manifest transactions.

Hi, Leo Prikler writes: > * guix/profiles.scm (manifest-transaction-effects): Delete duplicates in > install and remove. Let multiple upgrades and downgrades shadow previous > transactions of the same kind. > --- > guix/profiles.scm | 11 +++ > 1 file changed, 7 insertions(+), 4 deleti

bug#30027: core-updates: guile build hung during tests with defunct guile process

Hi, zimoun writes: > This old bug #30027 is about core-updates and Guile (2.2). > > <http://issues.guix.gnu.org/issue/30027> > > > On Mon, 08 Jan 2018 at 11:35, Mark H Weaver wrote: >> While building core-updates locally on my x86_64 system running GuixSD, >

bug#44906: Substitute requests fail if URL has trailing slash

Hi, Ludovic Courtès writes: > Hartmut Goebel skribis: > >> I propose fixing all places where string-append is used to join URLs, >> since joining URLs is not the same as string concatenation. We might >> restrict our algorithm to only joining a >> path.

bug#44808: Default to allowing password authentication on leaves users vulnerable

Hi, "Dr. Arne Babenhauserheide" writes: > To nudge them to secure their system, guix system reconfigure could emit > a warning that this is a potential security risk that requires setting > an explicit value (password yes or no) to silence. I think this is a good idea. Likewise, in the Guix ins

bug#45109: GNOME: unable to change alert "beep" sound since staging merge

Since the recent merge of the 'staging' branch into 'master' on 28 Nov 2020, I'm no longer able to configure the alert sound in GNOME. That's a pity, since I find the default "drip" sound extremely unpleasant. In more detail: To configure the alert sound, I first open GNOME Settings by clicking

bug#45109: GNOME: unable to change alert "beep" sound since staging merge

Hi Marius and Bengt, Thanks very much for your suggestions. I initially tried Marius's idea to revert the dconf update, which seemed to work, but now I find that I'm unable to reproduce the problem, even with my original post-staging-merge system where I first encountered it. I'm not sure what h

bug#44808: Default to allowing password authentication on leaves users vulnerable

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> "Dr. Arne Babenhauserheide" writes: >>> To nudge them to secure their system, guix system reconfigure could emit >>> a warning that this is a potential security risk that requires settin

bug#44808: Default to allowing password authentication on leaves users vulnerable

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Ludovic Courtès writes: > > [...] > >>> What do you think of the approach in >>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=aecd2a13cbd8301d0fdeafcacbf69e12cc3f6138>? &

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

Hi, Zhu Zihao writes: > Reproduce steps: > >guix environment --ad-hoc qbittorrent && cat > $GUIX_ENVIRONMENT/bin/qbittorrent > > > We can see the wrapper generated in qt-build-system doesn't extend > existing environment variable. Instead, it overrides them. > > It was discussed in > https:

bug#45109: GNOME: unable to change alert "beep" sound since staging merge

reopen 45109 thanks Earlier, I wrote: > I initially tried Marius's idea to revert the dconf update, which > seemed to work, but now I find that I'm unable to reproduce the > problem, even with my original post-staging-merge system where I first > encountered it. I spoke too soon. Now the problem

bug#45279: [core-updates] copy-recursively does not throw an error on missing directory

Ludovic Courtès writes: > Marius Bakke skribis: > >> On the 'core-updates' branch, using copy-recursively on a nonexistent >> directory does not cause a build failure. Instead an error is printed >> and the script continues: >> >> (copy-recursively "doesnotexist" output) >> [...] >> start

bug#22251: ghc-memory test suite fails on i686

Hi Simon, zimoun writes: > This bug is very old. And probably not relevant anymore. > > On Sun, 27 Dec 2015 at 14:35, Mark H Weaver wrote: >> The ghc-memory test suite has failed several times in a row on i686 with >> the same errors: >> >> http://hydra.gn

bug#45352: Same derivation listed twice in the output of "guix build --dry-run"

I've just observed that the output of "guix build -n " may contain duplicates, as witnessed by the following shell transcript in which "/gnu/store/c4wgkfsc209g954c56jdzy4wmn42688f-git-2.29.2.drv" occurs twice in the list of derivations that would be built. (This is my crude method of seeing how mu

bug#28490: Unable to abort 'make' with Ctrl-C while building .go files

Hi Simon, zimoun writes: > Digging in old bugs, I find bug#28490 about C-c to abort ’make’ when > compiling: > ><http://issues.guix.gnu.org/issue/28490> > > On Mon, 18 Sep 2017 at 01:38, Mark H Weaver wrote: >> It used to be that I could Ctrl-C to abort '

bug#30116: [PATCH] `substitute' crashes when file contains NUL characters (core-updates)

Hi, Maxim Cournoyer writes: > I was recently reminded of this bug by a new encounter; at last wrote a > test for your proposed fix, and it appear to work as intended! I've > committed it on your behalf in commit 485ac28235 on the core-updates > branch. Thanks for taking care of this Maxim, and

bug#27780: guix environment to build guile from git required excessive CPU time

Hi Maxim, Maxim Cournoyer writes: > Any update on this? If that's not an issue anymore, feel free to close > it, otherwise I'll do so in 2 weeks time. I haven't seen other reports of this, and I barely remember it. Also, I haven't used substitutes in years. I'm closing this bug. Thanks for w

bug#45174: ‘guix substitute’ doesn’t handle HTTP redirects

Hi Julien, Julien Lepiller writes: > Here is a patch to fix that issue. Since ci.guix.info now returns 200, > it's difficult to test the patch. [...] [...] > From f20e01f2a8df538519660772a7431b53d650d64f Mon Sep 17 00:00:00 2001 > From: Julien Lepiller > Date: Tue, 12 Jan 2021 18:07:25 +0100

bug#27447: pelican-quickstart produces files with store path shebangs

reopen 27447 thanks Hi Simon, zimoun writes: > On Fri, 18 Dec 2020 at 21:10, zimoun wrote: >> On Thu, 22 Jun 2017 at 12:35, ng0 wrote: > >>> In a pelican directory after running pelican-quickstart: >>> >>> egrep -nr "store" >>> … >>> pelicanconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvx

bug#27447: pelican-quickstart produces files with store path shebangs

Hi Simon, zimoun writes: > First, one key point is the dates… > >>> On Fri, 18 Dec 2020 at 21:10, zimoun wrote: On Thu, 22 Jun 2017 at 12:35, ng0 wrote: > > …so more than 3 years without any comment. That a bug has been neglected for years does not imply that it's no longer a bug, or tha

bug#46016: broken Proof-General (emacs front-end to Coq)

l Emacs as being an instance of Proof General. Mark >From a33bc91ac1327e3bcad335bb2eb84abaf7b785cb Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Tue, 7 Apr 2020 05:39:41 -0400 Subject: [PATCH] LOCAL: gnu: proof-general: Improve packaging. * gnu/packages/coq.scm (proof-gener

bug#45179: qutebrowser stuck at Cloudflare 'browser checks'

ben--- via Bug reports for GNU Guix writes: > I'm also having similar issues accessing gitlab.com with IceCat. > Installing the User Agent Switcher and setting to "Linux / Firefox 82" > fixed this for me. > > For context I also tried starting IceCat up in safe mode and switching > tracking protec

bug#45109: GNOME: unable to change alert "beep" sound since staging merge

Hi Marius, Marius Bakke writes: > Mark H Weaver skriver: > >> Since the recent merge of the 'staging' branch into 'master' on 28 Nov >> 2020, I'm no longer able to configure the alert sound in GNOME. That's >> a pity, since I find the def

bug#46981: Severe Emacs shell mode performance regression in recent Linux-libre

FYI, for those who use Emacs shell mode (M-x shell), I wanted to give a heads-up about a severe performance regression in Linux-libre 5.10.20, and I suspect the same regression exists in 5.11.3. For details, see the bug report I submitted to the Emacs developers, here:

bug#46981: Severe Emacs shell mode performance regression in recent Linux-libre

Mark H Weaver writes: > FYI, for those who use Emacs shell mode (M-x shell), I wanted to give a > heads-up about a severe performance regression in Linux-libre 5.10.20, > and I suspect the same regression exists in 5.11.3. > > For details, see the bug report I submitted to the E

bug#46981: Severe Emacs shell mode performance regression in recent Linux-libre

Mark H Weaver writes: > I've since confirmed that reverting the two upstream commits mentioned > in <https://bugs.gnu.org/46978> fixes the performance regression. I've > attached a preliminary patch for Guix that reverts those upstream > commits for linux-libre@5.10,

bug#46981: Severe Emacs shell mode performance regression in recent Linux-libre

The problem was fixed upstream in Linux-libre 5.10.21, and presumably also in 5.11.4, so I'm closing this bug now. Mark

bug#46949: bug report

Leo Famulari writes: > On Mon, Mar 08, 2021 at 08:25:05AM +0100, Christoph Unger wrote: >> This file is empty, 0 bytes, so I can't attach it (gmail won't let me). I >> have de-installed guix in the meantime. Sorry that I can't help you >> further. > > Okay. It's definitely suprising for this file

bug#47028: Discourage single-character package names

Hi Tobias, Tobias Geerinckx-Rice writes: > Mark H Weaver 写道： >> Yesterday, an obscure package called "t" was added to Guix. We >> should reject such short package names in Guix unless there's a very >> compelling reason to keep them. > > I complete

bug#45109: GNOME: unable to change alert "beep" sound since staging merge

Earlier, I wrote: > I will soon switch back to dconf-0.36 to see if the problem returns. Shortly after switching back to dconf-0.36, the problem has indeed returned. So, in summary, the problem has *never* happened to me with dconf-0.34, but happens quite frequently with dconf-0.36. Mark

bug#47115: Failure building grub-img.png when reconfiguring

Leo Famulari writes: > On Fri, Mar 12, 2021 at 05:58:27PM -0500, Jack Hill wrote: >> This is with Guix bb5d84a0489a629d30bc2e978807caf20f46e329. My last >> successful reconfigure was with 80739ea480a7db667b83b45e3a08be740449f689. >> The output of the reconfigure run is attached. Reconfiguring wit

bug#47115: Failure building grub-img.png when reconfiguring

Hi Jack, Jack Hill writes: > On Fri, 12 Mar 2021, Jack Hill wrote: > >> On Fri, 12 Mar 2021, Mark H Weaver wrote: >> >>> Jack: is the problem reproducible, or could it have been a sporadic >>> failure? >> >> So far I've only reconfigured

bug#47121: [Mumi] Why does Mumi display my name as "Mark HWeaver"?

Hi Ricardo, Why does Mumi discard the space between my middle initial and my surname, e.g. in ? The default web interface for Debbugs doesn't do it. Also, where should Mumi bugs be reported? Thanks, Mark

bug#47141: Zabbix packages vulnerable to CVE-2021-27927

I'm forwarding this to bug-guix@gnu.org so that it won't be forgotten. Mark Start of forwarded message Subject: Zabbix packages vulnerable to CVE-2021-27927 From: Léo Le Bouter To: guix-de...@gnu.org Date: Wed, 03 Mar 2021 21:08:54 +0100 Would be

bug#47144: security patching of 'patch' package

I'm forwarding this to bug-guix@gnu.org so that it won't be forgotten. Mark Start of forwarded message Subject: security patching of 'patch' package From: Léo Le Bouter To: guix-de...@gnu.org Date: Wed, 10 Mar 2021 04:14:35 +0100 Hello! I could

bug#47142: squid package vulnerable to CVE-2021-28116

I'm forwarding this to bug-guix@gnu.org so that it won't be forgotten. Mark Start of forwarded message Subject: squid package vulnerable to CVE-2021-28116 From: Léo Le Bouter To: guix-de...@gnu.org Date: Wed, 10 Mar 2021 01:22:51 +0100 CVE-2021-28

bug#47143: pjproject package is vulnerable to CVE-2021-21375 and CVE-2020-15260

I'm forwarding this to bug-guix@gnu.org so that it won't be forgotten. Mark Start of forwarded message Subject: pjproject package is vulnerable to CVE-2021-21375 and CVE-2020-15260 From: Léo Le Bouter To: guix-de...@gnu.org Date: Thu, 11 Mar 2021 0

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

I'm forwarding this to bug-guix@gnu.org so that it won't be forgotten. Mark Start of forwarded message Subject: libupnp package vulnerable to CVE-2021-28302 From: Léo Le Bouter To: guix-de...@gnu.org Date: Sat, 13 Mar 2021 02:12:45 +0100 CVE-2021

bug#47115: Failure building grub-img.png when reconfiguring

Hi Jack, Jack Hill writes: > In an effort to clear out more of the potentially problematic store items, > I switched to an older generation of the system as well as guix pull and > user profiles. I then ran guix gc. At this point, I was running guix from > commit 373e5fc96724fd38bb1263e4af909

bug#47115: Failure building grub-img.png when reconfiguring

Hi Jack, Jack Hill writes: > On Sun, 14 Mar 2021, Mark H Weaver wrote: > >> (1) You must *delete* the "older" system generations and user profiles >>e.g. by running "guix system delete-generations" and "guix package >>--delete-generatio

bug#47089: error: make-session: unbound variable

Hi Jean, Jean Louis writes: > Running guix package manager on Hyperbola GNU/Linux-libre: > > [root@protected ~]# guix pull --no-substitutes -K > accepted connection from pid 876, user root > Updating channel 'guix' from Git repository at > 'https://git.savannah.gnu.org/git/guix.git'... > Buildi

bug#47115: Grafts without deduplication can lead to breakage in Guile (was: Failure building grub-img.png when reconfiguring)

retitle 47115 Grafts without deduplication can lead to breakage in Guile thanks Hi Jack, Jack Hill writes: > I believe that I have identified the problematic difference in my > operating system config between my working and non-working hosts. Thanks very much for your investigation. > I am f

bug#47115: Redundant library grafts leads to breakage (was: Failure building grub-img.png when reconfiguring)

retitle 47115 Redundant library grafts leads to breakage thanks Hi, I looked a bit deeper, and now I think I finally know what's going on. It turns out that the grafting process is creating two redundant variants of the replacement guile-cairo. All of the relevant information is in /gnu/store/07

bug#47121: [Mumi] Why does Mumi display my name as "Mark HWeaver"?

Arun Isaac writes: >> @Arun, does this sound familiar to you? > > Thanks for the bug report! It was indeed a regression in guile-email. I > have fixed it, and added a test. See > https://git.systemreboot.net/guile-email/commit/?id=ca0520a33c9042a68691d85c6849f88412ca8357 Thanks to both of you fo

bug#47185: grub2 package is vulnerable to CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233 and CVE-2021-3418

Hi Léo, Léo Le Bouter via Bug reports for GNU Guix writes: > NOTE: SecureBoot on GNU Guix is not something common at all, so the > urgency to fix this issue is not as great as if we explicitly > advertised support for SecureBoot. I would go further and question whether *anyone* is using SecureBo

bug#47186: python2 variants made through (package-with-python2 (strip-python2-variant ...)) don't inherit grafts

Hi Léo, Léo Le Bouter via Bug reports for GNU Guix writes: > As outlined by: > - > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a01bfa7deed1d556fc75ab5588517442054bc5a9 > - > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=db87d6ddafd26c5ad657178cf7fdab524d05c522 > > Two commits

bug#47222: Serious bug in Nettle's ecdsa_verify

FYI... Start of forwarded message From: ni...@lysator.liu.se (Niels Möller) To: nettle-b...@lists.lysator.liu.se Subject: ANNOUNCE: Serious bug in Nettle's ecdsa_verify Date: Tue, 16 Mar 2021 09:07:56 +0100 I've been made aware of a bug in Nettle's code t

bug#47253: network-manager shepherd services does not wait to be online

Hi, raid5atemyhomework via Bug reports for GNU Guix writes: > I have a small number of daemons that need access to the network at > startup. I have configured their Shepherd services to require > `networking`. > > However, to my puzzlement, I consistently find that they are unable to > access t

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

Ludovic Courtès writes: > Maxim Cournoyer skribis: > >> We should patch GnuTLS so that it also honors the SSL_* environment >> variables documented in the Guix manual. > > Note that (1) the SSL_* variables are originally from OpenSSL, and (2) > GnuTLS developers made the conscious decision to no

bug#47271: guix graph --path results in backtrace

This is at commit 1955ef93b76e51cab5bed4c90f7eb9df7035355a on the master branch, plus some local patches on my private branch which I suspect are irrelevant to this: --8<---cut here---start->8--- mhw@jojen ~$ guix graph --path gtk+ imagemagick Backtrace: In ice-

bug#47257: [PATCH 1/1] gnu: mariadb: Update to 10.5.9 [fixes CVE-2021-27928].

Hi Léo, Léo Le Bouter via Bug reports for GNU Guix writes: > * gnu/packages/databases.scm (mariadb/fixed): New variable. > (mariadb)[replacement]: Graft. > --- > gnu/packages/databases.scm | 33 + > 1 file changed, 33 insertions(+) > > diff --git a/gnu/packages/d

bug#47257: [PATCH 1/1] gnu: mariadb: Update to 10.5.9 [fixes CVE-2021-27928].

Mark H Weaver writes: > 'package/inherit' is usually the right thing when defining other kinds > of package variants, however. One addendum to this guideline: if the package variant you're defining overrides the 'source' field[*], it's probably pointless t

bug#47253: network-manager shepherd services does not wait to be online

Hi, Earlier, I wrote: >> How about leaving "networking" as it is now, and instead adding a new >> service called "network-online" or similar, that requires "networking" >> and then waits until a network connection is established? I withdraw my proposal for a separate "network-online" service. It

bug#47271: guix graph --path results in backtrace

Julien Lepiller writes: > Sounds like you might have stale .go files somewhere maybe? Indeed, make clean-go fixed it. Thanks, Mark

bug#47293: Failure of “guix lint -c archival icecat”

zimoun writes: > Indeed, there is a bug. Because the source of ’icecat’ raises a case > that is not handled by ’check-archival’ in (guix lint). > > Basically in the snippet: > > --8<---cut here---start->8--- > (match (lookup-content (content-ha

bug#47222: [Niels Möller] ANNOUNCE: Nettle-3.7.2

Start of forwarded message From: ni...@lysator.liu.se (Niels Möller) To: nettle-b...@lists.lysator.liu.se, info-...@gnu.org Subject: ANNOUNCE: Nettle-3.7.2 Date: Sun, 21 Mar 2021 10:24:11 +0100 I've prepared a new bug-fix release of Nettle, a low-level cr

bug#47257: [PATCH v3] gnu: mariadb: Fix CVE-2021-27928.

Léo Le Bouter via Bug reports for GNU Guix writes: > v3 tested and builds fine: > > $ ./pre-inst-env guix build mariadb > /gnu/store/f70jymwyfcnsghy4jg8caibci59p8rgq-mariadb-10.5.8-dev > /gnu/store/cj3qym1x1jjh02m2g23cqpbhchrbmn6c-mariadb-10.5.8-lib > /gnu/store/mpb5bdf1vkwazqfmmwcvskdm50g191bg-m

bug#47231: sqlite package is vulnerable to CVE-2020-11655, CVE-2020-11656, CVE-2020-13434, CVE-2020-13435, CVE-2020-13630, CVE-2020-13631, CVE-2020-13632, CVE-2020-15358 and CVE-2020-9327

Léo Le Bouter via Bug reports for GNU Guix writes: > From b0f9566e9ff9a5f409a3fd4293c048ec58bc770d Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?L=C3=A9o=20Le=20Bouter?= > Date: Thu, 18 Mar 2021 07:09:10 +0100 > Subject: [PATCH] gnu: sqlite: Update to 3.32.3 [security fixes]. > > * gnu/packages/sql

bug#47405: Blender bogus RUNPATH entry

Leo Famulari writes: > I noticed this while building Blender: > > -- > starting phase `validate-runpath' > validating RUNPATH of 1 binaries in > "/gnu/store/zswz75ysalm105b774s2g2k6vq5g0jbc-blender-2.91.0/bin"... > /gnu/store/zswz75ysalm105b774s2g2k6vq5g0jbc-blender-2.91.0/bin/blender: > wa

bug#47418: [PATCH] gnu: imagemagick: Fix CVE-2020-27829.

Léo Le Bouter via Bug reports for GNU Guix writes: > * gnu/packages/patches/imagemagick-CVE-2020-27829.patch: New patch. > * gnu/local.mk (dist_patch_DATA): Register it. > * gnu/packages/imagemagick.scm (imagemagick/fixed): Apply patch to existing > graft. > --- > gnu/local.mk

bug#47418: [PATCH] gnu: imagemagick: Fix CVE-2020-27829.

Léo Le Bouter writes: > Thank you, let's get your better patch in then close this. I've now pushed those patches to 'master'. CVE-2020-27829 is fixed in commit bfc69d5e7c45eac865e231643b58396580afb231, so I'm closing this bug now. Thanks! Mark

bug#47458: Terrible UX upgrading Emacs in Guix

I just updated my Guix system, which included the Emacs update from 27.1 to 27.2. After "guix package -m mhw-manifest.scm" finished running (which takes a long time for me, since I don't use substitutes), and before I even noticed that it had finished, my existing Emacs session started misbehaving

bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

Hi Maxime, Maxime Devos writes: > On > $ guix --version >> guix (GNU Guix) 510e24f973a918391d8122fd6ad515c0567bf23e > > with > $ guix graph --type=references inkscape > > it can be seen inkscape retains the reference to imagemagick, > even though imagemagick is in native-inputs. I believe this

bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

Hi Efraim, Efraim Flashner writes: > It is the case for inkscape@1.0.2 I see now that I'm using an older version, although I would have preferred the newer one. I refer to the variable name 'inkscape' from my manifest file, and I expected that to point to the latest stable version. However, it

bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

Hi Leo, Leo Famulari writes: > On Tue, Mar 30, 2021 at 04:55:13AM -0400, Mark H Weaver wrote: >> I wonder if the 'inkscape' variable should be renamed 'inkscape/stable' >> (for use in packages such as 'dblatex/stable'), and then 'inkscape

bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

Hi Leo, Leo Famulari writes: > I didn't realize / remember that Inkscape was used that deep in the > package graph. I agree, we should delay this change, at least until a > rebuild cycle. The removal of inkscape@0.92.4 should certainly be delayed, but I see no reason why we couldn't immediately,

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

Pierre Neidhardt writes: > - The main recommendation for an easy fix without updating the scanner > is that we tweaked our build system to dump the store reference to a > separate ASCII file. Sounds good. I made a similar proposal in Dec 2018, earlier in this thread

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

Hi Ludovic, Ludovic Courtès writes: > What could have been nice is if there’s a way to mark specific strings > as being ASCII, or if there’s a “byte vector” data type compatible with > strings, for instance. Do we know that all strings containing store references will be representable in ASCII?

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

Pierre Neidhardt writes: > I'm not familiar with the grafting code, so anyone who is (Mark? Ludo?) > might be able to fix this much quicker than me! :) I'll think about what would be required to modify our grafting code to support UCS-4. Mark

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

. Mark >From 0fcfd804570fd1c07ffb1f6c176d6ec3430907df Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Fri, 2 Apr 2021 18:36:23 -0400 Subject: [PATCH] DRAFT: grafts: Add support for UTF-16 and UTF-32 store references. --- guix/build/graft.scm | 138 +-- tes

bug#47576: [security] ibus-daemon launches ungrafted subprocesses

Several processes on my Guix system load shared libraries from the *ungrafted* glib: specifically, all of the subprocesses of 'ibus-daemon'. The 'ibus-daemon' process itself seems to be properly grafted. However, its subprocesses are from an old, ungrafted build of 'ibus': --8<---cut

bug#47576: [security] ibus-daemon launches ungrafted subprocesses

Here's an obvious check that I should have included in my last message: --8<---cut here---start->8--- mhw@jojen ~$ guix gc --referrers /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22 /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22 mhw@jojen ~$

bug#47576: [security] ibus-daemon launches ungrafted subprocesses

Earlier, I wrote: > Looking for references to the old 'glib' was the *first* thing I > checked. I haven't yet checked anything else, so I don't know how > widespread this problem is. I looked for other ungrafted libraries loaded on my system, and I'm glad to report that I see no evidence of any g

bug#47576: [security] ibus-daemon launches ungrafted subprocesses

I wrote: > I still have no clue where the reference to that mysterious old version > (/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22) is coming > from. I found them: ~/.cache/ibus/bus/registry /var/lib/gdm/.cache/ibus/bus/registry On my system, those files include absolute pathnames

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

Pierre Neidhardt writes: > Wow, that was fast, thank you Mark! > > Any idea how I can test this, i.e. how I can force a graft? Just apply the patch to a git checkout of Guix, build it, and then use it to build anything you like, e.g. "./pre-inst-env guix build nyxt". With this patch applied, al

bug#47576: [security] ibus-daemon launches ungrafted subprocesses

Hi Julien, Julien Lepiller writes: > We should probably fix ibus so it regenerates its cache when it's a > different process. It could be as simple as using a subdirectory > computed from the absolute name of the ibus binary, maybe. Would you like to try? I won't be able to work more on this bu

bug#47359: IceCat shows ACE/Punycode instead of IDN

Hi Ludovic, Ludovic Courtès writes: > IceCat shows ASCII-compatible encoding (ACE, roughly Punycode) for > so-called internationalized domain names (IDNs) instead of displaying > them properly—e.g., instead of > . I see the same behavior,

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

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> With this patch applied, all graft derivations will be rebuilt, but >> *only* grafts. When it's ready (i.e. when it has better comments, >> docstrings, etc), this change is perfectly appropria

bug#47319: python-lxml is vulnerable to CVE-2021-28957

Leo Famulari writes: > On Mon, Mar 22, 2021 at 03:09:24PM +0100, Léo Le Bouter via Bug reports for > GNU Guix wrote: >> Has lots of dependents so I suppose it needs grafting? Is that useful >> and does it work for Python packages? > > Grafting Python packages is not something we've done in the p

bug#47614: [security] Chunked store references in .zo files in Racket 8

On my system, Racket 8.0 contains a *.zo file that contains a *chunked* store reference. As a result, it retains a reference to the ungrafted Gtk+, and therefore to the ungrafted glib, cairo, and libx11. The file is: /gnu/store/…-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/gtk/compil

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

Here's a revised draft of the patch, which updates the comments and refactors the code a bit to (hopefully) make it a bit more readable. Mark >From 6eec36e66d20d82fe02c6de793422875477b90d8 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Fri, 2 Apr 2021 18:36:23 -0400 Subject

bug#47614: [security] Chunked store references in .zo files in Racket 8

Hi Léo, Léo Le Bouter writes: > I think that probably replacing arbitrary paths in built binaries is a > risky and maybe unreliable engineering choice and that mechanisms > inside kernels should be preferred to give processes a different view > of the file system (retaining the path but changing

bug#47628: Epiphany fails to launch after webkitgtk-2.32.0 update

FYI, since updating to webkitgtk-2.32.0 (commit 3c5e1412e3ef769df8e4826d0aedabaa3aa0d631), epiphany fails to launch: no window appears, although GNOME Shell shows an empty outline in overview mode, as if there's a window but it has never been painted. When running 'epiphany' from the command line,

<    2   3   4   5   6   7   8   9   10   11   >