bug#78421: Occasional crashes when resuming from software suspend

On Wed, May 14, 2025, at 04:34, Ludovic Courtès wrote: > With Linux-libre 6.14.5-gnu (commit > 300d29e69988caf23684f08effa51f621c7ec083), my laptop occasionally > crashes when resuming from software suspend: blank screen, does not > answer to pings, cannot switch ttys, etc. and hard shutdown is the

bug#78311: guix install fails to install packages

On Wed, May 07, 2025 at 10:48:02PM +, di-v-n-2 via Bug reports for GNU Guix wrote: > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix > substitute: warning: ci.guix.gnu.org: host not found: Temporary failure in > name resolution > substitute: > substitute: updating

bug#77279: Linux-libre 5.4.291 fails to build for i686-linux

Thanks to dariqq for finding the upstream bug report about this build failure: https://lore.kernel.org/stable/d6947457-c1e7-476a-9857-f4a6450b9...@suse.com/ Looks like the build wasn't test upstream. We'll wait for it to get fixed upstream, since it doesn't seem like this kernel is used on i686-

bug#77487: 1.4 million extraneous symlinks under .guix-home/profile/share/icons

On Thu, Apr 03, 2025 at 02:05:40PM +0200, Timo Wilken wrote: > > In my ~/.guix-home/profile/share/icons/, I have a total of 1.4 million > symlinks: > > $ find ~/.guix-home/profile/share/icons/ -type l -printf x | wc -c > 1425657 Oof. I have nothing like that with Guix itself (compared to Guix H

bug#44053: Poor profile generation performance on spinning disks

On Thu, Apr 03, 2025 at 04:25:36PM +0900, Maxim Cournoyer wrote: > I've moved to NVMe myself and things have been zippy enough. I guess we > could consider this issue having been obsoleted by advances in > technology. > > Closing. It makes sense. If nobody will work on the bug, then it should be

bug#77279: Linux-libre 5.4.291 fails to build for i686-linux

Linux-libre 5.4.291 is failing to build for i686-linux. >From , performed on March 15 2025: -- [...] CC [M] arch/x86/oprofile/../../../drivers/oprofile/oprofile_files.o In file included from ./include/linux/export.h:42, from .

bug#76959: Empty Scheme files in system generation,

On Thu, Mar 20, 2025 at 08:46:53PM +0100, Rutherther wrote: > I cannot really find anything that would make this > explanation implausible in this thread. Am I missing something? > Were you guys somehow able to actually *verify* it's guix writing zeros > and not the files getting corrupted afterwar

bug#77086: Filesystems not unmounted on reboot

On Fri, Mar 21, 2025 at 05:50:51PM +0100, Rutherther via Bug reports for GNU Guix wrote: > I am writing with an update, because not everything I wrote in the first > e-mail was true exactly. Please let me know if updates distrub you and I > won't be CCing you again. Please don't hesitate to send

bug#76988: Architecture-specific kernels (arm64-generic) built for x86_64

Thanks for pointing this out! I don't do anything regarding the "generic" arm64 kernels, so I also don't know how they work or why they are built in any particular way. Here's a crude command to produce a list of interesting changes to the linux-libre packaging: `git log v1.4.0..HEAD --grep linu

bug#22137: A test of bug #44996

And now I'll re-close and archive this bug.

bug#44996: issues.guix.gnu.org does not display unarchived re-opened bugs correctly

I just tested this with my old bug #22137: https://issues.guix.gnu.org/22137#12 And issues.guix.gnu.org did the right thing (displayed the new messages). So this bug is fixed. Closing

bug#22137: A test of bug #44996

I've unarchived and reopened this bug in order to test another bug in our issues tracker: https://issues.guix.gnu.org/44996 Sorry for the noise...

bug#42990: Nicotine+ GTK segfaults

I just checked, and this segfault doesn't happen anymore. So I'm closing the bug.

bug#47328: Building qtwebkit fails on CI for i686-linux

We know longer have a qtwebkit package, so I'm closing this bug.

bug#45992: A "live" profile is missing

I haven't experienced this bug again, and I don't think we are going to figure out what happened. Closing!

bug#76966: Gui System - installation problems

On Wed, Mar 12, 2025 at 02:12:00PM +, João Mauricio wrote: > The download from guix.gnu.org in the download part > when I click to download the system for x86_64 > https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso Hm, that's too bad! Really slow! ftpmirror.gnu.org

bug#76966: Gui System - installation problems

On Tue, Mar 11, 2025 at 06:14:18PM +, João Mauricio wrote: > Hello! > In brazil the download of the system is incredibly slow, I tried using > different DNS and even tor with curl, none of it work. > The speed is B/s for me, the highest speed was 100Kb/s for some seconds >From what URL was th

bug#76959: Empty Scheme files in system generation, breaks `guix system` and boot

FYI, I made a mistake and accidentally arrnaged for 3 copies of these messages to be delivered. Of course, the Bas only meant to send a single copy. So if you are annoyed by the overwhelming deluge of messages in this ticket, blame me :)

