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

raid5atemyhomework via Bug reports for GNU Guix writes: > 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 >

bug#48701: Closed by 48943

Philip Munksgaard writes: > This issue has been fixed by #48943 and should be closed. You can close a bug report by emailing nnn-d...@debbugs.gnu.org where NNN is the bug number. For the body of the email you can say something like "Closing because ".

bug#49435: GRUB keymap is stored on encrypted root.

Barry Kane writes: > The problem: > On a system with encrypted root and using a non-us keymap such as DVORAK > programmer and setting this in the bootloader configuration, the relevant > files > for GRUB to use the keymap are stored on an encrypted partition, thus > requiring the user to

bug#48793: Make guix room available over matrix

bo0od writes: > if guix irc migrated to OFTC OFTC has a problematic registration process. In the registration process they encourage the use of Google captcha. Further there is no mention during the registration process of any alternative account registration options. The use of Google captcha

bug#48552: mesa 20.2.4 is not reproducible

When I run `guix challenge` it shows that these versions of mesa are not reproducible. ``` /gnu/store/2lyzzw7ybsm3s2n7fgqm17n33n62dl7c-mesa-20.2.4 /gnu/store/k72zqqiysk3qcwqj917hmlbvqs8shj0x-mesa-20.2.4 ``` This looks like it could also be related to bug#43849. `guix describe` outputs: ```

bug#48534: gtk+ 3.24.24 is not reproducible

Bone Baboon via Bug reports for GNU Guix writes: > differing file: > /share/icons/hicolor/icon-theme.cache This is the same file that was reported as not being reproducible in <https://issues.guix.gnu.org/30767>.

bug#48534: gtk+ 3.24.24 is not reproducible

`guix challenge` shows that these versions of gtk+ are not reproducible. ``` /gnu/store/5y1z0cl6g8ds86xhn2h9n1pk2hrjhh1h-gtk+-3.24.24 /gnu/store/8057xmgbnb8qkb1fn6jw3xcjx81fs92h-gtk+-3.24.24 /gnu/store/f354nhi011n2sz5vh266h8ss3rhadi1g-gtk+-2.24.32 ``` `guix describe` outputs: ``` Generation 24

bug#48520: rav1e 0.3.5 is not reproducible

`guix describe` outputs: ``` Generation 24 May 12 2021 18:06:24(current) guix d6aeebb repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: d6aeebb23639258311fdfb9dbf5f903079fde51a ``` `guix challenge

bug#48499: hunspell-dict-en-us is not reproducible

hunspell-dict-en-us is not reproducible. The diffoscope output for the README files that are not reproducible show that when the README files are being generated they are created with a date and time. The date and time will be different for each build and this is why they are not reproducible.

bug#40316: core-updates nss not reproducible

I am also getting the same four files that are not reproducible for nss on the master branch. As nss is also not reproducible on master maybe the title of this bug should be changed to "nss not reproducible". `guix describe` outputs: ``` Generation 24 May 12 2021 18:06:24(current) guix

bug#48487: Many guix-* not reproducible

There are many guix-* things that are not reproducible. `guix describe` outputs: ``` Generation 24 May 12 2021 18:06:24(current) guix d6aeebb repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: d6aeebb23639258311fdfb9dbf5f903079fde51a ``` In the

bug#35085: Emacs is not reproducible

Emacs 27.2 is not reproducible. `guix describe` outputs: ``` Generation 24 May 12 2021 18:06:24(current) guix d6aeebb repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: d6aeebb23639258311fdfb9dbf5f903079fde51a ``` `guix challenge emacs` outputs:

bug#48214: inetutils-1.9.4 build fails

. mphxs1iknnz5rfdhcs4i62j22yshqx-inetutils-1.9.4.drv.bz2 Description: Binary data Bone Baboon via Bug reports for GNU Guix writes: > On a x86_64 computer when I run `guix build --no-substitutes --keep-failed > inetutils` the build fails because of one failed test. > > `guix descr

bug#48214: inetutils 1.9.4 builds successfully

Closing bug#48214 because inetutils 1.9.4 now builds successfully even with IPv6 disabled.

bug#48214: inetutils-1.9.4 build fails

I have done several pulls since reporting that inetutils failed to build. I can now build inetutils-1.9.4 successfully. I still have IPv6 disabled. I do not know what the cause of the build failure was. I do not know why it can now build (likely a recent commit). Bone Baboon via Bug reports

bug#48343: Cannot boot after installation

