bug#48515: ell 0.40 test failure

[Maxim Cournoyer]

Hello,

Upon trying to reconfigure my system with master, I got the following
test failure for the recently updated ell package:

--8<---cut here---start->8---
PASS: unit/test-gvariant-util
PASS: unit/test-dbus-message
./build-aux/test-driver: line 107: 15217 Aborted "$@" > 
$log_file 2>&1
FAIL: unit/test-cipher
PASS: unit/test-dbus
PASS: unit/test-dbus-message-fds
PASS: unit/test-dbus-properties
PASS: unit/test-dbus-service
PASS: unit/test-main
PASS: unit/test-pbkdf2

Testsuite summary for ell 0.40

# TOTAL: 40
# PASS:  39
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log

make[3]: *** [Makefile:2099: test-suite.log] Error 1
make[2]: *** [Makefile:2207: check-TESTS] Error 2
make[1]: *** [Makefile:2713: check-am] Error 2
make: *** [Makefile:2715: check] Error 2

Test suite failed, dumping logs.

--- ./test-suite.log 


   ell 0.40: ./test-suite.log


# TOTAL: 40
# PASS:  39
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: unit/test-cipher
==

test-cipher: unit/test-cipher.c:93: test_aes_ctr: Assertion 
`l_cipher_encrypt(cipher, buf, buf, FIXED_LEN)' failed.
FAIL unit/test-cipher (exit status: 134)


command "make" "check" "-j" "24" failed with status 2
builder for `/gnu/store/zz6sia4wwcg0885fi696kmiak0abiwy6-ell-0.40.drv' failed 
with exit code 1
@ build-failed /gnu/store/zz6sia4wwcg0885fi696kmiak0abiwy6-ell-0.40.drv - 1 
builder for `/gnu/store/zz6sia4wwcg0885fi696kmiak0abiwy6-ell-0.40.drv' failed 
with exit code 1
--8<---cut here---end--->8---

Maxim

bug#48151: mariadb-10.5.8 build failing

[zimoun]

Hi,

I do not know if it is related but I note that the recent zstd change
seems to break mariadb, as reported here:



All the best,
simon

bug#48496: Guix reconfigure fails to switch to new system

[Ludovic Courtès]

Hi!

Tobias Geerinckx-Rice  skribis:

> Simon Streit 写道：
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> no code for module (system repl error-handling)
>
> Thank you for reporting this.  With commit
> 5fa46ca96da90ec19e32cc4d726f099d0979d60b on master, the system 
> tests that failed for me with this error no longer do.

What system tests were failing?

At first sight I don’t see how a67c00f4f7ee0a70fce14a7e1907cce332c85813
led to this:

--8<---cut here---start->8---
activating system...
Backtrace:
In ice-9/boot-9.scm:
  3422:24 19 (_)
   222:29 18 (map1 (((gnu system accounts)) ((gnu build accounts)) …))
   222:29 17 (map1 (((gnu build accounts)) ((gnu build #)) ((# …)) …))
   222:17 16 (map1 (((gnu build linux-boot)) ((guix build utils)) # …))
  3326:17 15 (resolve-interface (gnu build linux-boot) #:select _ # _ …)
In ice-9/threads.scm:
390:8 14 (_ _)
In ice-9/boot-9.scm:
  3252:13 13 (_)
In ice-9/threads.scm:
390:8 12 (_ _)
In ice-9/boot-9.scm:
  3536:20 11 (_)
   2835:4 10 (save-module-excursion #)
  3556:26  9 (_)
In unknown file:
   8 (primitive-load-path "gnu/build/linux-boot" #)
In gnu/build/linux-boot.scm:
 22:0  7 (_)
In ice-9/boot-9.scm:
   3409:4  6 (define-module* _ #:filename _ #:pure _ #:version _ # _ …)
  3422:24  5 (_)
   222:29  4 (map1 (((rnrs io ports)) ((system repl #)) ((srfi #)) …))
   222:17  3 (map1 (((system repl error-handling)) ((srfi srfi-1)) …))
   3329:6  2 (resolve-interface (system repl error-handling) #:select …)
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
no code for module (system repl error-handling)
--8<---cut here---end--->8---

Thoughts?

Ludo’.

bug#48496: Guix reconfigure fails to switch to new system

[Simon Streit]

Hi Tobias,

Tobias Geerinckx-Rice  writes:
> Simon Streit 写道：
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> no code for module (system repl error-handling)
>
> Thank you for reporting this.  With commit
> 5fa46ca96da90ec19e32cc4d726f099d0979d60b on master, the system
> tests that failed for me with this error no longer do.
>
> Could you confirm?

Yes, this commit runs through.


Cheers
Simon

bug#46333: sbcl-common-lisp-jupyter does not install kernel.json

[Guillaume Le Vaillant]

Hi Jack,

I guess it will be easier to just add a phase writing the "kernel.json"
file in the right place. In this build phase, to know if the package is
being built for SBCL or ECL, the '(%lisp-type)' function that will
return "sbcl" or "ecl" can be used. There's an example in the
sbcl-trivial-backtrace package.


signature.asc
Description: PGP signature

bug#46333: sbcl-common-lisp-jupyter does not install kernel.json

[Jack Hill]

Sharlatan,

Thanks for your recent work updated sbcl-common-lisp-jupyter. I was 
wondering if you had any thoughts on the best way to install the 
kernel.json file [0]. The last time I looked at it, I wasn't sure what the 
best solution would be. Do you have any ideas?


[0] https://issues.guix.gnu.org/46333

Best,
Jack

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

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Bone Baboon via Bug reports for GNU Guix 写道：

hunspell-dict-en-us is not reproducible.


Thanks!  Fixed in be528eb53d6c5c6d3ef7d74a02da2e2b97c0ccc6.



I checked hunspell-dict-de and it is reproducible.  I do not 
know if

other hunspell-dict-* are reproducible or not.


A quick

 for a in "" "--check --keep-failed"; do
   guix build --no-grafts \
 $(guix package -A ^hunspell-dict | cut -f1) $a
 done

suggests that they are, unless one embeds (say) the day of the 
week somewhere...


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#48419: Fwd: bug#48419: Unexpected problem during install of Guix System 1.3.0

[Matthias Cullmann]

( I'm forwarding this to the list - forgot to reply all )

-- Forwarded message -
From: Matthias Cullmann 
Date: Sat, 15 May 2021 at 15:31
Subject: Re: bug#48419: Unexpected problem during install of Guix System
1.3.0
To: Bengt Richter 


Hi Bengt,

here is what I get ( now under MX linux on the same box ).

$ ls /dev/disk/by-id/*|xargs file
/dev/disk/by-id/ata-Micron_M600_MTFDDAV256MBF_154010B93F27:   symbolic
link to ../../sda
/dev/disk/by-id/ata-Micron_M600_MTFDDAV256MBF_154010B93F27-part1: symbolic
link to ../../sda1
/dev/disk/by-id/ata-Micron_M600_MTFDDAV256MBF_154010B93F27-part2: symbolic
link to ../../sda2
/dev/disk/by-id/ata-Micron_M600_MTFDDAV256MBF_154010B93F27-part3: symbolic
link to ../../sda3
/dev/disk/by-id/wwn-0x500a075110b93f27:   symbolic
link to ../../sda
/dev/disk/by-id/wwn-0x500a075110b93f27-part1: symbolic
link to ../../sda1
/dev/disk/by-id/wwn-0x500a075110b93f27-part2: symbolic
link to ../../sda2
/dev/disk/by-id/wwn-0x500a075110b93f27-part3: symbolic
link to ../../sda3

$  lsblk -f
NAME   FSTYPE LABELUUID FSAVAIL FSUSE%
MOUNTPOINT
sda
├─sda1 vfat7C99-13AE 251.8M 0%
/boot/efi
├─sda2 ext4   rootMX19 90aa2c4f-5266-47bc-9b73-228c524b2790  211.2G 4% /
└─sda3 swap   swapMX   bf24ea70-f3e5-4023-9367-98bcc1c464ac
 [SWAP]

To me it looks quite standard?
Thx & regards.
Matthias


On Sat, 15 May 2021 at 11:35, Bengt Richter  wrote:

> Hi,
>
> On +2021-05-14 16:50:48 +0200, Matthias Cullmann wrote:
> > Hi there,
> >
> > I am trying to install Guix System 1.3.0 on an Asus ZenBook UX305 using
> the
> > wizard.
> >
> > After the partitioning I get the error in the attached screen shot.
> >
> > ( mount "/dev/sda1" on "mnt/boot/ef" : No such device)
> >
> > I had Linux installed already on this computer and would not need to
> > re-partition.
> >
> > Any ideas how to fix this?
> >
> > Thx & regards,
> >
> > Matthias
> >
> what does this output?
> --8<---cut here---start->8---
> $ ls /dev/disk/by-id/*|xargs file
> --8<---cut here---end--->8---
>
> Maybe you have nve disk that does not get translated to /dev/sdaX ?
>
> If you have linux running, try
> --8<---cut here---start->8---
> $ lsblk -f
> --8<---cut here---end--->8---
>
> Maybe you will see something like
>
> nvme0n1
> ├─nvme0n1p1 ...
> └─nvme0n1p2 ...
>
> which would suggest that your
> /dev/sda1
> maybe should be
> /dev/nvme0n1p1
>
> but in general, IMO device references without unique id's are bloody feet
> waiting to happen.
>
> I would suggest looking at uuid's for file systems, partitions, or devices,
> such as you can view with lsblk
>
> --
> Regards,
> Bengt Richter
>

bug#48496: Guix reconfigure fails to switch to new system

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Simon,

Simon Streit 写道：

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
no code for module (system repl error-handling)


Thank you for reporting this.  With commit 
5fa46ca96da90ec19e32cc4d726f099d0979d60b on master, the system 
tests that failed for me with this error no longer do.


Could you confirm?

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#48491: A bug

[Eduardo Almeida da Conceição]

$ guix pull
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   c2b183e
substitute: 
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
substitute: 
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)

Computing Guix derivation for 'x86_64-linux'... /Backtrace:
   9 (primitive-load 
"/gnu/store/a0zpydz0h9zyc33dz4zwkhc2shy2s36g-compute-guix-derivation")

In ice-9/eval.scm:
155:9  8 (_ _)
159:9  7 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))

In ice-9/boot-9.scm:
152:2  6 (with-fluid* _ _ _)
152:2  5 (with-fluid* _ _ _)
In ./guix/store.scm:
  2076:24  4 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)

In ./guix/self.scm:
  1303:16  3 (_ _)
928:4  2 (compiled-guix 
"/gnu/store/ac02hags203ylif03bsd4zlhs0bkzp9m-guix-c2b183e" #:version _ 
#:channel-metadata ?)
   191:26  1 (scheme-node "guix-packages" ((gnu packages abduco) (gnu 
packages abiword) (gnu packages #) (gnu # ?) ?) ?)

In ./guix/modules.scm:
   157:28  0 (module-closure _ #:select? _ #:dependencies _)

./guix/modules.scm:157:28: In procedure module-closure:
Throw to key `srfi-34' with args `(#[module: (gnu packages distributed) search-path: 
("/gnu/store/ac02hags203ylif03bsd4zlhs0bkzp9m-guix-c2b183e" 
"/gnu/store/idskkmlpd2cd42gnfidf5wjwj5qc8yxr-guile-gcrypt-0.1.0/share/guile/site/2.2" 
"/gnu/store/8a32sr1w5cz37hyypiw18m808vw2s6xw-module-import")] be46f90>)'.
guix pull: error: You found a bug: the program 
'/gnu/store/a0zpydz0h9zyc33dz4zwkhc2shy2s36g-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"c2b183e13d7bcd36cc62253add436eb2946abe4e"; system: "x86_64-linux";

