bug#62908: evolution-data-server@3.44.4 or above don't connect with Nextcloud online account (GNOME desktop)

[Liliana Marie Prikler]

Am Montag, dem 17.04.2023 um 15:33 + schrieb
christophe.pist...@posteo.net:
> evolution-data-server@3.44.4 or above don't connect with Nextcloud 
> online account
> 
> ## Steps to reproduce
> 
> The following steps assume you are using Guix System x86_64 with
> GNOME desktop/X11
> 
> 1. fresh install with guix-system-install-1.4.0.x86_64-linux.iso (or
> the 
> devel iso: sp7lgxn1q3d37536dwq2r5r9yd18jw50-image.iso)
> 
> 2. guix package -i evolution-data-server
>     (i.e: evolution-data-server@3.45.3 with 
> guix-system-install-1.4.0)
>     (i.e: evolution-data-server@3.46.0 with 
> sp7lgxn1q3d37536dwq2r5r9yd18jw50-image.iso)
> 
> 3. optional: guix package -i evolution
> 
> 4. go to Settings, connect to a Nexcloud account
> 
> ## Expected result
> 
> + Calendar (or Evolution) connect to the Nexcloud account and can
> manage 
> calendars and address books (display existing calendars/address
> books, 
> add new item or delete item).
> + Files connect to the Nexcloud account and display online documents.
> 
> ## Unexpected result
> 
> + Calendar (or Evolution) can't connect to the Nexcloud account and 
> display nor manage nothing (or only display the calendars list) with 
> this error:
> 
>    Address book:
>    Impossible de se connecter au carnet d’adresses « CardDAV : Sans
> nom »
>    Échec avec l’erreur HTTP 405 : Method Not Allowed
> 
>    Calendars:
>    Impossible de se connecter à l’agenda « Sur le Web : Next_Ponctuel
> »
>    Bad Request
> 
>    Impossible de se connecter à « usern...@nl.tab.digital »
>    Erreur de résolution de « usern...@nl.tab.digital » : Nom ou
> service 
> inconnu
> 
> + (side note: Files connect perfectly to the Nexcloud account and 
> display online documents)
> 
> see:
> https://lists.gnu.org/archive/html/help-guix/2023-03/msg00255.html
The currently packaged evolution also appears to suffer from other
issues (see e.g. https://issues.guix.gnu.org/62942)  You may want to
try that patch or wait for it to be upstreamed.

> ## Workaround
> 
> 1. fresh install with guix-system-install-1.3.0.x86_64-linux.iso
> 
> 2. guix package -i evolution-data-server (i.e: 
> evolution-data-server@3.34.2)
> 
> 3. optional: guix package -i evolution
> 
> 4. go to Settings connect to a Nexcloud account
> 
> Result:
> -> Calendar (and Evolution) connect to the Nexcloud account and can 
> manage calendars and address books (display existing
> calendars/address 
> books, add new item or delete item).
> -> Files connect to the Nexcloud account and display online
> documents.
As a matter of principle, don't install Guix from old ISOs.  Instead,
use `guix time-machine' or inferiors with Scheme.

> ## Additional information
> 
> + Upgrade from evolution-data-server@3.34.2 to 
> evolution-data-server@3.46.0 partially fails:
> 1. fresh install with guix-system-install-1.3.0.x86_64-linux.iso
> 2. guix package -i evolution-data-server (i.e: 
> evolution-data-server@3.34.2)
> 3. guix pull & sudo guix system reconfigure /etc/config.scm & reboot
> & 
> guix package -u
> Result:
> ->   Calendar (and Evolution) connect to the Nexcloud account and can
> manage calendars and address books (display existing
> calendars/address 
> books, add new item or delete item).
>   But: Evolution displays the same error messages as above (see:
> ## 
> Unexpected result)
>   Files connect to the Nexcloud account and display online
> documents.
> 
> + Downgrade from evolution-data-server@3.45.3 to 
> evolution-data-server@3.44.4 fails:
> 1. fresh install with >= guix-system-install-1.4.0.x86_64-linux.iso
> 2. guix package -i evolution-data-server@3.44.4
> Result:
> -> Same error: Calendar (or Evolution) can't connect to the Nexcloud 
> account and display nor manage nothing.
> 
> + Downgrade from evolution-data-server@3.45.3 to 
> evolution-data-server@3.34.2 fails:
> 1. fresh install with guix-system-install-1.4.0.x86_64-linux.iso
> 2. guix package -i evolution-data-server@3.34.2
> Result:
> -> no package found
None of this is useful.  For accurate version information, use `guix
describe'.

> + possibly related to: https://issues.guix.gnu.org/35267#3
IIUC the fix to that one is to install evolution-data-server in the
operating-system packages rather than on the user level.  Since
evolution is tied to its data-server, you'd need to have both in the
operating-system (my personal fix is to extend the gnome package so as
to include them both, but that's besides the point).  Since evolution
launches for you, this bug doesn't seem apply, however.

Cheers

bug#63043: texlive-font-maps.drv build failure when profiles lacks texlive-* packages

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hello!
>
> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Hi!
>>>
>>> (Cc: Maxim who may be familiar with the ‘texlive-font-maps’ hook.)
>>
>> Did you checked with Ricardo?  They were the author of that hook, per
>> git blame :-).
>
> I didn’t even look at ‘git blame’, I thought you were the one behind
> this iteration :-), but Ricardo and I discussed it briefly on IRC.
> Anyway, extending Cc!
>
>>> There are probably two things to fix:
>>>
>>>   1. The ‘manifest-lookup-package’ check seems inconsistent with what’s
>>>  passed to ‘union-build’.
>>
>> I think this is the problem to fix.  It's non-intuitive that
>> manifest-lookup-package transitively looks for things instead of looking
>> at the profile.  I actually got tripped by that as well when I authored
>> gdk-pixbuf-loaders-cache-file, so there's now a comment in that same
>> file that reads:
>>
>>  ;; XXX: MANIFEST-LOOKUP-PACKAGE transitively searches through
>>  ;; every input referenced by the manifest, while MANIFEST-INPUTS
>>  ;; only retrieves the immediate inputs as well as their
>>  ;; propagated inputs; to avoid causing an empty output 
>> derivation
>>  ;; we must ensure that the inputs contain at least one
>>  ;; loaders.cache file.  This is why we include gdk-pixbuf or
>>  ;; librsvg when they are transitively found.
>>
>> I think we need a 'manifest-lookup-inputs' or similar that stops at the
>> profile, to work at the same depth as manifest-inputs.  Then it wouldn't
>> find texlive-base and the hook wouldn't run (and fail).
>
> There were cases (like GDK pixbuf, GLib schemas, and all that) where the idea
> was to take whichever glib/GDK we’d find in the dependency graph, and
> pick the command we need from it.  That way, we wouldn’t introduce any
> additional dependency.  That was the reasoning.
>
> Thinking about, this particular case might be easier: we can make things
> consistent like so:
>
> diff --git a/guix/profiles.scm b/guix/profiles.scm
> index 0785f9..41f3e25bb3 100644
> --- a/guix/profiles.scm
> +++ b/guix/profiles.scm
> @@ -1786,6 +1786,8 @@ (define entry->texlive-input
> (cons (gexp-input thing output)
>   (append-map entry->texlive-input deps))
> '()
> +  (define texlive-inputs
> +(append-map entry->texlive-input (manifest-entries manifest)))
>(define texlive-bin
>  (module-ref (resolve-interface '(gnu packages tex)) 'texlive-bin))
>(define coreutils
> @@ -1809,8 +1811,7 @@ (define build
>;; that TeX live can resolve the parent and grandparent directories
>;; correctly.  There might be a more elegant way to accomplish 
> this.
>(union-build "/tmp/texlive"
> -   '#$(append-map entry->texlive-input
> -  (manifest-entries manifest))
> +   '#$texlive-inputs
> #:create-all-directories? #t
> #:log-port (%make-void-port "w"))
>  
> @@ -1867,7 +1868,7 @@ (define build
>(install-file (string-append b "/ls-R") a))
>  
>(mlet %store-monad ((texlive-base (manifest-lookup-package manifest 
> "texlive-base")))
> -(if texlive-base
> +(if (and texlive-base (pair? texlive-inputs))
>  (gexp->derivation "texlive-font-maps" build
>#:substitutable? #f
>#:local-build? #t
>
>
> That way, the hook only fire if we have ‘texlive-base’ (somewhere in the
> graph) *and* we have texlive-* packages in the manifest.

That is equivalent, but it doesn't address the core problem in my
opinion.  There's no use to run hooks for things which aren't propagated
at the level of the profile, I think.  If texlive-base in is the
profile, the person wants to use tex and friends.  But if it's wrapped
by some package deep down, we shouldn't care.

I see it the same way as when using libraries and compilers in a
profile; the compiler (consumer) needs to be present else no search path
is created.

Does it make sense?

-- 
Thanks,
Maxim

bug#63043: texlive-font-maps.drv build failure when profiles lacks texlive-* packages

[Ludovic Courtès]

Hello!

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
>> Hi!
>>
>> (Cc: Maxim who may be familiar with the ‘texlive-font-maps’ hook.)
>
> Did you checked with Ricardo?  They were the author of that hook, per
> git blame :-).

I didn’t even look at ‘git blame’, I thought you were the one behind
this iteration :-), but Ricardo and I discussed it briefly on IRC.
Anyway, extending Cc!

>> There are probably two things to fix:
>>
>>   1. The ‘manifest-lookup-package’ check seems inconsistent with what’s
>>  passed to ‘union-build’.
>
> I think this is the problem to fix.  It's non-intuitive that
> manifest-lookup-package transitively looks for things instead of looking
> at the profile.  I actually got tripped by that as well when I authored
> gdk-pixbuf-loaders-cache-file, so there's now a comment in that same
> file that reads:
>
>  ;; XXX: MANIFEST-LOOKUP-PACKAGE transitively searches through
>  ;; every input referenced by the manifest, while MANIFEST-INPUTS
>  ;; only retrieves the immediate inputs as well as their
>  ;; propagated inputs; to avoid causing an empty output derivation
>  ;; we must ensure that the inputs contain at least one
>  ;; loaders.cache file.  This is why we include gdk-pixbuf or
>  ;; librsvg when they are transitively found.
>
> I think we need a 'manifest-lookup-inputs' or similar that stops at the
> profile, to work at the same depth as manifest-inputs.  Then it wouldn't
> find texlive-base and the hook wouldn't run (and fail).

There were cases (like GDK pixbuf, GLib schemas, and all that) where the idea
was to take whichever glib/GDK we’d find in the dependency graph, and
pick the command we need from it.  That way, we wouldn’t introduce any
additional dependency.  That was the reasoning.

Thinking about, this particular case might be easier: we can make things
consistent like so:

diff --git a/guix/profiles.scm b/guix/profiles.scm
index 0785f9..41f3e25bb3 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1786,6 +1786,8 @@ (define entry->texlive-input
(cons (gexp-input thing output)
  (append-map entry->texlive-input deps))
'()
+  (define texlive-inputs
+(append-map entry->texlive-input (manifest-entries manifest)))
   (define texlive-bin
 (module-ref (resolve-interface '(gnu packages tex)) 'texlive-bin))
   (define coreutils
@@ -1809,8 +1811,7 @@ (define build
   ;; that TeX live can resolve the parent and grandparent directories
   ;; correctly.  There might be a more elegant way to accomplish this.
   (union-build "/tmp/texlive"
-   '#$(append-map entry->texlive-input
-  (manifest-entries manifest))
+   '#$texlive-inputs
#:create-all-directories? #t
#:log-port (%make-void-port "w"))
 
@@ -1867,7 +1868,7 @@ (define build
   (install-file (string-append b "/ls-R") a))
 
   (mlet %store-monad ((texlive-base (manifest-lookup-package manifest "texlive-base")))
-(if texlive-base
+(if (and texlive-base (pair? texlive-inputs))
 (gexp->derivation "texlive-font-maps" build
   #:substitutable? #f
   #:local-build? #t

That way, the hook only fire if we have ‘texlive-base’ (somewhere in the
graph) *and* we have texlive-* packages in the manifest.

Thoughts?

Ludo’.

bug#62589: Help with patch with delayed evaluation

[Ludovic Courtès]

Hi Nicolas,

Nicolas Graves  skribis:

> * gnu/packages/machine-learning.scm (nerd-dictation):
> Avoid inputs pulseaudio and ydotool when not necessary.
> Factor out wrapper make-nerd-dictation-package.
> Add package variants :
> - nerd-dictation/xdotool
> - nerd-dictation/sox-xdotool
> - nerd-dictation/sox-ydotool
> - nerd-dictation/sox-wtype
> ---
>  gnu/packages/machine-learning.scm | 97 ++-
>  1 file changed, 69 insertions(+), 28 deletions(-)

Applied with the changes below (using ‘with-imported-modules’ instead of
passing #:modules, and #$output instead of the now-deprecated
‘%output’).

I also tweaked the commit log according to our conventions.

Thank you,
Ludo’.

diff --git a/gnu/packages/machine-learning.scm b/gnu/packages/machine-learning.scm
index 84b40e7b9b..c4dc668b82 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -3882,39 +3882,40 @@ (define-public nerd-dictation
   (license license:gpl2+
 
 (define (nerd-dictation-gexp input-name output-name bash nerd-dictation)
-  #~(begin
-  (use-modules (guix build utils))
-  (let* ((exe (string-append %output "/bin/nerd-dictation"))
- (nerd-dictation-exe
-  #$(file-append nerd-dictation "/bin/nerd-dictation")))
-(mkdir-p (dirname exe))
-(call-with-output-file exe
-  (lambda (port)
-(format port "#!~a
+  (with-imported-modules '((guix build utils))
+#~(begin
+(use-modules (guix build utils))
+
+(let* ((exe (string-append #$output "/bin/nerd-dictation"))
+   (nerd-dictation-exe
+#$(file-append nerd-dictation "/bin/nerd-dictation")))
+  (mkdir-p (dirname exe))
+  (call-with-output-file exe
+(lambda (port)
+  (format port "#!~a
 if [ \"$1\" = begin ]
   then
 exec ~a $@ --input=~a --simulate-input-tool=~a
   else
 exec ~a $@
 fi"
-#$(file-append bash "/bin/bash")
-nerd-dictation-exe
-#$input-name
-#$output-name
-nerd-dictation-exe)))
-(chmod exe #o555
+  #$(file-append bash "/bin/bash")
+  nerd-dictation-exe
+  #$input-name
+  #$output-name
+  nerd-dictation-exe)))
+  (chmod exe #o555)
 
 (define-public nerd-dictation/xdotool
   (package
 (inherit nerd-dictation)
 (name "nerd-dictation-xdotool")
 (build-system trivial-build-system)
-(arguments (list
-#:modules '((guix build utils))
-#:builder
-(nerd-dictation-gexp "PAREC" "XDOTOOL"
- (this-package-input "bash-minimal")
- (this-package-input "nerd-dictation"
+(arguments
+ (list #:builder
+   (nerd-dictation-gexp "PAREC" "XDOTOOL"
+(this-package-input "bash-minimal")
+(this-package-input "nerd-dictation"
 (inputs (list bash-minimal nerd-dictation))
 (propagated-inputs (list pulseaudio xdotool
 
@@ -3922,36 +3923,33 @@ (define-public nerd-dictation/sox-xdotool
   (package
 (inherit nerd-dictation/xdotool)
 (name "nerd-dictation-sox-xdotool")
-(arguments (list
-#:modules '((guix build utils))
-#:builder
-(nerd-dictation-gexp "SOX" "XDOTOOL"
- (this-package-input "bash-minimal")
- (this-package-input "nerd-dictation"
+(arguments
+ (list #:builder
+   (nerd-dictation-gexp "SOX" "XDOTOOL"
+(this-package-input "bash-minimal")
+(this-package-input "nerd-dictation"
 (propagated-inputs (list sox xdotool
 
 (define-public nerd-dictation/sox-ydotool
   (package
 (inherit nerd-dictation/xdotool)
 (name "nerd-dictation-sox-ydotool")
-(arguments (list
-#:modules '((guix build utils))
-#:builder
-(nerd-dictation-gexp "SOX" "YDOTOOL"
- (this-package-input "bash-minimal")
- (this-package-input "nerd-dictation"
+(arguments
+ (list #:builder
+   (nerd-dictation-gexp "SOX" "YDOTOOL"
+(this-package-input "bash-minimal")
+(this-package-input "nerd-dictation"
 (propagated-inputs (list sox ydotool
 
 (define-public nerd-dictation/sox-wtype
   (package
 (inherit nerd-dictation/xdotool)
 (name "nerd-dictation-sox-wtype")
-(arguments (list
-#:modules '((guix build utils))
-#:builder
-(nerd-dictation-gexp "SOX" "WTYPE"
-  

bug#63048: [Home] Shell alias values are not properly quoted

[Ekaitz Zarraga]

I made something like this instead of reusing the code you suggested, Ludo.
But it doesn't work. I don't really know why:

diff --git a/guix/scripts/home/import.scm b/guix/scripts/home/import.scm
index fd263c0699..2d7a7abbf2 100644
--- a/guix/scripts/home/import.scm
+++ b/guix/scripts/home/import.scm
@@ -64,12 +64,23 @@ (define (destination-append path)
   (define alias-rx
 (make-regexp "^alias ([^=]+)=[\"'](.+)[\"']$"))
 
+  (define (quote-style line)
+(cond
+  ((string-match "^alias ([^=]+)=[\"].*$" line) 'double)
+  ((string-match "^alias ([^=]+)=['].*$" line)  'single)))
+
   (define (bash-alias->pair line)
 (match (regexp-exec alias-rx line)
   (#f #f)
   (matched
`(,(match:substring matched 1) . ,(match:substring matched 2)
 
+  (define (escape-alias-body quote-style body)
+(if (eq? quote-style 'single)
+  (let* ((escaped-dquotes (string-replace-substring  body "\"" "\\\"")))
+(string-replace-substring escaped-dquotes "\\'" "'"))
+  body))
+
   (define (parse-aliases input)
 (let loop ((result '()))
   (match (read-line input)
@@ -78,7 +89,7 @@ (define (parse-aliases input)
 (line
  (match (bash-alias->pair line)
(#f(loop result))
-   (alias (loop (cons alias result
+   (alias (loop (cons alias (escape-alias-body (quote-style line) 
result)
 
   (let ((rc (destination-append ".bashrc"))
 (profile (destination-append ".bash_profile"))

bug#62936: [core-updates] pre-inst-env no longer works

[Brian Cully via Bug reports for GNU Guix]

Josselin Poiret  writes:


Ran into this problem myself, here's the reason and the fix:

We build a modified `guile` executable in the source tree (for 
reasons),

and use that to run guix.  Note that it is only added to PATH by
./pre-inst-env!  That guile executable is linked against glibc, 
and so
after upgrading to a newer glibc, it isn't rebuilt (I don't know 
how
autotools cope with external dependencies getting updated).  So 
glibc
2.33 gets loaded, and once (gcrypt) tries to open the libgcrypt 
library,
it fails because that newer library needs at least glibc 2.34. 
The
solution is just to `rm guile` inside of the checkout and run 
`make`

again.


With a lot of help on IRC, the culprit was discovered: you *must* 
run ‘guix pull --branch=core-updates’ to update your current 
profile's guix. This is because guix does not update itself 
without the pull.


Without this step, the guix in your user profile will keep around 
its old rules about which C compiler to use, which, in turn, pulls 
in the old glibc, which causes the error I initially reported.


-bjc

bug#57134: (no subject)

[Marcel van der Boom]

reopen 57134
quit

Apologies for the noise. I had a manifest in place working around 
the bug, but unfortunately the bug is still there.

bug#57134: Closing (2nd attempt)

[Maxim Cournoyer]

close 57134
quit

2nd close attempt :-)

-- 
Thanks,
Maxim

bug#62890: StumpWM fails to start - Read only file system

[Guillaume Le Vaillant]

Kjartan Óli Águstsson  skribis:

> I just started experiencing an issue with stumpwm where it fails to
> start, complaining about a read only file system.  A web search for the
> error message leads me to
> https://lists.gnu.org/archive/html/help-guix/2021-02/msg00080.html,
> which sounds exactly like the problem I'm experiencing.  I'm unsure how
> to get the backtrace shared in that thread, or in general how to proceed
> with debugging this.
>
> guix describe shows:
>   guix 9a5e1dc
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 9a5e1dc1f16f5f8c056e64f2077b035784003673
> but I tried rolling back to an earlier system generation:
>   guix:
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: d513ba83ebca347164098bb0fa1354f3657bc7e2
> to no success so I doubt it is a new change in Guix.
>
> Unless I'm missing something in the help-guix thread there is no
> solution discussed there, so any help in debugging this would be greatly
> appreciated.

Hi,

I just got the same problem after reconfiguring a machine (using
guix-home, but I'm not sure if it is relevant). It only happens when
I try to load extra modules from the ".stumpwm/init.lisp" file.

It looks like the configuration indicating where to search for the
compiled Common Lisp files (ASDF's source-registry and
output-translations) is not taken into consideration by Stumpwm
anymore... so it tries to recompile them in the wrong place.

As a workaround, replacing:
  exec stumpwm
by:
  exec sbcl --no-userinit --non-interactive --eval '(require :asdf)' --eval 
'(asdf:load-system "stumpwm")' --eval '(stumpwm:stumpwm)'
in my ".xsession" file seems to work...


signature.asc
Description: PGP signature

bug#58813: [PATCH v2 3/5] Makefile.am: Auto-configure Git on 'make'.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler  writes:

> Am Sonntag, dem 23.04.2023 um 22:29 -0400 schrieb Maxim Cournoyer:
>> This means we do not need to worry anymore about manually syncing the
>> pre-push git hook or the Guix-provided git configuration.

> IIUC we still need to invoke 'make .git/whatever' manually, and I'd
> actually like it to be that way, just with a nice phony target like
> 'make git-config' or 'make .git'.  WDYT?

Do, because the targets are added to nodist_noinst_DATA, they are
included in the default 'all' target (i.e., just invoking 'make' builds
them).

Because of that, a .PHONY target is not needed.  I think this is best,
since otherwise when etc/git/pre-push changed, you'd have to remember to
run 'make configure-git' for example.  It'd be error prone, and
easy to forget.

-- 
Thanks,
Maxim

bug#57134: (no subject)

[Maxim Cournoyer]

done
quit

Hello,

Marcel van der Boom  writes:

> This has been resolved with the 1.22.2 update.
>
> close
> quit

I think to get these Debbugs control commands to work, you need to CC
cont...@debbugs.gnu.org and have the commands appear at the top of the
email body :-).

Otherwise, you can also reply to 57134-d...@debbugs.gnu.org as a
shortcut.

-- 
Thanks,
Maxim

bug#63050: "guix pull" requires graphical libraries

[Andreas Enge]

While trying out a "guix pull" on an aarch64 machine, for which many
packages are currently not available as substitutes, I notice an extra-
ordinary amount of dependencies, see below (and since I interrupted and
restarted it, there are even more dependencies in reality; I remember
X11 libraries such as libxi and libxt). Many of them are related to
graphical environments, which should not happen for a command line
program. Chances are they are pulled in for building documentation
(not necessarily of Guix, but of packages that are needed for pulling);
but this is still undesirable and should be sorted out.

Actually there is a relatively high risk that on non-x86 machines
"guix pull" will fail due to one of the packages not building.
And then if the packages are fixed, they cannot be pulled...
(but substitutes would still work then).

Andreas


The following derivations will be built:
  /gnu/store/vrzlz31xgsmz05m294maxvkwld98yvwp-profile.drv
  /gnu/store/bmk0f4b0ia9vvm9djkhjp5yiibgiwqkv-guix-827df9d1d.drv
  /gnu/store/75051kjkpqyk63jfcc21jxx6blh1v6xj-guix-command.drv
  /gnu/store/4mpya4wbmid6rxszs6qrlr56hgxpsmzx-guix-module-union.drv
  /gnu/store/81vk2gf0qfz325wk0rdfabpjxkwgnlcx-guile-git-0.5.2.drv
  /gnu/store/k8pg7wpmhzkip9h4x6vw958i81p9rrxd-libgit2-1.3.2.drv
  /gnu/store/w0irp6xn30nlmpizhcbjnvhqmsba41jn-cmake-minimal-3.24.2.drv
  /gnu/store/cqw34xafh837ikspy26787spipggx158-curl-7.85.0.drv
  /gnu/store/mss4yv015cil1vnjnglq506m83b7n3dy-cmake-bootstrap-3.24.2.drv
  /gnu/store/w8qxkrwpffd9qs5w1jggy1yi27ycm0xr-jsoncpp-1.9.5.drv
  /gnu/store/hlscqram59id51hxg0fj15041v52h1kw-meson-1.1.0.drv
  /gnu/store/97ghaxk1q09aqi92x9qg3nwb5vjm22hv-guile-gnutls-3.7.11.drv
  /gnu/store/n1rv809j9jwmax12057l0lcphz4bzi7s-gnulib-2022-12-06-1.440b528.drv
  /gnu/store/0nhbmnck41rl3i8hipkxfcvzyi36wgnr-git-minimal-2.33.1.drv
  /gnu/store/jhi11h8m8i86ivzrmvfhyj4h99rpqb4y-guix-827df9d1d-modules.drv
  /gnu/store/0sivy14wkr7g1wsn2jgyz6dh53883k0h-guix-config-modules.drv
  /gnu/store/1bwjqypxjn3671xmc9b9wh9bfg85nwra-guix-config-source.drv
  /gnu/store/0047yrla9lddhb9c1b4kl4bpd5v9d7ly-config.scm.drv
  /gnu/store/d11yp292a29g2m07xn12s6g2hs6w5rq2-guix-config.drv
  /gnu/store/1qwajh2vs8gmvm882zcw6np48fh7xva8-guix-packages-modules.drv
  /gnu/store/v2790dmh2savq6ddgq0ics8yz9y8ysvq-guix-packages.drv
  /gnu/store/034h41xz3m57gms9mx7yydssa66ns6xa-guix-extra.drv
  /gnu/store/lxanzzz28qk7ypdib5hz8xmibi73g6nv-guile-avahi-0.4.1.drv
  /gnu/store/s2vi6njxmxv4ng78rfdb9xkdiy40fngb-avahi-0.8.drv
  /gnu/store/1liwcy87b3cafm2wwfza5jl9c3xfh3k7-glib-2.72.3.drv
  /gnu/store/7yfb32ngiyx6gsky8ccmaq06qvg9qi8f-dbus-1.14.0.drv
  /gnu/store/0f25lrmw7yc1k9rxxq6af7bjr4kxpi7c-itstool-2.0.7.drv
  /gnu/store/sjj9z6kchsbmzskp5i23blpkj2b9v1na-python-libxml2-2.9.14.drv
  /gnu/store/4axvv1sli67w1jx0c5fxi4369pklby8p-yelp-tools-3.32.2.drv
  /gnu/store/a1y2z3nh0lmbyiddnc5qq92p991vc6fl-yelp-xsl-41.0.drv
  /gnu/store/mzial98cazz0wmigjd0by59ympr62zmv-xmlto-0.0.28.drv
  /gnu/store/r33mnrmy08757czq7x19lbawmngkswb8-docbook-xsl-1.79.2-0.fe16c90.drv
  /gnu/store/ywxvva73z0gmnjbdac9ml3fld4agy7ll-perl-xml-xpath-1.44.drv
  /gnu/store/744pph8mif8911dij1gw838slmgsplr4-perl-path-tiny-0.118.drv
  /gnu/store/nlrv7ll0gdf2k7g0v1g0d2c1sz2ff9pa-perl-unicode-utf8-0.62.drv
  /gnu/store/r84snp03sqlmvssfsa6f3wank4249dbm-perl-test-fatal-0.016.drv
  /gnu/store/rqk2rbnpjpcnqswz8hqari1rnw6r8v1m-doxygen-1.9.5.drv
  /gnu/store/zs50rf9mqd77lf7f7ycwj98mdvm3nwc1-guile-ssh-0.16.3.drv
  /gnu/store/cysfj5rhcnlwnd0skpb8x5cvh320qcpx-libssh-0.10.4.drv
  /gnu/store/kfqkj69hxgdl2yhn27l1cx3v4b83438k-guix-packages-base.drv
  /gnu/store/24bwa2hmiydpjjv58kbnszc67d0063w8-guix-extra-modules.drv
  /gnu/store/cl6757qxk66kpwhhwscwd3z3ir9ylfxy-guix-cli-core-modules.drv
  /gnu/store/fb71xmnmdi506sjjfqvvhk2n4q5nw9b5-guix-cli-core.drv
  /gnu/store/f5p7zbpi3f8bbc1bsdbr293r4p4qlr6k-guix-packages-base-modules.drv
  /gnu/store/gyncf7k5kvwcfbw1dx3jc73n9jmdw3ml-guix-home-modules.drv
  /gnu/store/9m9iiqd2yvlbjnpxzfwfk94bi9i2gj13-guix-home.drv
  /gnu/store/dqjb6lb1m8kaam2klgc44j1g040pr1h4-guix-system.drv
  /gnu/store/i2vpbmmyywk9sd11hl02zfg1nigq0k24-guix-system-tests-modules.drv
  /gnu/store/zm9yhv95zs1j68ypl9kr4gm4bbymgw3m-guix-system-tests.drv
  /gnu/store/ca9k2x3z22dn489g976p31fw8cr05p6s-guix-cli.drv
  /gnu/store/rk24641w60fqddyj0b4lizndcxvrpl45-guix-cli-modules.drv
  /gnu/store/wd94xqha92w7wj75704j48yh17pghv48-guix-system-modules.drv
  /gnu/store/sgyi2j6333mv08r8xxyxhaj47886q3hs-guix-daemon.drv
  /gnu/store/r80zify247zcsxdw1dm6aacr456zqxyf-guix-daemon-1.4.0-5.286cdf0.drv
  /gnu/store/w0ssgndl2aq7xzc3ibbkgg4dpgyf2mxb-guix-manual.drv
  /gnu/store/44l2hp82lmrhmsam320020pvf0wx79gb-guix-translated-texinfo.drv
  /gnu/store/hx8pv27k6r1q5gmdb0zmp9pqqadqp8gh-po4a-0.68.drv
  /gnu/store/04kfwmpg17hxxzq13b9s06zl63zcc706-texlive-fonts-latex-59745.drv
  /gnu/store/2lk5x3aw5vi59dkvf1qd0696fdmirgb7-texlive-bin-20210325.drv
  /gnu/store/1liwcy87b3cafm2wwfza5jl9c3xfh3k7-glib-2.72.3.drv
  /gnu/store/2l7j29ck29dcaaffi659pkpxr9bmp64f-gd-2.3.2.drv
  

bug#63048: [Home] Shell alias values are not properly quoted

[Ekaitz Zarraga]

As an extra note:

The problem I encountered was when the alias was defined using single quote 
marks:

alias ls='ls blabla "problem"'

this is parsed to:

("ls" . "blabla \"problem\"")

Which is written as:

alias ls="blabla "problem""

Which is wrong.

So the problem relies on the fact that the quotations marks have been changed 
from ' to " and the escaping have not been adjusted accordingly.

:)

bug#62956: Fail to update gajim

[Andreas Enge]

Am Mon, Apr 24, 2023 at 10:51:31AM +0200 schrieb Simon Tournier:
> Please note #62956 reporting the failure and proposing a patch.

Thanks for the notice! On core-updates, the current gajim requires
python-gssapi, which fails to build; so this would have to be repaired
additionally to the above patch.

Andreas

bug#63011: gajim 1.4.7 build failure

[Simon Tournier]

Hi,

On Sat, 22 Apr 2023 at 06:25, "bdju" via Bug reports for GNU Guix 
 wrote:
> Another day, another build failure. Python-related again.
> guix (GNU Guix) 040d35f088e0f1c856f3f5a9b6bf889b17bd68b3

Well, I have merge with the duplicated #62956 [1].

Note that #62956 [1] also contains a patch probably fixing the issue.


1: https://issues.guix.gnu.org/issue/62956


Cheers,
simon

bug#63024: Crash during `guix import pypi -r'

[Simon Tournier]

Hi,

On Sat, 22 Apr 2023 at 21:59, "Timo Wilken"  wrote:

> The `guix import pypi -r ...' command frequently crashes for me. When
> it does, it always crashes on the third download, the one for the
> first dependency's source distribution, like so:

Thanks for the report.  I am merging with #62334 [1].

1: http://issues.guix.gnu.org/issue/62334


Cheers,
simon

bug#62334: Network is unreachable only for recursive pypi import

[zimoun]

Hi,

On Fri, 24 Mar 2023 at 08:19, Maxim Cournoyer  wrote:

> I can't reproduce it either, so it seems a genuine network error on your
> side.

As I report in #62765 [1], it seems a regression on our side:

which passes with 29efa27.  And indeed, using 86d580c, “guix import pypi
num2words -r” passes without any error, downloading from the exact same
URL. Hum?!

Well, I do not know which change impacts this regression.

1: http://issues.guix.gnu.org/msgid/87ile2ihj4@gmail.com


Cheers,
simon

PS: Well, I just merged 2 other issues reporting the same behaviour.

bug#62936: [core-updates] pre-inst-env no longer works

[Josselin Poiret via Bug reports for GNU Guix]

Hello everyone,

Brian Cully via Bug reports for GNU Guix  writes:

> I did a full rebuild before submitting this bug: bootstrap -> configure
> -> make clean -> make.
>
> FWIW, I still have the issue with ‘pre-inst-env’ when not run from
> within ‘guix shell -D guix’, which is a step I have never previously
> needed. As I just explained on IRC:
>
> --8<---cut here---start->8---
>  i'm confused why it's suddenly a problem, though. i've never needed to
>   use ‘guix shell’ with pre-inst-env before  [15:41]
>  ludo says it's libgit2 linking against an old libc, but i have no idea
>   how that's even possible
>  for one thing: my system has been reconfigured. all my packages are now
>   running core-updates, and that includes libgit2. for another: doesn't
>   libgit link with a specific path in /gnu/store, so it'll use whatever
>   glibc it needs regardless of what's in my “system” configuration?
> --8<---cut here---end--->8---
>
> Even if this is some particular problem to my build environment somehow,
> I'd love an explanation as to what's going on because I'm extremely
> confused.
>
> In case it matters, I've re-run ‘system reconfigure’ and ‘home
> reconfigure’ since moving to core-updates, thinking maybe there's some
> bootstrapping issue. I'm now 2 system and home generations into
> core-updates, but I have the same problem.
>
> Thanks,

Ran into this problem myself, here's the reason and the fix:

We build a modified `guile` executable in the source tree (for reasons),
and use that to run guix.  Note that it is only added to PATH by
./pre-inst-env!  That guile executable is linked against glibc, and so
after upgrading to a newer glibc, it isn't rebuilt (I don't know how
autotools cope with external dependencies getting updated).  So glibc
2.33 gets loaded, and once (gcrypt) tries to open the libgcrypt library,
it fails because that newer library needs at least glibc 2.34.  The
solution is just to `rm guile` inside of the checkout and run `make`
again.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#57134: (no subject)

[Marcel van der Boom]

This has been resolved with the 1.22.2 update.

close
quit

bug#63048: [Home] Shell alias values are not properly quoted

[Ludovic Courtès]

Hi!

As Ekaitz reported on Mastodon, shell alias values are not properly
quoted, which causes problem when an alias value contains double-quotes
for instance:

--8<---cut here---start->8---
(define (bash-serialize-aliases field-name val)
  #~(string-append
 #$@(map
 (match-lambda
   ((key . #f)
"")
   ((key . #t)
#~(string-append "alias " #$key "\n"))
   ((key . value)
#~(string-append "alias " #$key "=\"" #$value "\"\n")))
 val)))
--8<---cut here---end--->8---

The solution is to borrow and factorize the code of
‘environment-variable-shell-definitions’, which does it right.

Ludo’.

bug#63047: Can't load glib debug symbols in gdb

[Josselin Poiret via Bug reports for GNU Guix]

Hi Andrew,

Andrew Tropin  writes:

> I try to run emacs in gdb with debug symbols for some libs available, I
> succeed with gtk+, but it doesn't work for glib and glibc.  It looks
> strange to me, but maybe I am doing something wrong.
>
> Reproducer:
>
> guix shell gdb emacs-next-pgtk glibc:debug gtk+:debug glib:debug \
>  --with-debug-info=glibc --with-debug-info=glib --with-debug-info=gtk+ \
>  --no-grafts -- gdb .emacs-30.0.50-real

At least for glibc, the glibc that is linked against is the one in (gnu
packages commencement), which is hidden from the user.  The one in (gnu
packages base), which you can refer to with "glibc" is different.  You
can try to find the proper debug output by looking at `guix size` of
your store path, then finding out the deriver for glibc with `guix gc
--derivers` and finally looking at the .drv to find out what the debug
output should be.

For glib, it might be similar, make sure that you're using exactly the
right store path for it.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63047: Can't load glib debug symbols in gdb

[Andrew Tropin]

I try to run emacs in gdb with debug symbols for some libs available, I
succeed with gtk+, but it doesn't work for glib and glibc.  It looks
strange to me, but maybe I am doing something wrong.

Reproducer:

guix shell gdb emacs-next-pgtk glibc:debug gtk+:debug glib:debug \
 --with-debug-info=glibc --with-debug-info=glib --with-debug-info=gtk+ \
 --no-grafts -- gdb .emacs-30.0.50-real

--8<---cut here---start->8---
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
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.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from .emacs-30.0.50-real...
(No debugging symbols found in .emacs-30.0.50-real)
(gdb) run -q
Starting program: 
/gnu/store/g59lvzvhbai1dcrbckaw4qvf4amxyfa2-profile/bin/.emacs-30.0.50-real -q
warning: Unable to find libthread_db matching inferior's thread library, thread 
debugging will not be available.
[New LWP 14944]
[New LWP 14945]
[New LWP 14946]
Gdk-Message: 11:19:32.820: Unable to load sb_v_double_arrow from the cursor 
theme
Gdk-Message: 11:19:32.820: Unable to load sb_h_double_arrow from the cursor 
theme
Gdk-Message: 11:19:32.838: Unable to load hand2 from the cursor theme
Gdk-Message: 11:19:32.838: Unable to load sb_h_double_arrow from the cursor 
theme
Gdk-Message: 11:19:32.838: Unable to load sb_v_double_arrow from the cursor 
theme
[New LWP 14947]
[LWP 14947 exited]
[New LWP 14948]
[New LWP 14949]
[LWP 14948 exited]
[LWP 14949 exited]
[New LWP 14950]
[New LWP 14951]
[LWP 14950 exited]
[LWP 14951 exited]
^Z
Thread 1 ".emacs-30.0.50-" received signal SIGTSTP, Stopped (user).
0x73def17b in pselect () from 
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6
(gdb) info dll
FromTo  Syms Read   Shared Object Library
0x77fcf050  0x77ff15ee  Yes (*) 
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-linux-x86-64.so.2
0x7769c070  0x779e9936  Yes 
/gnu/store/whgbkfyggc3ljkh7y9wqwvqgnsnnyf7w-gtk+-3.24.30/lib/libgtk-3.so.0
0x77ee6190  0x77f5efdd  Yes 
/gnu/store/whgbkfyggc3ljkh7y9wqwvqgnsnnyf7w-gtk+-3.24.30/lib/libgdk-3.so.0
0x77ea9b20  0x77eaf8c0  Yes (*) 
/gnu/store/vk23fcm4livzrnb3kzhxs6yjds8f355c-pango-1.48.10/lib/libpangocairo-1.0.so.0
0x77e61c80  0x77e8711e  Yes (*) 
/gnu/store/vk23fcm4livzrnb3kzhxs6yjds8f355c-pango-1.48.10/lib/libpango-1.0.so.0
0x7751fec0  0x775c462e  Yes (*) 
/gnu/store/f6ibajh7x233cvr30c2p314l2absk36h-harfbuzz-2.8.2/lib/libharfbuzz.so.0
0x77e316b0  0x77e3ed44  Yes (*) 
/gnu/store/np9pryvn0rxc00cc6g4jd7rlcxwk2mxs-atk-2.36.0/lib/libatk-1.0.so.0
0x7750d0a0  0x7750e20d  Yes (*) 
/gnu/store/6gq2n65ixpn6drd5wai2h7g5wjm6bp2b-cairo-1.16.0/lib/libcairo-gobject.so.2
0x773fc680  0x774c3a97  Yes (*) 
/gnu/store/6gq2n65ixpn6drd5wai2h7g5wjm6bp2b-cairo-1.16.0/lib/libcairo.so.2
0x773c9b50  0x773dccde  Yes (*) 
/gnu/store/xgiz9rvzvfhwx655lb6jpjx1whc4kjg8-gdk-pixbuf-2.42.4/lib/libgdk_pixbuf-2.0.so.0
0x7721e980  0x773267e6  Yes (*) 
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgio-2.0.so.0
0x77191760  0x771be826  Yes (*) 
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0
0x7706ed40  0x770f4a7e  Yes (*) 
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libglib-2.0.so.0
0x76fd5dc0  0x77018105  Yes (*) 
/gnu/store/343iqv9hvbvzp2in0hs03dvygccrcapl-libtiff-4.3.0/lib/libtiff.so.5
0x76f39500  0x76f8e0c5  Yes (*) 
/gnu/store/g5hf1zhqlcyx9vw3q1xa52bgddaqsfm5-libjpeg-turbo-2.0.5/lib/libjpeg.so.62
0x76f05900  0x76f2739a  Yes (*) 
/gnu/store/p7iq81hxxyk9zy7a9dngbf16zm8d4klx-libpng-1.6.37/lib/libpng16.so.16
0x76ee52f0  0x76ef5cc4  Yes (*) 
/gnu/store/8qv5kb2fgm4c3bf70zcg9l6hkf3qzpw9-zlib-1.2.11/lib/libz.so.1
0x76ed9390  0x76edd58b  Yes (*) 
/gnu/store/4d0ssibbd2glk1vc93zj738awmy22xad-giflib-5.2.1/lib/libgif.so.7
0x76e0fcc0  0x76e93bd6  Yes (*) 
/gnu/store/nfxcjvv9c2q6in9x52kkkayqv38k00ai-alsa-lib-1.2.4/lib/libasound.so.2
0x76512070  0x76a2df5c  Yes (*)