bug#53180: eog 40.3 build error: include file not found

2022-01-13 Thread raid5atemyhomework via Bug reports for GNU Guix
> > Yeah nautilus doesn't build at the moment for a similar reason as eog, I > > just posted a patch on https://issues.guix.gnu.org/53195 to fix it. I > > can push it shortly. > > Closing, thanks for fixing it Pierre. Confirming that gnome-desktop now builds completely, thanks Pierre and

bug#53180: eog 40.3 build error: include file not found

2022-01-11 Thread raid5atemyhomework via Bug reports for GNU Guix
> > > Eog and Epiphany should be fixed with Guix at > > > f7afefba00b65e94d073af3af2278a076c89dbc1 or later. > > > > Ha, it seems I'm late to the party. Thanks Guillaume! Will check. > > Unfortunately it seems to still be broken for me? It works with `guix build eog`, but *not* with `guix

bug#53180: eog 40.3 build error: include file not found

2022-01-11 Thread raid5atemyhomework via Bug reports for GNU Guix
> > Eog and Epiphany should be fixed with Guix at > > f7afefba00b65e94d073af3af2278a076c89dbc1 or later. > > Ha, it seems I'm late to the party. Thanks Guillaume! Will check. Unfortunately it seems to still be broken for me? ``` $ guix --version guix (GNU Guix)

bug#53180: eog 40.3 build error: include file not found

2022-01-11 Thread raid5atemyhomework via Bug reports for GNU Guix
> Eog and Epiphany should be fixed with Guix at > f7afefba00b65e94d073af3af2278a076c89dbc1 or later. Ha, it seems I'm late to the party. Thanks Guillaume! Will check. Thanks raid5atemyhomework

bug#53180: eog 40.3 build error: include file not found

2022-01-11 Thread raid5atemyhomework via Bug reports for GNU Guix
This seems to be the first bad commit. CCing Tobias Geerinckx-Rice. ``` $ git bisect good 294476022f19139e290acb448d4575de0f851673 is the first bad commit commit 294476022f19139e290acb448d4575de0f851673 Author: Tobias Geerinckx-Rice Date: Sun Jan 9 02:06:58 2022 +0100 gnu: libportal:

bug#53180: eog 40.3 build error: include file not found

2022-01-10 Thread raid5atemyhomework via Bug reports for GNU Guix
On guix `83abdc8371d90b6d4591a69fae5585a2a99c1627`, I get a build error for eog 40.3 while trying to upgrade my system that has `gnome-desktop-service-type` installed. ``` [52/70] Compiling C object src/libeog.so.p/eog-util.c.o FAILED: src/libeog.so.p/eog-util.c.o gcc -Isrc/libeog.so.p -Isrc

bug#53043: Dash To Dock 71 not working properly with Gnome Shell 41

2022-01-06 Thread raid5atemyhomework via Bug reports for GNU Guix
Hello, > Hi, > > Am Freitag, dem 07.01.2022 um 03:56 + schrieb raid5atemyhomework: > > > Hello Liliana, > > [...] > > It may be a related bug, but this may also be unique to how Guix > > packages both programs. So I want to know if other users on Guix are > > seeing the same thing as well. >

bug#53043: Dash To Dock 71 not working properly with Gnome Shell 41

2022-01-06 Thread raid5atemyhomework via Bug reports for GNU Guix
Hello Liliana, > Hi, > > Am Donnerstag, dem 06.01.2022 um 04:35 + schrieb > raid5atemyhomework: > > > I recently upgraded, and on reboot found that the Gnome Shell extension > > Dash to Dock was no longer working properly. > > Instead of displaying my favorite applications on the bottom

bug#53043: Dash To Dock 71 not working properly with Gnome Shell 41

2022-01-05 Thread raid5atemyhomework via Bug reports for GNU Guix
Hello Guix World, I recently upgraded, and on reboot found that the Gnome Shell extension Dash to Dock was no longer working properly. Instead of displaying my favorite applications on the bottom dock, it only displays the "applications" icon. Running applications are also not displayed. I

