bug#39374: Failing channels and graph on 1.0.1.10297-c5bbcb

[Ludovic Courtès]

Hi,

zimoun  skribis:

> Well, I assume this fix had been pushed since then.

Yes, definitely.

> Therefore, I am in favor to close this report.  Any objection?

Nope, closing!

Thank you,
Ludo’.

bug#40237: Cannot build gcc-toolchain with "make-gcc-toolchain"

[zimoun]

Hi Roel,

On Tue, 18 Oct 2022 at 21:21, Roel Janssen  wrote:

>> > When building this custom gcc-toolchain, it fails with:
>> 
>> Is it still the case?  Well, could you provide more information about
>> your use case?
>> 
>
> Actually, I don't have any more information, and most probably I messed up 
> myself.
> I suppose we can just close this. If there's anything actually wrong it'll 
> pop up
> another bug report. Shall I close this bug report, or would you like to keep 
> it open?

I am in favor to close it.  As you said, if there is anything wrong, the
bug will pop again elsewhere.  So closing. :-)

Thank you for your answer.


Cheers,
simon

bug#34427: guile-bootstrap@2.2 segfault?

[zimoun]

Hi,


On Tue, 18 Oct 2022 at 16:22, Efraim Flashner  wrote:

> We've moved the bootstrap guile to 3.0 for riscv64 and haven't seen
> any problems. I think we can just close this one and we'll revisit it
> if someone else decides to use guile-2.2 for a bootstrap guile and
> runs into this issue.

Therefore, I am closing.  Feel free to reopen if I missed something.


Cheers,
simon

bug#58631: Shepherd crash on berlin

[Ludovic Courtès]

Earlier today, berlin was unreachable.  From /var/log/messages, this
appears to be due to a crash of shepherd (PID 1); here are its last
words:

--8<---cut here---start->8---
Oct 19 06:32:36 localhost shepherd[1]: Respawning mumi-worker.
Oct 19 06:32:37 localhost shepherd[1]: Service mumi-worker has been started.
Oct 19 06:32:52 localhost ntpd[1837]: Soliciting pool server 193.141.27.6
Oct 19 06:33:56 localhost ntpd[1837]: Soliciting pool server 193.158.22.13
Oct 19 06:35:02 localhost ntpd[1837]: Soliciting pool server 62.75.236.38
Oct 19 06:35:43 localhost vmunix: [1586150.310354] shepherd[87089]: segfault at 
0 ip 7ff3018dc264 sp 7ffeae066810 error 6 in 
crash-handler.so[7ff3018dc000+1000]
Oct 19 06:35:43 localhost vmunix: [1586150.322247] Code: ff ff ff e8 6e fe ff 
ff 48 8d 3d b7 0d 00 00 e8 12 fe ff ff bf 27 00 00 00 31 c0 e8 26 fe ff ff 89 
ee 48 89 c7 e8 2c fe ff ff  04 25 00 00 00 00 00 00 00 00 0f 0b 48 89 c3 be 
01 00 00 00 89
Oct 19 06:36:09 localhost ntpd[1837]: Soliciting pool server 51.75.67.47
Oct 19 06:36:40 localhost postgres[1389]: [73-1] 2022-10-19 04:36:40.036 GMT 
[1389] LOG:  using stale statistics instead of current ones because stats 
collector is not responding
Oct 19 06:36:50 localhost postgres[87362]: [6-1] 2022-10-19 04:36:50.101 GMT 
[87362] LOG:  using stale statistics instead of current ones because stats 
collector is not responding
Oct 19 06:37:00 localhost postgres[1389]: [74-1] 2022-10-19 04:37:00.062 GMT 
[1389] LOG:  using stale statistics instead of current ones because stats 
collector is not responding
Oct 19 06:37:10 localhost postgres[87368]: [6-1] 2022-10-19 04:37:10.128 GMT 
[87368] LOG:  using stale statistics instead of current ones because stats 
collector is not responding
Oct 19 06:37:16 localhost ntpd[1837]: Soliciting pool server 3.64.117.201
Oct 19 12:48:58 localhost syslogd (GNU inetutils 2.0): restart
--8<---cut here---end--->8---

