bug#58207: Bug: Package Celluloid generates an icon cache which overwrites the profile's icon cache

[Pkill9]

The Celluloid package generates it's own icon cache at
share/icons/hicolor/icon-theme.cache. When you install the Celluloid, I
believe this overwrites the profile's icon-theme.cache, which causes
none of the other icons to show up in launchers that use this, for
example gnome shell's application launcher.

Perhaps also it is an issue that the profile's generated files do not
have priority over all the files within all the packages installed to
the profile, i.e. none of the packages should be able to overwrite the
files generated with the profile hooks. 

bug#58203: Cuirass fails to respect (target-x86-32?) in some circumstances

[Ludovic Courtès]

Marius Bakke  skribis:

> Hello,
>
> I noticed Cuirass attempts to run imath tests on i686-linux:
>
>   https://ci.guix.gnu.org/build/739643/details

Following the links, this corresponds to
, itself corresponding to commit
f5fe0082abe4547f3fb9f29d8351473cfb3a387b, which dates back to May.

So this is a recent build for an old commit; maybe it had been queued
for some time and just got unlocked today?  Weirdness.

The good news is that with today’s ‘staging’, everything’s fine:

--8<---cut here---start->8---
$ guix time-machine --commit=e0546a11f0b65e301dc9d1d1cfec26e686070029 -- 
weather imath -s i686-linux
computing 1 package derivations for i686-linux...
looking for 1 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org ☀
  100.0% substitutes available (1 out of 1)
  at least 0.2 MiB of nars (compressed)
  0.9 MiB on disk (uncompressed)
  0.230 seconds per request (0.2 seconds in total)
  4.3 requests per second

[...]

$ guix time-machine --commit=e0546a11f0b65e301dc9d1d1cfec26e686070029 -- build 
imath -s i686-linux -d --no-grafts
/gnu/store/g31xfskliryh10gij1hidydykqk7bb6z-imath-3.1.3.drv
--8<---cut here---end--->8---

Thanks,
Ludo’.

bug#42141: blast+ is not reproducible

[Maxim Cournoyer]

Hi,

Ricardo Wurmus  writes:

> zimoun  writes:
>
>> Hi,
>>
>> On Thu, 29 Sep 2022 at 23:09, Maxim Cournoyer  
>> wrote:
>>> Ricardo Wurmus  writes:
>>>
 Fixed with commit 1ee2d117d8fa9e2e0d4ec46cc497bb5e6337.
>>>
>>> Yay!  Thank you!  And for my curiosity, how did I get the two build
>>> farms to agree on an identical build, as reported in 'guix challenge'?
>>>
>>> That is odd.
>>
>> Because blast+ is multi-outputs and ’out’ is fine contrary to ’include’:
>>
>> $ guix challenge blast+:include
>> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include contents 
>> differ:
>>   local hash: 0q4nssknlmc54m8abndn9bhrlwm4m28lkb75i1wnwr0ghbalj02x
>>   
>> https://ci.guix.gnu.org/nar/lzip/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast%2B-2.11.0-include:
>>  0q4nssknlmc54m8abndn9bhrlwm4m28lkb75i1wnwr0ghbalj02x
>>   
>> https://bordeaux.guix.gnu.org/nar/lzip/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast%2B-2.11.0-include:
>>  0cakizfsqb1lla62cmwnng1h9gvqgf3lyjk0k7lkiaisj713mpzx
>>   differing files:
>> /include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
>> /include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
>>
>> 1 store items were analyzed:
>>   - 0 (0.0%) were identical
>>   - 1 (100.0%) differed
>>   - 0 (0.0%) were inconclusive
>
> Ah, thanks for explaining!

Ah!  Shouldn't the default be to compare all outputs?  It seems that'd
be less surprising and useful.

What do you think?

-- 
Maxim

bug#58205: reconfiguration stuck unless using '--no-grafts'

[Maxim Cournoyer]

Hi,

While working on Berlin today from a chroot, and with --no-substitutes
used for guix-daemon, I wasn't able to complete the 'guix system
reconfigure' step; it'd hand on a read call (seen using strace):

--8<---cut here---start->8---
statfs("/gnu/store", {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096, 
f_blocks=26843282944, f_bfree=14069128626, f_bavail=14067391234, f_files=0, 
f_ffree=0, f_fsid={val=[0x4f5822b0, 0xf74cbbd4]}, f_namelen=255, f_frsize=4096, 
f_flags=ST_VALID|ST_RELATIME}) = 0
write(14, "\t\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0006\0\0\0\0\0\0\0/gnu/sto"..., 152) 
= 152
read(14, "gmlo\0\0\0\0", 8) = 8
read(14, "\276\0\0\0\0\0\0\0", 8)   = 8
read(14, "@ build-started /gnu/store/kv1gh"..., 192) = 192
) = 12
write(2, "applying 3 grafts for guix-1.3.0"..., 48applying 3 grafts for 
guix-1.3.0-29.9e46320 ...
) = 48
read(14, "gmlo\0\0\0\0", 8) = 8
read(14, "\255\0\0\0\0\0\0\0", 8)   = 8
read(14, "@ build-log 17291 151\ngrafting '"..., 176) = 176
\)= 5
read(14,
--8<---cut here---end--->8---

After passing --no-grafts to 'guix system reconfigure', it could
complete without any error.

-- 
Thanks,
Maxim

bug#58204: guix system reconfigure hangs silently when substitute server is unreachable

[Maxim Cournoyer]

Hi,

While fixing up Berlin today, I had to use '--no-substitutes' on the
daemon started per 'info (guix)Chrooting', otherwise it'd hang up
without printing any of the warnings (totally silent).  Using strace, I
could see:

--8<---cut here---start->8---
guix substitute: warning: ci.guix.gnu.org: host not found: System error
--8<---cut here---end--->8---

It'd be nice if these warnings were propagated all the way up so the
user would realize what is happening and take action.

-- 
Thanks,
Maxim

bug#58203: Cuirass fails to respect (target-x86-32?) in some circumstances

[Marius Bakke]

Hello,

I noticed Cuirass attempts to run imath tests on i686-linux:

  https://ci.guix.gnu.org/build/739643/details

Which is odd, because the package definition has:

  (list #:tests? (not (target-x86-32?)))

This behavior does not reproduce when manually building for i686-linux.


signature.asc
Description: PGP signature

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

[Maxime Devos]

On 30-09-2022 05:10, Maxim Cournoyer wrote:

Hi,

Ludovic Courtès  writes:


Hi,

zimoun  skribis:


This “meta” bug raises 2 levels of issues for long-term:

  1. save the source code,
  2. save the current binary substitutes.


Maybe we can close this bug and open an issue for each of these, or
discuss them on guix-devel until there are actionable items that come
out of it?

Or better yet: we could file more specific bugs such as “Disarchive
lacks bzip2 support” or “SWH integration does not support Subversion”.

Thoughts?


Wholly agreed, this thread is already too long and the original problem
was fixed.  Closing.


I don't follow, our gf2x package (and a few others) still download from 
gforge.inria.fr?  Which to me seems to be what zimoun is referring to 
(in the response)?


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58198: topological-sort does not sort topologically in case of diamonds

[Maxime Devos]

Consider the following DAG (arrows are implicitly downwards):

top -> left, right
left,right -> bottom.

Or in ASCII art:

 top
/\
left  right
\/
 bottom

Currently, they are sorted incorrectly with topological-sort -- the 
exact resulting order depends on the order in which the dependencies are 
passed to 'topological-sort' (from (guix import utils)), but you can get 
the following:


right bottom left top

'bottom' and 'right' need to be switched.

(Background)
I would like to use a copy of 'topological-sort' for determining the 
order in which 'workspace' members need to be built in antioxidant, but 
currently it produces bogus results (at least for 'greetd').


Theoretically, it would also impact recursive imports (unverified) 
(topological-sort is used to emit them in topological order).


Code to reproduce the bug:

(use-modules (guix sets) (ice-9 match) (srfi srfi-1))

(define (topological-sort nodes
  node-dependencies
  node-name)
  "Perform a breadth-first traversal of the graph rooted at NODES, a 
list of

nodes, and return the list of nodes sorted in topological order.  Call
NODE-DEPENDENCIES to obtain the dependencies of a node, and NODE-NAME to
obtain a node's uniquely identifying \"key\"."
  (let loop ((nodes nodes)
 (result '())
 (visited (set)))
(match nodes
  (()
   result)
  ((head . tail)
   (if (set-contains? visited (node-name head))
   (loop tail result visited)
   (let ((dependencies (node-dependencies head)))
 (loop (append dependencies tail)
   (cons head result)
   (set-insert (node-name head) visited

(define %dependencies
  '((top left right)
(left bottom)
(right bottom)
(bottom)))
(define root-nodes '(top))
(define (node-dependencies node)
  (assoc-ref %dependencies node))
(define node-name identity)
(define sorted (topological-sort root-nodes node-dependencies node-name))
(write sorted)

;; Verify the dependencies have smaller indices
(define (node-index node)
  (list-index (lambda (x) (equal? node x)) sorted))
(define (check node)
  (unless (<= (apply max 0 (map node-index (node-dependencies node)))
  (node-index node))
(pk node)
(error "incorrectly sorted!")))
(for-each check (map car %dependencies))


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58166: Changes to mcron service not applied after home reconfiguration

[Fabio Natali]

On 2022-09-29, 16:21:20 +0100, Fabio Natali wrote:
> After updating the above snippet in my `home-config.scm' and launching
> a home-reconfiguration, I noticed that the mcron changes had not been
> picked up.

I stand corrected. Changes do seem to be picked up now. I'm no longer
able to reproduce this. Possibly solved after a recent upgrade. Thanks,
best, Fabio.

bug#42141: blast+ is not reproducible

[Ricardo Wurmus]

zimoun  writes:

> Hi,
>
> On Thu, 29 Sep 2022 at 23:09, Maxim Cournoyer  
> wrote:
>> Ricardo Wurmus  writes:
>>
>>> Fixed with commit 1ee2d117d8fa9e2e0d4ec46cc497bb5e6337.
>>
>> Yay!  Thank you!  And for my curiosity, how did I get the two build
>> farms to agree on an identical build, as reported in 'guix challenge'?
>>
>> That is odd.
>
> Because blast+ is multi-outputs and ’out’ is fine contrary to ’include’:
>
> $ guix challenge blast+:include
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include contents 
> differ:
>   local hash: 0q4nssknlmc54m8abndn9bhrlwm4m28lkb75i1wnwr0ghbalj02x
>   
> https://ci.guix.gnu.org/nar/lzip/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast%2B-2.11.0-include:
>  0q4nssknlmc54m8abndn9bhrlwm4m28lkb75i1wnwr0ghbalj02x
>   
> https://bordeaux.guix.gnu.org/nar/lzip/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast%2B-2.11.0-include:
>  0cakizfsqb1lla62cmwnng1h9gvqgf3lyjk0k7lkiaisj713mpzx
>   differing files:
> /include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
> /include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
>
> 1 store items were analyzed:
>   - 0 (0.0%) were identical
>   - 1 (100.0%) differed
>   - 0 (0.0%) were inconclusive

Ah, thanks for explaining!

-- 
Ricardo

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

[zimoun]

Hi,

On Thu, 29 Sep 2022 at 23:10, Maxim Cournoyer  wrote:

> Wholly agreed, this thread is already too long and the original problem
> was fixed.  Closing.

I disagree, the original problem is not fixed; as I explained.  Well,
since you consider it is, please also close the related patch#43442.

Cheers,
simon

bug#42141: blast+ is not reproducible

[zimoun]

Hi,

On Thu, 29 Sep 2022 at 23:09, Maxim Cournoyer  wrote:
> Ricardo Wurmus  writes:
>
>> Fixed with commit 1ee2d117d8fa9e2e0d4ec46cc497bb5e6337.
>
> Yay!  Thank you!  And for my curiosity, how did I get the two build
> farms to agree on an identical build, as reported in 'guix challenge'?
>
> That is odd.

Because blast+ is multi-outputs and ’out’ is fine contrary to ’include’:

--8<---cut here---start->8---
$ guix challenge blast+:include
/gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include contents 
differ:
  local hash: 0q4nssknlmc54m8abndn9bhrlwm4m28lkb75i1wnwr0ghbalj02x
  
https://ci.guix.gnu.org/nar/lzip/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast%2B-2.11.0-include:
 0q4nssknlmc54m8abndn9bhrlwm4m28lkb75i1wnwr0ghbalj02x
  
https://bordeaux.guix.gnu.org/nar/lzip/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast%2B-2.11.0-include:
 0cakizfsqb1lla62cmwnng1h9gvqgf3lyjk0k7lkiaisj713mpzx
  differing files:
/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
/include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h

1 store items were analyzed:
  - 0 (0.0%) were identical
  - 1 (100.0%) differed
  - 0 (0.0%) were inconclusive
--8<---cut here---end--->8---


Cheers,
simon

bug#58166: Changes to mcron service not applied after home reconfiguration

[Fabio Natali]

Dear All,

My Guix Home configuration includes a Mcron service along the lines of:

,
| (define my/home-mcron-service
|   (service
|home-mcron-service-type
|(home-mcron-configuration
| (jobs
|  (list
|   #~(job
|  '(next-minute)
|  (lambda () (system* "notmuch" "new"))
|  "Get new email and process it via the Notmuch hook scripts."))
`

After updating the above snippet in my `home-config.scm' and launching a
home-reconfiguration, I noticed that the mcron changes had not been
picked up.

For instance, `herd schedule mcron' prints information that's clearly
related to the previous job. A `herd restart mcron' also doesn't seem to
help.

The mcron job is finally picked up when restarting the system though,
which also seems to confirm the mcron job is ok, in itself.

I'll try and explore this a bit further later but I thought of opening a
bug as well. Anyone else having the same issue?

Thanks, best, Fabio.

bug#58191: missing substitute for @gschemasCompiled@ ?

[Attila Lendvai]

i'm attaching my current WIP diff while i was trying to debug this.

note that in my original submission there was a substitute for 
@gschemasCompiled@ (https://issues.guix.gnu.org/53072), but it did not reach 
master when it got pushed 
(https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/gnome-xyz.scm?id=a485e1e663060e8c62103d81dfffec591f624360).

i'm not sure whether it's important. it shouldn't be, because gpaste used to 
work for me right until a recent reconfigure... but i thought that i point it 
out. if that substitute was intentionally left out, then it may warrant a 
comment on why, because the package's .patch file (inherited from NixOS) adds 
the marker 
(https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/gpaste-fix-paths.patch).

i tried to reinstate the substitute, as you can see below, but it does not fix 
the new crash. i added some asserts, even sure-to-fail ones, and that code path 
seems not yet reached when the sigsegv already happens.

i'm out of ideas, and certainly out of my glib knowledge.



2 files changed, 11 insertions(+), 5 deletions(-)
gnu/packages/gnome-xyz.scm  | 12 
gnu/packages/patches/gpaste-fix-paths.patch |  4 +++-

modified   gnu/packages/gnome-xyz.scm
@@ -819,7 +819,7 @@ (define-public gnome-shell-extension-paperwm
 (define-public gpaste
   (package
 (name "gpaste")
-(version "42.1")
+(version "42.2")
 (source (origin
   (method git-fetch)
   (uri (git-reference
@@ -828,12 +828,13 @@ (define-public gpaste
   (file-name (git-file-name name version))
   (sha256
(base32
-"1dlqa69zvzzdxyh21qfrx2nhpfy0fbihxpgkxqmramcgv3h5k4q3"))
+"0qq2p19p3r3lz8yfynpnf36cipv54bzdbmq1x5zgwhyl4yl41g28"))
   (patches
(search-patches "gpaste-fix-paths.patch"
 (build-system meson-build-system)
 (native-inputs
- (list gettext-minimal
+ (list gcr
+   gettext-minimal
gobject-introspection
(list glib "bin"); for glib-compile-resources
pkg-config
@@ -862,7 +863,10 @@ (define-public gpaste
(substitute* '("src/gnome-shell/extension.js"
   "src/gnome-shell/prefs.js")
  (("@typelibPath@")
-  (string-append #$output "/lib/girepository-1.0/"
+  (string-append #$output "/lib/girepository-1.0/")))
+   (substitute* '("src/libgpaste/gpaste/gpaste-settings.c")
+ (("@gschemasCompiled@")
+  (string-append #$output 
"/share/glib-2.0/schemas/"
 (home-page "https://github.com/Keruspe/GPaste;)
 (synopsis "Clipboard management system for GNOME Shell")
 (description "GPaste is a clipboard manager, a tool which allows you to
modified   gnu/packages/patches/gpaste-fix-paths.patch
@@ -30,14 +30,16 @@ diff --git a/src/libgpaste/gpaste/gpaste-settings.c 
b/src/libgpaste/gpaste/gpast
 index 7e53eb64..57c399fc 100644
 --- a/src/libgpaste/gpaste/gpaste-settings.c
 +++ b/src/libgpaste/gpaste/gpaste-settings.c
-@@ -1013,7 +1013,11 @@ create_g_settings (void)
+@@ -1013,7 +1013,13 @@ create_g_settings (void)
  }
  else
  {
 -return g_settings_new (G_PASTE_SETTINGS_NAME);
 +// library used by introspection requires schemas but we cannot set 
XDG_DATA_DIRS for the library
 +GSettingsSchemaSource *schema_source = 
g_settings_schema_source_new_from_directory ("@gschemasCompiled@", NULL, FALSE, 
NULL);
++g_assert (schema_source);
 +g_autoptr (GSettingsSchema) schema = g_settings_schema_source_lookup 
(schema_source, G_PASTE_SETTINGS_NAME, FALSE);
++g_assert (schema);
 +g_settings_schema_source_unref (schema_source);
 +return g_settings_new_full (schema, NULL, NULL);
  }

bug#42141: blast+ is not reproducible

[Ricardo Wurmus]

Maxim Cournoyer  writes:

> Ricardo Wurmus  writes:
>
>> Fixed with commit 1ee2d117d8fa9e2e0d4ec46cc497bb5e6337.
>
> Yay!  Thank you!  And for my curiosity, how did I get the two build
> farms to agree on an identical build, as reported in 'guix challenge'?
>
> That is odd.

I don’t know.  I also got the same result from “guix challenge”, but I
hadn’t built it locally.  It was only when I built it on my machine (and
with “--check”) that I confirmed that the issue still existed.

Any way of making “guix challenge” tell us more about what it actually
compared?

-- 
Ricardo

bug#58149: guix pull error

[Matthieu Haefele]

Le 29/09/2022 à 19:55, Maxime Devos a écrit :



On 29-09-2022 17:35, Matthieu Haefele wrote:



(base) mhaefele@mdlspc113:work $ 
/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version

guix-daemon (GNU Guix) 1.0.1




Updating the daemon triggers the same error wit "unsupported compression scheme 
lzip"



(base) mhaefele@mdlspc113:work $ sudo -i guix pull


IIUC how your Guix service is set up, this does indeed update the daemon, but the old Guix daemon is still running, you'll need 
to restart it with whatever mechanism your foreign distribution uses.


Greetings,
Maxime.


Fair enough. But the daemon update fails because of lzip missing, so there is 
nothing new to restart here.

Best,
Mat



smime.p7s
Description: Signature cryptographique S/MIME

bug#58149: guix pull error

[Matthieu Haefele]

Hi,

Le 30/09/2022 à 09:59, Ludovic Courtès a écrit :

Matthieu Haefele  skribis:


(base) mhaefele@mdlspc113:work $ 
/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version

guix-daemon (GNU Guix) 1.0.1

It’s indeed a pre-lzip version¹.

Normally, ‘guix’ commands have been printing a message reading “Your
Guix daemon is severely outdated […]”  since February 2022 when talking
to an old daemon.  Can you confirm this was the case?  (If not, we have
a bug in the deprecation machinery.)

¹ https://guix.gnu.org/en/blog/2019/gnu-guix-1.0.1-released/


I worked intensively with guix this summer, I did not get any deprecation warnings, I am quite sure. And I still do not get any. 
So might be a good idea to check the deprecation machinery.


(base) mhaefele@mdlspc113:~ $ guix shell python-numpy python coreutils
(base) mhaefele@mdlspc113:~ $ echo $GUIX_ENVIRONMENT
/gnu/store/cy8y10jfnbq5y2r16i13q04h1lii428a-profile


Updating the daemon triggers the same error wit "unsupported compression scheme 
lzip"



(base) mhaefele@mdlspc113:work $ sudo -i guix pull

I would suggest doing a two-step upgrade; first upgrade to 1.3.0:

   sudo -i guix pull --commit=a0178d34f582b50e9bdbb0403943129ae5b560ff


Are you sure this commit is old enough ? I still get the same error.
By the way, a general question, where can you see the guix time line, such that one has a chance to pick up a relevant commit id 
at certain point in time ?


(base) mhaefele@mdlspc113:~ $ sudo -i guix pull 
--commit=a0178d34f582b50e9bdbb0403943129ae5b560ff
[sudo] password for mhaefele:
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale 
(fr_FR.UTF-8)

Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Updating channel 'guix-hpc-non-free' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-hpc-non-free.git'...
Updating channel 'guix-hpc' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-hpc.git'...
Building from these channels:
guix-hpc-non-freehttps://gitlab.inria.fr/guix-hpc/guix-hpc-non-free.git 07d3681
  guix-hpc  https://gitlab.inria.fr/guix-hpc/guix-hpc.git 546dd9d
  guix  https://git.savannah.gnu.org/git/guix.git    a0178d3
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
/gnu/store/d9sr20k80q6858yjqnx8fdmnvzz6y119-module-import-compiled.drv
   /gnu/store/7gcrnsrf95r5w8skikx3gjrimgzwb4cy-module-import.drv
   /gnu/store/lybfadhfwzldw724mpsbdzakv54wwvvr-hash.scm.drv
   /gnu/store/pl48shh9vvnd8q8909ra7hznhzlcn0gj-config.scm.drv
   /gnu/store/sc6fv5hqxvk1nziq20wi427hh3cmr88n-git.scm.drv
/gnu/store/mc20h5zjsyap4hgjsj949agm5jjxz8ql-compute-guix-derivation.drv
7,5 MB will be downloaded:
   /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4
   /gnu/store/0h9x3hqqh4fx52735a7mykqm7mdkqnf4-libgc-7.6.6
   /gnu/store/4jh61hq9b4pv1bjqimafcv2w1c20cqrc-libatomic-ops-7.6.6
   /gnu/store/b7pbksdw7f1x4faimd2xmgpcipsrp9ns-libffi-3.2.1
   /gnu/store/g3az3q22hmlqwwzqjv4vqfrhcfl88a2s-libunistring-0.9.10
   /gnu/store/w967m83560ik61vqv0v8aw3b0avb0hng-libltdl-2.4.6
   /gnu/store/wsq5x6sizjq8ggyfydccv1hcsciy40wi-gmp-6.1.2
   /gnu/store/y249ycgfvg0p83hwpwf5nbn1aghjcc9n-pkg-config-0.29.2
downloading from 
https://ci.guix.gnu.org/nar/lzip/4jh61hq9b4pv1bjqimafcv2w1c20cqrc-libatomic-ops-7.6.6...
Backtrace:
   3 (apply-smob/1 #)
In ice-9/boot-9.scm:
    705:2  2 (call-with-prompt _ _ #)
In ice-9/eval.scm:
    619:8  1 (_ #(#(#)))
In guix/ui.scm:
  1747:12  0 (run-guix-command _ . _)

guix/ui.scm:1747:12: In procedure run-guix-command:
unsupported compression scheme lzip
substitution of /gnu/store/4jh61hq9b4pv1bjqimafcv2w1c20cqrc-libatomic-ops-7.6.6 
failed
killing process 9967
guix pull: error: some substitutes for the outputs of derivation `/gnu/store/16c8c8hm1qdn6xz8014939mirc7c4d4j-guile-2.2.4.drv' 
failed (usually happens due to networking issues); try `--fallback' to build derivation from source






smime.p7s
Description: Signature cryptographique S/MIME

bug#58191: gpaste-client --version dies with a sigsegv

[Attila Lendvai]

this pretty much tells it all:

$ guix shell gpaste
$ gpaste-client --version

(/gnu/store/7xj6mjvd00f83bmscn6ya1zwd0wi67gf-profile/bin/gpaste-client:27755): 
GPaste-CRITICAL **: 10:49:21.373: Error calling StartServiceByName for 
org.gnome.GPaste: Process org.gnome.GPaste received signal 11

i tried to debug it, but it happens in a new thread, and i failed to obtain a 
backtrace by simply starting it in gdb.

the actual symptom is that the gpaste shell extension crashes the gnome shell 
while logging in, and upon the next login all gnome shell extensions are 
disabled. enabling them immediately crashes the entire gnome shell.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Being true to yourself means living in truth with each person in your life. It 
means refusing to say or do something that you don’t believe is right. Living 
in truth with other people means that you refuse to stay in any situation where 
you are unhappy with the behavior of another person. You refuse to tolerate it. 
You refuse to compromise.”
— Brian Tracy (1944–)

bug#58149: guix pull error

[Ludovic Courtès]

Hi,

Matthieu Haefele  skribis:

> (base) mhaefele@mdlspc113:work $ 
> /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version
>
> guix-daemon (GNU Guix) 1.0.1

It’s indeed a pre-lzip version¹.

Normally, ‘guix’ commands have been printing a message reading “Your
Guix daemon is severely outdated […]”  since February 2022 when talking
to an old daemon.  Can you confirm this was the case?  (If not, we have
a bug in the deprecation machinery.)

¹ https://guix.gnu.org/en/blog/2019/gnu-guix-1.0.1-released/

> Updating the daemon triggers the same error wit "unsupported compression 
> scheme lzip"
>
> 
>
> (base) mhaefele@mdlspc113:work $ sudo -i guix pull

I would suggest doing a two-step upgrade; first upgrade to 1.3.0:

  sudo -i guix pull --commit=a0178d34f582b50e9bdbb0403943129ae5b560ff

and follow the instructions at
.

After that you can optionally make the same operation to update to the
last commit in ‘master’.

HTH!

Ludo’.