bug#68231: Frei?

[Christian Miller via Bug reports for GNU Guix]

Hallo,

dafür gibt es den nonguix[0] Guix channel.

Ansonsten findest du Hilfe in IRC.  Es gibt im Libera.Chat[1] Netzwerk
den offizielen Guix IRC Kanal in #guix.  Der ist ganz praktisch für
jegliche (außer proprietäre) Fragen.

Außerdem gibt es auf dem gleichem Netzwerk einen #nonguix Kanal.  Der
ist für alles non-libre.  Dieser ist ganz klar inoffiziel.

Falls du keinen IRC Client hast, kannst du die Web[1] Variante von
Libera.Chat verwenden.  Einfach #guix oder #nonguix als Kanalname
eingeben.

Hoffe ich konnte dir somit weiterhelfen.  Du kannst mir auch direkt
per E-Mail Antworten, da nonguix inoffiziel ist.  Würde aber
vermutlich ein paar Tage benötigen für eine Antwort.

[0] https://gitlab.com/nonguix/nonguix
[1] https://libera.chat/
[2] https://web.libera.chat/
-- 
Christian Miller

bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur

[Collin J. Doering]

After updating cuirass (details below), my cuirass instance no longer builds 
anything! It continues to poll channels, run evaluations and queue builds, but 
none of the builds ever run.

--8<---cut here---start->8---
Before: Cuirass 1.1.0-13.1341725 (guix checkout 
c4cca9cb5d3e93ef146acb930a95da9d2da6fb06)
After:  Cuirass 1.2.0-1.bdc1f9f (guix checkout 
25b83bd9e4ceb77f08c0caee3ecdc48263b53a46)
--8<---cut here---end--->8---

After a bit of investigation, I noticed numerous instances of this in the logs 
following the update:

--8<---cut here---start->8---
/var/log/guix-daemon.log-2024-01-03 10:08:22 SIGPOLL
/var/log/guix-daemon.log:2024-01-03 10:08:22 unexpected build daemon error: 
interrupted by the user
--8<---cut here---end--->8---

It may be worth noting that I am running cuirass with substitutes on.

Any help appreciated.

-- 
Collin J. Doering

http://rekahsoft.ca
http://blog.rekahsoft.ca
http://git.rekahsoft.ca


signature.asc
Description: PGP signature

bug#64653: ‘static-networking’ fails to start

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

> [  121.282538] shepherd[1]: Service user-homes started.
> [  121.368316] ipmi_si IPI0001:00: Using irq 10
> [  121.405790] ipmi_si IPI0001:00: IPMI message handler: Found new BMC 
> (man_id: 0x0002a2, prod_id: 0x0100, dev_id: 0x20)
> [  121.419871] shepherd[1]: Exception caught while starting #< 
> 7f19889012a0>: (wrong-type-arg "port-filename" "Wrong type argument in 
> position ~A: ~S" (1 #) (# 7f1981887000>))
> [  121.420074] shepherd[1]: Service user-homes running with value #t.
> [  121.420218] shepherd[1]: Service networking failed to start.

I’m seeing a similar exception in a Hurd VM running shepherd 0.10.3rc1:

--8<---cut here---start->8---
Jan  3 23:13:22 localhost shepherd[1]: Exception caught while starting 
networking: (wrong-type-arg "port-filename" "Wrong type argument in position 
~A: ~S" (1 #) (#)) 
Jan  3 23:13:22 localhost shepherd[1]: Service networking failed to start. 
--8<---cut here---end--->8---

It’s interesting because it suggests that the offending ‘port-filename’
call comes from ‘load’, not from the network-setup code being loaded
(here, the /hurd/pfinet translator has been properly set up).

Looking at the code in ‘boot-9.scm’, I *think* we end up calling
‘primitive-load’; ‘shepherd’ replaces it with its own (@ (shepherd
support) primitive-load*).

I managed to grab this backtrace:

--8<---cut here---start->8---
Evaluating user expression (catch #t (lambda () (load "/gnu/store/64?")) # ?).
starting 
'/gnu/store/gn8q7p790a9zdnlciyp1vlncpin366r0-hurd-v0.9.git20230216/hurd/pfinet 
"--ipv6" "/servers/socket/26" "--interface" "/dev/eth0" "--address" "10.0.2.15" 
"--netmask" "255.255.255.0" "--gateway" "10.0.2.2"'
In ice-9/boot-9.scm:
142:2  7 (dynamic-wind # ?)
In shepherd/support.scm:
   486:15  6 (_ #)
In ice-9/read.scm:
   859:19  5 (read _)
In unknown file:
   4 (port-filename #)
In ice-9/boot-9.scm:
  1685:16  3 (raise-exception _ #:continuable? _)
  1780:13  2 (_ #< components: (#)
In ice-9/eval.scm:
159:9  1 (_ #(#(#) (# "port-fil?" ?)))
In unknown file:
   0 (make-stack #t)
#t
--8<---cut here---end--->8---

So it’s indeed ‘read’ as called from ‘primitive-load*’ that stumbles
upon a closed port.  It also happens when loading a file that simply
suspends the current fiber via ‘sleep’ or similar, but only on the Hurd
though.

To be continued…

Ludo’.

bug#48018: reviewed, checked and re-based the previous commit

[Maxim Cournoyer]

Hi,

"Wicki Gabriel (wicg)"  writes:

> I've checked the patch above which works like a charm.  I've created a
> new patch.  Please credit the original author before merging.

I've applied it on core-updates, as imagemagick causes a large number of
rebuilds.

-- 
Thanks,
Maxim

bug#68224: emacs-jsonrpc source no longer exists

[Nicolas Goaziou via Bug reports for GNU Guix]

Hello,

Maxim Cournoyer  writes:

> Hi,
>
> cuir...@gnu.org (Cuirass) writes:
>
>> The build emacs-jsonrpc.i686-linux for specification master 
>> is broken. You can find the detailed information about this build > href="https://ci.guix.gnu.org/build/3152892/details;>here.
>>
>> https://ci.guix.gnu.org/build/3152892/details
>
> I've tried the above build twice, and both times it failed to retrieve
> its source:

Trying to build it a couple times more made it succeed.

If problem reappears, I will advocate for setting the package back to
using ELPA source, despite .

Closing for now.

Regards,
-- 
Nicolas Goaziou

bug#68229: go.powerpc64le-linux 1.14.15 fails test suite

[Maxim Cournoyer]

Hello,

Efraim Flashner  writes:

> On Wed, Jan 03, 2024 at 11:29:50AM -0500, Maxim Cournoyer wrote:
>> Hello,
>> 
>> cuir...@gnu.org (Cuirass) writes:
>> 
>> > The build go.powerpc64le-linux for specification
>> > master is broken. You can find the detailed information
>> > about this build > > href="https://ci.guix.gnu.org/build/3139760/details;>here.
>> >
>> > https://ci.guix.gnu.org/build/3139760/details
>> 
>> The test failure is:
>> 
>> --8<---cut here---start->8---
>> --- FAIL: TestScript (0.00s)
>> --- FAIL: TestScript/vendor_complex (2.07s)
>> script_test.go:193: 
>> # smoke test for complex build configuration (1.990s)
>> > go build -o complex.exe complex
>> > [exec:gccgo] go build -compiler=gccgo -o complex.exe complex
>> [stderr]
>> # complex
>> gccgo: error: unrecognized command-line option
>> '-rpath=/gnu/store/qj6cnccz6vsffqa32rviw4zaqgh7xd6q-gcc-11.3.0-lib/lib'
>> [exit status 2]
>> FAIL: testdata/script/vendor_complex.txt:5: unexpected command 
>> failure
>> 
>> FAIL
>> FAIL cmd/go  46.068s
>> --8<---cut here---end--->8---
>> 
>> I don't see an obvious relationship with the recent commit touching
>> gccgo-12, but I'm CC'ing its author in case it could be.
>
> This one is go-1.14. That one already failed for ppc64le.

OK; Cuirass got it wrong again.  Should we leave the ticket open though,
since it's an actual problem?

-- 
Thanks,
Maxim

bug#68229: go.powerpc64le-linux 1.14.15 fails test suite

[Efraim Flashner]

On Wed, Jan 03, 2024 at 11:29:50AM -0500, Maxim Cournoyer wrote:
> Hello,
> 
> cuir...@gnu.org (Cuirass) writes:
> 
> > The build go.powerpc64le-linux for specification master is 
> > broken. You can find the detailed information about this build  > href="https://ci.guix.gnu.org/build/3139760/details;>here.
> >
> > https://ci.guix.gnu.org/build/3139760/details
> 
> The test failure is:
> 
> --8<---cut here---start->8---
> --- FAIL: TestScript (0.00s)
> --- FAIL: TestScript/vendor_complex (2.07s)
> script_test.go:193: 
> # smoke test for complex build configuration (1.990s)
> > go build -o complex.exe complex
> > [exec:gccgo] go build -compiler=gccgo -o complex.exe complex
> [stderr]
> # complex
> gccgo: error: unrecognized command-line option 
> '-rpath=/gnu/store/qj6cnccz6vsffqa32rviw4zaqgh7xd6q-gcc-11.3.0-lib/lib'
> [exit status 2]
> FAIL: testdata/script/vendor_complex.txt:5: unexpected command 
> failure
> 
> FAIL
> FAIL  cmd/go  46.068s
> --8<---cut here---end--->8---
> 
> I don't see an obvious relationship with the recent commit touching
> gccgo-12, but I'm CC'ing its author in case it could be.

This one is go-1.14. That one already failed for ppc64le.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#68209: python-mysql-connector-python.i686-linux 8.0.33 test failures

[Maxim Cournoyer]

Hello,

This problem also affects powerpc64le:
https://ci.guix.gnu.org/build/3140804.

Retitling accordingly.

-- 
Thanks,
Maxim

bug#68229: go.powerpc64le-linux 1.14.15 fails test suite

[Maxim Cournoyer]

Hello,

cuir...@gnu.org (Cuirass) writes:

> The build go.powerpc64le-linux for specification master is 
> broken. You can find the detailed information about this build  href="https://ci.guix.gnu.org/build/3139760/details;>here.
>
> https://ci.guix.gnu.org/build/3139760/details

The test failure is:

--8<---cut here---start->8---
--- FAIL: TestScript (0.00s)
--- FAIL: TestScript/vendor_complex (2.07s)
script_test.go:193: 
# smoke test for complex build configuration (1.990s)
> go build -o complex.exe complex
> [exec:gccgo] go build -compiler=gccgo -o complex.exe complex
[stderr]
# complex
gccgo: error: unrecognized command-line option 
'-rpath=/gnu/store/qj6cnccz6vsffqa32rviw4zaqgh7xd6q-gcc-11.3.0-lib/lib'
[exit status 2]
FAIL: testdata/script/vendor_complex.txt:5: unexpected command 
failure

FAIL
FAILcmd/go  46.068s
--8<---cut here---end--->8---

I don't see an obvious relationship with the recent commit touching
gccgo-12, but I'm CC'ing its author in case it could be.

-- 
Thanks,
Maxim

bug#66866: aarch64 system cross compilation + pinebook pro image broken?

[Mathieu Othacehe]

Hello,

I can reproduce the error by running:

--8<---cut here---start->8---
./pre-inst-env guix system build --target=aarch64-linux-gnu 
gnu/system/images/pine64.scm
--8<---cut here---end--->8---

which cause an issue in gawk-mesboot:

--8<---cut here---start->8---
checking host system type... Invalid configuration `aarch64-linux-gnu': machine 
`aarch64' not recognized
configure: error: 
/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash 
./config.sub aarch64-linux-gnu failed
--8<---cut here---end--->8---

Janneke, do you know what could have caused this regression?

Thanks,

Mathieu