Looks like you are running into many of the problems I had when I installed Guix on a computer. Sergey Petrov writes: > Hi Brendan! It works, I can proceed to system now > > On 5/12/21 10:17 PM, Brendan Tildesley wrote: >> If setting nomodeset is the answer, there is a trick you can use in >>

bug#48213: offlineimap build fails

Mark H Weaver writes: > Hi, > > Bone Baboon via Bug reports for GNU Guix writes: >> On a x86_64 computer when I run `guix build --no-substitutes >> offlineimap` the build fails because the "test_ipv6_available" test >> fails. > > 'offlineimap' i

bug#48352: Haskell cabal new-build fails

I am experiencing an error when I try to compile a Haskell program with Cabal a Haskell build tool. Previously I had Cabal working and was able to compile Haskell programs. https://lists.gnu.org/archive/html/help-guix/2021-04/msg00096.html Now when I try to build a Haskell program with `cabal

bug#48240: “guix copy” to host with daemon listening on TCP fails

Ludovic Courtès writes: > Fixed in da28efef36af8925bcd9e40a81cbf552cf8c2d02. Let me know if it > works for you! This commit appears to have fixed a problem with guix copy that I was having yesterday. I was getting this error "guix copy: error: failed to connect over SSH to daemon at '', socket

bug#48343: Cannot boot after installation

Sergey Petrov writes: > Hi! I've installed ordinary guix system following graphical installer, > but can't boot it, here what I got after installation complete: > > GC Warning: pthread_getattr_pp or pthread_attr_getstack failed for > main thread GC Warning: > Couldn't read /proc/stat > Welcome,

bug#48214: inetutils-1.9.4 build fails

Bone Baboon writes: > ** See my previous email in this thread that explains the rationale on >why I am disabling IPv6. Correction see https://issues.guix.gnu.org/48213#3 for my rationale for disabling IPv6.

bug#48239: rust-1.19.0 build fails

Mark H Weaver writes: > It might be worth trying the build a second time. I have tried to build Rust again after doing a pull. It fails with the same error.

bug#48214: inetutils-1.9.4 build fails

Ludovic Courtès writes: >> How can I use a package definition from core-updates with guix build or >> in a system configuration if it is not available on Guix's master >> branch? > > You can do better :-), you can install 2.0 from master like so: > > guix install inetutils

bug#48024: glib-2.62.6 build fails i686

Mark H Weaver writes: > One more important note: regardless of whether you run Guix from a git > checkout or use the official 'master' branch, if you build everything > locally, then it's important to pass "--gc-keep-derivations=yes" and > "--gc-keep-outputs=yes" to the Guix daemon. > > Those

bug#48024: glib-2.62.6 build fails i686

Efraim Flashner writes: >> > Bone Baboon: Can you build the attached test-glib.scm file and send back >> > the build log? I want to make sure I change the timeout to something >> > long enough. >> > >> > You can build it with 'guix build -f test-glib.scm' >> >> I ran `guix build

bug#48214: inetutils-1.9.4 build fails

> Bone Baboon via Bug reports for GNU Guix writes: >> I have reported this to the inetutils bug mailing list and asked if the >> inetutils test suite could be modified so that syslogd.sh does not fail >> if IPv6 is disabled. > > I received this response on the inet

bug#48214: inetutils-1.9.4 build fails

Bone Baboon via Bug reports for GNU Guix writes: > I have reported this to the inetutils bug mailing list and asked if the > inetutils test suite could be modified so that syslogd.sh does not fail > if IPv6 is disabled. I received this response on the inetutils mailing list: >

bug#48213: offlineimap build fails

Tobias Geerinckx-Rice writes: > you should report this upstream first I have reported this to Seth Michael Larson the maintainer of rfc6555. https://pypi.org/project/rfc6555/ I also asked Seth Michael Larson if the rfc6555 test suite could be modified so that test_ipv6_available does not fail if

bug#48214: inetutils-1.9.4 build fails

Tobias Geerinckx-Rice writes: > Bone Baboon via Bug reports for GNU Guix 写道： >> FAIL: syslogd.sh >> >> >> ../src/logger: ::1:7041: Cannot assign requested address > > Looks like the same cause as <https://issues.guix.gnu.org/48213>: &g

bug#48239: rust-1.19.0 build fails

Mark H Weaver writes: > Are you aware of any relevant customizations to your kernel > configuration that might possibly be related to this? The system configuration includes: ``` (kernel-arguments (append (list "nomodeset" "ipv6.disable=1") %default-kernel-arguments)) ```

bug#48024: glib-2.62.6 build fails i686

Mark H Weaver writes: >> I was having trouble finding the build log. > > Here's one way to find it: > > $ cd /var/log/guix/drvs > $ ls -ltr */*-glib-2* | tail > > The very small log files are the result of grafting derivations. > Look for the most recent one that's more than 1K. > > Alternatively,

bug#48024: glib-2.62.6 build fails i686

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

bug#48024: glib-2.62.6 build fails i686

Mark H Weaver writes: > Did you also run "make"? I have now. > Hmm. Can you please grep the build log for "TIMEOUT" and > "increase-test-timeout", and show me the matching lines? "increase-test-timeout": ``` starting phase `increase-test-timeout' phase `increase-test-timeout' succeeded after

