bug#31841: ./pre-inst-env guix system no longer works without ~/.config/guix

l...@gnu.org (Ludovic Courtès) writes: > Ricardo Wurmus skribis: > >> We could fix this by recording more of the configured >> GUILE_LOAD_{,COMPILED_}PATH and setting it up at runtime with >> pre-inst-env. Thanks, Ricardo. For now, I've changed my local 'guix' script to this: #!/bin/sh sou

bug#31841: ./pre-inst-env guix system no longer works without ~/.config/guix

flags 31841 + notabug close 31841 thanks Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> If there's a good reason to avoid implementing Ricardo's suggestion, I >> don't mind keeping my modified 'guix' script above, b

bug#31841: ./pre-inst-env guix system no longer works without ~/.config/guix

Hi, myg...@gmail.com writes: > Based on this thread I am now making guix like this ... > > guix environment guix --ad-hoc guile-sqlite3 --root=build-env -- make > [MAKECMDGOALS] Nice. Somehow I failed to know of the existence of the --root option. The "--ad-hoc guile-sqlite3" should no longer

bug#31380: grub fails to build on i686-linux

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Here's a proposed patch that I hope will fix the problem, although I'm >> unable to easily test it because I no longer use binary substitutes, and >> I have not yet buil

bug#31841: ./pre-inst-env guix system no longer works without ~/.config/guix

Hi, l...@gnu.org (Ludovic Courtès) writes: > myg...@gmail.com skribis: > >> Based on this thread I am now making guix like this ... >> >> guix environment guix --ad-hoc guile-sqlite3 --root=build-env -- make >> [MAKECMDGOALS] >> >> ... and using it like this ... >> >> source build-env/etc/profil

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

Hi Maxim, Maxim Cournoyer writes: > Mark H Weaver writes: > >> With the changes suggested above, I would have no objection to pushing >> this to core-updates. However, it occurs to me that we could handle the >> NUL case in a better way: >> >> Since the

bug#31970: epiphany: Strange "XXXXXXXXXXXXX..." entries in library RPATHs

Since the upgrade from epiphany-3.24.4 to 3.28.1 in commit fc5c5b92cf7a1f6d65079f3840df502edcf58f50, https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fc5c5b92cf7a1f6d65079f3840df502edcf58f50 which also changed the build-system from 'glib-or-gtk-build-system' to 'meson-build-system', warni

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

'meson-build-system' includes 'patchelf' as an implicit input for all packages that use it, and uses it from its 'fix-runpath' phase, sometimes directly and sometimes via (guix build rpath). 'patchelf' is a nasty hack which seems to only work on Intel-based systems. It certainly doesn't work on '

bug#31974: If a phase returns #f, a warning is issued, but the build continues

I just noticed that I made a mistake in commit d8a3b1b9e847d4a44d2695f95af77170d4d2788f, which changed 'gnu-build' in (guix build gnu-build-system) to issue a warning if a phase returns a value other than #t. The result is that if a phase returns a value other than #t, a warning is issued, but the

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

Hi Marius, Marius Bakke writes: > Mark H Weaver writes: > >> 'meson-build-system' includes 'patchelf' as an implicit input for all >> packages that use it, and uses it from its 'fix-runpath' phase, >> sometimes directly and sometimes vi

bug#31982: shaderc fails its test suite on all hydra-supported systems

shaderc fails its test suite on all systems supported by Hydra, but the builds succeed because the #f returned by meson-build-system's check phase is ignored, due to . https://hydra.gnu.org/build/2811833 (x86_64-linux) https://hydra.gnu.org/build/2811921 (i686-lin

bug#31982: shaderc fails its test suite on all hydra-supported systems

Hi Rutger, In commit 7f540654873a2761746bdc43be4727cad99b92c0, you updated 'sharerc' to upstream commit be8e087 and enabled tests. It turns out that it fails its test suite on all systems supported by Hydra, but the failure is effectively being ignored, because of . I

bug#31974: If a phase returns #f, a warning is issued, but the build continues

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> I just noticed that I made a mistake in commit >> d8a3b1b9e847d4a44d2695f95af77170d4d2788f, which changed 'gnu-build' in >> (guix build gnu-build-system) to issue a warning if a phase returns a