bug#53021: [PATCH] gnu: zfs: Update to 2.1.2.

2022-01-05 Thread raid5atemyhomework via Bug reports for GNU Guix
>From e12c75a2c4a6430a15511d1e8aba77cde90042f6 Mon Sep 17 00:00:00 2001 From: raid5atemyhomework Date: Wed, 5 Jan 2022 16:19:34 +0800 Subject: [PATCH] gnu: zfs: Update to 2.1.2. * gnu/packages/file-systems.scm (zfs): Update to 2.1.2. --- gnu/packages/file-systems.scm | 4 ++-- 1 file changed, 2

bug#51498: onionshare build is broken

2021-11-04 Thread raid5atemyhomework via Bug reports for GNU Guix
> > Can you test it again? I was able to build it just now with commit > > c0c974ad96767a1e207fe2823cd5479605485415. I was also able to build it > > with your provided commit above. > > Having diverging results suggests a nondeterministic build, which is bad, > right? I'm running on a Guix

bug#51498: onionshare build is broken

2021-11-04 Thread raid5atemyhomework via Bug reports for GNU Guix
> > Can you test it again? I was able to build it just now with commit > c0c974ad96767a1e207fe2823cd5479605485415. I was also able to build it > with your provided commit above. Having diverging results suggests a nondeterministic build, which is bad, right? I'm running on a Guix System

bug#51498: onionshare build is broken

2021-10-29 Thread raid5atemyhomework via Bug reports for GNU Guix
CC Tobias

bug#51498: onionshare build is broken

2021-10-29 Thread raid5atemyhomework via Bug reports for GNU Guix
onionshare is broken on master 89d8417; `guix time-machine --commit=89d8417b371f3918f0508bbc561675ec100a6add -- build onionshare` results in: ``` _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tests/gui_base_test.py:88: in new_share_tab

bug#50919: [PATCH] gnu: Update zfs to 2.1.1.

2021-09-30 Thread raid5atemyhomework via Bug reports for GNU Guix
Seems no major feature from 2.1.0 to 2.1.1 that require adaptation to a Guix operating system. Did a basic compile check. Thanks raid5atemyhomework >From 4f4a8c8688a9e76d8d1c7b6f0643294273be5e70 Mon Sep 17 00:00:00 2001 From: raid5atemyhomework Date: Thu, 30 Sep 2021 23:31:41 +0800 Subject:

bug#50918: "server is somewhat slow" error is more annoying than helpful

2021-09-30 Thread raid5atemyhomework via Bug reports for GNU Guix
So for the past several months I have been getting errors like these: ``` guix substitute: warning: while fetching https://ci.guix.gnu.org/nar/lzip/k9wmrk5m91599lk8gd4rc7h4df642qw0-curl-7.74.0: server is somewhat slow guix substitute: warning: try `--no-substitutes' if the problem persists guix

bug#49710: [PATCH v2] gnu: Update OpenZFS to 2.1.0.

2021-08-01 Thread raid5atemyhomework via Bug reports for GNU Guix
BUMP

bug#49710: [PATCH v2] gnu: Update OpenZFS to 2.1.0.

2021-07-23 Thread raid5atemyhomework via Bug reports for GNU Guix
Bleah, forgot to *completely* amend the commit that was using the release candidate... >From 14446422d6f7873b29d2fe04a9528de867b854b8 Mon Sep 17 00:00:00 2001 From: raid5atemyhomework Date: Fri, 23 Jul 2021 23:01:30 +0800 Subject: [PATCH] gnu: Update OpenZFS to 2.1.0. *

bug#47442: guix system delete-generations does not use bootloader configuration

2021-07-23 Thread raid5atemyhomework via Bug reports for GNU Guix
Bump.

bug#47253: network-manager shepherd services does not wait to be online

2021-07-23 Thread raid5atemyhomework via Bug reports for GNU Guix
Is there any chance any thought will be given over to this, or am I stuck trying to work around a single-threaded "does the job, but not well" Shepherd? I'm beginning to wonder if just using SystemD would work better, especially since it's so popular nearly every daemon package includes support