host version: "1.0.1"; pull-version: 1).
Please report it by email to .
$
$ guix --version
guix (GNU Guix) 1.0.1
Copyright (C) 2019 the Guix authors
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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

[Bone Baboon via Bug reports for GNU Guix]

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.

I checked hunspell-dict-de and it is reproducible.  I do not know if
other hunspell-dict-* are reproducible or not.

`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 hunspell-dict-en-us` outputs:

```
/gnu/store/3w1hj34h7w2if52lng2q1n12ddb034bj-hunspell-dict-en-us-2018.04.16 
contents differ:
  local hash: 17z7nzdzzirfkqsiixk3r4anxzmj2531k9hm30bv7kq19fb3drbb
  
https://ci.guix.gnu.org/nar/lzip/3w1hj34h7w2if52lng2q1n12ddb034bj-hunspell-dict-en-us-2018.04.16:
 0zc4xyr77bzsmzs6wjxmx59c0w2xr97qx47190k0wmjaskncdllq
  differing files:
/share/doc/hunspell-dict-en-us/README_en_AU.txt
/share/doc/hunspell-dict-en-us/README_en_US-large.txt
/share/doc/hunspell-dict-en-us/README_en_US.txt
/share/doc/hunspell-dict-en-us/README_en_CA.txt
/share/doc/hunspell-dict-en-us/README_en_GB-ise.txt
/share/doc/hunspell-dict-en-us/README_en_AU-large.txt
/share/doc/hunspell-dict-en-us/README_en_GB-large.txt
/share/doc/hunspell-dict-en-us/README_en_GB-ize.txt
/share/doc/hunspell-dict-en-us/README_en_CA-large.txt

1 store items were analyzed:
  - 0 (0.0%) were identical
  - 1 (100.0%) differed
  - 0 (0.0%) were inconclusive
```

