bug#47628: webkitgtk-2.32.0 is broken on my system (was Re: bug#47628: Epiphany fails to launch after webkitgtk-2.32.0 update)

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 > 3c5e1412e3ef769df8e4826d0aedabaa3aa0d631), epiphany fails to launch: no > window appears, although GNOME Shell shows an empty outline in overview >

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

Hi Leo, Leo Famulari writes: > On Mon, Apr 05, 2021 at 09:45:43PM +0200, Ludovic Courtès wrote: >> The GC’s scanner still gets it wrong though. I wonder whether having >> the grafting code more capable than the scanner could lead to bad >> surprises. WDYT? > > I'm going off-topic, but I've wis

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#47628: webkitgtk-2.32.0 fails to launch without /usr/bin

Hi Efraim, Efraim Flashner writes: > On Thu, Apr 08, 2021 at 11:07:31AM -0400, Mark H Weaver wrote: >> 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/Web

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

> Modulo these very minor issues, it looks like it’s ready to go! Sounds good. Thanks for the review! Below, I've attached my current revision of this draft patch, which incorporates your suggestions regarding the main code. What remains is to improve the tests. Regards, Ma

bug#36508: GDM files have incorrect owner after temporarily removing service

Hi Brendan, Brendan Tildesley via Bug reports for GNU Guix writes: > I recently encountered what is likely the same bug. The directory /var/lib/gdm > had the correct permissions gdm:gdm, but all the files inside had something > like > 973:gdm The underlying problem here, which I've also experi

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

Hi Léo, Léo Le Bouter writes: > On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote: >> >> Léo Le Bouter writes: >> >> > I think that probably replacing arbitrary paths in built binaries >> > is a risky and maybe unreliable engineering choice and tha

bug#47749: Feature Request: Make top/htop give usable readings for the packages

bo0od writes: > Using top/htop is helpful to know many info like running packages,memory > usage...etc > > But in guix the problem with any running service it show long path > /gnu/store/pathxxx/packagename this is not useful as the name of the > package will be hidden from screen due to its l

bug#47748: Packages which cant be find/removed by guix remove

Julien Lepiller writes: > Second, your operating-system declaration apparently is running > the avahi server. Since you didn't share it, I don't know if it comes > from a service dependency or if it's declared explicitely, The avahi service is included in '%desktop-services'. https://git.sav

bug#47064: [racket-users] bytevector-uncompress: internal error uncompressing

Hi Philip, [removed 'racket-users' from the recipient list] Philip McGrath writes: > My guess is that Racket CS is compressing string literals in compiled > code. Currently, Guix patches Racket source files to include the > absolute paths to foreign libraries in the store as string literals.

bug#47717: guix becomes unresponsive while building the 'vigra' package

bo0od writes: > > What kind of computer are you using? Are you using swap? > > 4GB DDR3 rams, i7 4th generation , 20GB for Guix about 9GB swap For the record: I don't use binary substitutes at all, and I build my GNOME system plus IceCat locally, using Guix, on a modest Thinkpad X200 with 4GB o

bug#47748: Packages which cant be find/removed by guix remove

Hi Julien, Julien Lepiller writes: > The manual suggests modify-services in some places: > > (modify-services %desktop-services > (delete avahi-service-type)) I don't see how this can work. (modify-services ...) expands into a call to 'map', which is incapable of deleting elements. Also, th

bug#47748: Packages which cant be find/removed by guix remove

Hi, bo0od writes: > > In particular, there are multiple > > profiles, and each of them could contain avahi or a reference to avahi. > > That doesnt address the issue im talking about, why guix remove doesnt > recognize the package that number 1 , number 2 if the package will break > somethin

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

Ludovic Courtès writes: > LGTM! Feel free to push this version or an improved one. I think it’s > good to have it in the upcoming release, and if it’s pushed sooner, > we’ll have more time to react in case something’s wrong. I pushed an improved version of the patch to 'master' as commit 1bab9b

bug#47064: [racket-users] bytevector-uncompress: internal error uncompressing