The interesting part is that we have a core dump—see ‘crash-handler.so’
above, which is shepherd’s mechanism to ensure there’s a core dump
before the machine stops.  Here’s what we get:

--8<---cut here---start->8---
ludo@berlin ~$ gdb -ix ~/.gdbinit 
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/bin/guile 
/core.shepherd-20221019
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/bin/guile...
Reading symbols from 
/gnu/store/4ws3vh3zrs1yi9lfaibha64chf3vn2rm-guile-3.0.7-debug/lib/debug//gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/bin/guile.debug...

warning: core file may not match specified executable file.
[New LWP 87089]

warning: Unable to find libthread_db matching inferior's thread library, thread 
debugging will not be available.
Core was generated by 
`/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/bin/guile 
--no-auto-com'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7ff3018dc264 in ?? ()
   from 
/gnu/store/cdc1gzbp3q15kdiwn2i5j3437jwx61ac-shepherd-0.9.2/lib/shepherd/crash-handler.so
(gdb) bt
#0  0x7ff3018dc264 in ?? ()
   from 
/gnu/store/cdc1gzbp3q15kdiwn2i5j3437jwx61ac-shepherd-0.9.2/lib/shepherd/crash-handler.so
#1  
#2  0x7ff3018dc264 in ?? ()
   from 
/gnu/store/cdc1gzbp3q15kdiwn2i5j3437jwx61ac-shepherd-0.9.2/lib/shepherd/crash-handler.so
#3  
#4  0x7ff30b2d2030 in raise ()
   from /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6
#5  0x7ff30b2bc526 in abort ()
   from /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6
#6  0x7ff30b7bb263 in ?? () from 
/gnu/store/2lczkxbdbzh4gk7wh91bzrqrk7h5g1dl-libgc-8.0.4/lib/libgc.so.1
#7  0x7ff30b7c2232 in ?? () from 
/gnu/store/2lczkxbdbzh4gk7wh91bzrqrk7h5g1dl-libgc-8.0.4/lib/libgc.so.1
#8  0x7ff30b7c25a8 in ?? () from 
/gnu/store/2lczkxbdbzh4gk7wh91bzrqrk7h5g1dl-libgc-8.0.4/lib/libgc.so.1
#9  0x7ff30b7c290f in ?? () from 
/gnu/store/2lczkxbdbzh4gk7wh91bzrqrk7h5g1dl-libgc-8.0.4/lib/libgc.so.1
#10 0x7ff30b7c78da in GC_generic_malloc_many ()
   from /gnu/store/2lczkxbdbzh4gk7wh91bz

bug#58622: Bug

[Nicolas Vallet]

Hi,
I just ran guix pull. I don't know where to start with this bug. Would you
have any clues ?
Best,
Nicolas

- cut here --
/guix substitute: erreur : connect*?: Aucun chemin d'acc?s pour atteindre
l'h?te cible
/la substitution de
/gnu/store/g0ha1fd0x299w48hfgs2sa1sl1b6vlnq-datefudge_1.23.tar.xz a échoué
Backtrace:
  14 (primitive-load
"/gnu/store/f1g2q1mzsh6mgdshzwiipx2l4y3qj0lf-compute-guix-derivation")
In ice-9/eval.scm:
155:9 13 (_ _)
159:9 12 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?)
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 11 (with-fluid* _ _ _)
152:2 10 (with-fluid* _ _ _)
In ./guix/store.scm:
  2165:24  9 (run-with-store #
# ?)
   1993:8  8 (_ #)
In ./guix/gexp.scm:
   300:22  7 (_ #)
   1181:2  6 (_ #)
   1047:2  5 (_ #)
893:4  4 (_ #)
In ./guix/store.scm:
  2050:12  3 (_ #)
   1398:5  2 (map/accumulate-builds #
# ?)
  1414:15  1 (_ #
("/gnu/store/7df196dbwb4w03q8wnvfys0j5npnqbcd-git-minima?" ?) ?)
  1414:15  0 (loop #f)

./guix/store.scm:1414:15: In procedure loop:
ERROR:
  1. &store-protocol-error:
  message: "some substitutes for the outputs of derivation
`/gnu/store/pzznh5migzi2fnxshqw771ivg54zz5a7-datefudge_1.23.tar.xz.drv'
failed (usually happens due to networking issues); try `--fallback' to
build derivation from source "
  status: 1
guix pull: erreur : You found a bug: the program
'/gnu/store/f1g2q1mzsh6mgdshzwiipx2l4y3qj0lf-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"3bb145b6e2a8c84e7739ead9ae76dc4d42bb9850"; system: "x86_64-linux";
host version: "45eac6cdf5c8d9d7b0c564b105c790d2d2007799"; pull-version: 1).
Please report the COMPLETE output above by email to .
- cut here --

bug#57965: Problem with freecad substitute

[zimoun]

Hi,

On Wed, 21 Sep 2022 at 08:25, Christopher Baines  wrote:

>> I want to install freecad, substitute available but the package starts
>> building locally.
>
> This is probably due to you ACL, see
> https://guix.gnu.org/en/manual/devel/en/html_node/Substitute-Server-Authorization.html#Substitute-Server-Authorization

Do we promote Bordeaux to be in the list of authorized substitute
servers?  If it is not already the case. :-)

Otherwise, I am in favour to close this report.  WDYT?


Cheers,
simon

bug#58309: [BUG Report] found a bug?

[zimoun]

Hi,

On Fri, 07 Oct 2022 at 07:40, Frank Pursel  wrote:

> Running guix pull succeeded.  It isn't clear what changed to allow it to
> succeed when it had repeatedly failed over the past 48 hrs but this
> ticket should now be closed.  I am grateful for the hidden hands and/or
> magic that made this possible.

Thank you for your follow-up.

Hum, your both errors are weird.  The first one,

--8<---cut here---start->8---
 gnutls-3.7.2-doc  1.0MiB 659KiB/s 00:01 [###   ]  84.1-Backtrace:
  18 (primitive-load 
"/gnu/store/8b0z5hm1kxha84g367yfshxjf1q4kka2-compute-guix-derivation")
In ice-9/eval.scm:

[...]

In ./guix/serialization.scm:
   102:11  1 (read-int #)
 80:6  0 (get-bytevector-n* # 8)

./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
--8<---cut here---end--->8---

and the second one,

--8<---cut here---start->8---
guile-ssh-0.15.1-debug  238KiB 227.0MiB/s 00:00 [##] 100.0%
Backtrace::
  15 (primitive-load 
"/gnu/store/k76q0ikk8a7769b0d2b9y3jj2mpaywh0-compute-guix-derivation")

[...]

In ./guix/store.scm:
  2050:12  4 (_ #)
  1402:13  3 (map/accumulate-builds # 
# ?)
   1398:5  2 (map/accumulate-builds # 
# ?)
  1414:15  1 (_ # 
("/gnu/store/063db2n6gr2pqvy77fxp82p0ki6vwklz-guile-avah?" ?) ?)
  1414:15  0 (loop #f)

./guix/store.scm:1414:15: In procedure loop:
--8<---cut here---end--->8---

Do you have issues with your store?  Maybe faulty?


Cheers,
simon

PS: Note you can close yourself the issue by replying to
58309-d...@debbugs.gnu.org. :-)

bug#58247: Using guix time-machine results in unsupported manifest format error

[zimoun]

Hi,

This issue is about the upgrade of manifest version from 3 to 4.  For
references,



On Mon, 03 Oct 2022 at 00:10, zimoun  wrote:

> Well, I do not know if a fix is possible.  The issue is a
> backward compatibility issue.

Ludo, what is your insight on that matter?  Is it fixable?  Or do we
mark the issue as ’wontfix’?


Cheers,
simon

bug#58622: guix pull error when substitutes unreachable

[zimoun]

Hi Nicolas,

On Wed, 19 Oct 2022 at 10:46, Nicolas Vallet  wrote:

> I just ran guix pull. I don't know where to start with this bug. Would you
> have any clues ?

I guess it is because an issue with Berlin being offline for a couple of
hours this morning.

Hum, the host commit 45eac6cdf5c8d9d7b0c564b105c790d2d2007799 should
have some fixes; as tested by 08023bcab35faafcf3e9c77babe910d9ece240d2.

Otherwise, it recommend to allow the other build farm named
bordeaux.guix.gnu.org, see [1] for the instructions.

1: 


Cheers,
simon

bug#58622: guix pull error when substitutes unreachable

[Nicolas Vallet]

Hi Simon,
A new pull worked perfectly! Many thanks.
Best,
Nicolas

Le mer. 19 oct. 2022 à 17:27, zimoun  a écrit :

> Hi Nicolas,
>
> On Wed, 19 Oct 2022 at 10:46, Nicolas Vallet  wrote:
>
> > I just ran guix pull. I don't know where to start with this bug. Would
> you
> > have any clues ?
>
> I guess it is because an issue with Berlin being offline for a couple of
> hours this morning.
>
> Hum, the host commit 45eac6cdf5c8d9d7b0c564b105c790d2d2007799 should
> have some fixes; as tested by 08023bcab35faafcf3e9c77babe910d9ece240d2.
>
> Otherwise, it recommend to allow the other build farm named
> bordeaux.guix.gnu.org, see [1] for the instructions.
>
> 1: <
> https://guix.gnu.org/manual/devel/en/guix.html#Substitute-Server-Authorization
> >
>
> Cheers,
> simon
>
>
>
>

bug#57844: Shepherd fails to start in user session ~50% of the time

[Ludovic Courtès]

Hi,

Andrew, does the bug report below ring a bell?

  https://issues.guix.gnu.org/57844

(I haven’t hit that problem myself.)

Ludo’.

Tom Willemse  skribis:

> Hi Guix!
>
> I've been using Guix on Archlinux for a little while now, and ever since
> I've started using Guix Home on my laptop to start up user-level
> services I've been having the issue that about 50% of the time when I
> boot my laptop shepherd fails to start. 
>
> My .xsession-errors says:
>
>> shepherd: while opening socket '/run/user/1000/shepherd/socket': bind:
>> Address already in use
>
> and looking at my shepherd log:
>
>> 2022-09-15 11:47:18 Service root has been started.
>> 2022-09-15 11:47:18 Service root has been started.
>> 2022-09-15 11:47:19 Starting services...
>> 2022-09-15 11:47:19 Starting services...
>> 2022-09-15 11:47:19 Exiting shepherd...
>> 2022-09-15 11:47:19 Service dunst has been started.
>> 2022-09-15 11:47:19 Service unclutter has been started.
>> 2022-09-15 11:47:19 Service syncthing has been started.
>> 2022-09-15 11:47:19 Service polybar has been started.
>> 2022-09-15 11:47:19 Service cmst has been started.
>> 2022-09-15 11:47:19 Service kdeconnect has been started.
>> 2022-09-15 11:47:20 Service xbindkeys has been started.
>> 2022-09-15 11:47:20 Service picom has been started.
>> 2022-09-15 11:47:20 Service xmodmap has been started.
>> 2022-09-15 11:47:20 Service redshift has been started.
>> 2022-09-15 11:47:20 Exiting shepherd...
>> 2022-09-15 11:47:20 Service syncthing has been stopped.
>> 2022-09-15 11:47:20 Service xbindkeys has been stopped.
>> 2022-09-15 11:47:20 Service redshift has been stopped.
>> 2022-09-15 11:47:20 Service cmst has been stopped.
>> 2022-09-15 11:47:20 Service kdeconnect has been stopped.
>> 2022-09-15 11:47:20 Service polybar has been stopped.
>> 2022-09-15 11:47:20 Service dunst has been stopped.
>> 2022-09-15 11:47:20 Service picom has been stopped.
>> 2022-09-15 11:47:20 Service unclutter has been stopped.
>> 2022-09-15 11:47:20 Exiting.
>
> It looks like it starts twice and then exits both, but I'm not sure why.
> I'm guessing it's the ~/.guix-home/activate and
> ~/.guix-home/on-first-login that are trying to start it.
>
> I'm not sure what other information I can provide you that will help, so
> please let me know!
>
>
> Cheers,
>
> Tom

bug#58631: Shepherd crash on berlin

[Ludovic Courtès]

Same backtrace with debugging symbols for libgc and libc:

--8<---cut here---start->8---
(gdb) bt
#0  0x7ff3018dc264 in ?? ()
   from 
/gnu/store/cdc1gzbp3q15kdiwn2i5j3437jwx61ac-shepherd-0.9.2/lib/shepherd/crash-handler.so
#1  
#2  0x7ff3018dc264 in ?? ()
   from 
/gnu/store/cdc1gzbp3q15kdiwn2i5j3437jwx61ac-shepherd-0.9.2/lib/shepherd/crash-handler.so
#3  
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#5  0x7ff30b2bc526 in __GI_abort () at abort.c:79
#6  0x7ff30b7bb263 in GC_add_to_heap (bytes=, 
p=0x7fefd1f7) at extra/../alloc.c:1232
#7  GC_expand_hp_inner (n=n@entry=2048) at extra/../alloc.c:1386
#8  0x7ff30b7c2232 in GC_collect_or_expand 
(needed_blocks=needed_blocks@entry=1, 
ignore_off_page=ignore_off_page@entry=0, retry=retry@entry=0) at 
extra/../alloc.c:1480
#9  0x7ff30b7c25a8 in GC_allocobj (gran=gran@entry=7, kind=) 
at extra/../alloc.c:1543
#10 0x7ff30b7c290f in GC_generic_malloc_inner (lb=lb@entry=112, 
k=k@entry=1) at extra/../malloc.c:191
#11 0x7ff30b7c78da in GC_generic_malloc_many (lb=lb@entry=112, k=k@entry=1, 
result=result@entry=0x7ff30b246e48) at extra/../mallocx.c:473
#12 0x7ff30b87fb45 in scm_inline_gc_alloc (kind=SCM_INLINE_GC_KIND_NORMAL, 
idx=6, 
freelist=0x7ff30b246e48) at gc-inline.h:79
#13 allocate_words_with_freelist (thread=0x7ff30b246d80, freelist_idx=6) at 
intrinsics.c:470
#14 0x7ff300039f95 in ?? ()
#15 0x7ff30b246d80 in ?? ()
#16 0x7ff302a2f7e8 in ?? ()
#17 0x0040 in ?? ()
#18 0x7ff30b88bb1c in scm_jit_enter_mcode 
(thread=thread@entry=0x7ff30b246d80, 
mcode=0x7ff30231e75c "B", , 
mcode@entry=0x7ff302a2f7e8 "I\211\314I)\304I\203\374 \017\205\345\b") at 
jit.c:6038
#19 0x7ff30b8e80c5 in scm_call_n (proc=, 
argv=argv@entry=0x7ffeae067878, 
nargs=nargs@entry=1) at vm.c:1602
#20 0x7ff30b862ea7 in scm_primitive_eval (exp=) at eval.c:671
#21 0x7ff30b88d729 in scm_primitive_load (filename=) at 
load.c:131
#22 0x7ff30b8e5915 in vm_regular_engine (thread=0x7ff30b246d80) at 
vm-engine.c:972
#23 0x7ff30b8e8029 in scm_call_n (proc=, 
argv=argv@entry=0x7ffeae067a58, 
nargs=nargs@entry=1) at vm.c:1608
#24 0x7ff30b862ea7 in scm_primitive_eval (exp=, 
exp@entry=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) 
load/lang) 
"/gnu/store/cdc1gzbp3q15kdiwn2i5j3437jwx61ac-shepherd-0.9.2/bin/shepherd") 
(quit at eval.c:671
--8<---cut here---end--->8---

This means we’re hitting this ‘abort’ call:

--8<---cut here---start->8---
GC_INNER void GC_add_to_heap(struct hblk *p, size_t bytes)
{
hdr * phdr;
word endp;

if (GC_n_heap_sects >= MAX_HEAP_SECTS) {
ABORT("Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS");
}
--8<---cut here---end--->8---

Indeed, the core dump weighs 13 GiB, so it looks like a memory leak (too
bad ‘info proc stat’ in GDB doesn’t work).

I have not observed it on any other machine.  The difference between
berlin and machines I have access to is that berlin is being hammered on
port 22, which means it gets to spawn sshd processes very often.  This
could be where the leak is.

Ludo’.

bug#58309: [BUG Report] found a bug?

[Maxime Devos]

On 05-10-2022 18:45, Frank Pursel wrote:

Dutifully reporting the output from today's 'guix pull':

  gnutls-3.7.2-doc  1.0MiB 659KiB/s 00:01 [###   ]  84.1-Backtrace:
   18 (primitive-load 
"/gnu/store/8b0z5hm1kxha84g367yfshxjf1q4kka2-compute-guix-derivation")
In ice-9/eval.scm:
 155:9 17 (_ _)
 159:9 16 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
 152:2 15 (with-fluid* _ _ _)
 152:2 14 (with-fluid* _ _ _)
In ./guix/store.scm:
   2165:24 13 (run-with-store # # ?)
1993:8 12 (_ #)
In ./guix/gexp.scm:
300:22 11 (_ #)
1181:2 10 (_ #)
1047:2  9 (_ #)
 893:4  8 (_ #)
In ./guix/store.scm:
   2050:12  7 (_ #)
   1402:13  6 (map/accumulate-builds # 
# ?)
1398:5  5 (map/accumulate-builds # 
# ?)
   1414:15  4 (_ # 
("/gnu/store/b59p3465k0gfhl2zirjsx1n0sh7pnm08-guile-ssh-?" ?) ?)
   1414:15  3 (loop #f)
708:11  2 (process-stderr # _)
In ./guix/serialization.scm:
102:11  1 (read-int #)
  80:6  0 (get-bytevector-n* # 8)


This one looks like a duplicate of , 
, 
, 
, maybe 
,  
(*),  and 
.


(*) I think this reports looks quite interesting, as it seems to mention 
having something to do with a HTTP error.


Greetings,
Maixme.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58309: [BUG Report] found a bug? followup

[Maxime Devos]

On 05-10-2022 19:58, Frank Pursel wrote:

Performed another 'guix pull' to receive one more change which led to
the additional reporting:

guile-ssh-0.15.1-debug  238KiB 227.0MiB/s 00:00 [##] 100.0%
Backtrace::
   15 (primitive-load 
"/gnu/store/k76q0ikk8a7769b0d2b9y3jj2mpaywh0-compute-guix-derivation")
In ice-9/eval.scm:
 155:9 14 (_ _)
 159:9 13 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
 152:2 12 (with-fluid* _ _ _)
 152:2 11 (with-fluid* _ _ _)
In ./guix/store.scm:
   2165:24 10 (run-with-store # # ?)
1993:8  9 (_ #)
In ./guix/gexp.scm:
300:22  8 (_ #)
1181:2  7 (_ #)
1047:2  6 (_ #)
 893:4  5 (_ #)
In ./guix/store.scm:
   2050:12  4 (_ #)
   1402:13  3 (map/accumulate-builds # 
# ?)
1398:5  2 (map/accumulate-builds # 
# ?)
   1414:15  1 (_ # 
("/gnu/store/063db2n6gr2pqvy77fxp82p0ki6vwklz-guile-avah?" ?) ?)
   1414:15  0 (loop #f)



Looks like a duplicate of the second part of 
, 
 (*), 
,  
and .


(*) I think this one is interesting, as it seems to indicate that build 
errors of packages aren't handled during "guix pull" -- there is a patch 
available for that, though not applied yet IIRC.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58586:

[Sharlatan Hellseher]

Hi,

I've sent patches in separate thread which fix this this issue:

https://issues.guix.gnu.org/58645

Regards,
Oleg

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#58650: build of /gnu/store/mw6ax0gk33gh082anrdrxp2flrbskxv6-openssl-1.1.1n.drv failed

[Sjors Provoost]

Sorry if this is a duplicate or has already been fixed in a more recent commit.

/builder for `/gnu/store/mw6ax0gk33gh082anrdrxp2flrbskxv6-openssl-1.1.1n.drv' 
failed with exit code 1
build of /gnu/store/mw6ax0gk33gh082anrdrxp2flrbskxv6-openssl-1.1.1n.drv failed
View build log at 
'/var/log/guix/drvs/mw/6ax0gk33gh082anrdrxp2flrbskxv6-openssl-1.1.1n.drv.gz'.
cannot build derivation 
`/gnu/store/236k6ncjl0nf7bqv4j0hni8i4yib3la4-git-minimal-2.36.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/gd577lh9007s0687m56fn65n8hrsjiqf-mallard-ducktype-1.0.2-checkout.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/rvj5bx06w2kjlxm3fg5p88dkxb6n8v9p-openjpeg-data-2020.11.30-checkout.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/00p96drllzndfp7zr63y26n1d64bdjwl-mallard-ducktype-1.0.2.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/kz4g88f4jv0w75qibq74q5lmpkgpl894-openjpeg-data-2020.11.30.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/izf75k3gvz0x6399qiks1drps445ykpg-openjpeg-2.4.0.drv': 1 
dependencies couldn't be built
Backtrace:
  14 (primitive-load 
"/gnu/store/wkw084zcvkyj53acs1gkchnvp0m7bvbl-compute-guix-derivation")
In ice-9/eval.scm:
155:9 13 (_ _)
159:9 12 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 11 (with-fluid* _ _ _)
152:2 10 (with-fluid* _ _ _)
In ./guix/store.scm:
  2129:24  9 (run-with-store # 
# ?)
   1966:8  8 (_ #)
In ./guix/gexp.scm:
   300:22  7 (_ #)
   1181:2  6 (_ #)
   1047:2  5 (_ #)
893:4  4 (_ #)
In ./guix/store.scm:
  2014:12  3 (_ #)
   1406:5  2 (map/accumulate-builds # 
# ?)
  1421:15  1 (_ # 
("/gnu/store/gcvv1i5shqmkd6x1pjwjdrvr7z4lb5ss-guile-ssh-?" ?) ?)
  1421:15  0 (loop #f)

./guix/store.scm:1421:15: In procedure loop:
ERROR:
  1. &store-protocol-error:
  message: "build of 
`/gnu/store/gwqx9mq7ll5ic97zvz22j9irlx2922wx-graphviz-2.49.0.drv' failed"
  status: 100