bug#74856: Evaluation failed on ci.guix.gnu.org

It's been okay, so I'm closing this bug.

bug#76959: Empty Scheme files in system generation, breaks `guix system` and boot

IRC user 'anticomputer' wrote the following about their experience with this problem: I have also run into this bug. It manifested itself as an empty boot parameters file causing guix system errors: `guix system: error: unrecognized boot parameters at '/var/guix/profiles/system/parameters'"` Ro

bug#76959: Empty Scheme files in system generation, breaks `guix system` and boot

In recent days, I reconfigured my system in the same way that I always do it. The resulting system was malformed, preventing boot and the use of `guix system`. Specifically, the files that make up the system itself --- such as '/var/guix/profiles/system-NNN-link/parameters' --- are empty! Zero by

bug#76660: current guix pull doesn't authenticate

On Sun, Mar 09, 2025 at 10:33:45AM +0100, Tomas Volf wrote: > I think it could be influenced by the commit you are currently on, and > the commit you are pulling as latest. So depending on time of previous > and current pull, it might work or it might not work. I assume that > limits the amount o

bug#76660: current guix pull doesn't authenticate

On Mon, Mar 10, 2025 at 12:38:20AM +0100, Tomas Volf wrote: > There is nothing to fix in guile-git, the fix needs to go into (guix > git). Sorry, my mistake.

bug#75080: guix pull fails on arm64 due to cmake DEB self-tests

On Tue, Mar 04, 2025 at 01:11:51PM +0100, Simon Josefsson wrote: > Fortunately it seems that building images without --disable-chroot now > appears to work for me (at least some of the time). Here is a > successful arm64 Guix GitLab pipeline job where 'guix install' works: Great! It's definitely

bug#76810: guix lint when nvd.nist.gov is down

On Fri, Mar 07, 2025 at 01:57:32PM +0100, Nicolas Graves wrote: > Looks like for some reason nvd.nist.gov is down. We should prepare for this site to disappear permanently. Very sorry to say, but it's likely this kind of public service from the US government goes away soon.

bug#76660: current guix pull doesn't authenticate

On Sun, Mar 02, 2025 at 08:08:50PM +0100, Tomas Volf wrote: > Can you pull *any* commit from 6ca7b07a251739dfaefa639e74c01e3013c9454c? Yes: -- $ guix package -p ~/.config/guix/current -l [...] Generation 242 Mar 02 2025 18:24:39 + guix 6ca7b07 out /gnu/store/3bp49nygmmfq340fcgw

bug#76660: current guix pull doesn't authenticate

On Sun, Mar 02, 2025 at 08:08:50PM +0100, Tomas Volf wrote: > Possible explanation would be that there is a bug in the descendancy > detection when your current Guix is on specific commits (my guesstimate > would be the trigger is having large commit message, I have reported > this issue before).

bug#76660: current guix pull doesn't authenticate

On Sat, Mar 01, 2025 at 11:37:40AM -0500, Jack Hill wrote: > guix pull: error: aborting update of channel 'guix' to commit > 6ca7b07a251739dfaefa639e74c01e3013c9454c, which is not a descendant of > f13f0769688493271f43f31a016957355dbecb30 > hint: This could indicate that the channel has been tamp

bug#76557: Syncthing Service is Broken

On Thu, Feb 27, 2025 at 03:56:13PM +0100, David Lecompte wrote: > I just ran "guix pull", "guix system reconfigure /etc/config.scm" and > rebooted and now the folder is synchronized as expected. So it may be so > that the problem was fixed thanks to the recent bug fix that you mentioned, > thanks.

bug#76607: Missing age-keygen - can't build package cache

On Thu, Feb 27, 2025 at 03:58:13PM +0100, Rostislav Svoboda wrote: > No module 'guix build age' exists. The "bin/age-keygen" is in the > gnu/packages/password-utils.scm. (See below) It's a shell command, not Scheme code. Try running `guix build age` and then looking in the age store item for age

bug#76608: guix git: error: unknown introductory commit and signer

On Thu, Feb 27, 2025 at 02:52:18PM +0100, Rostislav Svoboda wrote: > The command was `git pull --rebase savannah master`. (See my first > email in the thread) Right. You might need to check out the 'keyring' branch and pull it in order to get the updates to the keyring, since Steve (futurile) is

bug#76608: guix git: error: unknown introductory commit and signer

On Thu, Feb 27, 2025 at 02:16:47PM +0100, Rostislav Svoboda wrote: > Hello, is the error below caused by this commit? What command did you run to get the error in your email's subject? > 9c7ef1994d 2025-02-27 .guix-authorizations: Use subkey for > Steve/futurile. (11 minutes ago) Maxim Cournoyer

bug#75080: guix pull fails on arm64 due to cmake DEB self-tests