Hi Philip, Philip McGrath writes: > On 4/14/21 1:54 AM, Mark H Weaver wrote: >> In this case, I suspect that within a *.zo file, a Guix store item name >> was split into pieces, with the hash and "-" together in one piece but >> split somewhere between the &qu

bug#36508: GDM files have incorrect owner after temporarily removing service

x27;s true today, it might not be true tomorrow. (3) Groups don't even have home directories. > On 04/13/2021 10:51 PM Mark H Weaver wrote: >> >> There's some discussion of this issue at <https://bugs.gnu.org/44944>, >> although I'm not sure that

bug#36508: GDM files have incorrect owner after temporarily removing service

Ludovic Courtès writes: > Note that there are other places, in addition to GDM, where we > forcefully reset the UID/GID of the home directory (e.g., for the > ‘knot-resolver’ service.) > > My preferred solution to this would be to unconditionally chown -R home > directories upon activation (for e

bug#36508: GDM files have incorrect owner after temporarily removing service

Ludovic Courtès writes: > My preferred solution to this would be to unconditionally chown -R home > directories upon activation I also wonder if this could lead to security flaws similar to CVE-2021-27851 , but perhaps 'chown' has been written carefully to avoid such p

bug#36508: GDM files have incorrect owner after temporarily removing service

Ludovic Courtès writes: > Mark H Weaver skribis: > >> Here's one idea: when activating a system, *never* delete users or >> groups if files still exist that are owned by those users/groups. >> Checking all filesystems would likely be too expensive, but perhaps it &g

bug#47748: Packages which cant be find/removed by guix remove

bo0od writes: > > You seem to want it to do something different than it was intended to > > do, although I'm not precisely sure what that is. Do you want it to try > > to purge all copies of the given package from /gnu/store? If so, that > > might require deleting (or modifying) older syste

bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure

bo0od writes: > > I mean the ‘outrageously’ part. When Linux runs out of memory, it > > freezes up. Moral judgment is futile. Better to adopt raingloom's > > earlyoom suggestion or similar. > > Im using default guix system nothing special, If this package usable to > solve these stuff i su

bug#47786: Several build --keep-failed result in wrong env variables

tags 47786 + notabug close 47786 thanks Hi Dmitry, Dmitry Matveyev writes: > I use guix on Arch Linux, version > 050be36cbf3a42199f64f2e44c59f1cb1b3afab5. > > Several invocations of guix build --keep-failed creates directories in > /tmp like this one guix-build-hello-2.10.drv-0 for 1st build an

bug#36508: GDM files have incorrect owner after temporarily removing service

Hi Ludovic, Ludovic Courtès wrote: >>> Note that the ID allocation strategy in (gnu build accounts) ensures >>> UIDs/GIDs aren’t reused right away (same strategy as implemented by >>> Shadow, etc.). So if you remove “bob”, then add “alice”, “alice” won’t >>> be able to access the left-behind /ho

bug#36508: GDM files have incorrect owner after temporarily removing service

Hi Ludovic, Ludovic Courtès writes: > IDs as hash of the user names are interesting because that’d be > stateless (conversely, the current ID allocation strategy is stateful: > it arranges to not reuse recently-freed IDs.) > > But like you write, we’d need 32-bit UIDs. In libc, ‘uid_t’ > (speci

bug#47812: Incorrect code in the Guix manual, but only on the website

In the Guix manual, as it appears on our website, https://guix.gnu.org/manual/devel/en/html_node/X-Window.html the manual entry for 'slim-service-type' suggests the following code to remove the 'gdm' service from %desktop-services. --8<---cut here---start->8

bug#47812: Incorrect code in the Guix manual, but only on the website

Mark H Weaver writes: > The correct text was added about 2 years ago, in the following commit: > > > https://git.sv.gnu.org/cgit/guix.git/commit/?id=dbef9015db107dd148133420b89af552ef08f8ee > > I see no evidence of it being changed since then. > > Any idea where t

bug#47812: Incorrect code in the Guix manual, but only on the website

tags 47812 + notabug close 47812 thanks Hi Leo, Leo Famulari writes: > On Thu, Apr 15, 2021 at 08:12:13PM -0400, Mark H Weaver wrote: >> I see now that this new functionality was added to the 'staging' branch >> 3 days ago: >> >> >> https://git.sv

bug#47748: Packages which cant be find/removed by guix remove

Mark H Weaver writes: > Julien Lepiller writes: > >> The manual suggests modify-services in some places: >> >> (modify-services %desktop-services >> (delete avahi-service-type)) > > I don't see how this can work. For the record: Julien was right.

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

Ludovic Courtès writes: > IIUC, now that has been closed, > this bug is fixed. Am I right? Yes, I believe so. All store items referenced by Racket now seem to be properly grafted, so I'm closing this bug now. The more general issue with the grafting code--na

bug#47838: Grafter should check every byte it modifies, to avoid corruption

Recall that the grafting code performs a set of substitutions, replacing store item names (i.e. file names in /gnu/store) with replacement store items of the same length, with rules like: "fx3979c88s9yxdbchyf36qryawgzpwb5-libx11-1.6.10" => "rwkqxykm91a75w9afhb41saj0dmf30hw-libx11-1.6.12". The graf

bug#36508: GDM files have incorrect owner after temporarily removing service

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >>> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps >>> in some file in /etc, where entries are added but *never* automatically >>> removed. When allocating UIDs/GIDs, we

bug#36508: GDM files have incorrect owner after temporarily removing service

Hi Maxime, Maxime Devos writes: > On Thu, 2021-04-15 at 14:58 -0400, Mark H Weaver wrote: >> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps >> in some file in /etc, where entries are added but *never* automatically >> removed. When allocating UIDs

bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure

Hi Maxim, Maxim Cournoyer writes: > Mark H Weaver writes: > >> 'earlyoom' behavior is not necessarily desirable. I, for one, have a >> fairly old computer by today's standards, and sometimes I ask it to do >> intensive things that are at the edge of its

bug#48024: glib-2.62.6 build fails i686

Hi, Bone Baboon via Bug reports for GNU Guix writes: > On an i686 computer when I run the command `sudo guix system > --no-substitutes --cores=2 reconfigure configuration.scm` I get this > error: and in a later message: > 40/259 glib:glib / mutex TIMEOUT 60.04 s [...] >

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

Hi Pierre, and Ludovic, Pierre Neidhardt writes: > I also agree this looks like a net win even though the `guix gc` issue > is not fix. > The latter seems to be relatively easier to fix, doesn't it? Yes. I now have a plan to finally fix this bug for good. I intend to write a scanner in Scheme

bug#48169: icecat extensions icons disappeared

merge 43487 48169 thanks Hi, bo0od writes: > Icecat browser comes with default extensions, But currently (seems after > latest upgrade) extensions images disappeared. See for a description of the problem, and how to get the bundled extensions working again at the c

bug#48024: glib-2.62.6 build fails i686

Hi, [added Efraim Flashner to the CC list] Bone Baboon writes: > Thank you for your helpful response. > > Would a patch like this that addresses test timeouts be good to have in > the Guix repository? It would help other Guix users who also run into > test timeouts when building glib. Good qu

bug#48024: glib-2.62.6 build fails i686

Hi, Bone Baboon writes: > Mark H Weaver writes: >> The following patch, applied to your copy of Guix, should work around >> the problem: >> >> --8<---cut here---start->8--- >> diff --git a/gnu/packages/glib.scm b/gn

bug#48024: glib-2.62.6 build fails i686

Hi Efraim, Efraim Flashner writes: > In glib-2.68 test_timeout and test_timeout_slow are set to 60 and 180 > respectively. Right. Unfortunately, these timeouts are too short for many slower machines, such as 32-bit ARM systems. Bone Baboon has also recently reported being unable to build 'glib

bug#48024: glib-2.62.6 build fails i686

Earlier, I wrote: > I think that this recently-reported bug () > demonstrates that we can't safely remove the substitution. To avoid having to scroll past the very long build log in the initial bug report, it's probably best to read the bug report starting here: https:

bug#48213: offlineimap build fails

Hi, Bone Baboon via Bug reports for GNU Guix writes: > On a x86_64 computer when I run `guix build --no-substitutes > offlineimap` the build fails because the "test_ipv6_available" test > fails. > > In the system configuration ipv6 is disabled: [...] > Taking the failing test's name "test_ipv6_av

bug#48239: rust-1.19.0 build fails

Hi, Bone Baboon via Bug reports for GNU Guix writes: > On a x86_64 computer when I run `guix build --no-substitutes --cores=1 > rust` it fails during the build phase of rust-1.19.0. Thanks for the report. > The build log of rust-1.19.0 is attached. Here are the last few lines of the log: --8<

bug#48024: glib-2.62.6 build fails i686

Hi, Bone Baboon writes: > Efraim Flashner writes: >> I looked closer at the bug report and I see they are timing out at 60 >> and 180 for Bone Baboon as they currently are. >> >> Bone Baboon: Can you build the attached test-glib.scm file and send back >> the build log? I want to make sure I chan

bug#48024: glib-2.62.6 build fails i686

Hi, Bone Baboon writes: > Thank you for sharing this. Also thank you for the warning about > 'significant caveats and "rough edges"'. The "rough edges" could surely be smoothed out with some effort. I haven't been motivated to work on it, partly because until recently, I've felt quite alone i

bug#48024: glib-2.62.6 build fails i686

Hi, Bone Baboon writes: > How can I use the glib I have built in a system configuration while this > fix or a variation of it makes it's way into the Guix master branch? I guess that you'll need to set up a personal branch of Guix, like I do, with a patch applied to the 'glib' package, and anoth

bug#48214: inetutils-1.9.4 build fails

Hi, Bone Baboon via Bug reports for GNU Guix writes: > Ludovic Courtès writes: >>> How can I use a package definition from core-updates with guix build or >>> in a system configuration if it is not available on Guix's master >>> branch? >> >> You can do better :-), you can install 2.0 from maste

bug#48239: rust-1.19.0 build fails

Hi, Bone Baboon writes: > Mark H Weaver writes: >> Are you aware of any relevant customizations to your kernel >> configuration that might possibly be related to this? > > The system configuration includes: > > ``` > (kernel-arguments >(append > (

bug#48273: Icedove 78.10.0 build stuck at 'unpack' phase

Hi, In your original bug report, you stated that the build was stuck in the 'unpack' phase of the 'icedove' package, and you attached a screenshot showing that phase in-progress. In this later followup message, you're stating something different: that it's getting stuck in an earlier package buil

bug#48273: Icedove 78.10.0 build stuck at 'unpack' phase

Hi Leo, Leo Famulari writes: > On Tue, May 11, 2021 at 12:21:33AM +, bo0od wrote: >> Since you said these are giving 2 different readings then the issue is with >> timing, So i kept it for like 24 hour (or more) and now i hope the log make >> more sense since there are too many fail,warnings

bug#33542: Strange tarball download error on Hydra

reopen 33542 retitle 33542 Offloading to older Guix fails for lack of (guix base16) thanks Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Mark H Weaver writes: >> >>> On Hydra, the armhf builds for al variants of 'linux-libre

bug#33676: GuixSD on eoma68-a20?

Hi Danny, Danny Milosavljevic writes: > On Sat, 8 Dec 2018 17:39:01 +0100 > swedebugia wrote: > >> Could we pre-order some of these owned by the foundation to >> be used to to hack on this? >> >> See https://www.crowdsupply.com/eoma68/micro-desktop > > Guix received one but we have so far be u

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

In recent evaluations of 'master', there have been two more instances of this problem occurring, on x86_64 and i686: https://hydra.gnu.org/build/3252398 (from eval 110355, commit 08861d25) https://hydra.gnu.org/build/3225361 (from eval 110351, commit 69f867b1) I aborted these jobs. M

bug#33676: GuixSD on eoma68-a20?

Hi Danny and Ludovic, Danny Milosavljevic writes: > After the change, I get the following on Hydra > : > > --- > @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-

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

I found two more instances of this problem, in evaluation 110355: https://hydra.gnu.org/build/3253071 https://hydra.gnu.org/build/3252182 I killed these jobs, and cancelled all pending 'test.*' jobs. Mark

bug#33693: Missing icons in GNOME Shell since core-updates merge

Since the core-updates merge, on my x86_64 GuixSD system, GNOME Shell is missing some of its icons. Specifically: * In window "overview" mode, the window close buttons are not visible, although they still work if you know where to click. * In the built-in calendar (made visible when you click

bug#33722: While offloading, 'length' was applied to #

The following build on Hydra aborted due to an error while offloading. The 'length' procedure was applied to #. See below for the Nix error output. Mark https://hydra.gnu.org/build/3278275 Nix error output these derivations will be built: /gnu/store/ndbvyl6pf7xnr2xfl9a93bzw8vmrrzfg-te

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

I just found that 4 out of 6 Intel build slots on Hydra have been occupied for the last 10+ hours on more instances of this bug: https://hydra.gnu.org/build/3281985 https://hydra.gnu.org/build/3281874 https://hydra.gnu.org/build/3281957 https://hydra.gnu.org/build/3281830 I killed these j

bug#33754: guix-0.16.0-4.60b0402 fails to build on armhf-linux

guix-0.16.0-4.60b0402 fails to build on armhf-linux, in what appears to be a reproducible failure. https://hydra.gnu.org/build/3281991 Two tests fail: tests/graph.scm and tests/guix-package.sh. Both failures are ultimately caused by the following error: (match-error "match" "no matching pat

bug#33676: GuixSD on eoma68-a20?

Hi Andreas, Andreas Enge writes: > On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote: >> can you check whether dirindex (hashtables for directory) is enabled? >> # tune2fs -l /dev/... | grep -o dir_index >> See also >> https://blog.merovius.de/2013/10/20/ext4-mysterious-no-spa

bug#33751: [SECURITY] Which packages bundle sqlite?

Hi Alex, This issue is being tracked at , so it would be best to send followups regarding this issue to <33...@debbugs.gnu.org>. Alex Vong writes: > I also want to know should we graft in this case since updating sqlite > would cause ~4000s rebuilts. Yes, it should

bug#33778: guix copy fails

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> ~/dev/gx/branches/master/pre-inst-env guix copy --to=elephly.net:1022 >> /gnu/store/b10q1d2hks78i6vbjwrf71xxsyc1xb95-system >> Backtrace: >>8 (apply-smob/1 #) >> In ice-9/boot-9.scm: >> 705:2 7 (call-with-prompt _ _ #> proc

bug#33768: guix 0.16.0-4.60b0402 fails tests on aarch64

Vagrant Cascadian writes: > On 2018-12-17, Efraim Flashner wrote: >> On Sun, Dec 16, 2018 at 09:12:08PM +0100, Danny Milosavljevic wrote: >>> Should be fixed on master. Can you confirm? >> >> Vagrant confirmed on IRC that it is fixed on master. > > I think that was a different bug. > > As of 211

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

Hi Ludovic, Ludovic Courtès writes: > As discussed with Pierre at the R-B Summit, ‘sbcl-next’ lacks a > reference to ‘next-gtk-webkit’ even though is invokes it: > > $ guix gc --references $(type -P next) | grep next- > /gnu/store/9d66xb8wvggsp0x9pxj61mzqy007978f-sbcl-next-1.1.0 > /gnu/store/pqy

bug#33378: offload: Avoid hosts with little or no free disk space

Hi Ludovic, Ludovic Courtès writes: > l...@gnu.org (Ludovic Courtès) skribis: > >> ‘choose-build-machine’ in (guix scripts offload) could/should exclude >> build machines that don’t have at least, say, 100 MiB available in their >> store. That would avoid ENOSPC build failures such as >>

bug#33857: During installation test, guest kernel repeatedly hangs

The guest kernel within the QEMU guest of the following build https://hydra.gnu.org/build/3293174 has apparently gotten stuck multiple times in "task jbd2/vdb2-8:361". As I write this, the build is still in progress, and is being performed on guix.sjd.se. See below for the build log so far, wh

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

Hi Ludovic, Ludovic Courtès writes: > Pierre Neidhardt skribis: > >>> For now I lean towards looking for a way to address the issue >>> specifically for SBCL. >> >> Don't forget that we currently have 5 Lisp compilers. >> Besides, it's not clear that this can be fixed on the compiler's side, it

bug#33754: guix-0.16.0-4.60b0402 fails to build on armhf-linux

This has been resolved by updating Guix, so I'm closing this bug. Mark

bug#33378: offload: Avoid hosts with little or no free disk space

Hi Ludovic, Ludovic Courtès writes: > I suppose the only way to solve this correctly would be to keep the > build tree and then delete it from (guix scripts offload). WDYT? Generally, this sounds like a reasonable approach. However, one issue is that it will likely lead to build directories be

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

Pierre Neidhardt writes: >> : > Store file names are always ASCII so problems arise when they are stored >> : > as UTF-16 or UTF-32/UCS-4. >> : >> : I understand that most programs stick to ASCII filenames, but what about >> the odd >> : one using non-English, special characters? >> >> That’s

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

Hi Danny, Danny Milosavljevic writes: > On Mon, 24 Dec 2018 13:12:23 -0500 > Mark H Weaver wrote: > >> Of course, the usual reason to choose UTF-32 is to support non-ASCII >> characters while retaining fixed-width code points, so that string >> lookups are st

bug#34006: Guix gc killed live roots - broke git

Hi, swedebugia writes: > On 2019-01-07 12:31, Ricardo Wurmus wrote: >> >>> $ git pull swedebugia >>> fatal: unable to fork >>> >>> Stracing it reveals that it is missing something (see full attached): >> >> Where do you see that? > > Ah, sorry the full command was: > strace git pull swedebugia

bug#34066: patch-and-repack can truncate version number

Hi Efraim, Efraim Flashner writes: > When using 'git-fetch' for the source, when a patch is applied part of > the version number is truncated. > > The following derivations will be built: >/gnu/store/zsy0j8jfg4q4nz8xk5bpc3h5qrclm679-opencv-3.4.3-checkout.drv >/gnu/store/kadg4jnyar79mpz5b

bug#34112: Guix 0.16.0-8 FTBFS: ">>= (bind) used outside of 'with-monad'"

In the most recent evaluation of 'master' on hydra.gnu.org (eval 110393, corresponding to git commit 5327e912a8a477e472da9ec03c99cdedcc04af75), the 'guix' package failed to build on x86_64, with the following error: --8<---cut here---start->8--- guix/hg-download

bug#34112: Guix 0.16.0-8 FTBFS: ">>= (bind) used outside of 'with-monad'"

Mark H Weaver writes: > In the most recent evaluation of 'master' on hydra.gnu.org (eval 110393, > corresponding to git commit 5327e912a8a477e472da9ec03c99cdedcc04af75), > the 'guix' package failed to build on x86_64, with the following error: > > guix/hg-down

bug#34157: Hydra: mozjs-60 builds on x86_64 and i686 seemingly get stuck

Yesterday on Hydra, I found both Intel mozjs-60 builds seemingly stuck while exporting the source checkout to hydra.gnunet.org. One had been going for ~22.5 hours, and the other for ~12 hours. I forcefully killed them and restarted them. Now I see the same thing has happened on the second attemp

bug#34157: Hydra: mozjs-60 builds on x86_64 and i686 seemingly get stuck

Efraim Flashner writes: > On Mon, Jan 21, 2019 at 10:31:46AM -0500, Mark H Weaver wrote: >> Yesterday on Hydra, I found both Intel mozjs-60 builds seemingly stuck >> while exporting the source checkout to hydra.gnunet.org. One had been >> going for ~22.5 hours, and the ot

bug#34162: linux-libre 4.20+ fails to mount ext4 on aarch64

.. ) %base-initrd-modules)) Here's a proposed (untested) patch. Would you like to test it and see if it eliminates the need for this workaround? Mark >From 20a57e861cff4dce40c4eb6c7344f12d1f283cf8 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Wed, 23 Jan 2019 01:20:30 -0500 Subjec

bug#34162: linux-libre 4.20+ fails to mount ext4 on aarch64

Vagrant Cascadian writes: > On 2019-01-23, Mark H Weaver wrote: >> Here's a proposed (untested) patch. Would you like to test it and see >> if it eliminates the need for this workaround? > > It did, thanks! Okay, I pushed it to master, commit ff0b73028c0bbbcbf352

bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9)

reopen 34176 thanks Hi Mike, Mike Gerwitz writes: > On Tue, Jan 29, 2019 at 07:14:15 -0500, Mike Gerwitz wrote: >> reopen 34176 >> thanks > > I guess I don't have permission to do this, since nothing happened. Can > someone do this for me? No permission is needed, but it must be sent to the c

bug#34282: offload: error parsing derivation `*.drv': expected string `Derive(['

In the last day or so, I've seen three instances of an offloading error that I'd never seen before, which causes builds to abort on Hydra. So far, they have all been offloads from hydra.gnu.org to hydra-slave1.netris.org, a build slave which I maintain, and which is currently running an older vers

bug#34319: guix-core failed to build: return used outside of 'with-monad'

Hydra is currently unable to produce new evaluations of 'master', due to a build failure in the 'guix-core' derivation, specifically: /gnu/store/50lyirc9g8z8qv9r860hp00d5qm5xijd-guix-core.drv See below for the tail of the failed build log. Mark In ice-9/psyntax.scm: 1679:45 19

bug#34567: Bogus 'upower-service' deprecation message

My OS config includes a reference to 'upower-service', which is now deprecated, but the deprecation message is bogus: mhw@jojen ~$ guix system build /etc/config.scm --verbosity=1 /etc/config.scm:149:19: warning: 'slim-service' is deprecated, use 'slim-service-type' instead /etc/config.scm:1

bug#34568: flash-image.armhf-linux appears to succeed, when it actually failed

The following build appears to have succeeded: https://hydra.gnu.org/build/3378988 but if you look at the tail of the build log, it seems that it actually failed: https://hydra.gnu.org/build/3378988/log/tail-reload --8<---cut here---start->8--- [Kcopying

bug#34716: Guix test failure on i686: tests/processes

The following build of the 'guix' package on i686-linux failed: https://hydra.gnu.org/build/3386822 due to a failure in the 'test/processes' test. I've restarted the build in the hope that the second attempt might succeed. The Guix being built was guix-0.16.0-10.2637cfd, and it was built usin

bug#34777: Online package list is 3 weeks stale, but claims recent update

As I write this, our online package list claims to have been updated 2 days ago, but in fact the entries I checked are over 3 weeks stale. The main package list page includes the text "(updated March 4, 2019)" near the top of the page: https://www.gnu.org/software/guix/packages/ However, the e

bug#33608: bug#33882: Blender is not loading menu scripts

Hi Leo and Thorsten, Leo Famulari writes: > On Sun, Jan 06, 2019 at 12:03:03PM +0100, Thorsten Wilms wrote: >> Sounds reasonable. However, Blender is a case where it might be worthwhile >> to keep a 2.79 around even after the final release of 2.8, because the >> graphics card requirements have b

bug#34995: `guix pull` crash on commit 69cae3d33

Leo Famulari writes: > `guix pull` is crashing for me like this: > > $ guix pull --substitute-urls=https://ci.guix.info > Updating channel 'guix' from Git repository at > 'https://git.savannah.gnu.org/git/guix.git'... > Building from this channel: > guix https://git.savannah.gnu.org/git/g

bug#34995: `guix pull` crash on commit 69cae3d33

Mark H Weaver writes: > I see the same error when trying to build *anything* after updating to > commit 69cae3d3356a69b7fe69481338f760545995485e on the master branch. Reverting the following three commits fixes the problem for me: * 69cae3d335..: Ludovic Courtès 2019-03-22 syste

bug#35010: Many CPAN download URLs are no longer available

Many perl packages cannot be built on hydra.gnu.org because the source code is no longer available at the source URLs known to Guix. Moreover, apparently they were gone by the time Hydra made its first build attempt. Here are some examples: mirror://cpan/authors/id/E/ET/ETHER/URI-1.76.tar.gz

bug#35034: One libgit2 derivation fails on armhf, another succeeds

The 'guile2.0-git-0.2.0' package fails to build on hydra.gnu.org, because its dependency 'libgit2' fails to build: https://hydra.gnu.org/build/3429713#tabs-buildsteps However, there's another 'libgit2' derivation in the same evaluation, which succeeds: https://hydra.gnu.org/eval/110449?filte

bug#35034: guile2.0-git rewrites libgit2 input to use guile-2.0 (was: One libgit2 derivation fails on armhf, another succeeds)

retitle 35034 guile2.0-git rewrites libgit2 input to use guile-2.0 thanks It turns out that this problem is not specific to armhf. 'guile2.0-git' recently started failing to build on all Hydra-supported systems. I see now what's going on. The problem was introduced by: commit 03fb5ff6ae01a68

bug#35010: Many CPAN download URLs are no longer available

Ludovic Courtès writes: > The good news is that the (guix upstream) framework gets to see the > correct URL: > > scheme@(guile-user)> (package-latest-release perl-uri (force %updaters)) > $6 = #< package: "perl-uri" version: "1.76" urls: > ("mirror://cpan/authors/id/O/OA/OALDERS/URI-1.76.tar.gz"

bug#35038: Hydra unable to create new evaluations of master branch

I tried to create a new evaluation of 'master' on hydra.gnu.org to build the new kernels, and it failed with the following inscrutable error: building path(s) `/gnu/store/ar60js22kf3xwv06qdc1clhrvq1hf79z-profile' ERROR: In procedure read: In procedure scm_lreadr: #:13:133: Unknown # object:

bug#35012: Can't install icecat

Hi Alberto, > It keeps failing no matter what. I have about 200gb of disk space and > 8gb of RAM. This is the error I always get: > > $ guix package -c 7 --upgrade icecat --substitute-urls="https://ci.guix.info"; > substitute: updating substitutes from 'https://ci.guix.info'... 100.0% > substitute

bug#34454: Gtk upstream bug #1280 causes crashes in IceCat and Emacs

s, although I cannot reproduce this bug on my own system. If those affected by this issue would like to test this patch and report back, that would be helpful. Regards, Mark >From 5a11003732688c0fbbfdc831774f58ff6fe20a0b Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Fri, 2

bug#34454: Gtk upstream bug #1280 causes crashes in IceCat and Emacs

I applied my proposed patch to my private branch of Guix, rebuilt my system and user profiles, rebooted, and verified that things seem to be working fine. However, since I'm unable to reproduce the original bug, I will have to rely on others to check whether this fixes the problem. Thanks,

bug#35038: Hydra unable to create new evaluations of master branch

Ludovic Courtès writes: > Mark H Weaver skribis: > >> I tried to create a new evaluation of 'master' on hydra.gnu.org to build >> the new kernels, and it failed with the following inscrutable error: >> >> building path(s) `/gnu/store/ar60js22kf3xwv06

bug#35012: Can't install icecat

Hi Björn, Björn Höfling writes: > On Thu, 28 Mar 2019 23:11:22 -0600 > Alberto EFG wrote: > >> H, Mark and everyone who has been helpful >> >> > As other people have mentioned, this substitute should now be >> > available, >> I keep getting this, I don't know if I am doing something wrong:

<    3   4   5   6   7   8   9   10   11   >