bug#48213: offlineimap build fails

>> This would accommodate Guix users who have disabled ipv6. > > Guix doesn't virtualise the kernel and expects it to provide all that > is needful. Linux offers knobs for *everything*; that doesn't mean > everything is supported. Disabling kernel support for basic things > (namespaces, UNIX

bug#48024: glib-2.62.6 build fails i686

Mark H Weaver writes: > Right. Unfortunately, these timeouts are too short for many slower > machines, such as 32-bit ARM systems. Bone Baboon has also recently > reported being unable to build 'glib' on a 32-bit i686 system due to > these timeouts, even when making extreme efforts to reduce

bug#48214: inetutils-1.9.4 build fails

On a x86_64 computer when I run `guix build --no-substitutes --keep-failed inetutils` the build fails because of one failed test. `guix describe` outputs: ``` Generation 18 May 03 2021 13:15:55(current) guix 065d2cd repository URL: https://git.savannah.gnu.org/git/guix.git

bug#48213: offlineimap build fails

On a x86_64 computer when I run `guix build --no-substitutes offlineimap` the build fails because the "test_ipv6_available" test fails. In the system configuration ipv6 is disabled: ``` (kernel-arguments (append (list "nomodeset" "ipv6.disable=1") %default-kernel-arguments)) ``` Taking the

bug#48024: glib-2.62.6 build fails i686

Thank you for your helpful response. Would a patch like this that addresses test timeouts be good to have in the Guix repository? It would help other Guix users who also run into test timeouts when building glib. Mark H Weaver writes: > I also build everything locally, and have sometimes run

bug#47928: go-gopkg-in-yaml-v2-2.2.2 build fails

go-gopkg-in-yaml-v2 is a dependency for Docker and I am not able to build it on x86_64 or i686. On a x86-64 computer when I run `sudo guix system --no-substitutes reconfigure configuration.scm` I get this error. ``` building

bug#48151: mariadb-10.5.8 build failing

Tobias Geerinckx-Rice writes: > Your bug is available at and > through the usual 48151 at debbugs.gnu.org. However, it wasn't > sent to subscribers' inboxes because it was a whopping >9 MiB. > > Like most mailing lists, bug-guix@ has a (generous) message size >

bug#48094: strace-5.8 build fails

Ludovic Courtès writes: > Since the “dumping logs” phase failed, could you try to access the build > logs under /tmp/guix-build-strace*? (You need to build with > ‘--keep-failed’; see > .) Since I initially reported this bug

bug#47928: go-gopkg-in-yaml-v2-2.2.2 build fails

I get the same error when I try `guix build --no-substitutes --system=i686-linux go-gopkg-in-yaml-v2`. Bone Baboon writes: > On a i686 computer when I run `sudo guix system --no-substitutes --cores=1 > --max-jobs=1 reconfigure config.scm` I get this error: > > ``` > building >

bug#47928: go-gopkg-in-yaml-v2-2.2.2 build fails

raingloom writes: > On Mon, 26 Apr 2021 17:39:58 -0400 > Bone Baboon wrote: > >> raingloom writes: >> > My guess is that int is 32 bits on i686. >> >> The computer's CPU is 32 bit. >> >> How would I check if "int is 32 bits on i686"? > > Looking up an authoritative source (ie.: "the docs")

bug#48045: guix challenge error

Ludovic Courtès writes: > The bug comes from the fact that it’s gone beyond 100%. We could solve > it by programming more defensively, but it’d be great to see where the > problem comes from. > > Can you reproduce it with: > > ./pre-inst-env guix challenge >

bug#47928: go-gopkg-in-yaml-v2-2.2.2 build fails

raingloom writes: > My guess is that int is 32 bits on i686. The computer's CPU is 32 bit. How would I check if "int is 32 bits on i686"?

bug#48045: guix challenge error

On an x86_64 computer when I run `guix challenge` I get this error: ``` ... /gnu/store/5ds5bli4p6gja2yzmzzc0sik1kzrasp9-guix-extra contents differ: local hash: 0aacxb6n0vrki8lb7f02r3m756cpc650hbihj9dpklkpvlgasqad https://ci.guix.gnu.org/nar/lzip/5ds5bli4p6gja2yzmzzc0sik1kzrasp9-guix-extra:

bug#47964: webkitgtk-2.32.0 build fails

Leo Famulari writes: > Thanks for taking the time to perform all these builds; I'm sure they > took a long time. Thank you for helping me figure out how to build this package. > I'm guessing that "--cores=2 --max-jobs=1" used fewer threads than the > guix-daemon would normally choose by default

bug#47964: Closing bug#47964

Closing bug#47964 because webkitgtk can successfully be built using the command `sudo guix system --no-substitutes --cores=2 --max-jobs=1 reconfigure configuration.scm`. The build of webkitgtk is sensitive to the number of cores used.

bug#47964: webkitgtk-2.32.0 build fails

Leo Famulari writes: > I googled your error message: > > "No rule to make target 'JavaScriptCore-4.0.gir', needed by > 'WebKit2-4.0.gir'. Stop." > > And there are very many results, from many distros, and the answer in > all cases seems to be "Don't build this package with -j1". > > I have to

bug#47927: guix-1.2.0-21.4dff6ec build fails

Ludovic Courtès writes: > What about the stress test I mentioned? I let the stress test run for hours and there were no errors.

bug#47927: guix-1.2.0-21.4dff6ec build fails

Ludovic Courtès writes: > Could you try these two things as well: retrying the derivation build, > and running the stress test above? Since I submitted this bug I have done a `guix pull` and tried to reconfigure. Now when I run `guix build --no-substitutes --cores=1 --max-jobs=1

bug#47971: Improve Guix commands for update/upgrade

bo0od writes: > The current commands used to make sure everything updated are not > friendly to type nor to memorize The name of package management commands seems like it would largely be personal preference. Each person using Guix could customize the commands to their own preferences using Bash

bug#47964: webkitgtk-2.32.0 build fails

On an x86_64 computer when I run `sudo guix system --no-substitutes reconfigure config.scm` webkitgtk-2.32.0 fails to build. When I run `guix build --no-substitutes --cores=1 --max-jobs=1 webkitgtk` I get this error message: ``` make: *** [Makefile:155: all] Error 2 command "make" "-j" "1"

bug#47928: go-gopkg-in-yaml-v2-2.2.2 build fails

On a i686 computer when I run `sudo guix system --no-substitutes --cores=1 --max-jobs=1 reconfigure config.scm` I get this error: ``` building /gnu/store/yqwd4wbam8mx0n2idy1qj4861rzvra7n-go-gopkg-in-yaml-v2-2.2.2.drv... | 'check' phasebuilder for

bug#47808: guile-git-0.5.0.drv build failed on i686-linux

Thank you Now when I do a `guix pull --no-substitutes` guile-git build successfully. Ludovic Courtès writes: > Hi, > > Julien Lepiller skribis: > >> I have a branch with fixes for guile-git: >> https://gitlab.com/roptat/guile-git/-/tree/fix-segfault > > Following our discussion on IRC, I

bug#47911: Package outputs should be described in the UI

Leo Famulari writes: > At least once a month I have to help somebody on IRC who didn't notice > that our Git package is split into multiple outputs. > > They can't find `git send-email`, and the Guix package UI doesn't make > this clear enough. > > I had the idea that package outputs besides

bug#47808: guile-git-0.5.0.drv build failed

Ludovic Courtès writes: > Could you send the log file returned by: > > guix build --log-file > /gnu/store/2cllkgj32qqxvrlxkas27v6hd34g0b88-guile-git-0.5.0.drv > > ? > > It’s weird because this particular derivation was built at > ci.guix.gnu.org and substitutes are available: > >

bug#47808: guile-git-0.5.0.drv build failed

On an i686 computer when I run `guix pull --no-substitutes` I get this error: ``` Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git a5bbd38 building

bug#47451: Guix pull building lz4-1.9.3 fails

I am getting an error message that tells me to report it to this Guix bug mailing list. After reading the Specifying Additional Channels section of the Guix manual I created `~/.config/guix/channels.scm` with these contents: ``` (cons (channel (name 'openvpn-2-4-9) (url