bug#49710: [PATCH] gnu: Update OpenZFS to 2.1.0.

2021-07-23 Thread raid5atemyhomework via Bug reports for GNU Guix
>From 14446422d6f7873b29d2fe04a9528de867b854b8 Mon Sep 17 00:00:00 2001 From: raid5atemyhomework Date: Fri, 23 Jul 2021 23:01:30 +0800 Subject: [PATCH] gnu: Update OpenZFS to 2.1.0. * gnu/packages/file-systems.scm [zfs]: Update to 2.1.0, add support for new compatibility feature. ---

bug#48519: texlive-bin cannot be installed in a profile

2021-05-19 Thread raid5atemyhomework via Bug reports for GNU Guix
In recent commits, `texlive-bin` cannot be installed in a profile. This can be replicated by doing: guix pull guix install texlive-bin Or with a specific recent commit: guix time-machine --commit=b7c7a61 -- install -p tmp texlive-bin Note that it fails at the "building Tex Live

bug#48395: "You found a bug" in compute-guix-derivation

2021-05-13 Thread raid5atemyhomework via Bug reports for GNU Guix
``` $ guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to 696cf48 (27 new commits)... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git 696cf48 substitute:

bug#47442: guix system delete-generations does not use bootloader configuration

2021-03-28 Thread raid5atemyhomework via Bug reports for GNU Guix
Note as well that keyboard layouts at Grub time are also broken by this. As the keyboard layout is used when accepting passphrases for cryptodisks, this can leave a user potentially unable to boot at all without expert GRUB knowledge, if they selected a passphrase including characters not

bug#47442: guix system delete-generations does not use bootloader configuration

2021-03-27 Thread raid5atemyhomework via Bug reports for GNU Guix
Hello, I use a coreboot that does not have a VGA option rom, which means Grub can't use `gfxterm`, so I have this setting in my `operating-system`: (bootloader-configuration ; ... (terminal-outputs '(console))) This lets me see a boot menu at startup even without the VGA option

bug#47379: "statfs" test in tests/syscall.scm fails with BTRFS file systems.

2021-03-26 Thread raid5atemyhomework via Bug reports for GNU Guix
> btrfs balance moves the free space around so that you have fewer blocks > with extra freed space. I normally run 'btrfs balance start -dusage=70 > -musage=80 $mountpoint'. (unless I have it backwards) I think you do? Usually the numbers for `musage` are smaller I think. There is some old

bug#47253: network-manager shepherd services does not wait to be online

2021-03-20 Thread raid5atemyhomework via Bug reports for GNU Guix
Hello MArk, > [] I'll note, however, that merely waiting up to 30 seconds (orwhatever > timeout you choose) is not, in itself, a robust solution. What > happens if the network is down for more than 30 seconds? What if it > goes down after 'nm-online' checks, but before the dependent service has

bug#47253: network-manager shepherd services does not wait to be online

2021-03-19 Thread raid5atemyhomework via Bug reports for GNU Guix
Hello Mark, > > Of course, the big problem is that Shepherd is single-threadded and > > `nm-online` will block all other bootup. > > That's not good. For the sake of users who are not always connected to > the internet, I'd strongly prefer for the Guix boot process of a desktop > system to not be

bug#47253: network-manager shepherd services does not wait to be online

2021-03-18 Thread raid5atemyhomework via Bug reports for GNU Guix
I have a small number of daemons that need access to the network at startup. I have configured their Shepherd services to require `networking`. However, to my puzzlement, I consistently find that they are unable to access the network at startup. One daemon dies (and gets respawned so often

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-16 Thread raid5atemyhomework via Bug reports for GNU Guix
Here's another error! For *this* instance notice the very slow download speed; other downloads got up to 2MiB/s. If my understanding is correct the SJTUG server is effectively a caching proxy, meaning that the low download speed here probably means that the SJTUG server itself is downloading

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-15 Thread raid5atemyhomework via Bug reports for GNU Guix
> Hi Maxime, > > > On Mon, 2021-03-15 at 00:13 +, raid5atemyhomework via Bug reports for > > GNU Guix wrote: > > > > > Hello all, > > > [...] > > > I recently had to rebuild an OS (because I was dumb; the Guix language > > > fo

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-15 Thread raid5atemyhomework via Bug reports for GNU Guix
Hi Maxime, > On Mon, 2021-03-15 at 00:13 +0000, raid5atemyhomework via Bug reports for GNU > Guix wrote: > > > Hello all, > > [...] > > I recently had to rebuild an OS (because I was dumb; the Guix language > > for shepherd services can easily lead you deadloc

bug#47149: guix system init seems to ignore --fallback

2021-03-14 Thread raid5atemyhomework via Bug reports for GNU Guix
Split off from 46942 Recently I had to rebuild my Guix OS (ummm it was practice for installing Guix, not at all being too overconfident with `guix system --delete-generations` and screwing up a shepherd start service so that shepherd got into an infinite loop in an edge case...). Because the

bug#47147: Guix substituter gives up too easily, causing higher-level commands to fail catastrophically

2021-03-14 Thread raid5atemyhomework via Bug reports for GNU Guix
Split off from 46942 I recently had to rebuild a Guix OS. I ran a modified installer that used two substitute URLs: the SJTUG mirror, and the official Cuirass server in Berlin, listed in that order. Unfortunately, it seems the SJTUG mirror has some reliability problems, during install the

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-14 Thread raid5atemyhomework via Bug reports for GNU Guix
Hello all, Unfortunately, it seems that the SJTU server is somewhat unreliable, I sometimes get random failures in various parts talking to the substitute server, complaining of strange responses from the server: ``` Backtrace: In guix/ui.scm: 2164:12 19 (run-guix-command _ . _) In

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-05 Thread raid5atemyhomework via Bug reports for GNU Guix
Hi zimoun, Thanks, this is a definite improvement and I have set both systems to use it as the first item in `substitute-server`. I'll make a patch for the manual at least, then close this issue once that patch is accepted. So I was thinking of modifying the installer so at least some page

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-05 Thread raid5atemyhomework via Bug reports for GNU Guix
Hi zimoun, > Hi, > > On Fri, 05 Mar 2021 at 14:46, raid5atemyhomework > raid5atemyhomew...@protonmail.com wrote: > > > Are there any other mirror substitute servers aside from `ci.guix.gnu.org`? > > Well, only one in China I AFAIK. > > https://mirrors.sjtug.sjtu.edu.cn/guix > >

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-05 Thread raid5atemyhomework via Bug reports for GNU Guix
Hi all, In case it's useful, here's my `traceroute`, would this be helpful for Guix? I erased some internal IP addresses and omit a few bytes off the source country. After hop 25 `traceroute` couldn't find anything anymore. I annotated the IP addresses to country map. ``` $ sudo `which

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-05 Thread raid5atemyhomework via Bug reports for GNU Guix
Hi zimoun, > Hi, > > On Fri, 05 Mar 2021 at 11:22, raid5atemyhomework via Bug reports for GNU Guix > bug-guix@gnu.org wrote: > > > This can be very slow, including as slow as 4KiB/s at times. > > [...] > > > The problem is not on my ISP, or at least not solely

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-05 Thread raid5atemyhomework via Bug reports for GNU Guix
Hi all, > > - Is there a way to make `guix-daemon` use a Tor proxy? I have two > > systems using Guix, one is a Guix System, the other is using a foreign > > distro, and I'd like to adjust both to use Tor instead since it's faster. > > I saw that`guix-daemon` respects `http_proxy` and

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-05 Thread raid5atemyhomework via Bug reports for GNU Guix
> * Is there a way to make `guix-daemon` use a Tor proxy? I have two systems > using Guix, one is a Guix System, the other is using a foreign distro, and > I'd like to adjust both to use Tor instead since it's faster. I saw that `guix-daemon` respects `http_proxy` and `https_proxy` envvars,

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-05 Thread raid5atemyhomework via Bug reports for GNU Guix
Hello Christopher, > raid5atemyhomework via Bug reports for GNU Guix bug-guix@gnu.org writes: > > > Downloading substitutes from ci.guix.gnu.org is slow from my two Guix-using > > computers. > > One is a pure Guix System install without any channels, the other one is a