bug#31974: If a phase returns #f, a warning is issued, but the build continues

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> I grepped the build logs on Hydra from evaluation 110021 searching for >> the warning issued when a phase returns #f. Some of the build logs had >> been deleted, but of the builds whose logs are still p

bug#28211: Stack marking issue in multi-threaded code

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > I have a fix for some (most?) of the crashes we were seeing while > running multi-threaded code such as (guix build compile), and, > presumably, the grafting code mentioned at the beginning of this bug > report, although I haven’t checked yet.

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

severity 31971 important thanks Mark H Weaver writes: > Given that 'meson-build-system' is seeing increased usage in some > important packages, e.g. 'libinput' and several GNOME packages, this is > becoming an increasingly serious problem for non-Intel platforms. A

bug#28211: Stack marking issue in multi-threaded code

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> l...@gnu.org (Ludovic Courtès) writes: > > [...] > >>> I’m thinking we could perhaps add a compiler barrier before ‘vp->fp = >>> new_fp’ >>> statements, but

bug#28211: Stack marking issue in multi-threaded code

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> l...@gnu.org (Ludovic Courtès) writes: > > [...] > >>>> Indeed, we need something to ensure that the compiler won't reorder >>>> these writes. My recommendation wo

bug#28211: Stack marking issue in multi-threaded code

Hi Andy, Andy Wingo writes: > On Sat 30 Jun 2018 23:49, Mark H Weaver writes: > >>>> I should say that I'm not confident that _either_ of these proposed >>>> solutions will adequately address all of the possible problems that >>>> could occu

bug#32050: invoke (guix build utils) error reporting lacking

Hi Maxim, Maxim Cournoyer writes: > More problematic even, it seems "invoke" can't do everything that > "system*" can? > > For example, the following package builds fine: > > (define-public docbook-dsssl-doc > (package > (name "docbook-dsssl-doc") > (version "1.79") > (source (orig

