bug#60056: [PATCH RFC 1/6] build: Add gnu-build-system v2.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>> * guix/build/gnu-build-system2.scm: New file.
>> * Makefile.am (MODULES): Register it.
>> * guix/build-system/gnu2.scm: Use it.
>
> I won’t be able to review it in the coming days; a quick note:
>
>   • Changes to ‘gnu-build-system’ need thorough review, so don’t
> hesitate to ping me and others in the “core” team if nothing comes
> up, but don’t interpret silence as consent.

OK.  I've used the etc/teams.scm script output to CC the core team
members.  Hopefully it helped to ping them (did it for you?).

>   • I’m reluctant to duplicating ‘gnu-build-system’, even if it’s
> temporary.  I think now’s the right time for changes in
> ‘core-updates’ so we could make those changes there instead.

Yes, this is somewhat of a draft to allow people to test on master,
which lowers the cost (of building stuff).  If and when we decide to go
forward with it, I'll make the change to gnu-build-system directly on
core-updates.

-- 
Thanks,
Maxim

bug#60109: gnome-boxes and distributions

[Denis 'GNUtoo' Carikli]

Hi,

I've installed gnome-boxes and I found out that it proposes to download
and run many distribution installers.

As it contains many non-FSDG compliant distributions, many of these
distributions probably contain nonfree firmwares at least.

Not all distributions are problematic though, as it contain some FSDG
compliant distributions.

Denis.


pgpPPabvl5yni.pgp
Description: OpenPGP digital signature

bug#60026: Failed to compute derivation bug

[Joseph Turner via Bug reports for GNU Guix]

zimoun  writes:

> What are the resources (CPU/RAM/storage) of this rented VPS?

`du -sh /gnu/store` reveals 423M and `du -sh /` reveals 5G. I doubt that
storage is an issue here.

bug#60026: Failed to compute derivation bug

[Joseph Turner via Bug reports for GNU Guix]

I just tried one more time before upgrading and got this:

Backtrace:
  15 (primitive-load 
"/gnu/store/kb4ygpgdg1db86321s0hq0amclsq11gq-compute-guix-derivation")
In ice-9/eval.scm:
155:9 14 (_ _)
159:9 13 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 12 (with-fluid* _ _ _)
152:2 11 (with-fluid* _ _ _)
In ./guix/store.scm:
  2170:24 10 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1998:8  9 (_ _)
In ./guix/gexp.scm:
   299:22  8 (_ _)
   1180:2  7 (_ _)
   1046:2  6 (_ _)