bug#46942: ci.guix.gnu.org is slow from my system

2021-03-05 Thread raid5atemyhomework via Bug reports for GNU Guix
Downloading substitutes from ci.guix.gnu.org is slow from my two Guix-using computers. One is a pure Guix System install without any channels, the other one is a foreign Guix install with the-channel-that-cannot-be-named. ``` downloading from

bug#44808: Default to allowing password authentication on leaves users vulnerable

2021-02-10 Thread raid5atemyhomework via Bug reports for GNU Guix
Hi guix users, It strikes me that a better course of action here would be, rather than providing a warning that might not be noticed by the user, to remove the default and force people to explicitly put `password-authentication? #t` or `password-authentication? #f`. That way if I have set up

bug#38929: sane-hpaio not found by simple-scan?

2021-02-10 Thread raid5atemyhomework via Bug reports for GNU Guix
I have a USB-connected HP DeskJet Ink Advantage 1515 printer/scanner. On my own system (this is a full Guix System, not Guix on a foreign distro) I modified the configuration.scm: ```scheme (use-package-modules #;... scanner) (operating-system #;... (services (append #;...

bug#36380: service urandom-seed takes too long on boot

2021-02-07 Thread raid5atemyhomework via Bug reports for GNU Guix
```scheme (define (get-bytevector-n-timed port count max-time) "Read COUNT octets from PORT, blocking as necessary and return a bytevector containing the octets read, and taking no more than MAX-TIME seconds. If fewer bytes are available, a bytevector smaller than COUNT is returned." (define

bug#45512: Feature Request: keyfile support for LUKS volume opening

2020-12-28 Thread raid5atemyhomework via Bug reports for GNU Guix
Consider the following use-case: * I have a boot device including a partition backing `/`. * My `/home` is on a separate RAID array, because my homework is important and I would like to not lose it. * Each disk in the RAID array is *separately* LUKS-encrypted. * This allows me to decommission

bug#45497: Feature Request:dm-integrity mapped devices

2020-12-28 Thread raid5atemyhomework via Bug reports for GNU Guix
Frankly, MD RAID is incomplete without checksum. Checksum is provided in Linux by dm-integrity. Now, LVM2 can actually set up MD RAID with dm-integrity, however: * It doesn't expose all options. * It doesn't support specifying an MD journal for RAID4/5/6 to close the write hole. In

bug#45401: ZFS package not compiling on recent kernel

2020-12-24 Thread raid5atemyhomework via Bug reports for GNU Guix
Installing `zfs` results in the following errors: ``` In file included from /tmp/guix-build-zfs-0.8.5.drv-0/zfs-0.8.5/include/sys/dmu.h:848:0, from /tmp/guix-build-zfs-0.8.5.drv-0/zfs-0.8.5/include/sys/spa.h:44, from

bug#45401: ZFS package not compiling on recent kernel

2020-12-24 Thread raid5atemyhomework via Bug reports for GNU Guix
Looking at recent zfs release note: https://github.com/openzfs/zfs/releases/tag/zfs-0.8.5 and https://github.com/openzfs/zfs/releases/tag/zfs-0.8.6 > * Compatible with 2.6.32 - 5.9 Linux kernels zfs-0.8.6 includes a few "Linux 5.10 compat" but is still not rated for 5.10. Would it be possible

bug#45401: ZFS package not compiling on recent kernel

2020-12-24 Thread raid5atemyhomework via Bug reports for GNU Guix
Looking at recent zfs release note: https://github.com/openzfs/zfs/releases/tag/zfs-0.8.5 and https://github.com/openzfs/zfs/releases/tag/zfs-0.8.6 > * Compatible with 2.6.32 - 5.9 Linux kernels zfs-0.8.6 includes a few "Linux 5.10 compat" but is still not rated for 5.10. Would it be possible