On Wed, Feb 26, 2025, at 03:41, Simon Josefsson wrote: > Hi. What do you mean by disabled isolation? In the initial e-mail I > quoted the set of commands used which involved: > > (guix-daemon --disable-chroot --build-users-group=_guixbuild & > > Is that what you mean? Yes, I'm sorry I missed tha

bug#76557: Syncthing Service is Broken

On Tue, Feb 25, 2025 at 10:20:27AM -0500, Juliana Sims via Bug reports for GNU Guix wrote: > As of 651f8765b657e35baf85ac74a1f6b09ff71691cb, Syncthing's system service > fails to sync for at least some users, including me. Others have mentioned > needing to roll back to before Syncthing 1.29.2.

bug#76444: [PATCH v1] gnu: go-github-com-hanwen-go-fuse-v2: Downgrade to 2.5.0. (Closes: #76444)

On Thu, Feb 20, 2025 at 11:26:27AM -0800, Felix Lechner via Bug reports for GNU Guix wrote: > Change-Id: Idf9059dc969b3c4447e2576ae0601199f20e2525 I wrote the commit message and pushed as 1ce2226aec1e5b5f5cdeff47c0452a46e6c608a5

bug#76444: [PATCH] Blind update of Hanwen's go-fuse broke Gocryptfs

On Thu, Feb 20, 2025 at 10:59:21AM -0800, Felix Lechner via Bug reports for GNU Guix wrote: > The blind update of Hanwen's go-fuse to 2.7.2 [1] broke Gocryptfs. [2] Hi, thanks for debugging and sending a patch. What do you mean by "blind" in this context? > As a general note, I disagree with Gui

bug#74845: [PATCH v2] gnu: racket: Ensure package launchers reference config directory.

On Mon, Dec 16, 2024 at 03:25:48PM -0500, Suhail Singh wrote: > * gnu/packages/patches/racket-launcher-config-dir.patch: New file. With this > patch, packages installed at runtime via raco have configuration directory > correctly set. > * gnu/local.mk (dist_patch_DATA): Register it. > * gnu/packag

bug#76312: go-ulid "Texinfo markup in description is invalid"

On Sat, Feb 15, 2025 at 09:48:29PM +, Sharlatan Hellseher wrote: > I've fixed it in aadee4a58ddb4c0995c41dc4c0d16464665c54c1. > > Feel free to double check and/or close this issue. Thanks for the fix! Closing... signature.asc Description: PGP signature

bug#76312: go-ulid "Texinfo markup in description is invalid"

Hi Sharlatan, I noticed that `guix lint` complains about the description of go-ulid: -- $ guix lint go-ulid gnu/packages/golang-xyz.scm:17707:5: go-ulid@2.1.0: Texinfo markup in description is invalid -- I'm not sure, but it could be the leading white-space in the description. Are you a

bug#69889: Rclone is 4 years outdated

On Tue, Feb 04, 2025 at 09:37:05AM +, Sharlatan Hellseher wrote: > The project changed the module of release and now ships vendor and source > separatly: > - > https://github.com/rclone/rclone/releases/download/v1.69.0/rclone-v1.69.0-vendor.tar.gz > - > https://github.com/rclone/rclone/relea

bug#75080: guix pull fails on arm64 due to cmake DEB self-tests

On Wed, Feb 05, 2025 at 12:18:41AM +0100, Simon Josefsson via Bug reports for GNU Guix wrote: > Looking more carefully at the errors, I notice this part: > >actual-err>cpack-cfg> set(DPKG_EXECUTABLE "/usr/bin/dpkg") >actual-err>cpack-cfg> set(READELF_EXECUTABLE > "/gnu/store/pqai

bug#25752: go incremental builds broken

On Mon, Feb 03, 2025 at 08:27:43PM +, Sharlatan Hellseher wrote: > Based on above the issue is closed. Thanks for making the effort to understand the context and make a decision. It's really valuable work.

bug#76022: udisks is configured to use /media instead of /run

On Mon, Feb 03, 2025 at 12:16:57PM +0900, Maxim Cournoyer wrote: > Since commit 35263cd8627b296c3badc21de355b4fe613d7cd4 ("gnu: udisks: > Mount things under /media."), udisks mounts removable devices under the > /media directory instead of using the /run directory, which would > otherwise be the de

bug#76000: Installer adds "nss-certs" to generated operating-system packages list, but it is included in %base-packages

On Sat, Feb 01, 2025 at 08:11:03PM +, Laurence Rochfort wrote: > Running "guix system reconfigure" produces this message: > > "guix system: warning: multiple 'nss-certs' packages found; > 'nss-certs' is now included by default in '%base-packages'; ensure it > is not explicitly listed in the op

bug#75464: [PATCH] Remove broken tests from "thefuck"

On Fri, Jan 24, 2025 at 03:34:12PM +, Andrew Stubbs wrote: > These tests are reported broken upstream, but nothing has been done about it. Thanks for filing this bug report and making a patch to fix it! I pushed your patch as commit a20df73c7d69356c0800dcc082c1a71e987acf13 with the following

bug#75464: Package thefuck is broken

On Tue, Jan 28, 2025 at 05:23:23PM +, Andrew Stubbs wrote: > I sent a patch to guix-patches. It has shown up in the bug tracker, but it's > not in the mailing list archives ... maybe it got filtered (language?). Weird. > Will the maintainers have received it, or no? I did receive an email wi

bug#75510: Building grub-image.png.drv fails with rsvg

On Fri, Jan 24, 2025 at 10:55:34AM +0100, Roman Scherer wrote: > I'm not very familiar with grafts and have a question. When no grafts > are used for building the Grub image, does it mean it uses packages with > no security updates applied, or is it just that the grafts are not used > and the packa

bug#75724: error: libffi: unbound variable

On Tue, Jan 21, 2025 at 04:27:17AM +, Jaft wrote: > Ran into a bug, according to guix pull. It told me to report it here: > > Updating channel 'guix' from Git repository at > 'https://git.savannah.gnu.org/git/guix.git'...Updating channel 'nonguix' from > Git repository at 'https://gitlab.com

bug#75510: Building grub-image.png.drv fails with rsvg

On Fri, Jan 17, 2025 at 03:48:04PM +0100, Roman Scherer wrote: > Roman Scherer writes: > > Hmm, but it looks I'm now stuck using --no-grafts all the time. Any > ideas how to solve that? That's not great. I don't really understand this bug. Is it a problem in Guile? That would seem hard to fix in

bug#75600: python-pydevd-3.2.3 build failure

This should be fixed on the 'master' branch with commits ad9a2f9643358d19c212becf53ae59f6a1287125 and 0b06a5bc97938cae3da19e566c2f6f71cc299d78 I cherry-picked them from the 'python-team' branch.

bug#75559: gnupg update to 2.4.7 causing guix build -K seahorse to fail

On Wed, Jan 15, 2025 at 02:10:41AM +0100, Rostislav Svoboda wrote: > Thanks Leo. In theory, the fix should be straightforward (see > attachment). However, we need to be careful: > > $ guix search ^seahorse\$ | grep synopsis > synopsis: Manage encryption keys and passwords in the GNOME keyring Can

bug#75559: gnupg update to 2.4.7 causing guix build -K seahorse to fail

On Tue, Jan 14, 2025 at 05:52:46PM +0100, Rostislav Svoboda wrote: > I believe the commit: > 64d95c78e3 2024-12-29 gnu: gnupg: Update to 2.4.7. > causes guix build --keep-failed seahorse to fail. The build log shows: Thanks for the report! > From casually looking at gpg_check_version.py, it app

bug#75510: Building grub-image.png.drv fails with rsvg

On Sun, Jan 12, 2025 at 03:30:07PM -0500, Leo Famulari wrote: > On Sun, Jan 12, 2025 at 10:58:54AM +0100, Roman Scherer wrote: > > > > I can't reconfigure my (aarch64) system anymore. When building > > /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.dr

bug#75510: Building grub-image.png.drv fails with rsvg

On Sun, Jan 12, 2025 at 10:58:54AM +0100, Roman Scherer wrote: > > I can't reconfigure my (aarch64) system anymore. When building > /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv I see the > following backtrace: [...] > View build log at > '/var/log/guix/drvs/bp/da8gfvxm6iv3mc6

bug#75463: Incorrect sourcing on foreign distros

On Thu, Jan 09, 2025 at 03:26:52PM +0100, Einar Largenius wrote: > It has two lines: > > [ -L "$GUIX_PROFILE" ] || \ > > Shouldn't it be: > > [ -L "$GUIX_PROFILE" ] && \ Yes, you are correct. > > I use Guix on Fedora 41. This bug was fixed in commit 08bb2dbb13cc7180a9d8316f9d52b6f7a20d

bug#74952: [PATCH] guix-install.sh: Use "command -v nologin" instead of "which nologin".

On Wed, Dec 18, 2024 at 09:35:27PM +0100, Simon Josefsson via Bug reports for GNU Guix wrote: > Hi! > > In a small container image, I do not have the 'which' tool installed. I > believe 'command -v' is always available since it is /bin/sh standard. > How about changing the idiom for user/group a

bug#74797: linux-libre 6.11.11 fails to build on aarch64 (drivers/clk/meson/gxbb.c)

On Sat, Dec 14, 2024 at 10:21:05PM -0800, Vagrant Cascadian wrote: > Well, it only hgappened once, and with the same commit, it successfully > regenerated the tarball and everything was fine... Understood. Unfortunately I think it suggests a hardware malfunction, although it could be a software bu

bug#74797: linux-libre 6.11.11 fails to build on aarch64 (drivers/clk/meson/gxbb.c)

On Wed, Dec 11, 2024 at 10:36:27AM -0800, Vagrant Cascadian wrote: > linux-libre 6.11.11 fails to build on aarch64, while 6.11.10 built > fine. What commit of Guix does it happen with? Also, what's the derivation that fails to build? Do you know the name of the store item of the seemingly corrupt

bug#74856: Evaluation failed on ci.guix.gnu.org

I'd guess that the evaluation failures of the 'kernel-updates' job is related to the recent renaming of the manifests. I see that maintenance.git has been updated accordingly. But have the changes in maintenance.git been made effective on ci.guix.gnu.org? Or do we still need to do that?

bug#74856: Evaluation failed on ci.guix.gnu.org

A recent evaluation of the 'kernel-updates' job on ci.guix.gnu.org failed: https://ci.guix.gnu.org/eval/1903071 I was able to `guix time-machine` using the same commit, so the problem may be more subtle (specific to Cuirass) or it may be a transient error. I've pushed the master branch to 'kerne

bug#52501: xcalc seems broken

Yes, I did lose interest in this bug. Closing.

bug#67535: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]

On Sun, Nov 10, 2024 at 08:56:33PM +0900, Maxim Cournoyer wrote: > I was about to write this; thanks for be6g faster :-). I believe the > unpacking should now be fine even for i686, Leo? Yes, it's working now! Fantastic!

bug#74280: Bad Kernel config?

Fixed with commit 9cdcfb52ace77fe3b497b21deb639a3027ff02f0

bug#74229: bug#74270: u-boot-tools: tests fail

I bisected the package build failure. It began with "gnu: mesa: Update to 24.2.2." https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e00c621cbbf58a54ca2dd0c7075f154af26bcd54

bug#74280: Bad Kernel config?

On Sat, Nov 09, 2024 at 03:18:10PM +, Dariqq wrote: > Hi, > > (CC-ing the kernel team) > > I was looking through /var/log/messages and found this message there > > ** > ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **

bug#72042: [core-updates] Python-gst fails its test suite

On Mon, Sep 02, 2024 at 05:12:22PM +0200, Remco van 't Veer wrote: > The issue is here: > > https://gitlab.gnome.org/GNOME/pygobject/-/issues/624 > > I've tried and upgrading python-pygobject from 3.47.0 (currently on > master) to 3.48.2 (current upstream release) fixes the issue. Aha, thanks

bug#72429: CLISP build failure on kernel-updates / blocks linux-libre

While testing the recent kernel updates [0], I noticed that all builds on the 'kernel-updates' branch fail on aarch64-linux: https://ci.guix.gnu.org/eval/1528394?status=failed As shown in the build log for linux-libre-5.4.281 [1], the tests fail: -- finished 56 files: 5 errors

bug#67535: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]

I basically agree with you :) On Mon, Jul 29, 2024 at 09:21:57PM -0400, Richard Sent wrote: > Breaking changes are okay, and if we consider this too niche of a use > case or too high of a maintenance burden it should be dropped. I do > believe it should progress into the consideration stage instea