`guix challenge --diff=diffoscope hunspell-dict-en-us` outputs:

```
/gnu/store/3w1hj34h7w2if52lng2q1n12ddb034bj-hunspell-dict-en-us-2018.04.16 
contents differ:
  local hash: 17z7nzdzzirfkqsiixk3r4anxzmj2531k9hm30bv7kq19fb3drbb
  
https://ci.guix.gnu.org/nar/lzip/3w1hj34h7w2if52lng2q1n12ddb034bj-hunspell-dict-en-us-2018.04.16:
 0zc4xyr77bzsmzs6wjxmx59c0w2xr97qx47190k0wmjaskncdllq
 ci.guix.gnu.org  169KiB  350KiB/s 00:00 [##] 100.0%
--- /tmp/guix-directory.IJLlzu
+++ /gnu/store/3w1hj34h7w2if52lng2q1n12ddb034bj-hunspell-dict-en-us-2018.04.16
│   --- /tmp/guix-directory.IJLlzu/share
├── +++ 
/gnu/store/3w1hj34h7w2if52lng2q1n12ddb034bj-hunspell-dict-en-us-2018.04.16/share
│ │   --- /tmp/guix-directory.IJLlzu/share/doc
│ ├── +++ 
/gnu/store/3w1hj34h7w2if52lng2q1n12ddb034bj-hunspell-dict-en-us-2018.04.16/share/doc
│ │ │   --- /tmp/guix-directory.IJLlzu/share/doc/hunspell-dict-en-us
│ │ ├── +++ 
/gnu/store/3w1hj34h7w2if52lng2q1n12ddb034bj-hunspell-dict-en-us-2018.04.16/share/doc/hunspell-dict-en-us
│ │ │ │   --- 
/tmp/guix-directory.IJLlzu/share/doc/hunspell-dict-en-us/README_en_AU-large.txt
│ │ │ ├── +++ 
/gnu/store/3w1hj34h7w2if52lng2q1n12ddb034bj-hunspell-dict-en-us-2018.04.16/share/doc/hunspell-dict-en-us/README_en_AU-large.txt
│ │ │ │ @@ -1,10 +1,10 @@
│ │ │ │  en_AU-large Hunspell Dictionary
│ │ │ │  Generated from SCOWL Version 2018.04.16
│ │ │ │ -Sat Aug 22 06:52:10 UTC 2020
│ │ │ │ +Fri May  7 14:50:16 UTC 2021
│ │ │ │  
│ │ │ │  http://wordlist.sourceforge.net
│ │ │ │  
│ │ │ │  README file for English Hunspell dictionaries derived from SCOWL.
│ │ │ │  
│ │ │ │  These dictionaries are created using the speller/make-hunspell-dict
│ │ │ │  script in SCOWL.
│ │ │ │ @@ -340,9 +340,9 @@
│ │ │ │DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE 
GOODS
│ │ │ │OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
│ │ │ │HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 
STRICT
│ │ │ │LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 
ANY WAY
│ │ │ │OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY 
OF
│ │ │ │SUCH DAMAGE.
│ │ │ │  
│ │ │ │ -Build Date: Sat Aug 22 06:52:10 UTC 2020
│ │ │ │ +Build Date: Fri May  7 14:50:16 UTC 2021
│ │ │ │  Wordlist Command: mk-list -v1 --accents=both en_AU 70
│ │ │ │   --- 
/tmp/guix-directory.IJLlzu/share/doc/hunspell-dict-en-us/README_en_AU.txt
│ │ │ ├── +++ 
/gnu/store/3w1hj34h7w2if52lng2q1n12ddb034bj-hunspell-dict-en-us-2018.04.16/share/doc/hunspell-dict-en-us/README_en_AU.txt
│ │ │ │ @@ -1,10 +1,10 @@
│ │ │ │  en_AU Hunspell Dictionary
│ │ │ │  Generated from SCOWL Version 2018.04.16
│ │ │ │ -Sat Aug 22 06:52:06 UTC 2020
│ │ │ │ +Fri May  7 14:50:12 UTC 2021
│ │ │ │  
│ │ │ │  http://wordlist.sourceforge.net
│ │ │ │  
│ │ │ │  README file for English Hunspell dictionaries derived from SCOWL.
│ │ │ │  
│ │ │ │  These dictionaries are created using the speller/make-hunspell-dict
│ │ │ │  script in SCOWL.
│ │ │ │ @@ -340,9 +340,9 @@
│ │ │ │DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE 
GOODS
│ │ │ │OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
│ │ │ │HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 
STRICT
│ │ │ │LIABILITY, OR TORT (INCLUDING NEGLIGENCE O

bug#48468: substitute server connection timeout

[Mathieu Othacehe]

Hey,

> I'll have a closer look, thanks for your help.

So this snippet in the http-write procedure of the (guix scripts
publish) module:

--8<---cut here---start->8---
  (swallow-zlib-error
   (close-port port))
--8<---cut here---end--->8---

is closing the client port unconditionally, which means that guix
publish cannot keep connections alive, unless sitting behind an Nginx
proxy.

I'm trying to turn the close-port call into a maybe-close-port with the
following procedure:

--8<---cut here---start->8---
(define (maybe-close-port port)
(cond
 ((keep-alive? response)
  (poll-set-add! (http-poll-set server) port *events*))
 (else
  (close-port port
--8<---cut here---end--->8---

however this is terribly hacky, as I need to access the private poll-set
from (web server http).

Ludo, do you have a better idea?

Thanks,

Mathieu

bug#48284: Dovecot has two ‘location’ fields

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès  writes:

> I just noticed this compiler warning:
>
> gnu/services/mail.scm:431:0: warning: shadows previous definition of 
> `%namespace-configuration-location-procedure' at gnu/services/mail.scm:431:0
> : warning: shadows previous definition of 
> `namespace-configuration-location' at 
>
>
> I believe this comes from the fact that ‘define-configuration’
> automatically introduces a ‘location’ field (for the source code
> location of  instantiations), which clashes
> with this one:
>
>   (location
>(string "")
>"Physical location of the mailbox. This is in same format as
> mail_location, which is also the default for it.")
>
> I think this was revealed by the fix in commit
> dd0826fbf345dfe7289cf943ed2d29edc51d543f.
>
> Probably the only sane way to address it is by renaming the field above.

We could also rename the define-configuration produced %location field
accessor to something more explicit such as $name-source-location
instead of $name-location, no?

I don't think that field is being used much at all, given it was
effectively broken prior to the above commit, so renaming it should go
mostly unnoticed.

Maxim

bug#48496: Guix reconfigure fails to switch to new system

[Simon Streit]

Hi,

after pulling and trying to upgrade a system, Guix will fail switching
to a new system saying:

--8<---cut here---start->8---
The following derivation will be built:
   /gnu/store/hswsg23l03pyrf7nckr1zrmb0rfsssf6-grub.cfg.drv

building /gnu/store/hswsg23l03pyrf7nckr1zrmb0rfsssf6-grub.cfg.drv...
/gnu/store/3zpjx9ky5lyx3l90qvnp1qqrvrc70caf-system
/gnu/store/lrvf3k1qrs3mrb3aasq9b6i6gd321aiz-grub.cfg

activating system...
Backtrace:
In ice-9/boot-9.scm:
  3422:24 19 (_)
   222:29 18 (map1 (((gnu system accounts)) ((gnu build accounts)) …))
   222:29 17 (map1 (((gnu build accounts)) ((gnu build #)) ((# …)) …))
   222:17 16 (map1 (((gnu build linux-boot)) ((guix build utils)) # …))
  3326:17 15 (resolve-interface (gnu build linux-boot) #:select _ # _ …)
In ice-9/threads.scm:
390:8 14 (_ _)
In ice-9/boot-9.scm:
  3252:13 13 (_)
In ice-9/threads.scm:
390:8 12 (_ _)
In ice-9/boot-9.scm:
  3536:20 11 (_)
   2835:4 10 (save-module-excursion #)
  3556:26  9 (_)
In unknown file:
   8 (primitive-load-path "gnu/build/linux-boot" #)
In gnu/build/linux-boot.scm:
 22:0  7 (_)
In ice-9/boot-9.scm:
   3409:4  6 (define-module* _ #:filename _ #:pure _ #:version _ # _ …)
  3422:24  5 (_)
   222:29  4 (map1 (((rnrs io ports)) ((system repl #)) ((srfi #)) …))
   222:17  3 (map1 (((system repl error-handling)) ((srfi srfi-1)) …))
   3329:6  2 (resolve-interface (system repl error-handling) #:select …)
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
no code for module (system repl error-handling)
--8<---cut here---end--->8---

Checkout is at b905abfbd3235322c826e3b0ad45e410a3cd96f3

bug#47121: [Mumi] Why does Mumi display my name as "Mark HWeaver"?

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Closing, as the fix seems to have worked: 
.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#48398: many packages become nonfunctional if not install in fixed profile like ~/.guix-profile

[Leo Prikler]

Hi,

Am Dienstag, den 18.05.2021, 13:44 +0530 schrieb Shyam Saran:
> This below error I am getting
> 
> blueman-manager version 2.1.4 starting
> Traceback (most recent call last):
>   File "/gnu/store/894nlym6bvmn3cza9q775pg4f1gvixxa-blueman-
> 2.1.4/lib/python3.8/site-packages/blueman/main/Manager.py", line 111,
> in on_dbus_name_appeared
> check_bluetooth_status(_("Bluetooth needs to be turned on for the
> device manager to function"),
>   File "/gnu/store/894nlym6bvmn3cza9q775pg4f1gvixxa-blueman-
> 2.1.4/lib/python3.8/site-packages/blueman/Functions.py", line 73, in
> check_bluetooth_status
> if "PowerManager" not in applet.QueryPlugins():
>   File "/gnu/store/qrpkvnya5z5q2n1lc024wbxb27p9wrzq-python-pygobject-
> 3.34.0/lib/python3.8/site-packages/gi/overrides/Gio.py", line 351, in
> __call__
> result = self.dbus_proxy.call_sync(self.method_name, arg_variant,
> gi.repository.GLib.Error: g-dbus-error-quark:
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.blueman.Applet was not provided by any .service files (2)
> 
> (thanks for support)
That's a problem with DBus not finding your .service file.  You can
work around that by manually starting the service from a Guix
environment (`$GUIX_ENVIRONMENT/share/dbus-1/services` should list
them) or directly from store.

FWIW launching blueman-applet directly leads to another, more confusing
DBus error.  I'm not sure whether adding the dbus package to your
environment fixes any of it, but it's worth a try.
> 
> On Fri, 14 May 2021 at 03:25, Leo Prikler <
> leo.prik...@student.tugraz.at> wrote:
> > Am Donnerstag, den 13.05.2021, 19:56 +0530 schrieb Shyam Saran:
> > > many packages become nonfunctional if not install in fixed
> > profiles
> > > (e.g. ~/.guix-profile)
> > While this is true, there is not necessarily a common cause for all
> > such instances.  Even among packages, that hardcode ~/.guix-
> > profile,
> > there might be differences, so it's better to focus on specific
> > instances or groups of instances, in which one fix can be applied
> > to
> > all of them.
> > 
> > > 1. blueman
> > Please provide more information on blueman.
> > > 2. font-conf so most of font like font-lohit will not be
> > available
> > This one has a history.  Instead of exposing itself to the dangers
> > of
> > environment variables, fontconfig took the reasonable approach of
> > letting itself be controlled by XML files, so if you want it to
> > work
> > differently from how it usually behaves, you have to edit those.
> > 
> > > I had noticed that fixed profiles have become part of many
> > > packages/services definition which could be the reason that many
> > of
> > > these packages/services become dependent on these fixed profiles.
> > Which packages/services in particular?
> > 
> > > It can be checked with
> > > 
> > > $ ag   --scheme  '.guix-profile'
> > > $ grep -r '.guix-profile'
> > > 
> > > in code
> > I find 65 matches including documentation.  Even assuming every one
> > of
> > them was a package, it would affect about 1% of packages, many of
> > which
> > would probably be leaf packages.  So while this number is
> > definitely
> > large enough to intimidate those who want to quickly fix a number
> > of
> > them, it is also smaller in scale than the report would imply.
> > 
> > > 
> > > Also
> > > 
> > > We provides necessary services through putting environment
> > variables
> > > in each profiles
> > > 
> > > PROFILE_PATH/etc/profile
> > > 
> > >   like for pidgin/purple
> > >   PURPLE_PLUGIN_PATH
> > > 
> > >   for libraries
> > >   LIBRARY_PATH
> > > 
> > > 
> > > As suggestion
> > > 
> > > We could first provide augment all variables with guix specific
> > > prefix e.g. GUIX_PEV_...
> > > (PVS profile environment variables.)
> > > 
> > > So these all variables will become
> > > 
> > > 
> > >   GUIX_PEV_PURPLE_PLUGIN_PATH
> > >   GUIX_PEV_LIBRARY_PATH
> > > 
> > > then we could or could not (left to user) to set them
> > >   PURPLE_PLUGIN_PATH=$GUIX_PEV_PURPLE_PLUGIN_PATH
> > >   LIBRARY_PATH=$GUIX_PEV_LIBRARY_PATH
> > > 
> > > 
> > > So with prefixed env vars, in first look one will know it is
> > coming
> > > from guix related profiles.
> > > maybe it will also help in removing dependencies on fixed
> > profiles.
> > Guix already prefixes some environment variables, that might cause
> > issues if they are read by all variants of a package with GUIX_.  I
> > don't think this needs to be done for every search path, however. 
> > Again, specific instances like GUIX_PYTHONPATH can (and should be)
> > discussed, but I don't think this solves the relation to fixed
> > profiles.
> > 
> > Regards,
> > Leo
> > 

bug#48398: many packages become nonfunctional if not install in fixed profile like ~/.guix-profile

[Shyam Saran]

This below error I am getting

$ blueman-manager

   718s

blueman-manager version 2.1.4 starting
Traceback (most recent call last):
  File
"/gnu/store/894nlym6bvmn3cza9q775pg4f1gvixxa-blueman-2.1.4/lib/python3.8/site-packages/blueman/main/Manager.py",
line 111, in on_dbus_name_appeared
check_bluetooth_status(_("Bluetooth needs to be turned on for the
device manager to function"),
  File
"/gnu/store/894nlym6bvmn3cza9q775pg4f1gvixxa-blueman-2.1.4/lib/python3.8/site-packages/blueman/Functions.py",
line 73, in check_bluetooth_status
if "PowerManager" not in applet.QueryPlugins():
  File
"/gnu/store/qrpkvnya5z5q2n1lc024wbxb27p9wrzq-python-pygobject-3.34.0/lib/python3.8/site-packages/gi/overrides/Gio.py",
line 351, in __call__
result = self.dbus_proxy.call_sync(self.method_name, arg_variant,
gi.repository.GLib.Error: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.blueman.Applet was not provided by any .service files (2)




(thanks for support)




On Fri, 14 May 2021 at 03:25, Leo Prikler 
wrote:

> Am Donnerstag, den 13.05.2021, 19:56 +0530 schrieb Shyam Saran:
> > many packages become nonfunctional if not install in fixed profiles
> > (e.g. ~/.guix-profile)
> While this is true, there is not necessarily a common cause for all
> such instances.  Even among packages, that hardcode ~/.guix-profile,
> there might be differences, so it's better to focus on specific
> instances or groups of instances, in which one fix can be applied to
> all of them.
>
> > 1. blueman
> Please provide more information on blueman.
> > 2. font-conf so most of font like font-lohit will not be available
> This one has a history.  Instead of exposing itself to the dangers of
> environment variables, fontconfig took the reasonable approach of
> letting itself be controlled by XML files, so if you want it to work
> differently from how it usually behaves, you have to edit those.
>
> > I had noticed that fixed profiles have become part of many
> > packages/services definition which could be the reason that many of
> > these packages/services become dependent on these fixed profiles.
> Which packages/services in particular?
>
> > It can be checked with
> >
> > $ ag   --scheme  '.guix-profile'
> > $ grep -r '.guix-profile'
> >
> > in code
> I find 65 matches including documentation.  Even assuming every one of
> them was a package, it would affect about 1% of packages, many of which
> would probably be leaf packages.  So while this number is definitely
> large enough to intimidate those who want to quickly fix a number of
> them, it is also smaller in scale than the report would imply.
>
> >
> > Also
> >
> > We provides necessary services through putting environment variables
> > in each profiles
> >
> > PROFILE_PATH/etc/profile
> >
> >   like for pidgin/purple
> >   PURPLE_PLUGIN_PATH
> >
> >   for libraries
> >   LIBRARY_PATH
> >
> >
> > As suggestion
> >
> > We could first provide augment all variables with guix specific
> > prefix e.g. GUIX_PEV_...
> > (PVS profile environment variables.)
> >
> > So these all variables will become
> >
> >
> >   GUIX_PEV_PURPLE_PLUGIN_PATH
> >   GUIX_PEV_LIBRARY_PATH
> >
> > then we could or could not (left to user) to set them
> >   PURPLE_PLUGIN_PATH=$GUIX_PEV_PURPLE_PLUGIN_PATH
> >   LIBRARY_PATH=$GUIX_PEV_LIBRARY_PATH
> >
> >
> > So with prefixed env vars, in first look one will know it is coming
> > from guix related profiles.
> > maybe it will also help in removing dependencies on fixed profiles.
> Guix already prefixes some environment variables, that might cause
> issues if they are read by all variants of a package with GUIX_.  I
> don't think this needs to be done for every search path, however.
> Again, specific instances like GUIX_PYTHONPATH can (and should be)
> discussed, but I don't think this solves the relation to fixed
> profiles.
>
> Regards,
> Leo
>
>