bug#52727: When logged as user, GUILE_LOAD_COMPILED_PATH points to the system cache instead of the user cache

Hi Denis, Am Mittwoch, dem 22.12.2021 um 01:16 +0100 schrieb Denis 'GNUtoo' Carikli: > [A]s user GUILE_LOAD_COMPILED_PATH is somehow exported to system > paths: > > [gnutoo@primary_laptop ~]$ echo $GUILE_LOAD_COMPILED_PATH > > /run/current-system/profile/lib/guile/3.0/site-ccache:/run/current- > >

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

On Wed, Dec 22, 2021 at 01:46:41AM +, Luis Felipe via Bug reports for GNU Guix wrote: > Hello, > > Just wanted to inform that I ran > > `guix pull --branch=wip-fix-52051 && guix system reconfigure [...]` > > and I could log in without problems now. Thanks. Awesome! Would someone like to w

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

Hello, Just wanted to inform that I ran `guix pull --branch=wip-fix-52051 && guix system reconfigure [...]` and I could log in without problems now. Thanks. publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital

bug#51787: Disk performance on ci.guix.gnu.org

Hello, Ricardo Wurmus writes: > Today we discovered a few more things and discussed them on IRC. Here’s > a summary. > > /var/cache sits on the same storage as /gnu. We mounted the 5TB ext4 > file system that’s hosted by the SAN at /mnt_test and started copying > over /var/cache to /mnt_test

bug#52727: When logged as user, GUILE_LOAD_COMPILED_PATH points to the system cache instead of the user cache