bug#67535: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]

On Mon, Jul 29, 2024 at 11:00:36AM -0400, Richard Sent wrote: > For consideration, I know at least one 3rd-party channel relies on being able > to create a multiarch container containing i686 packages. I'll refrain from > linking since it packages nonfree software. This is an example where keepin

bug#67535: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]

For a long time we've not been able to build linux-libre on i686-linux because the source unpacking process runs out of memory. I'm forwarding this bug to guix-devel to get more attention. Is anybody actually using i686-linux anymore? Or should we begin to officially remove support for it?

bug#72040: [core-updates] Boost bug / breaks libreoffice [was libetonyek link failure]

On Thu, Jul 11, 2024 at 04:23:09PM -0400, Leo Famulari wrote: > Subject: [PATCH] WIP: Boost: Fix a bug that breaks libetonyek. > > This fixes <https://issues.guix.gnu.org/72040> > > * gnu/packages/patches/boost-fix-duplicate-definitions-bug.patch: New file. > * gnu/l

bug#72048: [core-updates] Epiphany (GNOME Web) fails to build (mesa?)

Thank you Ricardo! I was totally stuck on this. On Mon, Jul 22, 2024, at 05:29, Ricardo Wurmus wrote: > This is now fixed in commit bdff6baca39a73b3cfc5400e117795cad0c180cf. > > dbus-daemon watches XDG_* directories, and it bailed out because the > list of directories to watch is just too large.

bug#72048: [core-updates] Epiphany (GNOME Web) fails to build (mesa?)

On Mon, Jul 15, 2024 at 07:38:11PM -0400, Leo Famulari wrote: > It's weird that dbus is killed by signal 11, SIGSEGV. > > I see that some other package manually start dbus for the test suite, so > I'll try my hand at it. Hm, I didn't make any progress with this. Doe

bug#72048: [core-updates] Epiphany (GNOME Web) fails to build (mesa?)

On Sun, Jul 14, 2024 at 01:52:37PM -0400, Leo Famulari wrote: > I reported this problem upstream: > > https://gitlab.gnome.org/GNOME/epiphany/-/issues/2392 The GNOME team suggests that we make sure that dbus is running in the build environment, and indeed it seems there is something

bug#72048: [core-updates] Epiphany (GNOME Web) fails to build (mesa?)

I reported this problem upstream: https://gitlab.gnome.org/GNOME/epiphany/-/issues/2392

bug#72048: [core-updates] Epiphany (GNOME Web) fails to build (mesa?)

For some reason, mumi doesn't display the message I sent about this bug, but only the attachment. It does display on . In any case, here is the original message: On core-updates commit 378e1d9b69b030, Epiphany (the GNOME web browser) fails its test suite. Specifically, several of its tests fail l