bug#31925: 'guix substitutes' sometimes hangs on glibc 2.27

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > (+Cc: Andy as the ultimate authority for all these things. :-)) > > l...@gnu.org (Ludovic Courtès) skribis: > >> (let loop ((files files) >>(n 0)) >> (match files >> ((file . tail) >> (call-with-input-file file >>

bug#31925: 'guix substitutes' sometimes hangs on glibc 2.27

Hi, Andy Wingo writes: > On Thu 05 Jul 2018 05:33, Mark H Weaver writes: > >>> One problem I’ve noticed is that the child process that >>> ‘call-with-decompressed-port’ spawns would be stuck trying to get the >>> allocation lock: >>> >>> S

bug#32167: Kernel 'build' directory in the store is a broken symbolic link

Danny Milosavljevic writes: > On Mon, 16 Jul 2018 18:55:11 +0100 (BST) > wrote: > >> It would be good to keep the build directory though, since it's >> expected to exist, and it's easier to just download a module's >> source and compile it and test it. > > I agree. > > /run/booted-system/kernel/

bug#31319: ghc-case-insensitive: Duplicate 'inputs' field.

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Ping! > > I’d really like to apply the patch you posted in > > along with the corresponding package fixes. Yes, sorry for the long delay on this. I've been nervous about

bug#32229: Hydra evaluation failure: service 'ssh-daemon' requires 'loopback'

Hydra failed its most recent evaluation attempt for the 'master' jobset, with the following error: --8<---cut here---start->8--- considering jobset gnu:master (last checked 25842s ago) checking out Git branch master from https://git.savannah.gnu.org/r/guix.git I

bug#32229: Hydra evaluation failure: service 'ssh-daemon' requires 'loopback'

Mark H Weaver writes: > Hydra failed its most recent evaluation attempt for the 'master' jobset, > with the following error: [...] > srfi/srfi-1.scm:640:9: In procedure for-each: > Throw to key `srfi-34' with args `(# 'ssh-daemon' requires 'loopb

bug#32302: 01/03: gnu: glm: Update to 0.9.9.0.

Marius Bakke writes: > This is fixed in 1743172cdb420aafb2b417ee588e6d1bc66eebab, thanks for > reporting it! Thanks for the quick fix, Marius! Mark

bug#31974: If a phase returns #f, a warning is issued, but the build continues

Mark H Weaver writes: > I just noticed that I made a mistake in commit > d8a3b1b9e847d4a44d2695f95af77170d4d2788f, which changed 'gnu-build' in > (guix build gnu-build-system) to issue a warning if a phase returns a > value other than #t. > > The result is that if a

bug#32511: mariadb 10.1.35 fails to build on x86_64

l...@gnu.org (Ludovic Courtès) writes: > On berlin, mariadb 10.1.35 has one test failure (this is > /gnu/store/a5jm2hyalyblgjnxx5x3ly4fwvfivq5m-mariadb-10.1.35.drv, as > found in Guix commit b0cb92b2d43a2c4d5fa9b3f8c04c5732c60061e7, for > instance): FWIW, after staging was merged, I also ran into

bug#22629: Channels!

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Currently third-party channels are expected to provide nothing but > package modules. I'd like to say again that I have grave concerns that this could be the death-knell for long-term innovation in Guix. It's likely that whenever a change is p

bug#22629: Channels not needed for a stable branch (was: Channels!)

Hi, Alex Sassmannshausen writes: > My primary interest in channels at the moment comes from believing that > having a "stable" channel would be incredibly useful to increase > adoption rate of Guix. And for me. Konrad Hinsen writes: > Look at the wider Linux world: there are people who want to

bug#22629: Channels not needed for a stable branch

Konrad Hinsen writes: >> I also agree with you that we don’t need channels for providing a stable >> branch. The biggest obstacle to providing a stable branch is not >> technical, but it requires people maintaining it. > > Look at this from the opposite end: if you were interested in > maintaini

bug#32820: Some CSS not displaying in latest Icecat

Hi Chris, Christopher Lemmer Webber writes: > Overall very excited about the new Icecat being available! > > However, css is not displaying on some sites, and I'm not sure why. > Disable all extensions and try the following examples: > > https://addons.mozilla.org/en-US/firefox/ > https://gi

bug#32833: IceCat 60 showing sites as "insecure" despite using HTTPS

severity 32833 critical thanks Hi Mike, Mike Gerwitz writes: > Even if sites are using HTTPS, IceCat is still saying "This connection > is insecure" if you click on the "i" icon in the URL bar. This seems to > be a problem with every HTTPS site I visit. > > On the "Security" tab of the "Page In

bug#32840: linux-libre 4.18.9: shpchp is no longer a module (now: built-in)

Hi Nils, Nils Gillmann writes: > at taler we need shpchp as a module in the initrd. > > Before version 4.18.x, shpchp was a module we've build in guix' linux-libre, > you were able to just specify it for the initrd. > > With 4.18.9, this module became a compile-in/built-in (see linux > commit lo

bug#32833: IceCat 60 showing sites as "insecure" despite using HTTPS

Mark H Weaver writes: > To begin, I'm currently building IceCat using the bundled NSPR and NSS, > to see if that helps. Using the bundled NSPR and NSS works around the problem for me. I just pushed this change in commit 6d328879378fac9524000521f596fb5c68ed on 'master'.

bug#32820: Some CSS not displaying in latest Icecat

ct to affect this issue, namely: * 6d3288793..: Mark H Weaver 2018-09-25 gnu: icecat: Rebundle NSPR and NSS [security fix]. * 94e96f7f6..: Mark H Weaver 2018-09-24 gnu: icecat: Unbundle libevent, libogg, and libvorbis. * 257e32479..: Mark H Weaver 2018-09-23 gnu: icecat: Unbundle graphite2 and

bug#32840: linux-libre 4.18.9: shpchp is no longer a module (now: built-in)

Nils Gillmann writes: > at taler we need shpchp as a module in the initrd. > > Before version 4.18.x, shpchp was a module we've build in guix' linux-libre, > you were able to just specify it for the initrd. > > With 4.18.9, this module became a compile-in/built-in (see linux > commit log). I wan

bug#32873: Icecat 60 hides QR code of https://web.whatsapp.com

Hi Clément, Clément Lassieur writes: > Icecat 60 hides QR code of https://web.whatsapp.com. I need to use the > debugger to display it. It was working well with Icecat 52. This seems to be related to the "privacy.resistFingerprinting" setting in "about:config". This option is set to "true" by

bug#32916: font-awesome v5 build scripts are not free

Hi Leo, Leo Famulari writes: > We have a package of font-awesome, currently at version 4.7.0. > > It's a very simple package, installing the files generated by upstream > rather than trying to rebuild them. > > As of version 5, the tools used to build the generated files are not > free: > > http

bug#32916: font-awesome v5 build scripts are not free

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> I agree that version 5 of font-awesome does not meet the requirements of >> the FSDG, which states: >> >> A free system distribution should be self-hosting. This means that >&g

bug#32895: file progress reporter crashes on small files

Hi Ricardo, Ricardo Wurmus writes: > Downloading small files (such as cabal revisions) sometimes fails with a > backtrace like this: > > Starting download of > /gnu/store/plr3hf9gjdcg2qhi3x4k2wjm8zajqibc-ghc-cryptohash-md5-0.11.100.1-2.cabal > From > https://hackage.haskell.org/package/cryptoh

bug#32895: file progress reporter crashes on small files

And now I'm running into the same bug repeatedly while trying to test build security updates for IceCat, which involve downloading a great many small patches from Mozilla. Bah. Something is very broken here, and now it's interfering with my attempts to deploy critical security updates. I'm think

bug#32895: file progress reporter crashes on small files

I've applied the following temporary workaround to my private branch, to enable me to work on the IceCat security update. Mark --8<---cut here---start->8--- diff --git a/guix/status.scm b/guix/status.scm index c6956066f..8c6045a7d 100644 --- a/guix/stat

bug#32895: file progress reporter crashes on small files

I see now that this bug was already fixed while I sent several new messages about it. Oops. I should really make sure I've fetched email before responding. Sorry for the noise. Mark

bug#32877: Python-2 CVE-2018-1060 CVE-2018-1061 CVE-2018-14647 CVE-2018-1000802

Leo Famulari writes: > On Sat, Oct 06, 2018 at 06:53:36PM +0200, Marius Bakke wrote: >> From 2891a9acb7704c3397ef34fbb520b46936504422 Mon Sep 17 00:00:00 2001 >> From: Marius Bakke >> Date: Sat, 6 Oct 2018 18:50:47 +0200 >> Subject: [PATCH] gnu: python2: Add upstream security fixes. >> >> This

bug#32878: Python-3 CVE-2018-14647

Leo Famulari writes: > On Sat, Oct 06, 2018 at 04:51:07PM +0200, Marius Bakke wrote: >> From a60d655fd4dddb86e1c8134c675fb61af52b32af Mon Sep 17 00:00:00 2001 >> From: Marius Bakke >> Date: Sat, 6 Oct 2018 16:47:05 +0200 >> Subject: [PATCH] gnu: python: Fix CVE-2018-14647. >> >> * gnu/packages/

bug#33023: configure: GUIX_ASSERT_LIBGCRYPT_USABLE: command not found

When building the 'guix' package, or while running ./configure in a git checkout in an environment created by "guix environment guix", the following error occurs: ./configure: line 8083: GUIX_ASSERT_LIBGCRYPT_USABLE: command not found You can find the line above in the build logs on Hydra: h

bug#33023: configure: GUIX_ASSERT_LIBGCRYPT_USABLE: command not found

Mark H Weaver writes: > When building the 'guix' package, or while running ./configure in a git > checkout in an environment created by "guix environment guix", the > following error occurs: > > ./configure: line 8083: GUIX_ASSERT_LIBGCRYPT_USABLE: command no

bug#33030: Crash in progress-bar

Leo Famulari writes: > While updating my installed packages, Guix crashed as shown below. I > don't really know how to interpret it. > > $ guix --version > guix (GNU Guix) aa227b3be3d7728331a08dbd139c47c9b271dc23 > Copyright (C) 2018 the Guix authors > License GPLv3+: GNU GPL version 3 or later <

bug#33078: Attempt to build my GuixSD system now fails

When I try to build my x86_64 GuixSD system, based on my system configuration which I've not modified since May, it now fails: --8<---cut here---start->8--- mhw@jojen ~$ guix system build /etc/config.scm Backtrace: In srfi/srfi-1.scm: 592:17 19 (map1 (#< type

bug#33078: Attempt to build my GuixSD system now fails

Mark H Weaver writes: > When I try to build my x86_64 GuixSD system, based on my system > configuration which I've not modified since May, it now fails: Reverting commit acce0a474c1493ab18912bc46285248e4ccb0314 (services: wpa-supplicant: Extend to support configuration parameters) s

bug#32840: linux-libre 4.18.9: shpchp is no longer a module (now: built-in)

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Nils Gillmann writes: >> >>> at taler we need shpchp as a module in the initrd. >>> >>> Before version 4.18.x, shpchp was a module we've build in guix' li

bug#33280: Guix weather does not error nicely with 502 errors from hydra

swedebugia writes: > I did not change the default substitute-urls in 0.15 > > This is probably low priority. > > sdb@komputilo ~$ guix weather > computing 7,850 package derivations for x86_64-linux... > looking for 8,167 store items on https://mirror.hydra.gnu.org... > guix weather: warning: whil

bug#33297: Unable to build system, due to failure in raw-initrd

My attempt to update my GuixSD system to commit b20aef98a01923700f22ba471e4d2bb05765516b on the master branch resulted in the following failure, while trying to build raw-initrd. See below for the raw-initrd build log. Mark --8<---cut here---start->8---

bug#33297: Unable to build system, due to failure in raw-initrd

Mark H Weaver writes: > My attempt to update my GuixSD system to commit > b20aef98a01923700f22ba471e4d2bb05765516b on the master branch resulted > in the following failure, while trying to build raw-initrd. See below > for the raw-initrd build log. Reve

bug#33362: System tests stuck in "shepherd[1]: waiting for udevd..."

As I write this, there are two system test builds that have been stuck for many hours, endlessly printing "shepherd[1]: waiting for udevd...": https://hydra.gnu.org/build/3153725 https://hydra.gnu.org/build/3154365 They are both on i686-linux, and on the 'core-updates' branch, but with two di

bug#33362: System tests stuck in "shepherd[1]: waiting for udevd..."

Mark H Weaver writes: > As I write this, there are two system test builds that have been stuck > for many hours, endlessly printing "shepherd[1]: waiting for udevd...": > > https://hydra.gnu.org/build/3153725 > https://hydra.gnu.org/build/3154365 > > They are

bug#33410: Offloaded builds can get stuck indefinitely due to network issues

I just discovered that 4 out of 5 armhf build slots on Hydra have been stuck for 24 hours, apparently after the network connections to the build slaves were lost, possibly due to a temporary network outage. I've seen this kind of thing happen periodically since we switched to using guile-ssh for o

bug#33463: guix publish error on Hydra: fport_close: Bad file descriptor

FYI, I just spotted this output from "guix publish" on Hydra. Mark GET /sd34hpwkjdax611r4cqqk5rhna79sl9k.narinfo GET /ndbv402716xnhsy229m2mgx7lf415ank.narinfo GET /jj4ibyflqrd24xb16p7vsadj7nr3ik2k.narinfo GET /fxxba73sgq1r2vav5imj2wsp6cy4mqlj.narinfo GET /d38frkfi36nq10c0sss7fr8rnz2alhdn.n

bug#33542: Strange tarball download error on Hydra

On Hydra, the armhf builds for al variants of 'linux-libre-4.14.84' failed because the tarball download failed. See below for the build log. Strangely, it was unable to find the (guix base16) module. Any idea what went wrong here? I'll try restarting the builds. Mark --8<---

bug#33542: Strange tarball download error on Hydra

Mark H Weaver writes: > On Hydra, the armhf builds for al variants of 'linux-libre-4.14.84' > failed because the tarball download failed. See below for the build > log. Strangely, it was unable to find the (guix base16) module. I now see that 89f1fee8e788fc32d08583b4207c1

bug#33362: System tests stuck in "shepherd[1]: waiting for udevd..."

Mark H Weaver writes: > Mark H Weaver writes: > >> As I write this, there are two system test builds that have been stuck >> for many hours, endlessly printing "shepherd[1]: waiting for udevd...": >> >> https://hydra.gnu.org/build/3153725 >>

bug#33555: test.iso-image-installer.i686 got stuck after kernel oops

The most recent build of 'test.iso-image-installer.i686-linux', which was performed on hydra.gnunet.org, hit a kernel oops, and subsequently got stuck. https://hydra.gnu.org/build/3194778 Here's the kernel oops debugging output: --8<---cut here---start->8---

bug#33592: "herd restart term-tty2" caused *all* processes to be killed

After killing a Wayland 'gnome-session' that I had launched from the command-line on tty2, the login prompt did not return as it normally does. I decided to try "herd restart term-tty2" to see if that would help. That turned out to be a serious mistake. It caused TERM to be sent to all processes,

bug#33604: Backtrace in guix package -s

Hi Brett, Brett Gilio writes: > Hi all, When I run ex: `guix package -s emacs` it is presenting this > backtrace. It has been there for a few commits now. Does anybody have > thoughts on it? > > Backtrace: > In ice-9/boot-9.scm: > 829:9 19 (catch _ _ # …) > 829:9 18 (catch _ _ # …) > In

bug#33592: "herd restart term-tty2" caused *all* processes to be killed

Hi, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> After killing a Wayland 'gnome-session' that I had launched from the >> command-line on tty2, the login prompt did not return as it normally >> does. >> >> I decided to try

bug#43143: Building iwd on armhf triggers kernel panic

Vagrant Cascadian writes: > I've been getting kernel panics when i try to build iwd, a dependency of > network-manager. Which kernel package variant(s) and version(s) have you seen panic when building iwd? What hardware? Thanks, Mark

bug#43143: Building iwd on armhf triggers kernel panic

Hi Vagrant, Vagrant Cascadian writes: > On 2020-08-31, Vagrant Cascadian wrote: >> On 2020-08-31, Mark H. Weaver wrote: >>> Vagrant Cascadian writes: >>>> I've been getting kernel panics when i try to build iwd, a dependency of >>>> network-manag

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

Vitaliy Shatrov writes: > Hello again dear Guixen. > I use emacs-w3m as a browser on a single board computer. I want to read, > for example, issue #43159. > > I can read it on https://debbugs.gnu.org/43159. It's formatted properly, and > the patch is readable too. > > But the https://issues.

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

Earlier, I wrote: > I see similar problems with both 'lynx' and 'dillo' when remote CSS is > disabled. To be clear, Lynx doesn't have CSS support, so it's unable to properly render 'issues.guix.gnu.org'. Dillo can render it unless remote CSS is disabled. Mark

bug#38958: Timestamp out of range; substituting 2514-05-30 01:53:03.999999999

Hi, Ludovic Courtès writes: > The GNU make warnings come from this impenetrable function: > > --8<---cut here---start->8--- > FILE_TIMESTAMP > file_timestamp_cons (const char *fname, time_t stamp, long int ns) > { > int offset = ORDINARY_MTIME_MIN + (FILE_TI

bug#43138: Stack overflow in emacs 27 because of preloading emacs-seq

Hi Pierre, Pierre Langlois writes: > Mark H Weaver writes: > >> If 'emacs-seq' is included in Emacs 27, it seems to me that we should >> just delete it, unless there's something I'm missing. > > Agreed, I was curious if there was another reason for

bug#43138: Stack overflow in emacs 27 because of preloading emacs-seq

Pierre Langlois writes: > Replying with the bug on CC, I didn't realise your last email didn't > include it. I assume that was a mistake? Indeed, my mistake. I just resent my previous email to complete the record for this bug. > OK, pushed to master with 852ae64e11ef9107afabbdb307770f946376addd

bug#43093: Is Emacs 27.1 that breaks emacs-ess?

divoplade writes: > Is it possible to edit the title? Yes. To do so, send an email to 'cont...@debbugs.gnu.org' with the following two-line body: --8<---cut here---start->8--- retitle 43093 THE_NEW_BUG_TITLE_GOES_HERE thanks --8<---cut here---

bug#43228: r-v8 doesn't build since node 10.22 update

Hi Pierre, I'm quoting your message out of order to ease my reply. Pierre Langlois writes: > I'm afraid I broke r-v8 and a few of its dependants by updating node, > sorry about that! [...] > I'm not sure how to fix this, I'm happy to revert the node update if > needed, let me know! Then we'd ha

bug#43228: r-v8 doesn't build since node 10.22 update

Hi Pierre, Pierre Langlois writes: > Mark H Weaver writes: > >> One possible solution might be to update the replacement (graft) for >> _curl_ so that it's *built* against nghttp2-1.41. Something like this >> (untested): > > I'm afraid this still doesn&

bug#43228: r-v8 doesn't build since node 10.22 update

Hi Pierre, Your new patch looks good to me, but the node-10.22 source field could be simplified to avoid repeating the unchanged field (especially the snippet), by inheriting from (package-source node) like this: --8<---cut here---start->8--- (source (origi

bug#43238: `guix system build -n` to be more informative (builds/substitutes)

Hi Vitaliy, I reported this issue in April as bug #40612, so this is a duplicate. https://bugs.gnu.org/40612 That bug is still open, but it seems blocked on differences of opinion. Mark

bug#43296: [PATCH 1/1] gnu: Fix gnome-builder build.

Hi, Leo Prikler writes: > As reported in #43296, gnome-builder tries to be linked against the static > version of libselinux (propagated through glib/gio), failing to do so, as it > also wants to be a PIE. To keep the PIE, link it against the dynamic library. > * gnu/packages/gnome.scm (gnome-b

bug#43406: Emacs 27.1 memory consumption grows indefinitely

Hi Ludovic, Ludovic Courtès writes: > Since I upgraded to Emacs 27.1, its memory consumption grows without > bounds, to the point that it gets OOM-killed after just a couple of > hours (meaning that it’s used most of the 16G of RAM of my laptop!). > > Does that ring a bell to anyone? I have 50+

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

Maxim Cournoyer writes: > Vitaliy Shatrov writes: > > Closing since a dedicated tool for use in Emacs (emacs-debbugs) exists, > which works around the shortcomings of the Emacs web browsers (Probably > CSS related, as Mark pointed out). For what it's worth: not everyone uses Emacs, and it would

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

Ricardo Wurmus writes: >> On Mon, 14 Sep 2020 at 22:58, Mark H Weaver wrote: >> >>> For what it's worth: not everyone uses Emacs, and it would be good to >>> support users who choose to use simpler software. I guess that it would >>>

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

Earlier, I wrote: > However, I've noticed that in Dillo with CSS disabled, generating a > 'pre' for each line makes the line spacing larger than would be ideal. > It seems that some vertical padding or margins are added around each > 'pre'. It's likely that many browsers do this in their default s

bug#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

Efraim Flashner writes: > On Mon, Sep 14, 2020 at 09:25:25PM -0700, Mike Rosset wrote: >> * gnu/packages/audio.scm (jack-2): Update to 1.9.14. >> [arguments]: new 'declare-for-int phase after unpack that declares 'i in the >> for initialize statement. Add -lstdc++ to LDFLAGS 'set-linkflags phase

bug#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

Earlier, I wrote: > In contrast, a call to 'substitute*' will silently start doing nothing, > and may easily be forgotten. To make matters worse, a future version of > jack-2 might add another 'for' loop in that file, matching the same > pattern but where it is important that 'i' _not_ be initiali

bug#43132: [GUIX SYSTEM]: Malfunction

Maxim Cournoyer writes: > Raghav Gururajan writes: > >>> Maxim Cournoyer skribis: >>> I took Raghav to #btrfs last week, where with the help of gentle folks a failing drive was established as the most likely culprit. In other words, Btrfs checksuming capabilities helped qui

bug#43344: "basic" system tests fail (and all the other ones) on guix master

Hi, Danny Milosavljevic writes: > On Mon, 14 Sep 2020 15:26:52 +0200 > Mathieu Othacehe wrote: > >> Anything special with your hardware? KVM support disabled maybe? > > The culprit had been the Linux kernel update to 5.8.8. > > After downgrading to 5.8.7 it works just fine--no other changes don

bug#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

Mike Rosset writes: > Mark H Weaver writes: > >> [...] patches are more robust than 'substitute*' for >> fixing bugs, and less likely to be misapplied or left forgotten in a >> vestigial state after they are no longer needed. > > That change was not qu

bug#43403: Blender crashes on clicking 'Video Editing'. Segmentation fault

zna...@disroot.org writes: > Hi! I had workable blender long time ago when I used it (in > summer). Now, it crashes every time I click 'Video Editing' from menu. I also see crashes with essentially the same backtrace that you provided, but in my case I'm using Blender 2.79b and it doesn't crash u

bug#43403: Blender crashes on clicking 'Video Editing'. Segmentation fault

Hi Efraim, Efraim Flashner writes: > does it also happen when you're using an ungrafted version? > 'guix environment --ad-hoc --no-grafts blender -- blender' This was a good idea, but it made no difference for me with blender@2.79b. I can still reproduce the crash using the steps I described in

bug#43418: ffprobe/avprobe and ffmpeg/avconv should be added as dependencies of youtube-dl so it will function correctly

Leo Famulari writes: > On Tue, Sep 15, 2020 at 02:06:11PM +0200, Tobias Geerinckx-Rice via Bug > reports for GNU Guix wrote: >> Matters would be different if the error message were less clear, or perhaps >> if ffmpeg weren't so insanely great: >> >> λ guix size youtube-dl | tail -n1 >> total:

bug#43420: icecat causes pulseaudio to crash

Nathan Dehnel writes: > So...playing a youtube video in icecat causes pulse to crash. You can > play one video and it works, but it crashes if you open another tab or > page with a video in it. Also skipping around the seekbar causes it to > crash. > > bash-5.0$ pulseaudio > W: [pulseaudio] pid.c

bug#43403: Blender crashes on clicking 'Video Editing'. Segmentation fault

Hi, Malte Frank Gerdes writes: > i have a similar error. I'm using Blender 2.83.5 in a environment > created with guix environment --ad-hoc --no-grafts (as suggested). In a > new scene (right after startup not loading anything) selecting the cube > and trying to apply a Remesh Modifier Blender c

bug#43418: [PATCH] gnu: youtube-dl: Refer to ffmpeg.

Hi Tobias, > Addresses . > > * gnu/packages/video.scm (youtube-dl)[inputs]: Add ffmpeg. > [arguments]: Fall back to input ffmpeg instead of searching $PATH. Looks good to me. Thank you! Mark

bug#43418: ffprobe/avprobe and ffmpeg/avconv should be added as dependencies of youtube-dl so it will function correctly

Hi Tobias, Tobias Geerinckx-Rice writes: > Mark H Weaver 写道： > >> I see two possible approaches: ffmpeg could be added to youtube-dl's >> propagated-inputs, or it could be instead be added to 'inputs', and >> we could substitute hardcoded paths to &#

bug#43344: "basic" system tests fail (and all the other ones) on guix master

Leo Famulari writes: > On Wed, Sep 16, 2020 at 04:52:45PM +0200, Danny Milosavljevic wrote: >> commit 692d0626557451c4b557397f20b7394b612d0289 >> Author: Christoph Hellwig >> Date: Tue Sep 1 11:59:41 2020 +0200 >> >> block: fix locking in bdev_del_partition >> >> [ Upstream commi

bug#43344: "basic" system tests fail (and all the other ones) on guix master

Marius Bakke writes: > Leo Famulari writes: > >> On Wed, Sep 16, 2020 at 09:36:49PM -0400, Mark H Weaver wrote: >>> Next, it probably makes sense to test 5.8.9 with the above commit >>> reverted. Would someone like to try it? If that works, we can avoid &g

bug#43420: icecat causes pulseaudio to crash

Hi Nathan, Nathan Dehnel writes: > Pulseaudio is set to autospawn by default, which is maybe why it seems like > nothing is happening on your computer. Maybe try disabling autospawn and > try running pulse in a shell. In my previous tests, I ran pulseaudio from a shell, but I did not disable aut

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

The Guix build of IceCat-68 stores absolute file names of the form /gnu/store/…-icecat-68.…/* within user profiles in ~/.mozilla/icecat/*. For example, ~/.mozilla/icecat/*/extensions.json contains store references of the forms: /gnu/store/…-icecat-68.…/lib/icecat/browser/features/*.xpi and /gnu/st

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