892:4  5 (_ _)
In ./guix/store.scm:
  2055:12  4 (_ #)
   1403:5  3 (map/accumulate-builds # 
# ?)
  1419:15  2 (_ # _ _)
   739:13  1 (process-stderr _ _)
In unknown file:
   0 (display "substitute: \r" #)

ERROR: In procedure display:
In procedure fport_write: Broken pipe


Josselin Poiret  writes:

> Didn't think bullseye would be shipping 1.2, you may have better luck
> with the bookworm package (1.3.0) or the sid package (1.4.0rc-2).  You
> can also follow the manual installation procedure from the manual.

If you'd like me explore this issue a bit before upgrading, I'm happy to
hold off.

Joseph

bug#60026: Failed to compute derivation bug

[Joseph Turner via Bug reports for GNU Guix]

Thanks for your help!

zimoun  writes:

> What are the resources (CPU/RAM/storage) of this rented VPS?

1 core, 1GB ram, 20GB storage

Joseph

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> Hello Ludo, sorry to say I attempted your modprobe patch that uses
> (parameterize ((default-environment-variables …

Bah, turns out it’s trickier than this.  See
.

I figured I could test it in a VM.  I ended up with a minimal change,
pushed in commit b1aef25453067004279c4267cf25e8d6d365890d, that lets
modprobe load uvesafb for good (it was all about setting
‘LINUX_MODULE_DIRECTORY’).

Let me know if anything’s amiss!

Thanks,
Ludo’.

bug#60104: Hiccups installing GNU Guix 1.4.0rc2 system

[Ludovic Courtès]

Hi,

"J. Sims"  skribis:

> I managed to successfully install the GNU Guix 1.4.0rc2 system iso on
> an HP Dev One laptop (with help from USB stuff for
> networking). Everything mostly went as expected, except after the
> installation I got a screen saying crypttab couldn't find a specific
> partition.

What’s crypttab?  At which point exactly does this screen appears:
before GRUB, after GRUB, once the Linux kernel has booted?

> I assume this was something left over from a previous OS installation
> since wiping the partitions with cfdisk and then installing worked
> fine. Note that while my initial install attempts did use encryption,
> the final (successful) one did not; I don't think this has any effect
> one way or the other on the viability of installation since I ran into
> the same issue both with and without an encrypted Guix installation
> before wiping the partitions.

OK.

> Hopefully it should be simple enough to just completely rewrite the partition 
> table during installation and sidestep this issue.

Normally the installer will rewrite the partition table, unless (I
think) you choose to keep things unchanged.

Thanks,
Ludo’.

bug#60106: [Shepherd 0.9.3] ‘system*’ replacement cannot be passed environment variables

[Ludovic Courtès]

As we found out while debugging , the
Shepherd 0.9.3, with its ‘system*’ replacement (aka. ‘spawn-command’),
makes it very hard to spawn a command with different environment
variables.

The following options don’t work:

  • Changing shepherd’s own environment variables with ‘setenv’ for
instance: ‘spawn-command’ calls ‘fork+exec-command’, whose default
#:environment-variables is provided by the
‘default-environment-variables’ parameter, which gets its default
value at when shepherd starts.  There’s no environment variable
inheritance, contrary to the real ‘system*’.

  • Parameterizing ‘default-environment-variables’:

   (parameterize ((default-environment-variables …))
 (system* …))

That won’t work because ‘spawn-command’ delegates to the process
monitoring fiber, which has a different dynamic state and thus
doesn’t see this change.

  • Even a plain (set! default-environment-variables …) won’t work,
probably due to inlining within (shepherd services).

I think we’ll have to add a parameter to ‘spawn-command’ to specify
environment variables.

Ludo’.

bug#60002: installer console garbled on 1984.is VPS

[pelzflorian (Florian Pelz)]

Attila Lendvai  writes:
> their response: "I changed the video mode in libvirt to virtio instead of the 
> default cirrus."

Yes yes, now that you mention cirrus, yhetil.org turns up results:

https://issues.guix.gnu.org/36069

Could you test that patch maybe?  Well of course it would maybe require
the admins to switch you back to cirrus …


> 1) i cannot switch virtual
> consoles,

I guess you could have selected shell-based installation in the
graphical installer, it just wasn’t visible.


> 2) there's no DHCP on the network, i.e. it requires manual configuration 
> using a shell.

Maybe there’s no DHCP because the graphical installer lets you choose
which networking device you want to use.

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Desperately I tried also adding fsync, to no avail, both issues remain.
Non-working patch attached.

Maybe dynamic-wind is an inappropriate pattern here?

If I interrupt installation using Ctrl-C (which I normally don’t,
instead I unplug Ethernet), then I have to press Ctrl-C twice.  Maybe
that could be related to why I need to resume twice?

I’m in the dark.

Regards,
Florian

does not help

diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm
index 5f720f6641..f5935a29c9 100644
--- a/gnu/installer/final.scm
+++ b/gnu/installer/final.scm
@@ -201,6 +201,12 @@ (define (assert-exit x)
  (stop-service 'guix-daemon)
  (copy-file database-file saved-database)
 
+ ;; Sync it to the filesystem.
+ (let* ((flags O_RDONLY)
+(fd (open saved-database flags)))
+   (fsync fd)
+   (close fd))
+
  (mount-cow-store (%installer-target-dir) backing-directory))
(lambda ()
  ;; We need to drag the guix-daemon to the container MNT
@@ -218,8 +224,16 @@ (define (assert-exit x)
  ;; alive.
  (stop-service 'guix-daemon)
 
- ;; Restore the database and restart it.
+ ;; Restore the database.
  (copy-file saved-database database-file)
+
+ ;; Sync it to the filesystem.
+ (let* ((flags O_RDONLY)
+(fd (open database-file flags)))
+   (fsync fd)
+   (close fd))
+
+ ;; And restart guix-daemon.
  (start-service 'guix-daemon)
 
  ;; Finally umount the cow-store and exit the container.

bug#59546: qutebrowser and icecat stuck in infinite browser checks (cloudflare) on applicable sites

[bdju]

On Thu Dec 15, 2022 at 7:26 AM CST, Maxim Cournoyer wrote:
> That's a good lead; could you please test qutebrowser in Guix vs
> qutebrowser on another distribution yourself and confirm this hypothesis
> (that it works elsewhere?), and post your finings here?  If you can do
> that and post your finding, I we can reopen the ticket, as we'll have
> something actionable to look at.
>

I'm able to pass the browser check in a matter of seconds and log in to
GitLab from my PineBook Pro running postmarketOS (Alpine-based) using
qutebrowser.

Here is the :version output from the working qutebrowser:

qutebrowser v2.5.2
Git commit:
Backend: QtWebEngine 5.15.3, based on Chromium 87.0.4280.144
Qt: 5.15.6

CPython: 3.11.1
PyQt: 5.15.7

sip: 6.6.2
colorama: 0.4.6
jinja2: 3.1.2
pygments: 2.13.0
yaml: 6.0
adblock: 0.6.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebEngine: 5.15.6
PyQt5.QtWebKitWidgets: no
pdf.js: no
sqlite: 3.40.0
QtNetwork SSL: OpenSSL 3.0.7 1 Nov 2022

Style: QFusionStyle
Platform plugin: wayland
OpenGL: OpenGL ES
Platform: Linux-5.18.0-aarch64-with, 64bit
Linux distribution: postmarketOS edge (alpine)
Frozen: False
Imported from /usr/lib/python3.11/site-packages/qutebrowser
Using Python from /usr/bin/python3
Qt library executable path: /usr/lib/qt5/libexec, data path: /usr/share/qt5

Paths:
cache: /home/bdju/.cache/qutebrowser
config: /home/bdju/.config/qutebrowser
data: /home/bdju/.local/share/qutebrowser
runtime: /run/user/10001/qutebrowser
system data: /usr/share/qutebrowser

Autoconfig loaded: no
Config.py: /home/bdju/.config/qutebrowser/config.py has been loaded
Uptime: 0:02:55


guix version info for comparison:

qutebrowser v2.5.2
Git commit: 
Backend: QtWebEngine 5.15.5, based on Chromium 87.0.4280.144
Qt: 5.15.5

CPython: 3.9.9
PyQt: 5.15.5

sip: 6.6.1
colorama: 0.4.4
jinja2: 3.1.1
pygments: 2.12.0
yaml: 6.0
adblock: no
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebEngine: 5.15.5
PyQt5.QtWebKitWidgets: no
pdf.js: no
sqlite: 3.36.0
QtNetwork SSL: OpenSSL 1.1.1s  1 Nov 2022

Style: QFusionStyle
Platform plugin: xcb
OpenGL: Intel Open Source Technology Center, 3.0 Mesa 21.3.8
Platform: Linux-6.0.8-gnu-x86_64-with-glibc2.33, 64bit
Linux distribution: Guix System (unknown)
Frozen: False
Imported from
/gnu/store/675pkhpvbvi0yai1bggkkaj3h1xy2xrb-qutebrowser-2.5.2/lib/python3.9/site-packages/qutebrowser
Using Python from
/gnu/store/avmnzy8djp42r5926cwznz6ls9gablf8-python-wrapper-3.9.9/bin/python
Qt library executable path:
/gnu/store/mgkd6lgihvqv9n1rlsqfv2rv0zq9whnh-qtbase-5.15.5/lib/qt5/libexec,
data path:
/gnu/store/mgkd6lgihvqv9n1rlsqfv2rv0zq9whnh-qtbase-5.15.5/share/qt5
OS Version: 

--- /etc/os-release ---
NAME="Guix System"
ID=guix
PRETTY_NAME="Guix System"
LOGO=guix-icon
DOCUMENTATION_URL="https://guix.gnu.org/en/manual;

Paths:
cache: /home/brad/.cache/qutebrowser
config: /home/brad/.config/qutebrowser
data: /home/brad/.local/share/qutebrowser
runtime: /run/user/1000/qutebrowser

Autoconfig loaded: no
Config.py: /home/brad/.config/qutebrowser/config.py has been loaded
Uptime: 1 day, 3:11:30

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Hi Ludo…

Ludovic Courtès  writes:
> This time, I believe we only ever copy the database when we’re sure no
> guix-daemon process is accessing it.

Failure.  In addition to your partially helpful patch from before
(with which a second resume now works most of the time), I now tried
further the new change:

diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm
index 044f79372b..360b34d8cb 100644
--- a/gnu/installer/final.scm
+++ b/gnu/installer/final.scm
@@ -196,14 +196,15 @@ (define (assert-exit x)
  ;; the loaded cow-store locale files will prevent umounting.
  (install-locale locale)

- ;; Save the database, so that it can be restored once the
- ;; cow-store is umounted.
+ ;; Stop the daemon and save the database, so that it can be
+ ;; restored once the cow-store is umounted.
+ (stop-service 'guix-daemon)
  (copy-file database-file saved-database)
+
  (mount-cow-store (%installer-target-dir) backing-directory))
(lambda ()
  ;; We need to drag the guix-daemon to the container MNT
  ;; namespace, so that it can operate on the cow-store.
- (stop-service 'guix-daemon)
  (start-service 'guix-daemon (list (number->string (getpid

  (setvbuf (current-output-port) 'none)


No additional effect. :(  Perhaps at that time, the guix-daemon isnt
doing anything anyway (though the addition makes sense in general and
may help some users).  There are the same two problems, needing to
resume twice each time and eventually not being able to resume at all
(perhaps some multi-core issue?).  I sent installer-dump-89be04d5.

I tried interrupting the Ethernet on the same machine but with an
installed 1.4.0rc2 Guix System during `guix system reconfigure`.
This has no issues…  There must be corruption in the installer.

Regards,
Florian

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

[pelzflorian (Florian Pelz)]

Hello Ludo, sorry to say I attempted your modprobe patch that uses
(parameterize ((default-environment-variables …

No good.  Screen is black.  Same [ modprobe ] failure in dmesg on QEMU
and on real AMD hardware.

There are workarounds by surrounding modprobe within strace or
alternatively using kernel-module-loader-service (attached; but again,
without the file-exists? check, this would cause new issues on some
machines that dont need uvesafb).

A stupid

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index f6f1923121..a99cf09e31 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -289,6 +289,7 @@ (define (uvesafb-shepherd-service _)
  (provision '(maybe-uvesafb))
  (requirement '(file-systems))
  (start #~(lambda ()
+   (sleep 1)
 (or (file-exists? "/dev/fb0")
 (invoke #+(file-append kmod "/bin/modprobe")
 "uvesafb"


fails though.

All bad…

Regards,
Florian
diff --git a/gnu/system/install.scm b/gnu/sysdiff --git a/gnu/system/install.scm b/gnu/system/install.scm
index f6f1923121..2a1f401536 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -40,6 +40,7 @@ (define-module (gnu system install)
   #:use-module (gnu system locale)
   #:use-module (gnu services avahi)
   #:use-module (gnu services dbus)
+  #:use-module (gnu services linux)
   #:use-module (gnu services networking)
   #:use-module (gnu services shepherd)
   #:use-module (gnu services ssh)
@@ -283,29 +284,22 @@ (define %nscd-minimal-caches
 ;; These define a service to load the uvesafb kernel module with the
 ;; appropriate options.  The GUI installer needs it when the machine does not
 ;; support Kernel Mode Setting.  Otherwise kmscon is missing /dev/fb0.
-(define (uvesafb-shepherd-service _)
-  (list (shepherd-service
- (documentation "Load the uvesafb kernel module if needed.")
- (provision '(maybe-uvesafb))
- (requirement '(file-systems))
- (start #~(lambda ()
-(or (file-exists? "/dev/fb0")
-(invoke #+(file-append kmod "/bin/modprobe")
-"uvesafb"
-(string-append "v86d=" #$v86d "/sbin/v86d")
-"mode_option=1024x768"
- (respawn? #f)
- (one-shot? #t
-
-(define uvesafb-service-type
-  (service-type
-   (name 'uvesafb)
-   (extensions
-(list (service-extension shepherd-root-service-type
- uvesafb-shepherd-service)))
-   (description
-"Load the @code{uvesafb} kernel module with the right options.")
-   (default-value #t)))
+(define uvesafb-config
+  (computed-file "uvesafb.conf"
+ #~(with-output-to-file #$output
+ (lambda ()
+   (display
+(string-append "options uvesafb"
+  " " "v86d=" #$v86d "/sbin/v86d"
+   " " "mode_option=1024x768"))
+
+(define uvesafb-services
+  (list (service kernel-module-loader-service-type
+ '("uvesafb"))
+   (simple-service 'uvesafb-config etc-service-type
+ (list `("modprobe.d/uvesafb.conf"
+ ,uvesafb-config)
+   
 
 (define* (%installation-services #:key (system (or (and=>
 (%current-target-system)
@@ -450,8 +444,7 @@ (define bare-bones-os
  ;; installer.  Some may also need a kernel parameter like nomodeset
  ;; or vga=793, but we leave that for the user to specify in GRUB.
  `(,@(if (supported-package? v86d system)
- (list (service uvesafb-service-type))
- '())
+ uvesafb-services)
 
 (define %issue
   ;; Greeting.

bug#60056: [PATCH RFC 1/6] build: Add gnu-build-system v2.

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> * guix/build/gnu-build-system2.scm: New file.
> * Makefile.am (MODULES): Register it.
> * guix/build-system/gnu2.scm: Use it.

I won’t be able to review it in the coming days; a quick note:

  • Changes to ‘gnu-build-system’ need thorough review, so don’t
hesitate to ping me and others in the “core” team if nothing comes
up, but don’t interpret silence as consent.

  • I’m reluctant to duplicating ‘gnu-build-system’, even if it’s
temporary.  I think now’s the right time for changes in
‘core-updates’ so we could make those changes there instead.

Thanks,
Ludo’.

bug#60002: installer console garbled on 1984.is VPS

[Attila Lendvai]

close
done

> So the admins are using a Web interface to QEMU. Which one? What -vga > 
> option is it using?

their response: "I changed the video mode in libvirt to virtio instead of the 
default cirrus."

this has fixed both the garbling of text, and the resizing of the console to 
accommodate for the window based installer.

maybe it's worth mentioning in the/a troubleshooting section of the doc. i 
couldn't find anything about it using websearch.

my only remaining issue with the installer is that the menu based installation 
workflow is not possible when 1) i cannot switch virtual consoles, and 2) 
there's no DHCP on the network, i.e. it requires manual configuration using a 
shell.

but i'll report that as a different issue.

thank you,

- attila

bug#59256: Emacs-guix tab-completion returns gexp error

[calcium via Bug reports for GNU Guix]

The problem can be tracked back from elisp procedure 
`guix-pcomplete-search-in-help` in guix-pcomplete.el to `guix-help-string` in 
guix-misc.el, to this problematic code :
```
(guix-eval-read "(help-string )")
```

The procedure help-string exists, as can be seen below :
```
(guix-eval-read
 "(begin
  (use-modules (ice-9 format))
  (format #f \"~s\"
   help-string))") ;; => "#"
```

but the object that `(help-string)` returns seems incompatible with guile's own 
repl/shell 

The solution might be to just change the `help-string` procedure to return 
another kind of object, or to fix guile's repl/shell for that kind of object.

bug#59546: qutebrowser and icecat stuck in infinite browser checks (cloudflare) on applicable sites

[Maxim Cournoyer]

Hi,

"bdju"  writes:

[...]

>> I've had that too with Gitlab when using Icecat.  Sadly, it has nothing
>> to do with Guix but with how Cloudfare and the website identifies
>> browsers.
>>
>> For example, I had found out that by using a Windows Firefox 83 user
>> agent, I was able to login into Gitlab (using this plugin:
>> https://gitlab.com/ntninja/user-agent-switcher).  I reported the issue
>> to Gitlab, and they could apparently fixed it on their side (not yet
>> deployed) [0]
>>
>> [0]  https://gitlab.com/gitlab-org/gitlab/-/issues/345328
>>
>> I think other sites or CloudFare must be similarly faulty, or require
>> fingerprinting which is guarded against out-of-the-box in IceCat.
>>
>> Closing, as I doubt Guix has something to do with it.  If you find
>> something to the contrary, let us know!

> I too have fixed it in the past by switching my user agent. I opened and
> closed a similar bug some months or years back. That solution stopped
> working. I have consulted with folks in the qutebrowser IRC about this
> issue several times and it is not affecting everyone there, so it
> definitely seems guix-related to me. Something about our packages must
> make the browser(s) look odd to these infernal browser checks.

That's a good lead; could you please test qutebrowser in Guix vs
qutebrowser on another distribution yourself and confirm this hypothesis
(that it works elsewhere?), and post your finings here?  If you can do
that and post your finding, I we can reopen the ticket, as we'll have
something actionable to look at.

-- 
Thanks,
Maxim

bug#59546: qutebrowser and icecat stuck in infinite browser checks (cloudflare) on applicable sites

[bdju]

On Wed Dec 14, 2022 at 10:32 PM CST, Maxim Cournoyer wrote:
> Hello,
>
> "bdju"  writes:
>
> > I have hit this issue before, but not in a while. I don't know for sure
> > when the issue came back as it only matters for the initial login or
> > visit of the offending sites, so if you manage to get past you'll be
> > good until your cookie expires or gets deleted somehow. I got logged out
> > of many sites in qutebrowser recently and was made aware of the issue
> > being back. I also tested in icecat where some sites I still had a
> > cookie, but I managed to find one with a browser check and it indeed
> > never completes (can leave it open hours or even more than a day).
>
> > Some sites to test with include:
> > https://www.livechart.me/ (must click login button, main page works)
> > https://www.gitlab.com/ (again must click log in to start the check)
> >
> > Since this is happening in both icecat and qutebrowser with different
> > user agents and everything, I suspect a guix-related issue. I found that
> > at least one other person on IRC was also experiencing the infinite
> > browser checks. I use a few sites daily that are now unusable on my Guix
> > System machine due to these browser checks, so a fix would be very much
> > appreciated if anyone could figure this out.
>
> I've had that too with Gitlab when using Icecat.  Sadly, it has nothing
> to do with Guix but with how Cloudfare and the website identifies
> browsers.
>
> For example, I had found out that by using a Windows Firefox 83 user
> agent, I was able to login into Gitlab (using this plugin:
> https://gitlab.com/ntninja/user-agent-switcher).  I reported the issue
> to Gitlab, and they could apparently fixed it on their side (not yet
> deployed) [0]
>
> [0]  https://gitlab.com/gitlab-org/gitlab/-/issues/345328
>
> I think other sites or CloudFare must be similarly faulty, or require
> fingerprinting which is guarded against out-of-the-box in IceCat.
>
> Closing, as I doubt Guix has something to do with it.  If you find
> something to the contrary, let us know!
>
> -- 
> Thanks,
> Maxim

I too have fixed it in the past by switching my user agent. I opened and
closed a similar bug some months or years back. That solution stopped
working. I have consulted with folks in the qutebrowser IRC about this
issue several times and it is not affecting everyone there, so it
definitely seems guix-related to me. Something about our packages must
make the browser(s) look odd to these infernal browser checks. I know
that the issue is cloudflare essentially bullying those of us with more
niche setups, but cloudflare has sadly infected most of the Web, so we
have to play their game. I fear the number of qutebrowser users on guix
is in the single digits and so often I'm running into odd problems with
no solution, that again rarely seems to affect people on the other
distros when I go to ask for help. I think our Qt version is almost
always old which probably doesn't help.
I doubt I have the proper evidence to convince you this is guix's fault,
but just know that if you close this issue my problem may never be
solved (although it may never get solved either way honestly).

bug#60026: Failed to compute derivation bug

[zimoun]

Hi,

On Tue, 13 Dec 2022 at 10:20, Joseph Turner via Bug reports for GNU Guix 
 wrote:

> This occurred on a guix installation on a foreign distro, yes. On a
> VPS I rent, which I recently upgraded to Debian 11. Guix was installed
> using `apt install guix`.

What are the resources (CPU/RAM/storage) of this rented VPS?


Cheers,
simon