Hi, When running guix package -i hello as user (gnutoo) I have: > [gnutoo@primary_laptop ~]$ guix package -i hello > Backtrace: > In ice-9/boot-9.scm: >222:29 19 (map1 (((gnu packages gnupg)) ((gnu packages golang)) …)) >222:29 18 (map1 (((gnu packages golang)) ((gnu packages #)) (#) …)) >

bug#51787: Disk performance on ci.guix.gnu.org

Hi Ricardo, TL;DR: re: "Any ideas?" :) Read this [0], and consider how file systems may be interacting with with SSD wear-leveling algorithms. Are some file systems dependent on successful speculative transaction continuations, while others might slow down waiting for signs that an SSD controlle

bug#52719: Linux modules build fails

Leo Famulari 写道： This is . Did the merge command not work? Kind regards, T G-R signature.asc Description: PGP signature

bug#52719: Linux modules build fails

On Tue, Dec 21, 2021 at 09:59:44PM +, André A. Gomes wrote: > gnu/build/linux-modules.scm:257:5: kernel module not found "simplefb" > "/gnu/store/1ai7mxw5ad58ic9slxsjzsxaryi5wksp-linux-libre-5.10.87/lib/modules" This is .

bug#52667: System reconfiguration fails to build linux-modules.drv

Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道： I see two reasonable solutions. By the way, I think a better solution longer-term is to merge these tightly-coupled kernel attributes into a single object: (kernel (linux-libre-configuration (package linux-libre-lts …)

bug#52667: System reconfiguration fails to build linux-modules.drv

Vivien, Thanks for the report! Sorry it took me a while to get back to you. As discussed in #guix, an immediate work-around is: (initrd-modules ;; This cannot be built as a module for linux-libre-lts. ((@ (srfi srfi-1) delete) "simplefb" %base-initrd-modules)) I'm not sure what to do

bug#51968: Missing dependency for Xournal++

Daniel Meißner schreef op di 21-12-2021 om 12:43 [+0100]: > As you can see: among others the XDG_DATA_DIRS is set which causes > Xournal++ to find its icons.  Plus the GDK_PIXBUF_MODULE_FILE also > resolves the problem that Xournal++ cannot recognize the file format of > its application icon ‘pixma

bug#52684: [BUG] Multiple Packages Failing to Build

Christopher Rodriguez schreef op di 21-12-2021 om 16:38 [-0500]: > Ah, I see. That makes sense. > > However, I don't think we need to necessarily use all of 'beets' inputs > as inputs for 'beets-bandcamp', because it will build fine with just the > inputs listed. I know it isn't DRY, but it seem

bug#52719: Linux modules build fails

Hi Guix, I issued guix system reconfigure and the linux modules failed to build. Here's the backtrace: --8<---cut here---start->8--- Backtrace: 17 (primitive-load "/gnu/store/bvjcb7jbwlky0czin8p66949mil?") In ice-9/eval.scm: 619:8 16 (_ #f) 62

bug#52577: ‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded” error

On Tue, Dec 21 2021, Maxime Devos wrote: > Xinglu Chen schreef op di 21-12-2021 om 18:17 [+0100]: >> O[...] >> Yeah, the catch/throw system doesn’t really work well with ‘raise’. >> Here is what I found after some digging: [...] > > My point was that a raise-style exception shouldn't be wrapped in

bug#52684: [BUG] Multiple Packages Failing to Build

Ah, I see. That makes sense. However, I don't think we need to necessarily use all of 'beets' inputs as inputs for 'beets-bandcamp', because it will build fine with just the inputs listed. I know it isn't DRY, but it seems like the most efficient way to define the package might be to simply de

bug#52684: [BUG] Multiple Packages Failing to Build

Hi, Christopher Rodriguez schreef op di 21-12-2021 om 14:47 [-0500]: > I believe the issue was indeed beets-bandcamp missing needed > beets-related inputs. I started by copying all of the inputs from beets, > and then removed each one to see if it was required for beets-bandcamp > to build succ

bug#52684: [BUG] Multiple Packages Failing to Build

I believe the issue was indeed beets-bandcamp missing needed beets-related inputs. I started by copying all of the inputs from beets, and then removed each one to see if it was required for beets-bandcamp to build successfully. The attached patch works on my cloned repo; Is there somewhere else

bug#52520: Multicast is off by default

Hey, > BTW, for the purposes of fixing the bug you initially reported, I > suggest simply adding #:multicast-on #t as you initially proposed. > We discuss the proper API separately. Done with: d2f9578a9f1249dfecb0a6b4cd06fd9641fcd1a9. Thanks, Mathieu

bug#51787: Disk performance on ci.guix.gnu.org

Hey, > Today we discovered a few more things and discussed them on IRC. Here’s > a summary. Nice summary :) > We could take this opportunity to reformat /gnu with btrfs, which > performs quite a bit more poorly than ext4 but would be immune to > defragmentation. It’s not clear that defragmen

bug#52708: [BUG] Guix checkout fails `make check`

Copy that, will refer to it as 'Guix System' from now on. I'd picked up GuixSD from reading (apparently outdated) blog posts. Regarding the section header, I'd just copied something I found online for submitting good bug reports. You're right, though, it's oddly named. I think, going forward,

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

On Tue, Dec 21, 2021 at 05:51:28PM +, Maxime Devos wrote: > I don't think commenting new code is a drastic and extreme action. > I assume you were referring you were referring to the ‘16.6 hours’? Right. We don't want to use a timeout of 16.6 hours. From the perspective of a user, that's not m

bug#52684: [BUG] Multiple Packages Failing to Build

Copy that, Maxime. That makes sense. I'll work towards getting it to build without deleting that phase, then. Thanks for the feedback! On Tue, Dec 21, 2021, 13:02 Maxime Devos > wrote: Christopher Rodriguez schreef op di 21-12-2021 om 12:52 [-0500]: > Th

bug#52708: [BUG] Guix checkout fails `make check`

Christopher Rodriguez schreef op di 21-12-2021 om 12:21 [-0500]: > 5 Visual Proof (screenshots, videos, text) > == > >    Attached are personally created logs of each step of the process. > For >    further clarity, here is the output of `git -C ~/Downloads/

bug#52684: [BUG] Multiple Packages Failing to Build

Christopher Rodriguez schreef op di 21-12-2021 om 12:52 [-0500]: > That said, adding `(delete 'sanity-check)` for both beets and > beets-bandcamp does indeed make them build correctly. Is that the > appropriate fix here, or should I be trying to make them build > correctly > with the sanity chec

bug#52708: [BUG] Guix checkout fails `make check`

As an aside: It seems as though on the web interface at least I am causing all of my attachments to be concatenated with my messages. Is there a specific way to attach files to prevent this, or is it intended? OpenPGP_0x1102102EBE7C3AE4.asc Description: OpenPGP public key OpenPGP_signature De

bug#52684: [BUG] Multiple Packages Failing to Build

Hi Simon, thanks for taking the time to help me with this! I am currently trying to set up a development environment for myself, but I've run into some issues (which I've submitted as #52708) in the `make check` process. I'm editing the package definition for `beets-bandcamp` nonetheless, but

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

Leo Famulari schreef op di 21-12-2021 om 12:32 [-0500]: > > A comment like > > > > > ;; Set timeout to a huge number (16.6 hours), because > > > ;; upstream often sets timeouts low for spinning disks, > > > ;; slow CPUs, etc. > > > (limit [...] "6") > > > > could be useful (I'm assuming the

bug#51787: Disk performance on ci.guix.gnu.org

On Tue, Dec 21, 2021 at 06:26:03PM +0100, Ricardo Wurmus wrote: > We could take this opportunity to reformat /gnu with btrfs, which > performs quite a bit more poorly than ext4 but would be immune to > defragmentation. It’s not clear that defragmentation matters here. It > could just be that the

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

On Tue, Dec 21, 2021 at 12:37:30PM -0500, Leo Famulari wrote: > With this patch, I can boot and login to X on my X200s with HDD. > Obviously this failure and subsequent fix are not deterministic, but > it's a good sign! Let's get some more testing! I pushed the patch to a Savannah branch to ease t

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

On Tue, Dec 21, 2021 at 11:36:22AM -0500, Timothy Sample wrote: > diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm > index 85a4c3e..a680ed7 100644 > --- a/gnu/services/dbus.scm > +++ b/gnu/services/dbus.scm > @@ -106,6 +106,7 @@ (define-syntax directives > (define (services->sxml

bug#51787: Disk performance on ci.guix.gnu.org

Today we discovered a few more things and discussed them on IRC. Here’s a summary. /var/cache sits on the same storage as /gnu. We mounted the 5TB ext4 file system that’s hosted by the SAN at /mnt_test and started copying over /var/cache to /mnt_test/var/cache. Transfer speed was considerably f

bug#52577: ‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded” error

Xinglu Chen schreef op di 21-12-2021 om 18:17 [+0100]: > O[...] > Yeah, the catch/throw system doesn’t really work well with ‘raise’. > Here is what I found after some digging: [...] My point was that a raise-style exception shouldn't be wrapped in a (%exception ...) and then again in an &exceptio

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

On Tue, Dec 21, 2021 at 04:52:19PM +, Maxime Devos wrote: > Are there any good reasons for having a timeout at all? > (Except for the local-user denial of service, but local users can do > "guix build -f something-that-allocates-almost-all-memory-and-melts- > the-cpu.scm" anyway ...) > > If no

bug#52375: webkitgtk page crashes on core-updates-frozen

On Tue, Dec 21, 2021 at 11:39:05AM -0500, Maxim Cournoyer wrote: > Another reason is that adding the gst-plugins-good and gst-plugins-bad > would inflate the size of the webkitgtk package by more than 1 GiB! > (compare "guix size webkitgtk" vs "guix size webkitgtk gst-plugins-good > gst-plugins-bad

bug#52577: ‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded” error

On So, Dez 19 2021, Maxime Devos wrote: > Xinglu Chen schreef op vr 17-12-2021 om 21:57 [+0100]: >> On Fri, Dec 17 2021, Maxime Devos wrote: >> >> > Xinglu Chen schreef op vr 17-12-2021 om 15:03 [+0100]: >> > > (guard (c ((and (http-get-error? c) >> > >     (string=? "rate limit excee

bug#52375: webkitgtk needs gst-plugins-bad

On Tue, 21 Dec 2021, Jack Hill wrote: I asked about this issue on #webkitgtk:gnome.org on IRC. It turns out that what's missing from my environment is gst-plugins-bad (most likely the fakevideosink plugin contained therein). If I install gst-plugins-bad into an environment with a webgkitgtk br

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

Timothy Sample schreef op di 21-12-2021 om 11:36 [-0500]: > +    (limit (@ (name "auth_timeout")) "6") Are there any good reasons for having a timeout at all? (Except for the local-user denial of service, but local users can do "guix build -f something-that-allocates-almost-all-memory

bug#52375: webkitgtk page crashes on core-updates-frozen

Hello Jack, Jack Hill writes: > I asked about this issue on #webkitgtk:gnome.org on IRC. It turns out > that what's missing from my environment is gst-plugins-bad (most > likely the fakevideosink plugin contained therein). If I install > gst-plugins-bad into an environment with a webgkitgtk bro

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

Hi Leo, Leo Famulari writes: > On Tue, Dec 21, 2021 at 04:31:27AM -0500, Timothy Sample wrote: >> [1] https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/NEWS#L2487 >> [2] https://bugs.freedesktop.org/show_bug.cgi?id=86431#c3 >> >> After reading that I tried with the timeout bumped up to a m

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

On Tue, Dec 21, 2021 at 04:31:27AM -0500, Timothy Sample wrote: > [1] https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/NEWS#L2487 > [2] https://bugs.freedesktop.org/show_bug.cgi?id=86431#c3 > > After reading that I tried with the timeout bumped up to a minute, and > the X200 booted into GDM

bug#24496: offloading should fall back to local build after n tries

Hi, Maxim Cournoyer skribis: > I just reviewed this commit, and don't see anywhere where the behavior > would have changed. The discarding happens here: > > - (if (and node (< load 2.) (>= space %minimum-disk-space)) > + (if (and node > + (or (not threshold) (<

bug#52702: Cannot install a package from a `nar' archive without network access.

Hello, I cannot get Guix to install a package from a `nar' archive without network access. Here are the steps to reproduce the unexpected behaviour : These commands : ┌ │ guix install hello │ guix archive --export -r hello > hello.nar │ guix remove hello │ guix package --delete-generatio

bug#52694: time-machine error when leaping from version-1.2.0 to version-1.4.0

Hello, zimoun writes: > Hi Carl, > > On Mon, 20 Dec 2021 at 17:28, Carl Dong wrote: > >> $ guix time-machine --branch=version-1.2.0 -- time-machine >> --commit=6dffced09ecda024e0884e352778c221ad066fd6 -- describe > > This works for me: > > $ guix time-machine --branch=version-1.2.0 -- time-m

bug#52139: jupyter trying to modify /gnu/store

Hi Alexander, > [W 13:52:18.502 LabApp] 500 PUT /lab/api/workspaces/lab?1639227138494 > (127.0.0.1): [Errno 30] Read-only file system: > '[user]/.guix-profile/etc/jupyter/lab' I’ve fixed this via https://github.com/guix-science/guix-science/commit/ca5d2b79cc730f6d52f93f4e7347102b620ed988 Cheers

bug#51968: Missing dependency for Xournal++

Alexander Asteroth writes: > On Mon, Dec 20 2021, 14:47:24, Daniel Meißner > wrote: >>> I can reproduce the missing icons issue by running >>> guix shell --pure -f xournalpp-fix.scm -- xournalpp >>> >>> as suggested below. Wondering why the icons are not missing when I run >>> xournalpp in

bug#52552: [PATCH 1/2] gnu: Add python-pydbus.

* gnu/packages/python-xyz (python-pydbus): New variable. --- gnu/packages/python-xyz.scm | 21 + 1 file changed, 21 insertions(+) diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm index 2af4794019..35590aece2 100644 --- a/gnu/packages/python-xyz.scm +++ b/

bug#52552: [PATCH 2/2] gnu: pantalaimon: Propagate python-pydbus and python-notify2.

* gnu/packages/matrix.scm: Import (gnu packages glib). (pantalaimon): [native-inputs]: Change formatting, add python-pygobject. [propagated-inputs]: Add python-pydbus and python-notify2. --- gnu/packages/matrix.scm | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/gnu

bug#51968: Missing dependency for Xournal++

Hi, Alexander Asteroth schreef op di 21-12-2021 om 09:45 [+0100]: > [...] > In the meantime I found that as well. But the documentation (from my > perspective) is unfortunately incomplete. It neither specifies the > full > semantics (without looking into the macro-code) ‘Modify the given package

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

Hello, I dug out an old HDD, put it in my X200, and was able to reproduce this. Eventually I was able to log in to the thing by fiddling with the “auth_timeout” parameter in the D-Bus config. Josselin Poiret writes: > [...] > > Would it be possible to get both the elogind strace and the dbus lo

bug#52574: Cross-compiling glib failure

Hi, Maxime Devos skribis: > When compiling natively, we have the convenient 'with-build-variables' > procedure. Maybe we can have a 'with-cross-build-variables' for when > cross-compiling? > > That could be used in the 'gnu', etc. build systems as well, reducing > some duplication between build

bug#51968: Missing dependency for Xournal++

Hi Daniel, On Mon, Dec 20 2021, 14:47:24, Daniel Meißner wrote: >> I can reproduce the missing icons issue by running >> >>> guix shell --pure -f xournalpp-fix.scm -- xournalpp >> >> as suggested below. Wondering why the icons are not missing when I run >> xournalpp in my environment I discover