guix pull: error: You found a bug: the program 
'/gnu/store/wkw084zcvkyj53acs1gkchnvp0m7bvbl-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"998eda3067c7d21e0d9bb3310d2f5a14b8f1c681"; system: "x86_64-linux";
host version: "1.3.0.18313-998eda"; pull-version: 1).

- Sjors


6ax0gk33gh082anrdrxp2flrbskxv6-openssl-1.1.1n.drv.gz
Description: GNU Zip compressed data

bug#57844: Shepherd fails to start in user session ~50% of the time

[Andrew Tropin]

On 2022-10-19 18:21, Ludovic Courtès wrote:

> Hi,
>
> Andrew, does the bug report below ring a bell?
>

Yes, I don't remember if I created a thread on that (probably not) or
just discussed it in some chat, but when shepherd stops it doesn't clean
up its socket file, so you can't start shepherd again until manually
remove socket.

Checked it right now:
--8<---cut here---start->8---
herd stop root
shepherd # fails with Address already in use
--8<---cut here---end--->8---

I found it out, when was experimenting with the place, where I start
shepherd https://issues.guix.gnu.org/57692.  To inherit graphical
environment variables I start it by sway compositor, not login shell and
if in addition to sway session I login on another tty, elogind won't
remove XDG_RUNTIME_DIR => shepherd/socket is not removed => shepherd
fails to start after sway restart.