bug#72098: [core-updates] Icecat dependency icu4c-73 fails its tests

I was holding it wrong. icu4c-73 and icecat are fine on core-updates. Sorry for the noise!

bug#72098: [core-updates] Icecat dependency icu4c-73 fails its tests

On core-updates commit dd9660264b39b. the icu4c-73 package fails its tests like this: -- make[2]: Leaving directory '/tmp/guix-build-icu4c-73.1.drv-0/icu/source/test/cintltst' - | *** FAILING TEST SUMMARY FOR: intltest TestHebrewCalendarInTemporalLeapYe

bug#72040: [core-updates] Boost bug / breaks libreoffice [was libetonyek link failure]

On Sat, Jul 13, 2024 at 01:39:21PM -0400, Leo Famulari wrote: > There is some discussion on the Libreoffice mailing list, but so far > it's inconclusive from my perspective. But if I understand correctly, > their recommended solution would be to create a source origin of > Boost

bug#72040: [core-updates] Boost bug / breaks libreoffice [was libetonyek link failure]

On Thu, Jul 11, 2024 at 04:23:09PM -0400, Leo Famulari wrote: > Here's a patch that patches Boost, while also creating a hidden package > boost-for-source-highlight. This variant is only used by the > source-highlight package, which is used by gdb, and thus rust. So, it > aims to

bug#72046: [core-updates] OpenImageIO fails to build

On Thu, Jul 11, 2024, at 11:32, Leo Famulari wrote: > On Thu, Jul 11, 2024 at 11:25:34PM +0800, Zheng Junjie wrote: >> > So, it's a problem with cmake? >> > >> > Do you know if they've fixed it in later versions? >> >> see https://gitl

bug#72040: [core-updates] Boost bug / breaks libreoffice [was libetonyek link failure]

On Thu, Jul 11, 2024 at 03:15:27PM -0400, Leo Famulari wrote: > I'm testing a patch for Boost now. It will cause a huge number of > rebuilds, so it would be great to come up with another approach. Here's a patch that patches Boost, while also creating a hidden package boost-for-

bug#72040: [core-updates] Boost bug / breaks libreoffice [was libetonyek link failure]

I found the bug report, which is for Boost: https://github.com/boostorg/phoenix/issues/111 Basically, versions 1.81 through 1.83 exhibit this defect. I'm testing a patch for Boost now. It will cause a huge number of rebuilds, so it would be great to come up with another approach.

bug#72040: [core-updates] libetonyek link failure

On Thu, Jul 11, 2024 at 12:00:56PM -0400, Leo Famulari wrote: > I think this upstream report (closed without resolution) describes the > problem: > > https://bugs.documentfoundation.org/show_bug.cgi?id=152569 I sent a report to the mailing list where build failures are supposed to

bug#72040: [core-updates] libetonyek link failure

I think this upstream report (closed without resolution) describes the problem: https://bugs.documentfoundation.org/show_bug.cgi?id=152569 Boost 1.81 (and presumably 1.83, which we have on core-updates) is not compatible with the libetonyek code.

bug#72046: [core-updates] OpenImageIO fails to build

On Thu, Jul 11, 2024 at 11:32:53AM -0400, Leo Famulari wrote: > Okay, great. I confirm your patch fixes the problem. I'll push it to > core-updates on your behalf. Pushed as 50243774824597dbd141a074a7be0117dc450cef Thanks for your help! signature.asc Description: PGP signature

bug#72046: [core-updates] OpenImageIO fails to build

On Thu, Jul 11, 2024 at 11:25:34PM +0800, Zheng Junjie wrote: > > So, it's a problem with cmake? > > > > Do you know if they've fixed it in later versions? > > see https://gitlab.kitware.com/cmake/cmake/-/issues/25200 Thanks! > > Would this remove zlib support from openimageio? > > no, just fix

bug#72046: [core-updates] OpenImageIO fails to build

On Thu, Jul 11, 2024 at 02:29:59PM +0800, Zheng Junjie wrote: > see patch, as i known, because ours cmake too old, have a bug about zlib. So, it's a problem with cmake? Do you know if they've fixed it in later versions? > + #:phases #~(modify-phases %standard-phases > +

bug#72048: [core-updates] Epiphany (GNOME Web) fails to build (mesa?)

On core-updates commit 378e1d9b69b030, Epiphany (the GNOME web browser) fails its test suite. Specifically, several of its tests fail like this: -- >>> G_TEST_BUILDDIR=/tmp/guix-build-epiphany-44.8.drv-0/build/tests >>> GSETTINGS_SCHEMA_DIR=/tmp/guix-build-epiphany-44.8.drv-0/build/data >>>

bug#72046: [core-updates] OpenImageIO fails to build

On core-updates commit 378e1d9b69b030a165, openimageio fails to build like this: -- [ 30%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/imageio.cpp.o cd /tmp/guix-build-openimageio-2.5.13.0.drv-0/build/src/libOpenImageIO && /gnu/store/86fc8bi3mciljxz7c79jx8zr4wsx7xw8-gcc

bug#72042: [core-updates] Python-gst fails its test suite

On core-updates commit 378e1d9b69b030a, python-gst fails its test suite like this: -- == FAIL: testPropertyMarshalling (test_types.TestFraction) -- Traceback

bug#72039: [core-updates] ki18n test failure of KCatalogTest (locales problem?)

On Thu, Jul 11, 2024 at 02:00:45AM +0800, Zheng Junjie wrote: > i think just disable this test, see > > https://invent.kde.org/frameworks/ki18n/-/commit/241e0cfa96b1491721f361f1713b3514c58bde56#note_654140 > https://gitweb.gentoo.org/proj/kde.git/commit/?id=28525d897f1a83a81df0bbc3ff08de8d94083617

bug#72040: [core-updates] libetonyek link failure

On core-updates commit 736939037346, libetonyek fails to build like this (sorry in advance for the long lines, full log attached): -- CXXLDlibetonyek-0.1.la

bug#72039: [core-updates] ki18n test failure of KCatalogTest (locales problem?)

On core-updates commit 736939037346, ki18n fails its test suite like this: * Start testing of KCatalogTest * Config: Using QtTest library 5.15.10, Qt 5.15.10 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.4.0), unknown unknown PASS : KCatalogTest::initTestC

bug#72038: Closing

I messed up this report so I'm closing it and will open a new one. I think it will be too confusing to leave this report open as it is.

bug#72038: [core-updates] libetonyek test failure of KCatalogTest (locales problem?)

On core-updates commit 736939037346, libetonyek fails its test suite like this: -- * Start testing of KCatalogTest * Config: Using QtTest library 5.15.10, Qt 5.15.10 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.4.0), unknown unknown PASS : KCatalogTes

bug#71729: Emacs 29.4 emergency bugfix release

On Sun, Jun 23, 2024 at 10:39:18AM +0200, Liliana Marie Prikler wrote: > Note: Security bugs should go to guix-security instead. But thanks for > pointing out the new Emacs release, I've pushed an update. (Thus > marking this done) I think that only secret security bugs should go to guix-security

bug#71462: Default ntp service configuration not working on IPv6 network

On Mon, Jun 10, 2024 at 08:30:32AM +, Guillaume Le Vaillant wrote: > On an IPv6-only network, the default configuration for ntp-service-type > doesn't work, because the default pool used (<0.guix.pool.ntp.org>) > doesn't have IPv6 addresses. > > In fact, the <1.guix.pool.ntp.org> and <3.guix.p

bug#70324: After upgrade of linux-libre, linux-libre-documentation fails to build

On Thu, Apr 11, 2024 at 03:18:49PM -0400, Leo Famulari wrote: > I sent a patch: > > https://issues.guix.gnu.org/issue/70343 This should be fixed with commit cc38699cf0cfd804a43ca1b6c8602cfc84e06117 Please let us know if you see more problems. Thanks for the report!

bug#70324: After upgrade of linux-libre, linux-libre-documentation fails to build

On Thu, Apr 11, 2024 at 10:55:39AM -0400, Leo Famulari wrote: > Okay, thanks for looking. We can add a dependency on python-pyyaml and > it should work. I sent a patch: https://issues.guix.gnu.org/issue/70343 And CI will test it here: https://ci.guix.gnu.org/eval/1241100

  1   2   3   4   5   6   7   8   9   10   >