>   https://issues.guix.gnu.org/57844
>
> (I haven’t hit that problem myself.)
>
> Ludo’.
>
> Tom Willemse  skribis:
>
>> Hi Guix!
>>
>> I've been using Guix on Archlinux for a little while now, and ever since
>> I've started using Guix Home on my laptop to start up user-level
>> services I've been having the issue that about 50% of the time when I
>> boot my laptop shepherd fails to start. 
>>
>> My .xsession-errors says:
>>
>>> shepherd: while opening socket '/run/user/1000/shepherd/socket': bind:
>>> Address already in use
>>
>> and looking at my shepherd log:
>>
>>> 2022-09-15 11:47:18 Service root has been started.
>>> 2022-09-15 11:47:18 Service root has been started.
>>> 2022-09-15 11:47:19 Starting services...
>>> 2022-09-15 11:47:19 Starting services...
>>> 2022-09-15 11:47:19 Exiting shepherd...
>>> 2022-09-15 11:47:19 Service dunst has been started.
>>> 2022-09-15 11:47:19 Service unclutter has been started.
>>> 2022-09-15 11:47:19 Service syncthing has been started.
>>> 2022-09-15 11:47:19 Service polybar has been started.
>>> 2022-09-15 11:47:19 Service cmst has been started.
>>> 2022-09-15 11:47:19 Service kdeconnect has been started.
>>> 2022-09-15 11:47:20 Service xbindkeys has been started.
>>> 2022-09-15 11:47:20 Service picom has been started.
>>> 2022-09-15 11:47:20 Service xmodmap has been started.
>>> 2022-09-15 11:47:20 Service redshift has been started.
>>> 2022-09-15 11:47:20 Exiting shepherd...
>>> 2022-09-15 11:47:20 Service syncthing has been stopped.
>>> 2022-09-15 11:47:20 Service xbindkeys has been stopped.
>>> 2022-09-15 11:47:20 Service redshift has been stopped.
>>> 2022-09-15 11:47:20 Service cmst has been stopped.
>>> 2022-09-15 11:47:20 Service kdeconnect has been stopped.
>>> 2022-09-15 11:47:20 Service polybar has been stopped.
>>> 2022-09-15 11:47:20 Service dunst has been stopped.
>>> 2022-09-15 11:47:20 Service picom has been stopped.
>>> 2022-09-15 11:47:20 Service unclutter has been stopped.
>>> 2022-09-15 11:47:20 Exiting.
>>
>> It looks like it starts twice and then exits both, but I'm not sure why.
>> I'm guessing it's the ~/.guix-home/activate and
>> ~/.guix-home/on-first-login that are trying to start it.

~/.guix-home/activate should be launched only by guix home reconfigure,
so it shouldn't be touched during startup of the session at all, also
they both have a condition, which must prevent the start of shepherd if
socket exists.

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=883fb8f41b08a8455f16c736a83fb1ae8a3df0a1#n105
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=883fb8f41b08a8455f16c736a83fb1ae8a3df0a1#n131

Tom, can you show your startup scripts, please (like xsession or
whatever you use for starting graphical environment)?  Sharing home
environment config can be useful as well.  Do you use some display/login
manager?

>>
>> I'm not sure what other information I can provide you that will help, so
>> please let me know!
>>


-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature